Re: IPv6 and email routing, was Re: AAAA records to be added for root se

Tony Finch wrote:
> On Fri, 4 Jan 2008, John C Klensin wrote:
> > However, there is also a rule that, if no MX records are present at a
> > particular node, the mail system looks for an A RR at the same node and
> > treats it as if its label appeared with an MX preference of 0.  That
> > default does not apply to AAAA records, so it is necessary that
> > operators understand that, if mail systems are to be accessed using
> > IPv6, they MUST have MX records at the relevant nodes.
> The only document that I know of which specifies IPv6 email routing is RFC
> 3974, which says that AAAA should be treated exactly the same as A. As far
> as I know, Exim, Postfix, and Sendmail follow RFC 3974.
It seems that at least Postfix doesn't handle this the way it should do 
it. It does IPv6, but not according to how I understand it which is:
------------------------------------------
all_mxs = dig("dom", "MX");
sort_on_prio(all_mxs);

done = 0;

for (mx in all_mxs && done == 0)
{
        all_addrs = dig(mx, "AAAA|A");
        sort_aaaa_first_then_a(all_addrs);

        for (addr in all_addrs)
        {
                if (connect_to(addr, 25))
                {
                        ret = try_smtp_exchange();
                        if (connection_timeout) next;

                        if (ret == 2xx) done = 1; success(); last;
                        if (ret == 4xx) last;
                        if (ret == 5xx) done = 1; DSN(); last;
                }
        }
}

if (!done)
{
        queue_message_for_later_retry();
}
------------------------------------------

Then if we have:
-------------------------------------------
example.com.
        MX      10 a.example.com.
        MX      20 b.example.com.

a.example.com.
        AAAA    2001:db8::11
        A       192.0.2.11

b.example.com.
        AAAA    2001:db8::22
        A       192.0.2.22
------------------------------------------

'a' & 'b' are both separate MX's. As such according to the above 
pseudo-code, which I deduced from the RFC, whenever 'a' is contactable 
and you can get a response from it, you should honor that response. Thus 
if you contact 'a' and it replies with a "450 Out of diskspace, try 
later" or other temp failure or a 5xx error etc, one should go to 'b'.
Postfix contacts a-AAAA, gets a 450 diskspace, then contacts a-A, gets 
the same error again, and then tries b-AAAA and then b-A, which might 
accept the message.
We actually noticed this last year because of one of Paul Vixies email 
setups rejects-all over IPv4 but accepts mail on IPv6, but as IPv6 gets 
greylisted (and thus it sends a 450) postfix tried the IPv4 address 
also, which resulted in a 500, rejecting the message, if Postfix would 
have properly followed the RFC like in the above pseudo code then it 
would have requeued the message and tried again a bit later, which would 
have caused the message delivery to succeed.
Indeed it is an odd-case, but it is the way it is specified in the RFC.
Also, the real thing is that one should not retry on the same MX as it 
is the same host, otherwise it would be a different host with a 
different weight in the MX label.
Also indeed, this does also lighten the load on 'email clusters' where 
the MX label has maybe 20 A records or so, as the sender should only try 
once to that MX label, and not try and contact all 20 of them.
Greets,
 Jeroen

signature.asc
Description: OpenPGP digital signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf