3

We've noticed an occasional repeatable problem in our sendmail config. The scenario is we receive a message from the internet with one of our users in the To: list, and one of the other users in the To: list has a domain with a DNS problem. In this case, sendmail gets a DNS error on the bad address, and exits with "host name lookup failure", so the message gets stuck in our queue for a few days, and never delivers to the recipient on our system.

As an example, if I send a message with this To: line:

  To: cheeks@swcp.com, bubbatest@lovelacesandia.com

swcp.com is a local domain handled by this server, and "cheeks" has a local alias pointing to "cheeks@ebi2". lovelacesandia.com is a non-local domain with a problem (currently all queries to it result in SERVFAIL). The originating mailer probably has a copy of this message stuck in their own queue, because they can't reach lovelacesandia.com either. The copy of the message that is stuck in my queue only has one recipient:

RPFDA:cheeks@ebi2

Here is the output of "sendmail -v -d8-9.5 -qRcheeks"

Running /var/spool/mqueue/t7QHX1uB080255 (sequence 1 of 1)
host_map_lookup(swcp.com) => dns_getcanonname(swcp.com, trymx=1)
dns_getcanonname: trying swcp.com. (AAAA)
dns_getcanonname: trying swcp.com. (A)
dns_getcanonname: swcp.com
FOUND swcp.com
host_map_lookup(swcp.com) => CACHE swcp.com
host_map_lookup(ebi2) => dns_getcanonname(ebi2, trymx=1)
dns_getcanonname: trying ebi2.swcp.com (AAAA)
dns_getcanonname: trying ebi2.swcp.com (A)
dns_getcanonname: ebi2.swcp.com
FOUND ebi2.swcp.com
host_map_lookup(swcp.com) => CACHE swcp.com
getmxrr([ebi2.swcp.com], droplocalhost=1)
dns_getcanonname(ebi2.swcp.com, trymx=0)
dns_getcanonname: trying ebi2.swcp.com. (AAAA)
dns_getcanonname: trying ebi2.swcp.com. (A)
dns_getcanonname: ebi2.swcp.com
cheeks@ebi2... Connecting to ebi2.swcp.com. via smtp...
220 ebi2.swcp.com ESMTP Sendmail 8.15.1/8.14.9; Wed, 26 Aug 2015 11:44:59 -0600 (MDT)
>>> EHLO ame1.swcp.com
250-ebi2.swcp.com Hello ame1.swcp.com [216.184.2.118], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 100000000
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP
>>> STARTTLS
220 2.0.0 Ready to start TLS
>>> EHLO ame1.swcp.com
250-ebi2.swcp.com Hello ame1.swcp.com [216.184.2.118], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 100000000
250-DSN
250-ETRN
250-AUTH PLAIN LOGIN
250-DELIVERBY
250 HELP
>>> MAIL From:<cheeks@swcp.com> SIZE=1672
250 2.1.0 <cheeks@swcp.com>... Sender ok
host_map_lookup(ebi2.swcp.com) => dns_getcanonname(ebi2.swcp.com, trymx=1)
dns_getcanonname: trying ebi2.swcp.com. (AAAA)
dns_getcanonname: trying ebi2.swcp.com. (A)
dns_getcanonname: ebi2.swcp.com
FOUND ebi2.swcp.com
>>> RCPT To:<cheeks@ebi2.swcp.com>
>>> DATA
250 2.1.5 <cheeks@ebi2.swcp.com>... Recipient ok
354 Enter mail, end with "." on a line by itself
host_map_lookup(swcp.com) => CACHE swcp.com
host_map_lookup(swcp.com) => CACHE swcp.com
host_map_lookup(lovelacesandia.com) => dns_getcanonname(lovelacesandia.com, trymx=1)
dns_getcanonname: trying lovelacesandia.com. (AAAA)
dns_getcanonname: trying lovelacesandia.com. (A)
dns_getcanonname: trying lovelacesandia.com. (MX)
dns_getcanonname: trying lovelacesandia.com.swcp.com (AAAA)
FAIL (2)
lovelacesandia.com: Name server timeout
timeout writing message to ebi2.swcp.com.
cheeks@ebi2... Deferred: Name server: ebi2.swcp.com.: host name lookup failure
Closing connection to ebi2.swcp.com.

This is with Sendmail 8.15.1 on FreeBSD 10.1. I suspect this condition has existed a long time, but we only recently diagnosed it. Most of the messages that fit this scenario turn out to be spam so nobody cares. But occasionally someone sends mail to a large-ish list of people (without using BCC) and one of the addresses has gone bad.

If we were involved in trying to deliver to the bogus address, I would understand why we had a problem. What I don't get is why my sendmail cares about a bogus address in the header To: which we are not going to attempt delivery for.

We have these FEATUREs which I thought might be involved:

FEATURE(blacklist_recipients)
FEATURE(`delay_checks', `friend', `n')

I've done tests with them both removed, and get the same result.

If anybody has any ideas about what causes this, or how to mitigate it, I'd appreciate it. Thanks,

Mark

0

With some rlytest experiments, sendmail is not touching header recipients; however, in your case the bad domain must have been a recipient, as otherwise the address will not be run through the lookup wringer? Since sendmail will tempfail anything destined to a domain that returns SERVFAIL, a milter is regardless your best bet; configuring milter-regex is one option:

dnl for sendmail.mc
INPUT_MAIL_FILTER(`milter-regex', `S=unix:/var/spool/milter-regex/sock, T=S:30s;R:2m')dnl

And with that daemon running and using that socket file, a milter-regex.conf along the lines of:

discard
envrcpt /@lovelacesandia\.com>/i

A complicating factor will be if these messages are being delivered directly to the sendmail binary as the Mail Submission Agent, in which case the submit.cf configuration will need to be altered to call a milter, or instructed to not do domain lookups and instead funnel everything off to the main Mail Transport Agent, which can then do the discard if necessary.

  • Thanks for your answer. I thought sendmail would only process the envelope recipients, I didn't realize it would do DNS lookups for the header items in the "data" payload. I'll consider whether to try dealing with this in a milter, or just live with the current situation. In a milter, I assume I'd have to process this in xxfi_header? – Mark Costlow Sep 4 '15 at 0:24
  • The bad domain is probably a RCPT, somehow, so I'd expect it to be in xxfi_envrcpt. If not, a full header check would be necessary. – thrig Sep 4 '15 at 21:43
0

I was hit by this problem too.

After a while of searching, one possible workaround is to use this snippet in sendmail.mc:

FEATURE(`nocanonify', `canonify_hosts')
CANONIFY_DOMAIN(`$=m')

This might have side effects, as detailed in the docs, and I am not entirely sure, if it is the best solution to the problem. But it works for now.

  • I did end up using FEATURE(nocanonify, canonify_hosts) and have not run into any bad side effects. (I do not have CANONIFY_DOMAIN in there for what it's worth) – Mark Costlow Jun 6 '18 at 16:40
  • 1
    Right. That's basicly, where I am now too. TBH I haven't fully understood the documented side effects. What I do think: Most modern users of mail use fully qualified, usually canonical domains in their headers, so the canonification isn't that important these days any more. – Elrond Jun 7 '18 at 11:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.