Solved sendmail throwing "aaa@bbb... Deferred: Name server: xxx.: host name lookup failure"

Hi all,

My sendmail on FreeBSD 11.2-RELEASE-p9 is relaying mail to my internal Exchange server and is refusing to forward mail when one of the TO addresses has an invalid domain.

The mail has many recipients, including a valid one on my Exchange server. According to tcpdump, SMTP succeeds with MAIL FROM and RCPT TO, and proceeds to send the headers. As it iterates through the additional recipients, sendmail on FreeBSD does a name lookup on each one (trying AAAA, A, and MX records additionally with search domain permutations to each of the sendmail host's name servers) and when it fails (because the sender mistyped the additional recipient's addresses) it returns the error:

"aaa@bbb... Deferred: Name server: xxx.: host name lookup failure"

It's a misleading message as the "xxx" server mentioned (which is my Exchange server) is not actually any of the nameservers on which it fails (because it's not a DNS server).

Anyway, the question is: is there a way to turn off this function in sendmail?

NB: FEATURE(accept_unresolvable_domains) does not work (I think it only applies to the MAIL FROM header).
Adding the domain bbb to /etc/hosts doesn't work as it seems sendmail does not check it.
 
How did you set up that relay? Because if Exchange is the main MTA then a logical approach would be to use smarthost, and if you use that then Sendmail normally doesn't bother to check the validity of the recipients. That's for the smarthost to sort out.
 
Hi,

the Exchange server is really a stub - it uses the FreeBSD sendmail server as a smarthost, so I can't configure a smarthost on sendmail. I'm really trying to find the right knob on sendmail that prevents domain lookups for recipients.

Thanks,
Scott
 
Anyway, the question is: is there a way to turn off this function in sendmail?

Yes. I remember having used that when I did not yet have a persistent internet connection, so DNS not always available (but that was 20 years ago). In my paperwork I find this one mentioned:

Code:
        FEATURE(`nocanonify', `canonify_hosts')

Considering Your issue, it appears to me that in Your case the mail should be delivered to all functional adresses, and only the broken ones held back (and returned to sender after some delay). One should find out why this does not happen in Your case (if it doesn't happen), as this would be the normal behaviour as I always experienced it. Anyway, the mentioned option seems to disable this DNS-lookup entirely.

A different approach in order to force a sensible behaviour might be to remove the 'm' flag from the mailer definition. Then every adressee would be delivered a separate instance of the mail, and only the broken ones should be held back. (Depending if this is feasible from bandwidth considerations.)

NB: FEATURE(accept_unresolvable_domains) does not work (I think it only applies to the MAIL FROM header).

My docs also recommend this one; they say it is necessary when receiving mail while outbound-DNS is down. So You're probably right, it is about the sending address.
 
Considering Your issue, it appears to me that in Your case the mail should be delivered to all functional adresses, and only the broken ones held back (and returned to sender after some delay). One should find out why this does not happen in Your case (if it doesn't happen), as this would be the normal behaviour as I always experienced it. Anyway, the mentioned option seems to disable this DNS-lookup entirely.

Thanks for replying. Note that my sendmail server is not forwarding to all of the TO addresses, rather just the single envelope recipient (which is a valid recipient on my Exchange server). The email in question has 20 or so people in the TO field. My user, who has a mailbox on my Exchange server, is just one of those. So my sendmail is only relaying to one RCPT TO. However it appears to be doing some due diligence: it is verifying that other people to whom the email is also sent (presumably by the sender's MTA) are valid.

Scott
 
Thanks for replying. Note that my sendmail server is not forwarding to all of the TO addresses, rather just the single envelope recipient (which is a valid recipient on my Exchange server). The email in question has 20 or so people in the TO field. My user, who has a mailbox on my Exchange server, is just one of those. So my sendmail is only relaying to one RCPT TO. However it appears to be doing some due diligence: it is verifying that other people to whom the email is also sent (presumably by the sender's MTA) are valid.

Oha! This is again something different. I just tried it out: feed some mail into sendmal with a proper destination and a bunch of bogus in the To: field. That mail gets straightly delivered to the destination with no complaints whatsover; the bogus To: fields seem not to matter.

And: yes, all of the bogus appear in the resolver log of my DNS.
But this seem not to stop the delivery.

These DNS lookups happen because, for instance, I am using different hostnames in the LAN than those that should be visible in outgoing mail. So, on each (outgoing) mail all the addresses (to: , From:, Sender:, etc.etc.) must be checked for substitution - and for this to work they must be made fully-qualified. This is not just "due diligence", it has it's practical purpose.

Lets ask something else: do You have a properly configured fully namespace-aware DNS, i.e. one that will on an unresolvable Hostname immediatey answer with NXDOMAIN - or does it go astray and end up in some timeout or other failure (like some DNS do, for whatever reason)?
Considering the wording, a nonexistant hostname is not a "failure", it's a "not found":

Code:
$ host bogus.wei.wedwsy
Host bogus.wei.wedwsy not found: 3(NXDOMAIN)

Maybe You just have to fix the DNS.
 
PMc

Thanks for the reply. It does indeed to appear to be DNS related.

When I telnet to my sendmail server and hand type the mail, it happily accepts the mail:

Code:
250 2.0.0 x3TEAGT5059622 Message accepted for delivery

But then the mail sits in /var/spool/clientmqueue. Looking at the q file I see the same issue:

Code:
Mhost map: lookup (barwidgeelavender.com.au): deferred
(The leading M is part of the queue file).

Interestingly sendmail didn't do the A/AAAA/MX lookup of barwidgeelavender.com.au during submission, rather when it attempted to relay the mail to the MX record of the RCPT recipient.

The A record lookup in tcpdump for the domain resulted in a ServFail:

Code:
00:15:37.771221 IP sendmail.44831 > dns.domain: 15892+ A? barwidgeelavender.com.au
00:15:37.812092 IP dns.domain > sendmail.44831: 15892 ServFail 0/0/0

I think the issue is actually that the nameserver responsible for barwidgeelavender.com.au
is down and so recursive lookups fail:
Code:
# dig @1.1.1.1 -t A barwidgeelavender.com.au

; <<>> DiG 9.14.1 <<>> @1.1.1.1 -t A barwidgeelavender.com.au
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48259
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;barwidgeelavender.com.au.      IN      A

;; Query time: 77 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Apr 30 00:27:00 AEST 2019
;; MSG SIZE  rcvd: 53

According to WHOIS, there are various nameservers for that domain, but they either return no answer or REFUSED.

Can you try again using your earlier test but including aaaa@barwidgeelavender.com.au in the list of To: addresses?

In any case, the domain still breaks sendmail and I still need to turn off the behaviour of validating To: headers (I can understand envelope validating but not the contents).

Thanks,
Scott
 
Aye, You're right, here are problems...

But then the mail sits in /var/spool/clientmqueue. Looking at the q file I see the same issue:

Code:
Mhost map: lookup (barwidgeelavender.com.au): deferred
(The leading M is part of the queue file).

Yepp, same here.

Interestingly sendmail didn't do the A/AAAA/MX lookup of barwidgeelavender.com.au during submission, rather when it attempted to relay the mail to the MX record of the RCPT recipient.

That may depend on how the queueing behaviour is configured.

Can you try again using your earlier test but including aaaa@barwidgeelavender.com.au in the list of To: addresses?

Alright, I typed it in on the desktop, destined to a user on my gateway machine. The desktop sendmailer just passed it onwards normally, and there were no DNS lookups, BUT, as I see now, my desktop has this one still configured:
FEATURE(`nocanonify', `canonify_hosts')

Then. on the gateway machine it does not look so good:
Code:
Apr 29 18:08:49 <mail.info> gate sm-mta[56241]: x3TG8nYO056241: from=<pmc@disp.***********>, size=425, class=0, nrcpts=1, msgid=<201904291605.x3TG5KIK037155@disp.****************>, proto=ESMTP, daemon=MTA, relay=disp.*************** [**.**.**.**]
Apr 29 18:09:09 <mail.crit> gate sm-mta[56303]: x3TG8nYO056241: SYSERR(root): timeout writing message to local
Apr 29 18:09:09 <mail.info> gate sm-mta[56303]: x3TG8nYO056241: to=<pmc@gate************>, delay=00:00:20, xdelay=00:00:04, mailer=local, pri=120425, relay=local, dsn=4.4.2, stat=Deferred: Name server: local: host name lookup failure

And the nameserver says:

Code:
Apr 29 18:09:08 <local0.info> gate named[2004]: lame-servers: info: REFUSED unexpected RCODE resolving 'barwidgeelavender.com.au/A/IN': 113.52.144.43#53
Apr 29 18:09:08 <local0.info> gate named[2004]: lame-servers: info: REFUSED unexpected RCODE resolving 'barwidgeelavender.com.au/A/IN': 113.52.144.41#53
Apr 29 18:09:08 <local0.info> gate named[2004]: query-errors: info: client @0x2d1d9000 ************#58556 (barwidgeelavender.com.au): view infra: query failed (failure) for barwidgeelavender.com.au/IN/A at query.c:6710
Apr 29 18:09:08 <local0.info> gate named[2004]: query-errors: info: client @0x2cc97800 ************#19061 (barwidgeelavender.com.au): view infra: query failed (SERVFAIL) for barwidgeelavender.com.au/IN/A at query.c:6068
Apr 29 18:09:09 <local0.info> gate named[2004]: lame-servers: info: REFUSED unexpected RCODE resolving 'barwidgeelavender.com.au/MX/IN': 113.52.144.43#53
Apr 29 18:09:09 <local0.info> gate named[2004]: lame-servers: info: REFUSED unexpected RCODE resolving 'barwidgeelavender.com.au/MX/IN': 113.52.144.41#53
Apr 29 18:09:09 <local0.info> gate named[2004]: query-errors: info: client @0x2cc97800 ***********#23904 (barwidgeelavender.com.au): view infra: query failed (failure) for barwidgeelavender.com.au/IN/MX at query.c:6710
Apr 29 18:09:09 <local0.info> gate named[2004]: query-errors: info: client @0x2d1d9c00 ***********#10677 (barwidgeelavender.com.au): view infra: query failed (SERVFAIL) for barwidgeelavender.com.au/IN/MX at query.c:6068

In any case, the domain still breaks sendmail and I still need to turn off the behaviour of validating To: headers (I can understand envelope validating but not the contents).

As I wrote before, You may try the FEATURE(`nocanonify', `canonify_hosts') option.

Furthermore, when searching for the creepy SYSERR(root): timeout writing message to local that just appeared in my logs, I find this thread here, concerning the very same problem. And there is also a remedy given by trev - which seems to do a similar thing, but for local delivery.
Furthermore, I find this discussion which also circles the same issue.

That should now give You enough material to decide on Your solution.
 
Thanks PMc,

Turning on FEATURE(`nocanonify', `canonify_hosts') worked, although it broke my mail hub function (as non-qualified recipients were no longer qualified/canonified). I fixed this my making my server treat mail sent to the hub locally.

The other option of define(`confDIRECT_SUBMISSION_MODIFIERS', `C')dnl seemed inappropriate as I do not send mail directly on the command line, which is how I understand that option works.

Scott
 
The other option of define(`confDIRECT_SUBMISSION_MODIFIERS', `C')dnl seemed inappropriate as I do not send mail directly on the command line, which is how I understand that option works.

No. It applies when you receive email with an unresolvable domain otherwise -- as I noted in the thread mentioned above -- the email is not delivered to valid recipients on your mailserver and languishes in the queue without this option in the submit.mc file. What it does is as per my comment:

# Line below fixes unresolvable domains encountered when delivering
# email locally (after having been accepted by smtp).
# C = Don't perform hostname canonification.

I spent a fair amount of time figuring this out at the time, but all I now recall is as per the comment above. Alas, none of us is getting any younger...
 
Back
Top