Sendmail mailq filling with lookup errors

[support_5]

Dear all,

Since upgrading to Sendmail 8.11.1 we have experienced some mail with the following error:

host map: lookup

: deferred

DNS is obviously working sort of OK as most mail is happily delivered and sendmail -vq clears the queue. When I run:

/usr/sbin/sendmail -bv -v -oL10 address [address...]

I get a Name Server Timeout error. I have unsuccessfully tried this solution:

FEATURE(`nocanonify', `canonify_hosts')dnl

I also have tried to comment out the section of the sendmail.cf file:

Pass to name server to make hostname noncanonical.

This does not work for me either. I get a messy mailstorm.

The solution was to restart the named daemon on our DNS forwarder.

I hope this solution is useful to other people as I have worked it out from the hard work of other users.

The attachment I have included shows how to accept mail for three domains and use a genericstable to change the from domain of senders.

Cheers,

Damian Hickey

[Christopher Caldwell · Accepted solution]

Are the lookup problems for domains you control (your DNS) or for a generally random sampling of external domains?

If you're having problems with external lookups, what's your Internet connectivity look like?

If you're having problems with internal lookups, make sure forward and reverse lookups work for all of the names (and MX's) in question.

I [generally] run a caching only name server on all of my sendmail hosts - folks used to try to get you to split DNS from other features due to memory or processing constraints, but with today's memory, OS, and processing power, I don't think separating the two makes much sense.

sendmail relies heavily on DNS in part to make sure you aren't getting spammed and in part to make sure the right thing happens with delivery and address rewriting.

With your original .cf, if the mail is eventually gets delivered (via sendmail -q or through the normally periodic processing of the queue), that tells me that there's a timing issue with DNS lookups.

[support_5]

Christopher,

You are quite right. We had a malfunctioning DNS forwarder.

I put up my reply as I think several people have had this issue.

Cheers,

Damian Hickey