ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Address transformations

2016-07-31 15:14:24


--On Sunday, July 31, 2016 14:32 -0400 John R Levine
<johnl(_at_)taugh(_dot_)com> wrote:

I think we all agree that was a mistake, and CNAMEs are fine
in MAIL and RCPT and you shouldn't mess with them, but I
can't find any place this advice has been explicitly
deprecated.

Try Section 2.3.5 of RFC 5321 (or its predecessor in 2821,
which was a tad less explicit):

this particular case.  YMMD, in which case specific
suggestions for what needs to be fixed and how to fix it
would be welcome.

Putting on my nitpicky lawyer hat, I note that RFC 1123 is a
full standard.  RFC 2821 is a proposed standard obsoleted by
RFC 5321 which is a draft standard which updates but does not
obsolete 1123.

Putting on a similar hat, there is a wart (actually a
wart-epidemic) in the IETF "obsoletes/updates" language and
definitions wrt these cases.  First, it has never been clear
whether a Proposed (or even Draft) Standard can obsolete or even
update a full Standard.  If the answer is "no", then I hope
everyone is still supporting explicit routes and the VRFY
command because, IIR, 821 requires them.  Second, there is no
mechanism at all for identifying a replacement for a section (or
set of sections) of a document and marking them obsolete.   The
sentence from 5321 that says "It obsoletes RFC 821, RFC 974, RFC
1869, and RFC 2821 and updates RFC 1123 (replacing the mail
transport materials of RFC 1123)." is, I contend, crystal-clear
as to intent.  But, if you argue, as the above implies, that
such a statement is invalid on its face because 5321 is only a
Draft Standard --or that "replacing the mail transport
materials..." cannot be considered as equivalent to obsoleting
those sections, my reaction isn't to disagree but to find other
ways to spend my time.

So my reading is that while 5321 tells me that it's OK to use
a CNAME in MAIL FROM/RCPT TO, 1123 still tells me that it's
better to resolve those CNAMEs first.

See above and note that the sections of 1123 that tell you that
are among those presumably-replaced mail transport material.

I hope that nobody who matters believes this, but if you look
at the two documents it's not a totally ridiculous way to
reconcile them.  Should we open up 5321 again, I think a
sentence specifically revoking the CNAME advice in 1123
wouldn't hurt.

See "warts" above.   The assumption in writing 5321 was that
"replacing the mail transport materials..." did specifically
revoke (a word that is not in the IETF standards status
vocabulary) anything about mail transport that 1123 says that is
inconsistent with 5321.   Certainly it is possible to read it in
other ways, but most of them lead to silly states (or at least
wart-infections or outbreaks).

For anyone who is curious, the near-certainty that we would need
to spend significant time on such status arguments has been a
major reason why the working drafts of 5321bis have not been
posted since, IIR, one snapshot around six years ago.  I have
significant doubts that the community really has the energy to
work through the technical issues and text to settle on 5321bis
and presumably advance it to Full Standard.  I am almost
positive that there is insufficient energy to engage in a
"status of documents" debate at the same time.  I am certain
that _I_ don't have the energy.

    john



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