Re: Last Call: draft-klensin-rfc2821bis

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

Doug,


--On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis
<[e-mail]> wrote:

>...
> In the past you had made several comments that RFC2821bis
> would not change SMTP, and that you had also stated AAAA
> records where NOT defined as SMTP server discovery records.
> (Not in those words of course.)  It does not appear this
> change was your choice, but nonetheless and surprisingly this
> unfortunate change is now being made.
> 
> The "update" of RFC2821 is making a _significant_
> architectural change to SMTP by explicitly stating AAAA
> records are within a list of SMTP server discovery records.

Well, to be very precise, 2821 is ambiguous on the subject. Some
people have read (and implemented) it as if the text said
"address records", implying a default MX for the AAAA case as
well as the A one.   Others have read it more narrowly and only
supporting the default for A RRs.    To the extent to which
2821bis is expected to eliminate ambiguities that were present
in 2821, it had to say something on this subject.    If it says
"address records" (as the current text does), you (and perhaps
Mark and others) dislike the consequences and claim "significant
architectural change".   If it is changed to explicitly indicate
that only A RRs can be used to imply an MX record, then I assume
that those who read 2821 the other way and are now supporting
AAAA records to generate an implied MX would claim "significant
architectural change".  

Given that, the document can't win.  The choices are between
ambiguity (which I hope is the lowest preference for all of us)
and picking an option that some people won't like.

For me --and, again, this is personal opinion only-- that set of
choices pretty much cancels out arguments based on "significant
architectural change" and leaves us with a choice based on the
more fundamental "what is the right thing to do from the
standpoint of the installed base and efficient email operation".


As you know, I prefer to make those decisions based on normal
transport and delivery of normal mail.  Put differently, making
changes to, or decisions about, mail protocols in order to make
a spam-fighting technique work better doesn't appeal to me very
much, especially if that technique is easily worked around or
otherwise has little long-term value.  YMMD, of course.

>...

Even without the anti-spam argument that you raise, I think
there are mail performance and DNS reasons (one cited by Mark)
for declaring the utility of implicit MX records, even those
built on A RRs, to be at an end.  But that would clearly be a
significant change to 2821/ 2821bis, so I think that, regardless
of whether this issue is reconsidered for 2821bis, I'd recommend
the BCP path I comments on in an earlier note.  Remembering that
it is very late in the processing cycle for 2821bis, suppose an
I-D that could lead to such a BCP were in the archives and under
active discussion.  I would think that it would be easier to
make a case for a sentence or two in 2821bis that indicated that
the whole question of whether implicit MXs were a good idea and
that made an informative reference pointer to the relevant I-D
would be easier than getting clear consensus to ban implicit MXs
based on AAAA records or, for that matter, to get equally clear
consensus on the current text.

      john

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