Sendmail: mailq, lookup deferred?

[Catherine Pinatiello]

Sendmail has spontaneously decided to queue mail to certain domains rather than sending them, apparently because of a name server timeout. This is bogus, because when I do an nslookup or traceroute, the name servers resolve just fine. Furthermore, after I have done the nslookup or traceroute, mail can be sent to those domains on a flush of the queue (for a short time). If I try to flush the queue before doing the manual nslookup or traceroute, the mail just sticks with "name server timeout".

I don't know why this would suddenly start happening, what is causing it, or how to fix it. We tried to forward through another machine as a relay, sending mail through their server instead of ours, but it still sticks. Apparently sendmail does some sort of lookup BEFORE forwarding the mail to another server to be sent! So I can't even fix it THAT WAY.

We are on a redhat 7.2 machine running sendmail 8.11.6 - what the heck is wrong here? :(

[Stuart Browne]

Are you running a local DNS server?

What's the contents of your /etc/resolf.conf ?

When you do an 'nslookup', are you querying the DNS for an MX target (i.e. nslookup -q=mx domain.com) ?

When it happens, try forcing the queue in Verbose mode(/usr/lib/sendmail -v -q), and see what errors come up.

[Catherine Pinatiello]

I found out that the problem had something to do with the dns server configuration on the destination servers. Apparently they were not returning a reverse lookup or an MX record or whatever, that sendmail interprets as a SERVFAIL. So I had to recompile sendmail.cf with the entry:

FEATURE(`nocanonify', `canonify_hosts')dnl

and then it would send mail to these domains.

[support_5]

For HPUX, this may be caused by an nfile value that is too low.

[Steven E. Protter]

Also be aware that AOL and other large ISP's validate DNS prior to accepting mail.

sendmail -v -d38.2 youraddress@aol.com

Will show you the dialog.

If the sending domain does not exist, AOL won't take the mail.

Lots of ways around it, especially if you control your own dns server.

[Johan Nielsen]

I had a similar problem on an HP-UX box and it turned out to be a DNS problem. Try set set q=any within the nslookup prompt and make sure the information you get back is valid.

Our problem was corrupt CACHE meaning our what was in memory on our DNS server regarding ROOT servers was corrupt or incorrect. The solution was a different OS (Not NT4) as a DNS server.

Good luck - this can be extremely frustrating.