4

We've got a linux server running sendmail that relays email through our primary mail server, but ever since a change of DNS servers last week, it's been timing out connecting to our mail server. Upon further investigation, /var/log/maillog shows lines like the following, incl. the incorrect IP address for the mail server:

Apr  4 15:37:32 yip sendmail[20583]: p34JVgLE020540: to=<user@domain.tld>, ctladdr=<root@host.domain.tld> (0/0), delay=00:05:50, xdelay=00:02:00, mailer=esmtp, pri=258071, relay=mailserver.domain.tld. [xxx.xxx.xxx.xxx], dsn=4.0.0, stat=Deferred: Connection timed out with mailserver.domain.tld.

Now, we had updated the linux server's DNS servers last week along with the migration by editing /etc/resolv.conf. Running dig mailserver.domain.tld, host mailserver.domain.tld, or nslookup mailserver.domain.tld on the linux server all result in the correct IP address being returned. Where could sendmail be getting/caching the incorrect IP address and how can I resolve that issue?

morgant
  • 1,470
  • 6
  • 23
  • 33

3 Answers3

5

sendmail does cache information about a host's status before reconsulting DNS. Tweaking Timeout.hoststatus can change this, but then again restarting sendmail for your particular case is the way to go (instead of waiting for the timeout to expire).

adamo
  • 6,925
  • 3
  • 30
  • 58
  • Thanks, very good to have confirmation of what I was seeing (and how to adjust in the future, if needed). – morgant Apr 05 '11 at 11:18
  • 1
    The default timeout setting for TO_HOSTSTATUS is 30 minutes. Normally this is ok, but some mail providers (like Message Labs) rotate the IPs of their mail servers frequently as an antispam measure. These means that Sendmail may be up to 30 minutes out of date with its IP address for the remote mail host. From what I can tell, the TTL of the DNS records is NOT taken into account in Sendmail's caching. – Doug Luxem Mar 22 '13 at 21:11
2
  • Restart sendmail.
  • Restart nscd (if it's in use on the system).

Also make sure you have the correct MX record entries. Sendmail relies on the MX lookup.

Try dig mx domain.tld and see if that results in the correct host. If not, you can force sendmail to deliver mail destined for a particular domain using the mailertable file typically found in /etc/mail/.

A typical mailertable entry looks like:

xxx.com esmtp:[192.168.1.2]

Where "xxx.com" is the domain and the IP for delivery is explicitly stated.

ewwhite
  • 197,159
  • 92
  • 443
  • 809
  • I had used `dig -t MX domain.tld` to verify the MX record matched the hostname of the mail server in question. A restart of `sendmail` using `/etc/init.d/sendmail restart` seemed to resolve the issue and mail started flowing. Any idea why `sendmail` would've held onto the old IP for so long? – morgant Apr 04 '11 at 21:36
  • 1
    @morgant: If you actually changed DNS servers (their addresses, as opposed to their contents), *that* information is cached from `/etc/resolv.conf` by libc the first time the resolver is invoked. – geekosaur Apr 05 '11 at 19:15
  • That explains it. Yes, the DNS server changed and the former DNS server was dishing out old IPs, so it was still querying against the old server. – morgant Apr 06 '11 at 02:15
1

Sendmail doesn't do any caching itself, it relies on the local name server.

There's a couple of things that are worth checking, though you'll probably of done them already:

  • Check /etc/hosts has no entries for the relay server, that'll take precedence over DNS
  • Check the Sendmail resolver options to see if it's actually set to use DNS
  • Ensure /etc/resolv.conf is only pointing to updated DNS servers, and 1 of them isn't still returning the old value. Do this manually by running nslookup and entering "server 1.2.3.4" for each DNS server, remember it could return 2 different IPs on repeat queries if it's set to have duplicate entries. I've seen this plenty of times.

I know they're all pretty basic, but it's easy for a very rushed admin to make a simple mistake like one of these.

Ewan Leith
  • 1,705
  • 8
  • 7
  • `/etc/mail/sendmail.cf` had no entry for `ResolverOptions`, so it was relying on the defaults (I'm unsure whether that'd include `DNSRCH`, but I'd assume so). I had used `dig @server mailserver.domain.tld` to verify that each of the DNS servers in `/etc/resolve.conf` was dishing out the correct IP. – morgant Apr 04 '11 at 21:34
  • yes the default includes DNSRCH. – Ewan Leith Apr 06 '11 at 10:12