Robert A. Rosenberg wrote:
IMO there is no VALID excuse for allowing AAAA-Fallback except for
the "We Allow A-Fallback so we should allow AAAA-Fallback" claim.
I see the existence of A-Fallback support as an invalid issue to
avoid justifying the need to not require the use of MX.
Sorry for adding a second message to this thread after writing...
| So that's it then, 2821bis-09 as is modulo some pending nits.
...almost a week ago. But meanwhile I think 2821bis-09 could do
a better job explaining the issue.
For a domain with A and AAAA the proposed rules based on RFC 974
make no difference. An explicit MX means that the client can try
A or AAAA (or both after one failed). An implicit MX has exactly
the same effect, so arguaby the explicit MX is redundant, or even
a deployment barrier.
If the domain.example has A and AAAA, but accepts SMTP only over
IPvX, it needs more than a simple explicit MX for its own name,
it needs an explicit MX pointing to say smtp.domain.example, and
smtp.domain.example gets either A or AAAA corresponding to IPvX.
Maybe 2821bis could mention this as example. Pete's back to the
roots (RFC 974) proposal means, that a domain with only AAAA has
the same implicit MX like any other domain. For an IPv4 sender
it is not reachable.
Likewise a domain with only A has the same implicit MX like any
other domain, for an IPv6 sender it is not reachable. In both
cases simply adding an explicit MX does not change the picture.
Hector argues that it's the job of IPv6 domains to be reachable,
for that they must either also offer A, or use an explicit MX
with an IPv4 SMTP at a third party in addition to their AAAA.
Assuming that 2821bis will be as long a standard as STD 10
(about 30 years) adding this pragmatical idea could backfire
when IPv4 is remote history.
Frank