Subject: [yam] [Technical Errata Reported] RFC6409 (3995)

From: RFC Errata System <[email-masked]>
Date: Thu, 22 May 2014 03:59:30 -0700 (PDT)

The following errata report has been submitted for RFC6409,
"Message Submission for Mail".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6409&eid=3995

--------------------------------------
Type: Technical
Reported by: Tony Finch <[email-masked]>

Section: 8.7

Original Text
-------------
   NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in
   addresses and the session-opening announcement.  As with other SMTP
   requirements, RFC 5321 effectively prohibits an MSA from forwarding
   such messages into the public Internet.  Nonetheless, unconditionally
   resolving aliases could be harmful.  For example, if www.example.net
   and ftp.example.net are both aliases for mail.example.net, rewriting
   them could lose useful information.

Corrected Text
--------------
   NOTE: RFC 821 and RFC 1123 prohibited the use of domain name
   aliases in addresses and the session-opening announcement.
   Because of this it is still common for MTAs to canonicalize
   domains in email addresses.  However this requirement was dropped
   during the development of RFC 2821.  The current rules about 
   domain name aliases are set out in RFC 5321 section 2.3.5.

Notes
-----

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6409 (draft-ietf-yam-rfc4409bis-03)
--------------------------------------
Title               : Message Submission for Mail
Publication Date    : November 2011
Author(s)           : R. Gellens, J. Klensin
Category            : INTERNET STANDARD
Source              : Yet Another Mail
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Ned Freed <[email-masked]>
Date: Thu, 22 May 2014 07:17:46 -0700 (PDT)

This looks correct to me, although it's right at the edge of what's acceptable
in an errata.

				Ned

> _______________________________________________
> yam mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yam

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 May 2014 11:36:58 -0400

--On Thursday, 22 May, 2014 07:17 -0700 Ned Freed
<[email-masked]> wrote:

> This looks correct to me, although it's right at the edge of
> what's acceptable in an errata.

Yeah.  Reluctantly concur.  I am not aware of any impulses
toward updating 6409 and do not believe this report changes that.

    john

>>    NOTE: SMTP [SMTP-MTA] prohibits the use of domain name
>>    As with other SMTP requirements, RFC 5321 effectively
>>    prohibits an MSA from forwarding such messages into the
>>    public Internet.  Nonetheless, unconditionally resolving
>>    aliases could be harmful.  For example, if www.example.net
>>    and ftp.example.net are both aliases for mail.example.net,
>>    rewriting them could lose useful information.
> 
> 
>> Corrected Text
>> --------------
>>    NOTE: RFC 821 and RFC 1123 prohibited the use of domain
>>    name aliases in addresses and the session-opening
>>    announcement. Because of this it is still common for MTAs
>>    to canonicalize domains in email addresses.  However this
>>    requirement was dropped during the development of RFC
>>    2821.  The current rules about domain name aliases are set
>>    out in RFC 5321 section 2.3.5.
> 
>> Notes
>> -----
> 
> 
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary,
>> please use "Reply All" to discuss whether it should be
>> verified or rejected. When a decision is reached, the
>> verifying party (IESG) can log in to change the status and
>> edit the report, if necessary.
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 May 2014 11:40:02 -0400

> toward updating 6409 and do not believe this report changes that.

Two votes for "Verified" (along with my own sense) is good enough for me.

/me goes off to do it...

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 May 2014 12:25:07 -0400

> Two votes for "Verified" (along with my own sense) is good

Actually, something else just occurred to me.  I don't think it
changes the "verified" answer and I can't remember why Randy and
I left the prohibition there when it was removed from SMTP.   If
it was intentional rather than an oversight, I'd think it might
have something to do with the following:

Despite the assertion that it is common to canonicalize names
(probably true, since "common" is hard to quantify), the SMTP
specs generally discourage in-transit fixups.  An implementation
that discovered that the FQDN in an address was associated with
a CNAME record would be equally justified in simply rejecting
the message.  There is also the matter of SMTP's effective
requirement that an SMTP delivery server know the names by which
it is called (see the recent thread on the ietf-smtp list).  So
we might have intended to urge caution because
[email-masked] with

   random-alias.example.com. IN CNAME smtp.example.com.

could fail entirely if the server at smtp.example.com. either:

	* did not have "random-alias.example.com" configured as
	one of its names.  Or
	
	* strictly followed the 821 interpretation and rejected
	that mailbox address.

Note also that the locally-configured name requirement provides
some protection in which the evil owner of example.net creates 

   evil-server.example.net. IN CNAME smtp.example.com.

which would, at best, make some attack vectors harder to trace.

Again, I don't think this changes the "verified" answer.  It
does illustrate a reason why this is at the boundary as an
erratum.  And, if someone wanted to add the above as a comment
to the approved erratum, I certainly wouldn't object.

    john

---

From: Randall Gellens <[email-masked]>
Date: Fri, 23 May 2014 08:07:03 -0700

I think the wording is unclear and should be improved.  See in-line:

>     domains in email addresses.

Because of what?  The prohibition on CNAMEs?

"it is still common for MTAs to" should be worded as "some MTAs" to 
be more factual (otherwise it raises questions of how common).

>   However this requirement was dropped

What requirement was dropped?  The wording should be clear.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Scandal is gossip made tedious by morality.     --Oscar Wilde

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 May 2014 14:28:44 -0400

Unless I'm wrong about how motivated any of us are to do a 6409
update to fix this, can we just note (as a comment on the
erratum since it has gotten this far) that there is an issue
with the text (as noted) and that it needs to be examined
carefully in any rewrite.  I agree with Randy's comments about
clarity, but doubt that is worth spending a lot more time on now
unless something thinks the issue is really important enough to
justify a revision.

   john

--On Friday, 23 May, 2014 08:07 -0700 Randall Gellens
<[email-masked]> wrote:

>>     aliases in addresses and the session-opening
>>     announcement.  As with other SMTP requirements, RFC 5321
>>     effectively prohibits an MSA from forwarding such
>>     messages into the public Internet.  Nonetheless,
>>     unconditionally resolving aliases could be harmful.  For
>>     example, if www.example.net and ftp.example.net are both
>>     aliases for mail.example.net, rewriting them could lose
>>     useful information.
>> 
>> 
>>  Corrected Text
>>  --------------
>>     announcement.
>>     Because of this it is still common for MTAs to
>>     canonicalize domains in email addresses.
> 
> "it is still common for MTAs to" should be worded as "some
> MTAs" to be more factual (otherwise it raises questions of how
> common).
> 
>>     during the development of RFC 2821.  The current rules
>>     about domain name aliases are set out in RFC 5321 section
>>     2.3.5.
>> 
>>  Notes
>>  -----
>> 
>> 
>>  Instructions:
>>  -------------

---

From: Barry Leiba <[email-masked]>
Date: Fri, 23 May 2014 18:01:11 -0400

Is it sufficiently important to add the note that I should ask the RFC
Editor to pull it back, so I can add the note and re-verify?

Barry

On Friday, May 23, 2014, Randall Gellens <[email-masked]> wrote:

> I completely agree with John.  A note on the errata is fine (since it has
> already been marked as verified).
>
> At 2:28 PM -0400 5/23/14, John C Klensin wrote:
>
> Nostalgia isn't what it used to be.
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 May 2014 19:51:35 -0400

--On Friday, 23 May, 2014 18:01 -0400 Barry Leiba
<[email-masked]> wrote:

> Is it sufficiently important to add the note that I should ask
> the RFC Editor to pull it back, so I can add the note and
> re-verify?

Depends...

If you expect that Randy and/or myself will revise the doc
within the next year or two, this discussion thread suffices and
there is no need to do anything else -- not going to forget any
time soon.  I imagine we could quibble about the text and spin
up a version with the change in less time than we've spent on it
in the last week, but getting it through Last Call and approved
(and preventing that from turning into a debate about the
fundamental philosophy of email and its relationship to the DNS
and the differences in character among the three Pu-ers I got to
compare yesterday) would be your problem, not ours.

Almost the same answer applies if the expectation is that the
spec will never be revised: IMnvHO, we are spending a lot of
time hair-splitting about fussy original text for which a
careful reading of 5321 (without which anyone trying to do much
with 6409 is in big trouble anyway), good sense, and operational
experience and necessity will almost always provide the right
answer.

On the other hand, if you expect there to ultimately be a
revision by someone with no memory of active participation in
YAM, done after Randy and I are sufficiently retired to be
unlikely to a review and/or have forgotten all about this, then,
yes, let's erect a large sign that effectively says "the
original text is defective, the proposed change isn't quite
right, and someone revising the spec better dig through old
email messages and think carefully about exactly what to say and
how".

best,
    john

---

From: Randall Gellens <[email-masked]>
Date: Fri, 23 May 2014 14:51:14 -0700

I completely agree with John.  A note on the errata is fine (since it 
has already been marked as verified).

---

From: Randall Gellens <[email-masked]>
Date: Sat, 24 May 2014 12:08:48 -0700

Consider the work to add the clarifications as a down payment on the 
work of any eventual revision, or insurance that a revision will be 
done without forgetting this discussion now.  Or, if it's worth 
publishing the errata, it's worth noting that it isn't quite right.

-------------- Randomly selected tag: ---------------
Sambo (SUM-bo; Swedish; noun): Two unmarried persons living together
in a matrimonial manner, as a couple.

---

From: John C Klensin <[email-masked]>
Date: Sun, 25 May 2014 22:25:46 -0400

--On Saturday, May 24, 2014 12:08 -0700 Randall Gellens
<[email-masked]> wrote:

> Consider the work to add the clarifications as a down payment
> on the work of any eventual revision, or insurance that a
> revision will be done without forgetting this discussion now.
> Or, if it's worth publishing the errata, it's worth noting
> that it isn't quite right.

Wfm, noting however that, in my role as keeper of the XML with
comments, etc., I've already marked this change --with a note
that the text isn't quite right-- into the source that would be
used to build 6409bis if Randy and I were to do it.  My previous
note was written with that in mind.

   john

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 May 2014 11:06:19 -0400

> note was written with that in mind.

OK... then please agree on an exact wording change to the errata
report, and I will get the change made.

Barry

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 May 2014 11:41:55 -0400

--On Monday, May 26, 2014 11:06 -0400 Barry Leiba
<[email-masked]> wrote:

>> that the text isn't quite right-- into the source that would
>> be used to build 6409bis if Randy and I were to do it.  My
>> previous note was written with that in mind.
> 
> OK... then please agree on an exact wording change to the
> errata report, and I will get the change made.

If Randy has strong preferences to the contrary and wants to
take the lead to sort out wording, I'll defer to him.   But my
preference right now, based on avoidance of pointless work,
would just be to add a sentence to what is in the erratum
already that says "the above wording is not quite correct and
needs to be examined carefully before a revised version is
inserted into a revised document" ... or something to that
effect - exact wording doesn't make any difference.  In other
words, I recommend flagging this rather than trying to develop
supposedly-final text that would just need another pass if/when
the document is revised.

If we were proposing posting a revision now and processing it,
my attitude would be somewhat different.
 
   john

---

From: Randall Gellens <[email-masked]>
Date: Tue, 27 May 2014 10:15:13 -0700

>  my attitude would be somewhat different.

WFM.

(and I think that is the first time I've ever used that acronym.)

-------------- Randomly selected tag: ---------------
Rocky's Lemma of Innovation Prevention:

Unless the results are known in advance, funding agencies will
reject the proposal.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 27 May 2014 13:59:51 -0400

*** ACTION FOR RFC EDITOR ***

>>  supposedly-final text that would just need another pass if/when

OK... then:

RFC Editor: Please return this errata report to "Reported" state so I
can make the changes.  Thanks.

Barry