Subject: [EAI] Last Call: <draft-ietf-eai-popimap-downgrade-07.txt> (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 06 Sep 2012 08:05:26 -0700

The IESG has received a request from the Email Address
Internationalization WG (eai) to consider the following document:
- 'Post-delivery Message Downgrading for Internationalized Email
Messages'
  <draft-ietf-eai-popimap-downgrade-07.txt> as Proposed Standard

Please note: This document is one a set of four interdependent
documents:

draft-ietf-eai-5738bis
draft-ietf-eai-popimap-downgrade
draft-ietf-eai-rfc5721bis
draft-ietf-eai-simpledowngrade

These documents should be reviewed, evaluated, and understood
together.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-09-20. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The Email Address Internationalization (SMTPUTF8) extension to SMTP
   allows UTF-8 characters in mail header fields.  Upgraded POP and IMAP
   servers support internationalized Email messages.  If a POP/IMAP
   client does not support Email Address Internationalization, POP/IMAP
   servers cannot deliver Internationalized Email Headers to the client
   and cannot remove the message.  To avoid the situation, this document
   describes a conversion mechanism for internationalized Email messages
   to be in traditional message format.  In the process, message
   elements requiring internationalized treatment are recoded or removed
   and receivers are able to know that they received messages containing
   such elements even if they cannot process the internationalized
   elements.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgrade/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgrade/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 9 Sep 2012 11:33:24 -0400

>   <draft-ietf-eai-popimap-downgrade-07.txt> as Proposed Standard

Rats; I missed this in earlier review:

-- Section 3.2.1 --

   This procedure may generate empty <group> elements in "From:",
   "Sender:" and "Reply-To:" header fields.
   [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty)
   <group> elements in "From:", "Sender:" and "Reply-To:" header fields.

It does not.  It adds group syntax to "From" only.  Group syntax is
already allowed in "Reply-To", and the draft does not change the rules
for "Sender".

If this spec also needs "Sender" to change, I can update the
5322upd-from-group for that, but it's not there now.

Barry

---

From: John C Klensin <[email-masked]>
Date: Sun, 09 Sep 2012 11:48:12 -0400

--On Sunday, September 09, 2012 11:33 -0400 Barry Leiba
<[email-masked]> wrote:

>...
>    This procedure may generate empty <group> elements in
> "From:",    "Sender:" and "Reply-To:" header fields.
>    [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow
> (empty)    <group> elements in "From:", "Sender:" and
> "Reply-To:" header fields.
> 
> It does not.  It adds group syntax to "From" only.  Group
> syntax is already allowed in "Reply-To", and the draft does
> not change the rules for "Sender".
> 

Barry, I think it does.  The presumption (since before 822) has
been that "Sender:" can contain any address that can appear in
"From:".   The ancient history is that "From:" need not even
contain a deliverable address if "Sender:" is specified to match
a business correspondence model in which:

    From: "Big boss who doesn't use computers"
    Sender: [email-masked]

has to be legitimate.  5322 and its predecessors took some of
that capability away, but the only difference now is that
"From:" can take a list of mailboxes and "Sender:" can take only
one.

I think 5322upd-from-group needs to apply to both
backward-pointing address types to be effective for what
popimap-downgrade needs.

Sorry for not finding this in my reviews -- I should have.

    john

---

From: Barry Leiba <[email-masked]>
Date: Sun, 9 Sep 2012 11:52:59 -0400

> backward-pointing address types to be effective for what

I will make the change.  I'll also remind the EAI group that there
have been a couple of objections to the 5322upd-from-group spec, which
I have to address.  I might do that by scoping it down a bit with some
"SHOULD NOT use" sort of language to address those concerns.  Have to
review them and see.

> Sorry for not finding this in my reviews -- I should have.

As should I have.  Flrg.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sun, 9 Sep 2012 11:55:43 -0400

> I will make the change.

But in any case, the downgrade doc needs to remove "reply-to" from the
list of header fields that 5322upd-from-group changes.  Maybe this:

OLD

NEW
   This procedure may generate empty <group> elements in
   "From:",    "Sender:" and "Reply-To:" header fields.
   [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow
   (empty) <group> elements in "From:" and "Sender:".

Barry

---

From: John C Klensin <[email-masked]>
Date: Sun, 09 Sep 2012 12:15:21 -0400

--On Sunday, September 09, 2012 11:52 -0400 Barry Leiba
<[email-masked]> wrote:

> I will make the change.  I'll also remind the EAI group that
> there have been a couple of objections to the
> 5322upd-from-group spec, which I have to address.  I might do
> that by scoping it down a bit with some "SHOULD NOT use" sort
> of language to address those concerns.  Have to review them
> and see.

My suggestion is to say something like the following:

	A great deal of Internet email procedures and software
	assume that the addresses in "From:" and "Sender:"
	fields can be replied to and are suitable for use in
	mail organizing and filtering.  The use of groups
	instead of mailboxes may disrupt those uses.
	Consequently, with this specification legitimizes the
	use of group syntax, that syntax should be used in those
	fields only under special circumstances and with
	caution.  In particular, users and MUAs should generally
	not permit the use of group syntax in those fields in
	outgoing messages since the syntax will usually provide
	even less information than a null address ("<>") which
	is already prohibited by RFC 5321.

That could be either in Security Considerations or a separate
section.  You could even do something radical and incorporate it
as a section called "Applicability" and use the words "LIMITED
USE" (and, since no one seems to remember, a citation of RFC
2026 Section 3.3).   You can probably figure out how to use
fewer words, but something like that would address the comments
I've seen so far and, IMO, generally strengthen the spec.

best,
   john

---

From: SM <[email-masked]>
Date: Sun, 09 Sep 2012 09:44:38 -0700

Hi John,

>         Consequently, with this specification legitimizes the

As an editorial nit about the last line quoted above:

   Although this specification legitimizes the

Regards,
-sm

---

From: [email-masked]
Date: Sun, 09 Sep 2012 12:01:44 -0700 (PDT)

> 5322upd-from-group for that, but it's not there now.

I think the answer to that is yes, this needs to be allowed for "Sender".

				Ned

---

From: [email-masked]
Date: Sun, 09 Sep 2012 12:28:46 -0700 (PDT)

>    (empty) <group> elements in "From:" and "Sender:".

Looks like the correct change to me.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Sun, 9 Sep 2012 17:01:23 -0400

...
> 2026 Section 3.3).

I have just posted drft-leiba-5322upd-from-group-04:
   http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/

That changes the definition of Sender as well as From, and also adds a
new "Applicability Statement" section that has an edited version of
John's suggested text.  I like the result, and I hope others do as
well.  I will post something to the 5322upd-from-group thread, asking
that those who had objected look at the new text and see if they're
happy (or at least somewhat happier) with it.

Barry

---

From: Franck Martin <[email-masked]>
Date: Sun, 9 Sep 2012 21:58:47 +0000

I'm happier,

Made comments in another thread on why I believe it opens a security hole
wider rather than trying to close it.

I guess I could leave with it, when this downgrade is only done from a
SMTPUTF8 compatible MTA to an ASCII MTA.

I mean a SMTPUTF8 MTA MUST reject such downgrade.

Let's not try to legitimize an attack vector (Friendly from having nothing
to do with the author of the email).

On 9/9/12 2:01 PM, "Barry Leiba" <[email-masked]> wrote:

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

---

From: John C Klensin <[email-masked]>
Date: Sun, 09 Sep 2012 18:47:03 -0400

--On Sunday, September 09, 2012 21:58 +0000 Franck Martin
<[email-masked]> wrote:

> I'm happier,
> 
> Made comments in another thread on why I believe it opens a
> security hole wider rather than trying to close it.
> 
> I guess I could leave with it, when this downgrade is only
> done from a SMTPUTF8 compatible MTA to an ASCII MTA.

But, as several people have tried to remind you, the EAI specs
are consistent with the prohibitions in RFC 5321, prohibitions
that expressedly forbid MTAs from changing addresses enrounte
(for downgrading or any other reason).  The specs in Last Call
now don't apply to MTAs or MTA actions _at all_.  They apply
_only_ to communication between an SMTPUTF8-compatible IMAP or
POP server and a legacy IMAP or POP client.

The experimental versions of the EAI specs did provide for
in-transit downgrading.   The main conclusion from those
experiments (described in RFC 6530, which I'd still encourage
you to read) was that such MTA->MTA downgrading was a bad idea.

So the WG agrees with you, so do the specs, and you are
attacking a (rather worn and threadbare) strawman.

Please focus on where this actually occurs and what the specs
actually say.  And, again, you might start by responding to
Ned's questions.

> I mean a SMTPUTF8 MTA MUST reject such downgrade.

With regard to whether it will tolerate group syntax in
backward-pointing header fields, the decision has absolutely
nothing to do with EAI and whether MTA is SMTPUTF8-capable or
not.  However, to get anything close to a "MUST reject", you'd
need to propose a very radical change to the way email is
specified.   In theory and largely in practice, MTAs deal with
envelopes, not header fields.  RFC 5321 and its successors are
carefully designed to never require that an MTA do anything with
header fields other than prepending information to them.   I
think we all recognize that mail filtering and classification
has created a lot of exceptions in which header fields (and
content) are inspected prior to the final delivery server.  Even
that typically occurs close to either the submission or final
delivery points.  I think you would get a _lot_ of resistance to
a change that would _require_ SMTP MTAs to inspect message
bodies (including header fields) to see if they contained some
offending construction.

> Let's not try to legitimize an attack vector (Friendly from
> having nothing to do with the author of the email).

I've seen no evidence at all that this does any such thing.

   john

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2012 00:53:32 -0000

>SMTPUTF8 compatible MTA to an ASCII MTA.

An SMTPUTF8 compatible MTA will never, ever, send mail to an ASCII MTA
that has addresses that need to be downgraded.

Perhaps this would be a good time to reread the existing EAI RFCs to
be sure you understand the framework within which this is all going on.

R's,
John