I'm sorry, but I can't understand what you are talking about.
That is at least in part because you are using vocabulary that
does not appear in 2821bis or other common IETF standardized
email technology. You also seem to be making assumptions that
aren't part of the 2821 model (whether they are valid or not).
In 2821 and its predecessors, MX records and the associated
preferences were specified as the preferred mechanism for
finding the next-hop SMTP server. There was also a special
case, originally part of a transition mechanism for RFC 974,
that, if no MX records were found for a particular name, one or
more A RRs would be located for the name and treated as if they
were the targets of an MX record with preference zero.
While various implementations have been more permissive over
time, the data field in an MX RR has always been expected to be
a DNS name that would, in turn, resolve to one or more A RRs.
That is the mechanism that has been used for Internet mail over
IPv4 for many years.
Now, as far as I know, 2821bis makes only two changes in this
area. The first is to be explicit about the expected data value
in MX records. The second is to explicitly specify that names
with AAAA records are permitted as an alternative to names with
A records. Without that change, which was anticipated in 2821
but not as explicit because of the state of development
experience at the time, it would be impossible to run SMTP over
IPv6 without local imaginative extensions of the standard.
It does not provide for an extension of the "if there are no MX
records, look for an A RR" model because the mailing list
concluded that the transition mechanism was not needed for IPv6
transition and because it would have required the standard to
specify preferential rules for A and AAAA records. It seemed
much better to let those configuring mail systems to use the
existing MX preference mechanism to specify what treatment they
That is really all the material to which you refer does (or
Now, are you suggesting that:
(1) It is time to abandon the current Internet email fabric in
terms of, e.g., your "notify and retrieve" proposals?
(2) That we should not specify operation of SMTP over IPv6 but
either prohibit that or leave it to the imagination?
(3) That MX records are so useless that we should deprecate them
and embark on some other "discovery" mechanism rather than
(4) Something else?
--On Thursday, 20 March, 2008 09:33 -0700 Douglas Otis
While this response may be a bit late, the change in section
5.1 indicating SMTP server discovery now explicitly supports
IPv6 address records represents a significant change from
While a desire to retain current practices has some
justification, extending an already dubious and archaic
practice to the explicit use of IPv6 raises significant
The level of misuse afflicted upon SMTP often results in an
exploration of DNS SMTP discovery records to determine whether
a purported domain might be valid in the forward direction.
To remain functional, reverse DNS checks are often avoided
due to the poor level of maintenance given this zone. A
move to deprecate A records for discovery when performing
these checks to ascertain domain validity would favourably
impact the level of undesired transactions. To combat
rampant domain spoofing, some domains also publish various
types of SMTP related policy records. To counter problems
related to wildcard policy records, a lack of policy may be
conditioned upon presences of possible SMTP discovery
Adding IPv6 to the list transactions needed to qualify SMTP
domains that is predominately triggered by geometrically
growing levels of abuse or misuse appears to be a remarkably
poor choice. To suggest a domain might reply upon this
mechanism again appears to be remarkably poor advice.
Reliance upon a communication system should not be
predicated upon such a questionable mechanisms. During the
next disaster, would you want FEMA to not use MX records or
to depend upon IPv6 address records? Not including IPv6 as
a discovery record would better protect networks in the face
of growing misuse of SMTP while also better ensuring the
integrity of SMTP.
IETF mailing list
IETF mailing list