ietf
[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-20 15:04:02

Doug,

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
thought appropriate.

That is really all the material to which you refer does (or
changes).

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
updating 2821?

(4) Something else?

      john

        I think Doug is saying don't let domains with just AAAA
        records be treated as valid RHS of email.  Today we
        have to add records to domains with A records to say that
        these are not valid RHS of email.  With MX synthesis
        from AAAA you create the same problem for domains with
        AAAA records.

                user@<A record owner>
                user@<MX record owner>
                user@<AAAA record owner>  * don't allow this.
 
        Mark
 
--On Thursday, 20 March, 2008 09:33 -0700 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> wrote:

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

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

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

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.

-Doug
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf




_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews(_at_)isc(_dot_)org
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf