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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]