Sendmail and "reject=451 4.1.8 Domain of sender address xyz@zyx.net does not resolve", A and MX records
Johnny Elliott
resolve"
It seems the latest versions of the sendmail configuration file is set
to check for the sender's domain has an "A" record in DNS. This
doesn't seem correct to me... I feel that if there is a "MX" record
in DNS for the domain portion of the sender address then that should
be sufficent. I made the following change in the proto.m4 file:
From:
Kresolve host -a<_RES_OK_> -T<TEMP>')
To:
Kresolve dns -R mx -a<_RES_OK_> -T<TEMP>')
This check to see if there is a MX record for the domain.
This is not complete as this ONLY checks for MX records. Some sites
don't have a MX record and rely on the A record to for mail
exchanging. (Does sendmail even allow this anymore?) Have to do more
hacking of the proto.m4 file for this though.
What does everyone think?
Johnny Elliott
Jorey Bump
How can you get an MX record for a domain that doesn't resolve?
Claus Aßmann
> It seems the latest versions of the sendmail configuration file is set
> to check for the sender's domain has an "A" record in DNS. This
Wrong. What evidence do you have for this claim?
> doesn't seem correct to me... I feel that if there is a "MX" record
> in DNS for the domain portion of the sender address then that should
> be sufficent. I made the following change in the proto.m4 file:
[omitted, it breaks things]
sendmail looks for an AAAA, A, or MX record (if DNS is available).
--
If you feel the urgent wish to send me a courtesy copy of a Usenet
posting, then make sure it's recognizable as such!
The FAQ: http://www.sendmail.org/faq/ Before you ask.
Villy Kruse
Claus Aßmann <ca+se...@mine.informatik.uni-kiel.de> wrote:
>
>sendmail looks for an AAAA, A, or MX record (if DNS is available).
>
If the DNS servers isn't confident in saying that the A record does not
exist, then further lookup is suspended until the DNS server has found out.
If the A or AAAA record truely does not exist, then a proper functional
DNS server would say so, and the MX record is then looked up.
When you get a reject=451 then it is either the name server doesn't
respond with a definite answer or doesn't respond at all. In either
case it is assumed the name server is just temporarly unavailable.
It could also be because a NS record somwhere refers a zone to a name
server which does not have the full knowlege of that zone. This is
called "lame delegation" and is not uncommon, unfortunately.
Villy
Johnny Elliott
> Johnny Elliott wrote:
> > "reject=451 4.1.8 Domain of sender address x...@zyx.net does not
> > resolve"
>
> > It seems the latest versions of the sendmail configuration file is set
> > to check for the sender's domain has an "A" record in DNS. This
>
> Wrong. What evidence do you have for this claim?
while I was getting the error from sendmail. (Even after a sendmail
restart.)
> > doesn't seem correct to me... I feel that if there is a "MX" record
> > in DNS for the domain portion of the sender address then that should
> > be sufficent. I made the following change in the proto.m4 file:
>
> [omitted, it breaks things]
>
> sendmail looks for an AAAA, A, or MX record (if DNS is available).
Now the 'Kresolve host -a<OKR> -T<TEMP>' seems to be working, with
only a MX record. (bounces.amazon.com is a good example that I've
been using.)
Ok, then what is causing sendmail to have different information than
that being returned by 'dig'. Can the local resolver be cacheing the
infomation? Can sendmail be cacheing it? How can I test against the
local resolver?
All this running Sendmail v8.12.4, SuSE 7.4, Kernel 2.4.18, Bind
9.2.1.
Thanx,
Johnny Elliott
Johnny Elliott
> On 11 Jun 2002 02:10:21 GMT,
> Claus Aßmann <ca+se...@mine.informatik.uni-kiel.de> wrote:
>
>
> >
> >sendmail looks for an AAAA, A, or MX record (if DNS is available).
> >
>
>
> If the DNS servers isn't confident in saying that the A record does not
> exist, then further lookup is suspended until the DNS server has found out.
> If the A or AAAA record truely does not exist, then a proper functional
> DNS server would say so, and the MX record is then looked up.
What is defined as confident? A NEG response within the
Timeout.resolver.retrans.normal period?
> When you get a reject=451 then it is either the name server doesn't
> respond with a definite answer or doesn't respond at all. In either
> case it is assumed the name server is just temporarly unavailable.
> It could also be because a NS record somwhere refers a zone to a name
> server which does not have the full knowlege of that zone. This is
> called "lame delegation" and is not uncommon, unfortunately.
>
Ok, bounces.amazon.com is doing it again....
I've added the following to the mc config file:
LOCAL_CONFIG
Kdnsmx dns -R mx -a<OKR> -T<TEMP>
null:/var/spool/mqueue # /usr/lib/sendmail -bt
> /map resolve bounces.amazon.com
map_lookup: resolve (bounces.amazon.com) bounces.amazon.com: Name
server timeout
no match (75)
> /map dnsmx bounces.amazon.com
map_lookup: dnsmx (bounces.amazon.com) returns
service-5-bounces.amazon.com<OKR> (0)
null:/var/spool/mqueue # dig bounces.amazon.com
; <<>> DiG 9.2.1 <<>> bounces.amazon.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52977
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;bounces.amazon.com. IN A
;; Query time: 1 msec
;; SERVER: 192.168.0.5#53(192.168.0.5)
;; WHEN: Tue Jun 11 10:29:01 2002
;; MSG SIZE rcvd: 36
null:/var/spool/mqueue # dig MX bounces.amazon.com
; <<>> DiG 9.2.1 <<>> MX bounces.amazon.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12635
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;bounces.amazon.com. IN MX
;; ANSWER SECTION:
bounces.amazon.com. 1622 IN MX 10
service-5-bounces.amazon.com.
bounces.amazon.com. 1622 IN MX 10
service-3-bounces.amazon.com.
bounces.amazon.com. 1622 IN MX 10
service-4-bounces.amazon.com.
;; ADDITIONAL SECTION:
service-5-bounces.amazon.com. 1622 IN A 207.171.178.145
service-3-bounces.amazon.com. 1622 IN A 207.171.178.143
service-4-bounces.amazon.com. 1622 IN A 207.171.178.144
;; Query time: 1 msec
;; SERVER: 192.168.0.5#53(192.168.0.5)
;; WHEN: Tue Jun 11 10:29:05 2002
;; MSG SIZE rcvd: 186
The resolver is returning a definite response within one msec. Is the
response that it is receiving a valid NEG response for the A record?
None of the name servers for amazon.com seems to be lame. They all
give back an "aa" flag in dig.
Thanx,
Johnny Elliott
Johnny Elliott
> If the DNS servers isn't confident in saying that the A record does not
> exist, then further lookup is suspended until the DNS server has found out.
> If the A or AAAA record truely does not exist, then a proper functional
> DNS server would say so, and the MX record is then looked up.
>
> When you get a reject=451 then it is either the name server doesn't
> respond with a definite answer or doesn't respond at all. In either
> case it is assumed the name server is just temporarly unavailable.
> It could also be because a NS record somwhere refers a zone to a name
> server which does not have the full knowlege of that zone. This is
> called "lame delegation" and is not uncommon, unfortunately.
Hmmm, I've gotten access to another system which has similar
configuration.
null:/var/spool/mqueue # dig bounces.amazon.com
; <<>> DiG 9.2.1 <<>> bounces.amazon.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 40105
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;bounces.amazon.com. IN A
;; Query time: 1 msec
;; SERVER: 192.168.0.5#53(192.168.0.5)
;; WHEN: Tue Jun 11 10:40:21 2002
;; MSG SIZE rcvd: 36
[root@cis1 root]# dig bounces.amazon.com
; <<>> DiG 9.1.3 <<>> bounces.amazon.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51987
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;bounces.amazon.com. IN A
;; AUTHORITY SECTION:
amazon.com. 6976 IN SOA ns-1.amazon.com.
hostmaster.amazon.com. 2002060701 10800 3600 2592000 7200
;; Query time: 2 msec
;; SERVER: 66.221.68.167#53(66.221.68.167)
;; WHEN: Tue Jun 11 10:46:20 2002
;; MSG SIZE rcvd: 88
The status is different on each. The sendmail resolve works correctly
on cis1 (with the status of NOERROR.) but not on null (with the status
of SERVFAIL)
So, it appears the status SERVFAIL maybe causing the problem. Now
have to figure out why I'm getting the SERVFAIL, as both machine's
binds are also configured similarly (nothing special in the
configuration files.)
Johnny Elliott
Johnny Elliott
resolvers in our network that are configured to use external bind DNS
servers as forwarders. The external bind DNS servers then look up the
queries for the Win2K servers. Well, this seems to be the problem. I
removed forward setting in the Win2K servers and allowed them to query
directly to the internet... Now the dig request is coming back with
the correct NOERROR status and the sendmail resolve map works
correctly.
Thanx everyone for the pushes,
Johnny Elliott
Claus Aßmann
> Claus Aßmann
> > sendmail looks for an AAAA, A, or MX record (if DNS is available).
> Now the 'Kresolve host -a<OKR> -T<TEMP>' seems to be working, with
> only a MX record. (bounces.amazon.com is a good example that I've
> been using.)
KNOWNBUGS:
* Sender addresses whose domain part cause a temporary A record lookup
failure but have a valid MX record will be temporarily rejected in
the default configuration. Solution: fix the DNS at the sender side.
If that's not easy to achieve, possible workarounds are:
- add an entry to the access map:
dom.ain OK
- (only for advanced users) replace
# Resolve map (to check if a host exists in check_mail)
Kresolve host -a<OKR> -T<TEMP>
with
# Resolve map (to check if a host exists in check_mail)
Kcanon host -a<OKR> -T<TEMP>
Kdnsmx dns -R MX -a<OKR> -T<TEMP>
Kresolve sequence dnsmx canon
> Ok, then what is causing sendmail to have different information than
> that being returned by 'dig'. Can the local resolver be cacheing the
> infomation? Can sendmail be cacheing it? How can I test against the
> local resolver?
Seems you found the reason for that problem... (M$ DNS server).
Villy Kruse
Johnny Elliott <j...@blacknova.com> wrote:
>v...@pharmnl.ohout.pharmapartners.nl (Villy Kruse) wrote in message news:<slrnagb8a...@pharmnl.ohout.pharmapartners.nl>...
>> On 11 Jun 2002 02:10:21 GMT,
>> Claus Aßmann <ca+se...@mine.informatik.uni-kiel.de> wrote:
>>
>>
>> >
>> >sendmail looks for an AAAA, A, or MX record (if DNS is available).
>> >
>>
>>
>> If the DNS servers isn't confident in saying that the A record does not
>> exist, then further lookup is suspended until the DNS server has found out.
>> If the A or AAAA record truely does not exist, then a proper functional
>> DNS server would say so, and the MX record is then looked up.
>
>What is defined as confident? A NEG response within the
>Timeout.resolver.retrans.normal period?
>
Yes, that is a NXDOMAIN response. Once you get a NXDOMAIN, you know for
sure that the name with the specific type does not exist. The name
may very well exist with another type.
Villy
Villy Kruse
Johnny Elliott <j...@blacknova.com> wrote:
The amazon name server returns no information when asked. Your own
name server may then turn that into a SERVFAIL. It is a little uncertain
if that should be taken as it doesn't know or that it returned all that
is to be known about A records with the specified name. The aa flag
is set so the server claims to be authoritative. Maybe close examination
of the relevant rfc documents could cast light on this; bind does not
behave like this, though.
$ dig bounces.amazon.com. @ns-1.amazon.com. A
; <<>> DiG 8.3 <<>> bounces.amazon.com. @ns-1.amazon.com. A
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;; bounces.amazon.com, type = A, class = IN
;; AUTHORITY SECTION:
amazon.com. 2H IN SOA ns-1.amazon.com. hostmaster...
2002060701 ; serial
3H ; refresh
1H ; retry
4w2d ; expiry
2H ) ; minimum
;; Total query time: 365 msec
;; FROM: pharmnl to SERVER: ns-1.amazon.com. 207.171.178.132
;; WHEN: Wed Jun 12 09:43:37 2002
;; MSG SIZE sent: 36 rcvd: 88
Villy
Villy Kruse
Villy Kruse <v...@pharmnl.ohout.pharmapartners.nl> wrote:
>
>The amazon name server returns no information when asked. Your own
>name server may then turn that into a SERVFAIL. It is a little uncertain
>if that should be taken as it doesn't know or that it returned all that
>is to be known about A records with the specified name. The aa flag
>is set so the server claims to be authoritative. Maybe close examination
>of the relevant rfc documents could cast light on this; bind does not
>behave like this, though.
Correction.
That last statement was wrong, after further study, it is even quite normal
that you get NOERROR and and empty answer section when a given name with
a given type does not exist.
Villy