Subject: [EAI] Rather serious bug in RFC 6531

From: John C Klensin <[email-masked]>
Date: Mon, 04 Jan 2021 00:35:25 -0500

Today's New Year's bad news...

Many of you who were around in 2011 and early 2012 will recall
that there was a fairly extended discussion in the EAI WG about
whether to retain the "UTF8SMTP" keyword used in the
experimental versions of the protocol (documented in RFC 5336)
and the standards track version (documented in RFC 6531).
Primarily because the semantics of the extension and several
things surrounding it had changed and systems (and those trying
to debug mail transactions) should know exactly what they are
asking for and agreeing to, the WG concluded that the extension
keyword should be changed, the WG decided to change the
extension name, ultimately to SMTPUTF8.   Put differently,
because the Experimental and Standards Track versions really
were incompatible in important ways, the intent was to make it
clear that the protocols were different. 

Because the reason for changing the extension keyword was to
make it clear whether the Experimental or Standards Track
protocols were being used, while it was, as far as I can
remember or tell from minutes or my notes, never explicitly
discussed, I believe the clear intent of the WG was that the
keywords used in the WITH clause in time stamp trace fields use
the new keyword form.  

For whatever reason, that didn't happen.  AFAICT, other than
being assigned a separate section number and introductory
sentence, keywords in the IANA Considerations discussion of the
WITH clause were carried forward unchanged from RFC 5336 even
though SMTPUTF8 replaced UTF8SMTP in the Descriptions, leading
to the potential for exactly the "which protocol is really in
use?" question that the WG intended to avoid.

I want to stress that the authors are not to blame for this.
Every one of us who was involved with the WG during WG and IETF
Last Call on what because RFC 6531 is equally responsible for
not spotting the problem and insisting that the WG discuss it.
The question is what we do about it today.

>From a procedural standpoint, RFC 6531 is (only) a Proposed
Standard and revising it to correct a clear mistake, especially
a mistake that is inconsistent with the WG's reasoning in 2011,
is entirely in order.   From a more pragmatic standpoint, the
questions are whether making the change at this point would be
worth the disruption.  If we are absolutely positive that there
are no implementations of RFC 5336 left in the wild, the answer
is probably not even those it means accepting long-term
confusion between the extension keyword and the WITH values (a
problem that, AFAIK, we don't have with any other SMTP
extension.   On the other hand, if we expect more SMTPUTF8
implementations in the future than we have today or if there
might still be implementations of the Experimental protocol out
there, changing/correcting the WITH keywords now would probably
reduce confusion in the long terms and would be less painful now
than later.

Making the change, should we decide to do so, would require a
one (substantive) page RFC explaining the WG's intent and
requesting IANA change the keywords.  I suppose, as a guilty
party for not catching this a decade ago, I'm willing to write
an post it.  If we decide to note make the change, I might
generate such an I-D anyway just to have a slightly more
permanent/ available record than this note that the decision was
explicit.

What do people think?

    john

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 4 Jan 2021 17:16:57 +0800

Hello John and all,

     Happy New Year to all!
     The final version of the draft is https://tools.ietf.org/html/draft-ietf-eai-rfc5336bis-16 
     which keeps the following text:

   |  WITH       | Description                     | Reference         |
   | protocol    |                                 |                   |
   | types       |                                 |                   |
   +-------------+---------------------------------+-------------------+
   | UTF8SMTP    | ESMTP with UTF8SMTPbis          | [RFCXXXX]         |
   | UTF8SMTPA   | ESMTP with UTF8SMTPbis and SMTP | [RFC4954]         |
   |             | AUTH                            | [RFCXXXX]         |
   | UTF8SMTPS   | ESMTP with UTF8SMTPbis and      | [RFC3207]         |
   |             | STARTTLS                        | [RFCXXXX]         |
   | UTF8SMTPSA  | ESMTP with UTF8SMTPbis and both | [RFC3207]         |
   |             | STARTTLS and SMTP AUTH          | [RFC4954]         |
   |             |                                 | [RFCXXXX]         |
   
In Dec. 2011, the WG chair announced that "
Unless there are such objections, the new keyword notification will be forwarded to the RFC Editor and IANA."
https://mailarchive.ietf.org/arch/msg/ima/IWLgpfyrx80mggZbVEsAiaFI6hE/ 

Before the final version of this draft, if I remember it correctly, when we asked whether we should change "UTF8SMTP" "UTF8SMTPA" "UTF8SMTPS"... to something else, some WG members recommended that we just keep it.

I tried to dig the message in the mailing list, but I can not find it.

Anyone remember it? discussion in the mailing list or the meeting?

Best Regards
Jiankang Yao

From: John C Klensin
Date: 2021-01-04 13:35
To: ima; YAO Jiankang
CC: ars-ads
Subject: Rather serious bug in RFC 6531
Today's New Year's bad news...

What do people think?

    john

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Jan 2021 10:46:12 +0000

Hi all,

On 04/01/2021 09:16, Jiankang Yao wrote:
> Hello John and all,
>      Happy New Year to all!
>      The final version of the draft is 
> https://tools.ietf.org/html/draft-ietf-eai-rfc5336bis-16 
> <https://tools.ietf.org/html/draft-ietf-eai-rfc5336bis-16>
>     | UTF8SMTPA   | ESMTP with UTF8SMTPbis and SMTP | [RFC4954  <https://tools.ietf.org/html/rfc4954>]         |
>     |             | AUTH                            | [RFCXXXX]         |
>     | UTF8SMTPS   | ESMTP with UTF8SMTPbis and      | [RFC3207  <https://tools.ietf.org/html/rfc3207>]         |
>     | UTF8SMTPSA  | ESMTP with UTF8SMTPbis and both | [RFC3207  <https://tools.ietf.org/html/rfc3207>]         |
>     |             | STARTTLS and SMTP AUTH          | [RFC4954  <https://tools.ietf.org/html/rfc4954>]         |
>     |             |                                 | [RFCXXXX]         |
> <https://mailarchive.ietf.org/arch/msg/ima/IWLgpfyrx80mggZbVEsAiaFI6hE/>
> Before the final version of this draft, if I remember it correctly, 
> when we asked whether we should change "UTF8SMTP" "UTF8SMTPA" 
> "UTF8SMTPS"... to something else, some WG members recommended that we 
> just keep it.

My personal opinion is that the likelyhood of older versions being 
implemented is low and my desire to minimize number of different WITH 
keywords is high, so I think the decision in RFC 6531 not to change 
keywords is the right one.

Best Regards,

Alexey

> *From:* John C Klensin <mailto:[email-masked]>
> *Date:* 2021-01-04 13:35
> *To:* ima <mailto:[email-masked]>; YAO Jiankang <mailto:[email-masked]>
> *CC:* ars-ads <mailto:[email-masked]>
> *Subject:* Rather serious bug in RFC 6531
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: "John Levine" <[email-masked]>
Date: 4 Jan 2021 12:32:48 -0500

>keywords is the right one.

Having just done some EAI compliance tests for the UASG, I can report
that all the systems that have any EAI support at all do what the RFC
says. The SMTP keyword is SMTPUTF8, and the WITH clause is UTF8SMTP.
(Well, except for Microsoft whose WITH clauses are wrong with or
without EAI.)

At this point I am not aware of any live implmentations of the experimental
version other than in IMAP at Coremail, and that one is sufficiently broken 
that I doubt anyone is using it.

I agree we should leave it alone.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Jan 2021 13:26:18 -0500

--On Monday, January 4, 2021 12:32 -0500 John Levine
<[email-masked]> wrote:

>> My personal opinion is that the likelyhood of older versions
>> being  implemented is low and my desire to minimize number of
>> different WITH  keywords is high, so I think the decision in
>> RFC 6531 not to change  keywords is the right one.
> 
> Having just done some EAI compliance tests for the UASG, I can
> report that all the systems that have any EAI support at all
> do what the RFC says. The SMTP keyword is SMTPUTF8, and the
> WITH clause is UTF8SMTP. (Well, except for Microsoft whose
> WITH clauses are wrong with or without EAI.)

This is good to know, but since it would be really strange for
an implementation to ignore the spec, make its own guesses as to
what the keywords should be, and then use them, it would be
surprising if it were otherwise.  The only case we might see
would be one using the old SMTP extension keyword of UTF8SMTP,
which would indicate the experimental protocol.   Good news that
we are not seeing that and we can only hope that all
implementations sending out SMTPUTF8 are actually conforming to
the Proposed Standard protocol in area where they are different.
Our of curiosity, are/were your tests sensitive enough to tell
the difference?

As you hint, Microsoft has significant history of qualifying for
"really strange", going back at least to the implementations of
Exchange Server in the early 1990s whose version of SMTP used an
X.400 design and terminology.

> At this point I am not aware of any live implmentations of the
> experimental version other than in IMAP at Coremail, and that
> one is sufficiently broken  that I doubt anyone is using it.
> 

I think it is important that we discuss this and make an
explicit decision.  The big argument for making a change is that
people (notably yourself included) get confused as refer to the
SMTP extension and associated changes as "UTF8SMTP".  That is
much better than referring to them as "EAI", but having three
terminology options where we should have one is unhealthy and
confusing to those who are not insiders and even some of us.  On
the other hand, if the specified WITH keywords are widely
deployed (as they seem to be) and we don't expect to see a
significant number of new implementation in the near or mid-term
future (I haven't noticed a significant rate of growth recently,
but maybe others have), inflicting a change on everyone as the
result of a mistake we didn't catch a decade ago does not seem
wise or appropriate.

best,
   john

---

From: "John Levine" <[email-masked]>
Date: 4 Jan 2021 14:01:16 -0500

>Our of curiosity, are/were your tests sensitive enough to tell

They weren't looking for nested addresses if that's what you're
asking. But if they used UTF8SMTP as the keyword, they'd have failed
and nobody did.  I noticed the Coremail IMAP stuff because it was
failing tests in odd ways.

>explicit decision.

I think we should make an explicit decision to leave it alone. If we
changed it I wouldn't expect implementations to change anytime soon.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Jan 2021 16:32:04 -0500

--On Monday, January 4, 2021 17:16 +0800 Jiankang Yao
<[email-masked]> wrote:

>    |  WITH       | Description                     | Reference
> |    | protocol    |                                 |
> |    | types       |                                 |
> |
> +-------------+---------------------------------+-------------
> ------+    | UTF8SMTP    | ESMTP with UTF8SMTPbis          |
> [RFCXXXX]         |    | UTF8SMTPA   | ESMTP with UTF8SMTPbis
> and SMTP | [RFC4954]         |    |             | AUTH
> | [RFCXXXX]         |    | UTF8SMTPS   | ESMTP with
> UTF8SMTPbis and      | [RFC3207]         |    |             |
> STARTTLS                        | [RFCXXXX]         |    |
> UTF8SMTPSA  | ESMTP with UTF8SMTPbis and both | [RFC3207]
> |    |             | STARTTLS and SMTP AUTH          |
> [RFC4954]         |    |             |
> | [RFCXXXX]         |   

Yes,  We know about that -- the same text is in the RFC and it
would have been strange of impossible for it to have been
changed (back) without anyone noticing.
 
> Unless there are such objections, the new keyword notification
> will be forwarded to the RFC Editor and IANA."

But that message, clearly talks about SMTPUTF8 only, not the
WITH keywords.  If anything, given the comparison toe the
Experimental version of the spec, it could be taken as implying
that the latter should be changed to match, but it certainly is
not explicit about that.

> Before the final version of this draft, if I remember it
> correctly, when we asked whether we should change "UTF8SMTP"
> "UTF8SMTPA" "UTF8SMTPS"... to something else, some WG members
> recommended that we just keep it.

My memory is fading, but I don't remember that discussion and
certainly do not remember a consensus call on the subject.  For
the reasons given in the response I just sent to John Levine and
noting that the WG even went out of its was to specify that the
email internationalization protocols should be known as
"SMTPUTF8" and not "EAI" [1], I cannot imagine that there would
not be been strong objections to leave the old WITH keywords,
Not only would the risk of confusion been clear, but the
tradition with WITH keywords is that they are a close match to
the particular protocol or extension in use.   I certain believe
you what you say that some people said "just keep it", but
strongly suspect this just dropped through the cracks rather
than being the result a specific question and WG consensus.

> Anyone remember it? discussion in the mailing list or the

See above.  Not in any of my notes or on the design team list.

It appears to me that, in chronological order, (i) the authors
failed to identify this as a possibly significant issue and
source of confusion and insist that the WG discuss it and make
an explicit decision, (ii) the co-chairs didn't either, (iii) no
one in the WG read the document carefully enough to identify the
issue and insist that it be discussed and consensus reached
(either while the document was under development or during WG
Last Call), (iv) the WG co-chairs and document shepherd didn't
notice before passing the document off to IESG, (v) no one
studied it carefully enough during IETF Last Call either, (vi)
IANA didn't notice or question it, but that isn't their job,
especially when they were not asked to make a change, (vii) nor
did the ADs at them time.

No one of the groups of people in the above list are at fault;
we all are.  I don't know whether to interpret as bad news for
the way document reviews are done in the IETF (and hence what
"IETF Consensus" about a document means) or more evidence that
the not enough people are paying serious attention to i18n
issues to make the IETF a place to do competent work in that
area.

_However_, that would all be relevant to 6531 if we were a month
or two post-publication and had then just noticed.  At this
point, eight years on, it no longer makes a difference and, IMO,
the _only_ question is whether the disadvantages of the
terminology difference and likely continuing terminology
confusion outweigh the likely inconvenience and confusion of
making a change.

Alexey and John Levine prefer "no change".  Speaking as an
individual only, I think the argument is strongly for "no
change" if we believe that almost every MTA that is going to
implement SMTPUTF8 has already done so.   If we believed that
today's MTAs would be in the minority a decade from now (I don't
think I believe that), then it might be worth making the change,
dealing with the pain of transition, and waiting for current
implementation to catch up (probably quite a while as John L
predicts -- it is certainly not something I would prioritize if
I were making those types of decisions).

best,

[1] For all the good that did.

---

From: [email-masked]
Date: Mon, 04 Jan 2021 09:53:15 -0800 (PST)

> (Well, except for Microsoft whose WITH clauses are wrong with or

FWIW, we generate the entire list of values: UTF8SMTP[A][S] and UTF8LMTP[A][S]
as necessary.

> I agree we should leave it alone.

Yeah, this seems like the right choice to me as well.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 5 Jan 2021 09:17:42 -0500

> FWIW, we generate the entire list of values: UTF8SMTP[A][S] and UTF8LMTP[A][S]

I think everyone else does, too.  The code is pretty simple. replace the 
prefix E with UTF8.

There's a buglet in Courier where he forgets to remove the E, e.g., 
UTF8ESMTPS.  I think I sent him the one-line fix.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly