Hi
Please can you help on this: the Net Admins decided to use DNS to resolve names, so this is preventing mail being delivered when using commands like
date | mailx -s "test" abc.xyz@asdf.xx.yy
.
What we were asked was to edit
/etc/resolv.conf
and add 3 entries, in all servers
Normally a network admin task, however not a terribly complex one...
simply add a nameserver entry for the DNS hosts in use (or a search pragma for local domains )
eg.
search asdf.xx.yy xx.yy
nameserver 10.0.0.59
nameserver 192.168.1.59
or you can indicate a local domain by setting the env variable LOCALDAOMAIN, eg...
export LOCALDOMAIN="$LOCALDOMAIN asdf.xx.yy"
May be I did not express myself correctly. what is happening is ever since the net Admin decided to use DNS to resolve names, the
mailx
command is not working anymore, so the servers are not sending email alerts to administrators
You are absolutely right, you did not express yourself correctly. Even after the second attempt, I'm not sure what you want/need.
When net admins decide to modify essential services, they also should take care of the ramifications, i.e. set up the entire system / domain so it works correctly after their m...aintenance. But even if they introduced DNS, you still could use the hosts (i.e. files) name resolution option. Or, just for test purposes, you could mail to the user@numericalIP.
Ok, before I was asked to edit
/etc/resolv.conf
and add some entries, I was able to use the
mailx
command from any server to send email from servers to myself and other people. But now I am not able to send emails from any server
So your MTP (probably sendmail if you don't know which transfer program your using) cannot resolve the asdf.xx.yy domain.
Can you do the following
telnet asdf.xx.yy 25
ehlo
MAIL FROM:<fretagi@this.host>
RCPT TO:<abc.xyz@asdf.xx.yy>
DATA
This is a test mail, did I get it.
.
quit
If not, at what point does it fail?
this is it:
? mail from: fretagi@this.host
Subject: test
rcpt to : abc.xyz@asdf.xx.yy
test3, test 4
.
EOT
? from:... List:; syntax illegal for recipient addresses
/dead.letter... Saved message in /dead.letter
I realise that I'm joining this thread very late but you say "mailx command is not working anymore, so the servers are not sending email alerts to administrators". So presumably your user community is still able to use email otherwise they would all be complaining? You are saying that emails to sysadmins aren't working because their domain address(es) are not being resolved?
If that is the case then you have two options:
In generic Unix terms, OS's (and you didn't say which OS this is) will look in /etc/hosts for name resolution before resorting to DNS. Therefore, by inserting IP addresses in /etc/hosts you can catch it early and resolve the name within the system.
If I've still misunderstood the issue please explain further.
on the
/etc/hosts
of the servers, I have inserted
10.100.48.11 prep01.headquarter.tmm
as instructed by the DNS admin, but unfortunately if I run the
mailx
command in this server, I do not get mail from it
I'm joining this thread even later than my learned friend hicksd8, so apologies for that.
Do you get any errors at all? I'm thinking of it failing to connect and leaving a dead.letter file, return e-mail to the sending account, mail stuck in the mail queue (use mailq to see this)
If it is all clear, then see if you can try sendmail -v target.user@domain.name
It will just sit at a prompt, but you can type some simple message and then a line just containing a full-stop . to end the text.
My sanitised session looks like this. I type the parts in green:-
$> sendmail -v robin@mydomain.somewhere
Hello from the unix server.
.
robin@mydomain.somewhere... Connecting to my-relay-01.internal.domain. via relay...
220-SMTP Relay
220 Warning: no name found in DNS for your host address
>>> EHLO my.unix.server.domain
250-unix.server.domain
250-SIZE 0
250-ETRN
250-ENHANCEDSTATUSCODES
250-DSN
250-VRFY
250-AUTH
250 8BITMIME
>>> MAIL From:<ROBIN@my.unix.server.domain> SIZE=28
250 2.0.0 ROBIN@my.unix.server.domain OK
>>> RCPT To:<robin@mydomain.somewhere>
250 2.0.0 robin@mydomain.somewhere OK
>>> DATA
354 Ready for data
>>> .
250 2.0.0 Message received OK
robin@mydomain.somewhere... Sent (2.0.0 Message received OK)
Closing connection to my-relay-01.internal.domain.
>>> QUIT
221 2.0.0 unix.server.domain closing
$>
If you get a train of output like this and without errors, then you can be happy that the mail is leaving your unix server. You will then need to talk to whomever manages the mail relay server. There can be filtering in place to prevent spam generation and you may be getting caught in that. Some companies only allow mail from recognised systems.
I hope that this helps,
Robin
Hi
this is what I get when I run the
sendmail
command:
sendmail -v fretagi@mydomain.com
Hello from the unix server.
.
/dead.letter... Saved message in /dead.letter
I am not sure what dead.letter means