Re: Last Call: draft-klensin-rfc2821bis

[John C Klensin <[e-mail]>]

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


--On Thursday, 20 March, 2008 09:33 -0700 Douglas Otis
<[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf




_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf