From: Anthony Howe (achowe+postfix-userssnert.com)
Date: Mon Jul 24 2006 - 12:30:03 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Wietse Venema wrote:
> Anthony,
>
> Your call-back software refuses mail when a multi-homed MX host
> is not reachable on one of its IP addresses.
>
> This behavior seems broken. Why didn't you implement MX record
> processing as specified in the RFC?

It does do MX record processing, including the implicit MX 0 rule (RFC
974, 2821). And when there is only one MX record, as with porcupine.org,
and the host does not answer, it waits 30 seconds before trying once
more. As I recall the RFC states that at least two MX records should be
tried when attempting a connection/delivery and is unclear as how to
handle sites with only a single MX record (though I should really lookup
chapter and verse just to refresh my memory).

Also multi-homed does not count as multiple MX records, at least in the
case of the implicit MX 0 rule. I visited a related issue recently
before in a support ticket (see below for excerpt).

In the porcupine.org case, spike.porcupine.org has one A record and one
AAAA record which I'd argue is not really multi-homed, because not all
hosts support IPv6 yet, so cannot be relied upon.

Anthony

$ dig mx porcupine.org

; <<>> DiG 9.2.3 <<>> mx porcupine.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25483
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
;porcupine.org. IN MX

;; ANSWER SECTION:
porcupine.org. 27597 IN MX 10 spike.porcupine.org.

;; AUTHORITY SECTION:
porcupine.org. 27597 IN NS ns2.cloud9.net.
porcupine.org. 27597 IN NS spike.porcupine.org.
porcupine.org. 27597 IN NS ns1.cloud9.net.

;; ADDITIONAL SECTION:
spike.porcupine.org. 27599 IN A 168.100.189.2
spike.porcupine.org. 27597 IN AAAA
2001:240:587:0:2d0:b7ff:fe88:2ca7
ns1.cloud9.net. 70492 IN A 168.100.1.2
ns2.cloud9.net. 70492 IN A 168.100.1.3

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jul 24 19:11:44 2006
;; MSG SIZE rcvd: 189

>
> Wietse
>
> <achowe+postfix-userssnert.com>
> (reason: 550 5.7.1 <achowe+postfix-userssnert.com>... recipient denied, bec
> ause MX 10 'spike.porcupine.org.' [2001:240:587:0:2d0:b7ff:fe88:2ca7] for <wiets
> eporcupine.org> not answering)

---- Quaisi Related Topic ----

Host does not have an MX record, but 4 A records. Only one gets tried:
...

----
Iteration over MX records is described by RFC 974 and the implicit MX 0
record:

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.

There is no mention about multi-homed hosts. I just have to query one of
those A records of a multi-home host, because they should ALL provide
the same answer.

RFC 2821 which obsoletes 974 describes in section 5.:

If no MX records are found, but an A RR is found, the A RR is treated as
if it was associated with an implicit MX RR, with a preference of 0,
pointing to that host. If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present. If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.

Again NO mention that in the absense of MX records, do I need to iterate
over several of the A records. That only applies in the presense of MX
records which have preferences.

----
The only reason the one record gets tried twice is because many domains
only supply ONE mx record in, which case a reasonable attempt to deliver
would be to make repeated connections to it after a delay interval. No
mention of making multiple repeated lookups to redetermine that implicit MX.

In you're case you have an single implicit MX 0 that is multi-homed. To
do as you want, it would have to have N different MX records with the
same preference using the same multi-homed host, THEN it would try
multiple different ones.

RFC 974 again:

The mailer is required to attempt delivery to the lowest
valued MX. Implementors are encouraged to write mailers so that they
try the MXs in order until one of the MXs accepts the message, or all
the MXs have been tried. A somewhat less demanding system, in which
a fixed number of MXs is tried, is also reasonable. Note that
multiple MXs may have the same preference value. In this case, all
MXs at with a given value must be tried before any of a higher value
are tried. In addition, in the special case in which there are
several MXs with the lowest preference value, all of them should be
tried before a message is deemed undeliverable.

And RFC 2821 does make some further mention:

The destination host (perhaps taken from the preferred MX record) may
be multihomed, in which case the domain name resolver will return a
list of alternative IP addresses. It is the responsibility of the
domain name resolver interface to have ordered this list by
decreasing preference if necessary, and SMTP MUST try them in the
order presented.

Although the capability to try multiple alternative addresses is
required, specific installations may want to limit or disable the use
of alternative addresses. The question of whether a sender should
attempt retries using the different addresses of a multihomed host
has been controversial. The main argument for using the multiple
addresses is that it maximizes the probability of timely delivery,
and indeed sometimes the probability of any delivery; the counter-
argument is that it may result in unnecessary resource use. Note
that resource use is also strongly determined by the sending strategy
discussed in section 4.5.4.1.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]