Testing SMTP over IPv6

[Peter Tattam]

I stand corrected.  Thanks for tha clarification.  I would hazard a guess
though that for at least 75% of cases the guidelines I suggested might apply.
Anyone like to comment as to how sendmail will typically react in the suggested
scenario?

Peter

On Thu, 2 Dec 1999, Matt Crawford wrote:

> > > > 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
> 

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210