0

I previously resolved an issue with upstream timeout errors by changing the nameservers in my resolv.conf to Google's nameservers.

While the upstream timeout and 504 errors were sorted by doing this, now sendmail refuses to "sendmail".

Testing sendmail with:

echo "Subject: test" | /usr/lib/sendmail -v UncleStanley@re****mail.com

UncleStanley@re****mail.com... Connecting to [127.0.0.1] via relay...
220 sd-2***8.de**ox.ro ESMTP Sendmail 8.14.4/8.14.4/Debian-4; Mon, 7   Sep 2015 05:16:37 +0200; (No UCE/UBE) logging access from: localhost(OK)-localhost [127.0.0.1]
>>> EHLO sd-2***8.de**ox.ro
250-sd-2***8.de**ox.ro Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5
250-DELIVERBY
250 HELP
>>> VERB
250 2.0.0 Verbose mode
>>> MAIL From:<root@sd-2***8.de**ox.ro> SIZE=14 AUTH=root@sd-2***8.de**ox.ro
250 2.1.0 <root@sd-2***8.de**ox.ro>... Sender ok
>>> RCPT To:<UncleStanley@re****mail.com>
>>> DATA
250 2.1.5 <UncleStanley@re****mail.com>... Recipient ok
354 Enter mail, end with "." on a line by itself

. 050 ... Connecting to [smtp-server] via relay... 050 ... aliased to o****extr 050 o****extr... Connecting to local... 050 o****extr... Sent 250 2.0.0 t873Gbx9003582 Message accepted for delivery [email protected]... Sent (t873Gbx9003582 Message accepted for delivery) Closing connection to [127.0.0.1] QUIT 221 2.0.0 sd-2***8.de**ox.ro closing connection

Now I suppose that would seem okay. The mail was sent but it isn't, as the message has not been sent.

In the mail.info log I have found

Sep  7 05:49:27 sd-28368 sendmail[4020]: t873nRpj004020: from=root, size=14, class=0, nrcpts=1, msgid=<201509070349.t873nRpj004020@sd-2***8.de**ox.ro>, rel$
Sep  7 05:49:27 sd-28368 sm-mta[4021]: t873nR8I004021: from=<root@sd-2***8.de**ox.ro>, size=307, class=0, nrcpts=1, msgid=<201509070349.t873nRpj004020@sd-2$
Sep  7 05:49:27 sd-28368 sm-mta[4021]: t873nR8I004021: to=<UncleStanley@re****mail.com>, ctladdr=<root@sd-2***8.de**ox.ro> (0/0), delay=00:00:00, xdelay=00:00:00,$
Sep  7 05:49:27 sd-28368 sm-mta[4021]: t873nR8I004021: t873nR8J004021: DSN: Host unknown (Name server: [smtp-server]: host not found)
Sep  7 05:49:27 sd-28368 sm-mta[4021]: t873nR8J004021: to=o****extr, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30000, dsn=2.0.0, stat=Sent
Sep  7 05:49:27 sd-28368 sendmail[4020]: t873nRpj004020: to=UncleStanley@re****mail.com, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=300$

DSN: Host unknown (Name server: [smtp-server]: host not found)

Now after a bit of reading I have learned that I may use an external stmp-server.

But my thing is I did not have to do any of that before I was forced to change the nameservers in resolv.conf.

I'm sure that there is probably something very simple that I am missing but I cannot find a solution anywhere. Does anyone know how to solve this issue?

My resolv.conf is below:

domain on****.net
search on****.net
nameserver 62.265.16.6
nameserver 62.265.16.7

The IP addresses in the above resolv.conf, aren't the IP addresses issued with the server. They have been edited.

8
  • I don't see the contents of your resolv.conf here. What did you put in it? Sep 7, 2015 at 10:01
  • By any chance was your original resolv.conf pointing to local nameservers? Ones that might have an RR for 'smtp-server'? And did you transfer your 'search' directives to the new resolv.conf? Sep 7, 2015 at 10:08
  • Is the log entry with the DSN in any way redacted, or is smtp-server what the error message actually says?
    – Jenny D
    Sep 7, 2015 at 10:12
  • I have included the original resolv.conf, but edited the ip addressees. I had not altered the messages from the log in any way.
    – Adrian
    Sep 7, 2015 at 10:50
  • 2
    Those are not valid IP addresses. And even if they were valid, they are probably not Google nameservers. Please do not obfuscate anything if you can possibly avoid it. Sep 7, 2015 at 11:19

0

You must log in to answer this question.

Browse other questions tagged .