Testing SMTP over IPv6

[Matt Crawford]

> > > IPv6 only servers		MX    a
> > > IPv6 + IPv4 servers	MX    b
> > > IPv4 only servers		MX    c
> > > 
> > > Where a < b < c
> > 
> > No, this sort of ordering is only important if not all the servers
> > can do "final delivery" (i.e., take the message out of the SMTP
> > world).
> 
> By definition, MXs that are greater than the the mininmum would not
> remove mail messages from the SMTP world.

No, not by definition.  Those "non-best" MX's *need not* remove
messages from SMTP, because they have somewhere "better" to send them
by SMTP.  But they MAY, and often DO, perform what SMTP would
call "final delivery".

>  If they don't have v6 access, the mail will queue indefinitely, or
> possibly bounce if it can't reach any MX's that are lower.

*Assuming* the non-best mail exchangers can't do final delivery, this
is correct.

> I am uncertain as to whether how an SMTP server would interpret an
> MX list that had pointers to AAAA or A6 records in them.  Anyone
> have any ideas?  Would they simply remove those names from the list
> resulting in truncated MX list?

Since the MX record points to a FQDN, not an address.  A pure IPv4
node would fail to get any addresses for the IPv6-only "best" MX.
Here comes the big gotcha: RFC 974 (full standard STD 14) requires
the seding host to try (one of) the lowest-preference MX target(s)
first, but DOES NOT REQUIRE that any of the others be tried at all!
Of course it's recommended that all be tried, with the words
"Implementors are encouraged to".

So in your example, mail could hit one of the v4-only mailers and
that mailer could never attempt to connect to a dual-stack mailer and
yet still be strictly compliant.  True, such a mailer would still
fail in some v4-only scenarios, such as when the destination host is
"mx 0" for itself, but is permanently smtp-unreachable behind a
firewall, with an "mx 10" relay provided.

It's an ugly internet.

					Matt