neither is Windows but somebody did that for you.

2 members found this post helpful.

is that for both the powershell and bash examples ? is that who you are expecting to be identified as ?

is <> even an allowed sender address. does that mean no-one can reply to you ? i wouldve thought that most mail transport agents would reject that email address automatically assuming you are a mass spammer.

your responses seems uncomprehensive and purposely obtuse.

1 members found this post helpful.

I think s/he means the address is in those pointy brackets, not that they are alone, i.e. <myaddress@google.com>

1 members found this post helpful.

Progress! We need to see the contents of those emails...it will tell us why the message failed! just post one of the messages you see via cat

1 members found this post helpful.

When the sender (From: ) is identified as <>, the email is a BOUNCE message from either the sending MTA or the receiving MTA. No, the email cannot be replied to.
It would be contrary to the RFC to reject email From: <> I tend to delete it when it's To: a non-existent user, because it is the result of a forged From: on some spam sent from some other server. However, when it's To: a real user (customer), then it gets delivered, because it will tell the user why their email didn't work.

Which is why we need to see the emails the OP found in /var/spool/mail -- they will tell us why the email is not being delivered.

1 members found this post helpful.

This is from Putty:

This is the rest:

OK. mailx is using Postfix but postfix has no path to the outside world. The BOUNCEs are from your local MTA:
Your next step is to determine why postfix can't see outside destinations. Note that in a corporate environment, that may be intentional. Back in the day, I once had a requirement to download and install software to a server that didn't have internet access. I had to d/l onto my windows desktop, then sftp to the server from there. That doesn't help you, however.

It is possible that you can configure the users email (in ~/.mailrc) to use the mail server that does have access to the internet, but you'll need to discuss that with the server's administrator and/or the corporate security folks. They'd also be the ones to configure the server to have internet access.

Please let us know what you find out.

1 members found this post helpful.

are you sure it is working for regular email ?:
it seems to be timing out for both regular email and text fone-numbers.

1 members found this post helpful.

As I recall, the OP said it was working for regular email destinations within his network.
We suggested testing with a destination outside the network, and those, like email to vtext.com, did not work.

That condition can make sense in a corporate network, where "internal" servers are often behind one or more firewalls with all access to the "outside" cut off.

It should be possible to configure the server to use the corporate MTA that is connected to the world, but I suspect the OP would need to get permission, and maybe help, to do that.

2 members found this post helpful.

Quick question kinda outside the scope of this issue........what does OP stand for?

Original Post or Original Poster depending on context.

1 members found this post helpful.

I see you got an answer...I was going to reply with "you"

Any thoughts about my thoughts in #53 ?

I was trying to find "~/.mailrc" to make some 'adjustments' but could not find it. Is it at the same path in every distro ?

It probably doesn't exist if there has been no customization of email usage at the user level. I don't have one for either my personal account or the superuser account, yet mailx works for me to send email from both. But then, my server's not behind a corporate firewall.

Again, I think you, as a DBA, (right?), are going to have to discuss your issue with the server's admin, to see what it takes to send email to the world from that server. [That's the issue...sending email. If/when you can send email to vtext.com, you will get your messages on your phone.] Don't be surprised if you're told "Not going to happen" -- that server is [I presume] your Oracle database server, and therefore contains proprietary data and is cut off from the world for some very good reasons.

If that happens, consider sending the email to your corporate mailbox, then putting a filter there to forward the email to your phone@vtext.com. Use something unique in the subject to trigger that forward. Just an idea.

1 members found this post helpful.