Date: Tue, 18 May 2004 01:04:07 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: fullermd@over-yonder.net Cc: cyrille.lefevre@laposte.net Subject: Re: bind timeouts Message-ID: <200405180804.i4I8477E019740@gw.catspoiler.org> In-Reply-To: <20040518063753.GB2038@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 May, Matthew D. Fuller wrote:
> On Tue, May 18, 2004 at 08:14:04AM +0200 I heard the voice of
> Christian Hiris, and lo! it spake thus:
>>
>> As far as i know MX records _must_ have an A record.
>
> RFC1035 states:
> MX records cause type A additional section processing for the host
> specified by EXCHANGE. The use of MX RRs is explained in detail
> in [RFC-974].
>
> RFC974 says:
> There is one other special case. If the response contains an
> answer which is a CNAME RR, it indicates that REMOTE is actually
> an alias for some other domain name. The query should be repeated
> with the canonical domain name.
That covers the intial lookup, meaning that a CNAME pointing to an MX is
legal.
Pointing an MX at a CNAME is likely to break the RFC 974 mail loop
prevention algorithm. Just below the paragraph you quoted:
If the response does not contain an error response, and does not
contain aliases, its answer section should be a (possibly zero
length) list of MX RRs for domain name REMOTE (or REMOTE's true
domain name if REMOTE was a alias). The next section describes how
this list is interpreted.
[ snip ]
It is possible that the list of MXs in the response to the query will
be empty. This is a special case. If the list is empty, mailers
should treat it as if it contained one RR, an MX RR with a preference
value of 0, and a host name of REMOTE. (I.e., REMOTE is its only
MX). In addition, the mailer should do no further processing on the
list, but should attempt to deliver the message to REMOTE. The idea
here is that if a domain fails to advertise any information about a
particular name we will give it the benefit of the doubt and attempt
delivery.
If the list is not empty, the mailer should remove irrelevant RR's
from the list according to the following steps. Note that the order
is significant.
For each MX, a WKS query should be issued to see if the domain
name listed actually supports the mail service desired. MX RRs
which list domain names which do not support the service should be
discarded. This step is optional, but strongly encouraged.
The WKS lookup is deprecated ..
If the domain name LOCAL is listed as an MX RR, all MX RRs with a
preference value greater than or equal to that of LOCAL's must be
discarded.
This is the important part. If an MX points to an alias for LOCAL, the
MTA may fail to trim this MX record (and the MX records with the same or
greater preference values) from the list, which may cause the MTA to
connect to itself in an attempt to deliver the message, or it may cause
the MTA to attempt to deliver the message using an MX record with a
higher preference number, which might loop the message right back to
this host.
The only ways of preventing this undesirable behavior are:
Configure the MTA with a list of all the aliases (CNAMEs) for
LOCAL. The MTA must be reconfigured whenever an alias is added
or deleted.
Look up the IP addresses for the domain names listed by the
MX records an compare the list of IP addresses to the IP
addresses of the MTA host. This may require a number of DNS
queries to be made before the first delivery attempt can be
made. It is not possible to attempt delivery if a domain name
specified by one of the MX RRs with the lowest preference value
is unresolvable due to a temporary DNS failure.
Example of the latter problem:
$ORIGIN example.com.
IN MX 0 mail.subdomain1.example.com.
IN MX 10 mail.subdomain2.example.com.
Using the latter anti-looping algorithm, the MTA must do a DNS lookup of
the IP address(es) of mail.subdomain1.example.com to verify that a
delivery attempt to mail.subdomain1.example.com would not connect back
to the local host. If the MTA is unable to resolve the IP address(es)
of mail.subdomain1.example.com, it must not attempt to deliver the
message to mail.subdomain2.example.com because this could result in a
mail loop.
Disallowing MX RRs from pointing to CNAMEs and only using the official
host name means that the MTA can just do a simple string comparision to
prevent a loop.
> RFC2821 obsoletes 974, but says substantially the same in regards to
> CNAME's. So, by the RFC's it's allowed.
RFC 2821 modifies this part of RFC 974:
If it determines that it should relay the message without rewriting
the address, it MUST sort the MX records to determine candidates for
delivery. The records are first ordered by preference, with the
lowest-numbered records being most preferred. The relay host MUST
then inspect the list for any of the names or addresses by which it
might be known in mail transactions. If a matching record is found,
all records at that preference level and higher-numbered ones MUST be
discarded from consideration. If there are no records left at that
point, it is an error condition, and the message MUST be returned as
undeliverable. If records do remain, they SHOULD be tried, best
preference first, as described above.
Which seems to say that the MTA must do IP address lookups on the names
specified by the MX records ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200405180804.i4I8477E019740>