Subject: [EAI] Last Calls issued

From: John C Klensin <[email-masked]>
Date: Thu, 06 Sep 2012 11:32:04 -0400

Hi.

Just to be sure the WG is informed, the Last Calls have been
issued on the four IMAP/POP documents.  They contain the "should
be reviewed, evaluated, and understood together" language that
we requested.  The Last Call expires two weeks from today.
Statements of enthusiasm from WG participants would be welcome.
I am assuming there will be no surprises from those who receive
this list given the many, many, requests we've made for reviews
and comments.

The Last Call announcements themselves were copied to this list.

    john

---

From: Barry Leiba <[email-masked]>
Date: Thu, 6 Sep 2012 14:49:05 -0400

> The Last Call expires two weeks from today.

If, indeed, there are no surprises, I (as an IESG member, but not your
responsible AD) see no particular value in statements of enthusiasm
from WG participants.  Those are of more value in WGLC, I think.  The
IESG is aware, from the shepherd writeup, of the consensus of the WG,
and I think a quiet last call period will be just fine.

Of course, if issues are raised during last call, WG participants are
encouraged to speak up and set folks right.

Barry, the other App AD

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Sep 2012 16:05:01 -0400

Barry,

That certainly works for me -- we have occasionally gotten
signals to the contrary from some other ADs, but you and Pete
have the lead on this.

best,
   john

--On Thursday, September 06, 2012 14:49 -0400 Barry Leiba
<[email-masked]> wrote:

>> Statements of enthusiasm from WG participants would be
>> welcome. I am assuming there will be no surprises from those
>> who receive this list given the many, many, requests we've
>> made for reviews and comments.
> 
> If, indeed, there are no surprises, I (as an IESG member, but
> not your responsible AD) see no particular value in statements
> of enthusiasm from WG participants.  Those are of more value
> in WGLC, I think.  The IESG is aware, from the shepherd
> writeup, of the consensus of the WG, and I think a quiet last
> call period will be just fine.
> 
> Of course, if issues are raised during last call, WG
> participants are encouraged to speak up and set folks right.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 6 Sep 2012 17:15:53 -0400

> signals to the contrary from some other ADs, but you and Pete

Understood, and Pete can say otherwise: he's the responsible AD.  I
think expressions of "I read it, and it's ready" from WG participants
during WGLC are valuable, to assure us that there was sufficient
review.  But during IETF last call, unless there are issues the WG has
to respond to, I think the WG record can stand on its own.

b

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Sep 2012 17:33:57 -0400

--On Thursday, September 06, 2012 17:15 -0400 Barry Leiba
<[email-masked]> wrote:

> Understood, and Pete can say otherwise: he's the responsible
> AD.  I think expressions of "I read it, and it's ready" from
> WG participants during WGLC are valuable, to assure us that
> there was sufficient review.  But during IETF last call,
> unless there are issues the WG has to respond to, I think the
> WG record can stand on its own.

Certainly that is consistent with my personal view.  Unless the
IETF Last Call turns up controversies, a conclusion that is
carefully checked within the WG should basically stand on its
own, without adding to the noise on  the IETF list.

   john

---

From: Franck Martin <[email-masked]>
Date: Thu, 6 Sep 2012 22:36:06 +0000

Hi all,

I'm joining late, but I have a concern, and because I see now a deadline,
I'm going to short cut heavily. I'm sorry in advance, but I just learn of
the workgroup about a week ago and I have been busy on other things, I
could not get up to speed correctly.

Here in short my concern, and I just need to be pointed to some prior
discussion so I can form an opinion.

My personal concern, in the documents of the workgroup, is the
specification change of the From header from mailbox-list to address-list,
I think these concerns are partly articulated in the security section of:
http://tools.ietf.org/html/draft-leiba-5322upd-from-group-03

Some protocols attempt to validate that originator address by
   matching the "From" address to a particular verified domain (see
   Author Domain Signing Practices (ADSP) [RFC5617
<http://tools.ietf.org/html/rfc5617>] for one such
   protocol).  Such protocols will not be applicable to messages that
   lack an actual email address (whether real or fake) in the "From"
   field, and local policy will determine how such messages are handled.
   Senders, therefore, need to be aware that using group syntax in the
   "From" might adversely affect deliverability of the message.

As you may know, there is a new specification being developed, DMARC,
where the goal will be to hand it over to the IETF. While ADSP has not
seen much traction, DMARC while still a young specification has seen some
traction with today a seriously large amount of mailboxes protected by
DMARC.

Like ADSP, the articulation of DMARC is based on the domain name(s)
present in the From: header, because these are labels visible to the end
user at the MUA level. Removing such labels from the From: headers, may
render the situation more difficult, therefore lowering the authentication
advantage of DMARC. I'm for increased authentication capabilities
(security) not less.

I can see, this notation is used in this set of documents applying to all
headers and in particular the From: header which is somehow rendered to
the end user via the MUA.

We are going to move into an IPv6 world, where there is a non-null
possibility that reputation will be organized around other labels than the
IP address.

In short, I don't understand why in the case of a downgrade, the email is
not represented with the domain part in punnycode, while the local part
could be left blank, or could be a special label like x-utf8local

To be noted, this is my own writing, this is not the view of the DMARC
group, nor the view of my employer, etcŠ But I felt I needed to say
something before the door close.

So I just need a bootstrap to the relevant archives and discussions.

Thanks.

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Sep 2012 19:49:47 -0400

Franck,

Three very general comments may help here.   They may not make
you happy, but should at least clarify things a bit.

(1) Anything that tries to make careful tests on headers is
going to need rethinking for the EAI/ SMTPUTF8 extensions.  The
particular issue with group "From:" headers is just the tip of a
rather large iceberg that has, e.g., a much larger effect on
canonicalization and comparisons for DKIM.  That set of issues
are discussed to some extent in RFC 6530.

(2) The only place where EAI-related specs specifically call for
the use of that empty group syntax on "From:" is in the
interface between an SMTPUTF8-compliant IMAP or POP server and a
legacy client.  For most purposes, if you are doing anti-spam
filtering, it would be before the message enters the mail store
and so would be unaffected by this change.  There is no
assumption that message originators will ever use group syntax
in "From:" (and I note that there is no equivalent in the SMTP
envelope FROM command unless you count "<>" (which has other
implications, of course).  Passing messages with empty group
syntax in the "From:" field to a POP or IMAP client just about
guarantees that the message will not be reply-able by ordinary
means, but that would be true of anything else that could be
transmitted to such a client.

(3) We could, as you suggest, have preserved the domain name in
that particular downgrading model.  But doing so would have
required some very peculiar syntax that would be almost certain
to break existing (legacy) implementations.  Consider, as just
one example, what 
   From: Encoded-Name: @domain;
(with no local-part) might do to a header parser.  Even then, it
would apply only to that one, optional, downgrade case.  It
wouldn't help on the SMTP wire and it wouldn't help with any
other downgrading strategy.  If, on the other hand, you are
suggesting rendering the local-part into some encoding like
Punycode, the WG has been over variations on that option more
times than I can count.  The short summary is that it just isn't
feasible, especially if one expects to preserve the 5321
principle that no system prior to the delivery server is
permitted to interpret (or transform) the local part of an email
address. 

Independent of where the problem manifests itself, message
originators will need to be aware that use of addresses or other
features that require SMTPUTF8 risks deliverability problems.
Of course, if a user provides only a non-ASCII address, failure
to use SMTPUTF8 facilities _guarantees_ non-deliverability.

If you think some additional warnings about the possible
implications of actually using group syntax in "From:" are
needed, I suggest that the place to argue for putting them is in
draft-leiba-5322upd-from-group.

best,
   john

p.s. The work that led to this WG started in roughly 2003.  The
WG was chartered in 2005 and the work has been widely discussed
in a number of forums in the subsequent eight or nine years.  If
there is more that we should have done to be sure you and others
became aware of it before last week, I'd like to know for future
such efforts.

--On Thursday, September 06, 2012 22:36 +0000 Franck Martin
<[email-masked]> wrote:

> Hi all,
> 
> I'm joining late, but I have a concern, and because I see now
> a deadline, I'm going to short cut heavily. I'm sorry in
> advance, but I just learn of the workgroup about a week ago
> and I have been busy on other things, I could not get up to
> speed correctly.
> 
> Here in short my concern, and I just need to be pointed to
> some prior discussion so I can form an opinion.
> 
> specification change of the From header from mailbox-list to
> address-list, I think these concerns are partly articulated in
> the security section of:
>    matching the "From" address to a particular verified domain
> (see    Author Domain Signing Practices (ADSP) [RFC5617
>    protocol).  Such protocols will not be applicable to
> messages that    lack an actual email address (whether real or
> fake) in the "From"    field, and local policy will determine
> how such messages are handled.    Senders, therefore, need to
> be aware that using group syntax in the    "From" might
> adversely affect deliverability of the message.
> 
> 
> As you may know, there is a new specification being developed,
> DMARC, where the goal will be to hand it over to the IETF.
> While ADSP has not seen much traction, DMARC while still a
> young specification has seen some traction with today a
> seriously large amount of mailboxes protected by DMARC.
> 
> Like ADSP, the articulation of DMARC is based on the domain
> name(s) present in the From: header, because these are labels
> visible to the end user at the MUA level. Removing such labels
> from the From: headers, may render the situation more
> difficult, therefore lowering the authentication advantage of
> DMARC. I'm for increased authentication capabilities
> (security) not less.
> 
> I can see, this notation is used in this set of documents
> applying to all headers and in particular the From: header
> which is somehow rendered to the end user via the MUA.
> 
> 
> We are going to move into an IPv6 world, where there is a
> non-null possibility that reputation will be organized around
> other labels than the IP address.
> 
> In short, I don't understand why in the case of a downgrade,
> the email is not represented with the domain part in
> punnycode, while the local part could be left blank, or could
> be a special label like x-utf8local
> 
> To be noted, this is my own writing, this is not the view of
> the DMARC group, nor the view of my employer, etcŠ But I felt
> I needed to say something before the door close.
> 
>> issued on the four IMAP/POP documents.  They contain the
>> "should be reviewed, evaluated, and understood together"
>> language that we requested.  The Last Call expires two weeks
>> from today. Statements of enthusiasm from WG participants
>> would be welcome. I am assuming there will be no surprises
>> from those who receive this list given the many, many,
>> requests we've made for reviews and comments.
>> 
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Franck Martin <[email-masked]>
Date: Fri, 7 Sep 2012 00:25:45 +0000

John,

Thanks for the quick comments/info.

1) will read RFC 6530 then

2) the issue is that the MUA is not passed the domain to render it to the
user. While I understand the goals of MUA UI developers are sometimes at
the antipodes of the security people. I still think it is important to
pass this label to the MUA. If the MTA and MUA are all UTF8 compatible,
then there is no issue, but not sure how fast the transition will be. This
is why I raise this point here and not in draft-leiba-5322upd-from-group
only.

3) I understand the local part cannot be punycoded. So what I was
suggesting is a constant string for the local part that means, could not
convert, but the domain part would be puny code

Something like

From: "John Doe" <x-utf8-invalid@domain>
Or
From: "John Doe" <x-utf8-noreply@domain>

The noreply string tends to be interpreted by various automatic
software(email list management) correctly.

Finally, netease (chinese biggest ISP) is doing DMARC filtering, I'm
worried they will be an early adopter of this spec and will quickly get
conflicted with DMARC, and I'm not sure DMARC will win over the users
requesting readable UTF8 email addresses.

I'm not sure about the warning, this could indeed help to get people to be
careful, I'm worried that if we put in DMARC to reject such emails, as
draft-leiba-5322upd-from-group security note says, then getting DMARC
though IETF will hit a conflict with a prior RFC and therefore rewritten
in a way that minimizes DMARC effectiveness. May be the security
consideration in draft-leiba-5322upd-from-group just need to be copied and
pasted in all these RFCs?

PS to the PS: shit happens. The DMARC spec is public since end of January
but similar mechanisms have been tested well before. We tried to reach
wide, but you can't keep an eye on everything and no one raised this issue
early to the DMARC group AFAIK. I guess, this WG has already considered
ADSP, and reached a conclusion. I just need to get the executive summary
;).

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Sep 2012 22:20:04 -0400

--On Friday, September 07, 2012 00:25 +0000 Franck Martin
<[email-masked]> wrote:

> 2) the issue is that the MUA is not passed the domain to
> render it to the user. While I understand the goals of MUA UI
> developers are sometimes at the antipodes of the security
> people. I still think it is important to pass this label to
> the MUA. If the MTA and MUA are all UTF8 compatible, then
> there is no issue, but not sure how fast the transition will
> be. This is why I raise this point here and not in
> draft-leiba-5322upd-from-group only.

The WG has been over this territory several times, although in
slightly different form.  Consider that, if the delivery MTA
cannot accept SMTPUTF8 messages, we have a non-issue: such a
message will never reach the mail store, much less the POP or
IMAP client.  It is only when all of the following conditions
are met that the situation you are concerned about would arise:

	* The delivery MTA is SMTPUTF8-capable
	* The mailstore has been upgraded to match
	* The POP and/or IMAP servers have also been upgraded.
	* The POP or IMAP client are ASCII-only as far as
	   headers are concerned.

Now POP, IMAP, and 5322 (and 5321, but it is not particularly
relevant to POP and IMAP clients) all require that address
fields, with the exception of the group syntax (where it is
allowed) consist of a local-part and a domain, separated by "@".
If a non-ASCII address arrives at the POP/IMAP server-client
boundary, it cannot be transmitted to the client without doing
something that, as far as the existing/legacy specs are
concerned, is screwy.  The WG concluded that, of many options
that it considered, the use of Group syntax, even in the
backward-pointing fields, was least likely to cause harm.   But
suppose some other conclusion had been reached and the plan was
to change the "From:" syntax to permit "<@domain>" without a
local part, or perhaps <[]@domain>, or perhaps a new header
field, say 

     From-Domain: Domain-using-A-labels

In each of those cases, the odds are extremely high that a
legacy client would either reject the construction as a syntax
error or get terribly confused.  None of those options would
help you.  So what you now need is a client that is upgraded to
handle the new form of the information.  The WG's conclusion was
that it made no sense to encourage such "halfway" client
upgrades because the work needed to implement and deploy them
wasn't likely to be that much different from the work to
implement and deploy fully upgraded, SMTPUTF8-capable, clients.
And they don't have the problem.

So I think the advice we would give you is that, if you need the
MUA to receive domain information contained in non-ASCII "From:"
addresses, you recommend either fully upgraded MUAs or that the
delivery MTA be configured to not accept SMTPUTF8 mail at all.
Nasty tradeoff, but you are going to find everything else more
than a little fragile.

> 3) I understand the local part cannot be punycoded. So what I
> was suggesting is a constant string for the local part that
> means, could not convert, but the domain part would be puny
> code

Again, considered by the WG as an alternative and rejected.
Part of the reason is that while there are a bunch of
conventions floating around, the community has been been very
reluctant to reserve local-part strings in the protocol:
"postmaster" is the only exception, and it goes back to almost
the beginning.

> software(email list management) correctly.

And to be interpreted as a normal address by other things.

> Finally, netease (chinese biggest ISP) is doing DMARC
> filtering, I'm worried they will be an early adopter of this
> spec and will quickly get conflicted with DMARC, and I'm not
> sure DMARC will win over the users requesting readable UTF8
> email addresses.

I'll let the readers of this list who are more familiar with the
situation in China respond if they think it appropriate but,
again, the only good solution is to be sure users have
fully-upgraded clients.

> I'm not sure about the warning, this could indeed help to get
> people to be careful, I'm worried that if we put in DMARC to
> reject such emails, as draft-leiba-5322upd-from-group security
> note says, then getting DMARC though IETF will hit a conflict
> with a prior RFC and therefore rewritten in a way that
> minimizes DMARC effectiveness. May be the security
> consideration in draft-leiba-5322upd-from-group just need to
> be copied and pasted in all these RFCs?

Again, I think the actual situation here will be much more
constrained in practice than you are assuming.  And, again,
there is no satisfactory solution other than upgrading.  A
strong warning to not use empty group syntax in a remapped
"From:" field is essentially a request to refuse to deliver mail
content with internationalized headers to a legacy client.  That
causes a lot of messages to fail too.

> PS to the PS: shit happens. The DMARC spec is public since end
> of January but similar mechanisms have been tested well
> before. We tried to reach wide, but you can't keep an eye on
> everything and no one raised this issue early to the DMARC
> group AFAIK. I guess, this WG has already considered ADSP, and
> reached a conclusion. I just need to get the executive summary
> ;).

Ack.

best,
    john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 7 Sep 2012 08:32:21 +0200

> delivery MTA be configured to not accept SMTPUTF8 mail at all.

Keep in mind that upgrading MUAs to accept internationalized mail is 
extremely easy.

Arnt

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 7 Sep 2012 15:08:55 +0800

----- Original Message ----- 
From: "Arnt Gulbrandsen" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 07, 2012 2:32 PM
Subject: Re: [EAI] Last Calls issued

> Keep in mind that upgrading MUAs to accept internationalized mail is 

Some  email server companies in China will release EAI SMTP server products  supporting rfc6531 and RFC6532 in the end of this year.
Hope to see available EAI MUA soon. 

Jiankang Yao

---

From: Franck Martin <[email-masked]>
Date: Fri, 7 Sep 2012 12:18:03 +0000

>Keep in mind that upgrading MUAs to accept internationalized mail is

Like it is easy to upgrade away from IE6? Still 0.6% of users are using
it, and it was still at 2% a year ago.

Upgrades are slow, and 2% is still a number that scares marketers when you
tell them you won't be supporting that many...

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Sep 2012 08:46:42 -0400

--On Friday, September 07, 2012 12:18 +0000 Franck Martin
<[email-masked]> wrote:

>>> So I think the advice we would give you is that, if you need
>>> the MUA to receive domain information contained in non-ASCII
>>> "From:" addresses, you recommend either fully upgraded MUAs
>>> or that the delivery MTA be configured to not accept
>>> SMTPUTF8 mail at all.
>> 
>> Keep in mind that upgrading MUAs to accept internationalized
>> mail is extremely easy.
> 
> Like it is easy to upgrade away from IE6? Still 0.6% of users
> are using it, and it was still at 2% a year ago.
> 
> Upgrades are slow, and 2% is still a number that scares
> marketers when you tell them you won't be supporting that
> many...

But, Franck, that is exactly where Arnt's comments and mine come
together.  There are only three choices for getting the
information you want to a client:

(i) Upgrade the client to accept internationalized mail.

(ii) Upgrade the client to accept and process some new and funky
syntax (or specialized new header fields) to as to preserve some
of the information in internationalized mail but not to actually
accept internationalized mail.

(iii) Decide that internationalized mail won't get to the
client, whether it is rejected by the delivery MTA or just not
delivered in some other way.  

The POP-IMAP "downgrade" mechanisms are really members of the
family of (iii) -- they don't deliver the message, they deliver
a surrogate that helps the user understand that some things are
inaccessible until the client is downgraded (or they access the
message through some other client, etc.).  If one concludes
those surrogate messages are a bad idea, then one works out
non-delivery in some other way, such as by hiding the fully
internationalized messages from the user entirely.  Reasons why
one might conclude "bad idea" include not being able to reply to
the message (from one perspective, not because information is
lost but because one did not receive the message), because key
information is lost in the surrogate-creation process (your
situation with domain names is just one example -- message
signatures will probably be high on the list for others), as
well as "just too much trouble".

The WG concluded that, of those three choices, the second one
makes no sense.  It is substantially as hard to implement as the
first.  It involves the same statistics, the same deployment
problems, and the same likely resistance from marketers.

Wrt IE and other examples, the problem is, in part, the need to
install something new, learn something new, etc., without an
expectation of improvements that is compelling to users.  Here,
that message is very simple: "you want to be able to send
messages to or receive mail from users with internationalized
addresses or setups, you are going to upgrade".   

In terms of speed of penetration of the upgrades, I'd actually
worry a lot more about users of European, Latin-script,
languages than about China.  For the former, ASCII may be "good
enough".  For the latter, a fairly strong case has been made
that it is not.  That is precisely why Jiankang's data show
implementation commitments that are well ahead of any
implementation commitments we've seen from Europe or North
America.  How the transition will play out in the latter in
terms of what delivery servers will accept (and what addresses
will be permitted) relative to development and deployment of POP
and IMAP clients and servers is, at this point, anyone's guess.
For China, it will deploy because people are convinced that they
need it and because, from a marketing standpoint, critical mass
will probably be reached quickly and _not_ having upgraded
software will become intolerable.   At least that is the general
best guess.

    john

---

From: Franck Martin <[email-masked]>
Date: Fri, 7 Sep 2012 12:51:21 +0000

>And to be interpreted as a normal address by other things.

And will just bounce, like many other thingsŠ I don't see the issue to
reserve a local-part string in the protocol if it ensure greater security
with not loosing much convenience.

>causes a lot of messages to fail too.

Getting the client to upgrade to benefit of the complete From: info, seems
a reasonable approach, but I'm worried of the time the situation is left
in limbo.

The MTA can reject unauthenticated emails following DMARC, but for cousin
domains, at the moment we rely on the user to see that the email did not
come from the right domain.

>> reached a conclusion. I just need to get the executive summary

So reading https://datatracker.ietf.org/doc/draft-ietf-eai-email-clients

Is there normative information than ensure a receiving SMTPUTF8 compatible
MTA MUST reject an email that contains a group syntax address in the From:
? Because there is no reason why the UTF8 email address cannot be
transmitted (unless we have some serious relaying).

There is still the case of a SMTPUTF8 compatible MTA sending to a legacy
MTA, where the From: may contain a group syntax. This would oblige DMARC
compatible receivers to upgrade to SMTPUTF8 quickly. I thought tying up
the adoption of one standard to the other is frown uponŠ

I'm still uneasy as the WG prefers a convenient solutions rather than a
secure one, and all of this is handled in the backend, it is not like we
ask the user to do these things.

I'm afraid we are opening a door where the group syntax can be used even
in a fully UTF8 compatible environment. As a transition mechanism, may be,
and even, we have seen transition can take years...

---

From: Franck Martin <[email-masked]>
Date: Fri, 7 Sep 2012 12:57:34 +0000

>(i) Upgrade the client to accept internationalized mail.

When is the upgrade date? ;)

>accept internationalized mail.

I'm not talking of some funky syntax here. Not sure why you focus on that.
A reserved local string is not funky syntax.

>delivered in some other way.

You know if this traffic is non-null the marketers will screamŠ.So
deciding unilaterally/locally to reject this type of email will not fly.
This has to be defined in the standard.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 7 Sep 2012 15:40:38 +0200

> it, and it was still at 2% a year ago.

No, not like that. If you want an IE comparison: like it was easy for IE 
to implement support for <meta charset>.

Arnt

---

From: Joseph Yee <[email-masked]>
Date: Fri, 7 Sep 2012 10:45:12 -0400

On Fri, Sep 7, 2012 at 8:57 AM, Franck Martin <[email-masked]> wrote:

<snip>

> A reserved local string is not funky syntax.

Hi Franck,

If the string is simple dictionary string, then the chance of stepping
over existing user expectation & behaviour is very high.  Then the
only possible choice left is to concatenate some non-dictionary
strings (like xn--*, x-*, *----pleaseupgradeyouremailclient) to make
it unique for both human and machine.  And this adds some funkiness to
the syntax.

Then in practice one have to guard the use of the new non-dictionary
string in all account name very well against confusion and malicious
use.  You are not only have to guard against account name under your
management, you have to guard the email name with similar pattern
coming to your users.

Joseph

---

From: [email-masked]
Date: Fri, 07 Sep 2012 07:30:11 -0700 (PDT)

> delivered in some other way.

To be fair, these group thingies are being produced in downgrade
context where the expectation is that the client hasn't been upgraded.

If this was known to cause an actual problem with a widely deployed client then
I and probably several others would have objected. But tests were done and that
doesn't appear to be the case. If there's evidence (not speculation, evidence)
to the contrary, please present it.

But the broader point is that there is no magic bullet here. It would have been
great if the magic upgrade fairy had graced us with its presence and fixed the
installed base with a wave of the wand. But that didn't happen, so a choice had
to be made amongst various less-than-great alternatives, each involving some
sort of tradeoff.

> problems, and the same likely resistance from marketers.

Exactly. And as it happens I personally disagree with the choice that was made.
But you won't find me arguing that there was a way to avoid all the tradeoffs.

> enough".

More likely ISO-8859-X or something similar at this point. But from
an EAI perspective it's pretty much the same thing.

  For the latter, a fairly strong case has been made
> software will become intolerable.   At least that is the general

That's certainly the hope. And the risk.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 7 Sep 2012 16:49:47 +0200

On 09/07/2012 02:46 PM, John C Klensin wrote:
> message through some other client, etc.).

Surrogate message. That's the right term.

If I had thought of that, that's what I would have written. Is it still 
worth changing, and does anyone else agree that surrogate is a better 
word than synthetic?

(Yes, the message is both synthetic and a surrogate. But I feel that 
surrogate goes to the heart of the thing.)

Arnt

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Sep 2012 11:43:43 -0400

--On Friday, September 07, 2012 16:49 +0200 Arnt Gulbrandsen
<[email-masked]> wrote:

>> family of (iii) -- they don't deliver the message, they
>> deliver a surrogate that helps the user understand that some
>> things are inaccessible until the client is downgraded (or
>> they access the message through some other client, etc.).
> 
> If I had thought of that, that's what I would have written. Is
> it still worth changing, and does anyone else agree that
> surrogate is a better word than synthetic?
> 
> (Yes, the message is both synthetic and a surrogate. But I
> feel that surrogate goes to the heart of the thing.)

First, let's see if others agree (or at least don't object).  If
they do and Pete is ok with this, let's handle this (and any
other comments from within the WG) as a small variation on the
normal Last Call process: Joseph or I will send a note to the
IESG around the 19th or 20th summarizing any changes the WG
concluded it ought to make.

For planning purposes, I don't want to see new drafts before the
21st because they would just confuse people about what Last Call
comments are based on.  But I hope to have new drafts of any
documents we decide should be modified (I know that
popimap-downgrade is already on the list and your note probably
adds simple downgrade) can be posted right after that so the
actual IESG review and vote can occur on cleaned-up documents
that reflect any Last Call comments with which we agree.

Ok?
   john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 7 Sep 2012 17:48:08 +0200

> Ok?

Sure.

I'm happy with or without the change. Either way is good and while 
"best" is better than "good", the price of change rises as publication 
nears.

Arnt

---

From: [email-masked]
Date: Fri, 07 Sep 2012 11:32:56 -0700 (PDT)

> > surrogate is a better word than synthetic?

I like surrogate better - more specific - but if we've used synthetic in
multiple places we need to coordinate the change.

> concluded it ought to make.

WFM.

				Ned

---

From: Pete Resnick <[email-masked]>
Date: Fri, 7 Sep 2012 16:13:29 -0500

> own, without adding to the noise on  the IETF list.

Indeed, not only do I agree that they add little value, I have sometimes 
been downright negative about such comments. My own view is that 
consensus building (and judging) is about finding objections and 
addressing them. Statements of support are nice, but are simply happy 
fluff. They are equivalent to (though much nicer than) statements of the 
form, "I just don't like this document." (*Shrug*) Not helpful.

So, please do keep an eye on the IETF list and address any objections. 
But statements of support or enthusiasm are unnecessary.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

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

> A reserved local string is not funky syntax.

It's a Very Big Deal to reserve a local-part, and I would agree to do
it only in extreme circumstances.  This isn't one.  What's more, this
doesn't even *approach* any criteria I might use to agree to do that,
because this is a transitional case in a *very* limited situation.

Further, the overarching point here is to make sure that whatever is
in the From *cannot* be a valid address that can ever be replied to.
That means that it *cannot* be a valid address *currently*... that it
will be something that existing non-EAI-compliant M*As will allow use
of in replies.  Any reserved name will be allowed in replies by any
M*A that is not updated to conform to this, and that could cause
someone to intercept replies by registering whatever local-part we try
to reserve, hoping that he will snag confidential replies that way.

We absolutely can't allow that.

---
John has reminded you of this, but let me highlight it and ask some
specific questions:

- These protocols suggest using group syntax in From *only* in the
specific situation where an EAI-compliant IMAP or POP server is giving
the message to a non-EAI-compliant IMAP or POP client, in response to
that client's asking for it.

- Protocols such as ADSP and DMARC will mostly be used *upstream* of
that path, at or before the message reaches the MDA.

- The use of the group syntax is *only* to allow the non-EAI-compliant
IMAP or POP client to see some semblance of the message, rather than
being told that the message is unavailable to it.

- The translation of the non-ASCII From address into group syntax will
preserve the address, in 2047-encoded form, as the "name" of the
group, so an MUA can still display it.

Here are my questions, Franck:

- To what extent do you think DMARC (or ADSP) will be applied *in
clients* (MUAs)?

- To what extent do you think there will be situations where DMARC
will cause the message to be flagged such that the MUA warns the user
herself to look carefully at the "from" domain?

- In those situations, do you think my last point above will not
suffice, that the user will not be able to look at the 2047-decoded
group name?

- Do you think, given that these specs are coming out *before* DMARC,
that it's unreasonable to expect (or for DMARC to require) that
clients that are updated to conform to it also implement EAI?

Barry

---

From: "John Levine" <[email-masked]>
Date: 9 Sep 2012 21:03:59 -0000

>it, and it was still at 2% a year ago.

I think those numbers confirm that it is indeed easy to upgrade away
from IE6, since over 99% have done so.  People still using it have
some other issue.

I really don't understand your problem with DMARC and empty From:
headers.  DMARC is not the FUSSP, and there will always be mail to
which it is not applicable.  Given that it doesn't even attempt to
deal with slightly misspelled domain names (paypai.com, or your
friends at [email-masked]), it's hard to see what new
problems an empty From: header would introduce.

As other people have noted, we expect little or no use except in mail
downgraded during a POP or IMAP fetch, and in those cases DMARC would
have done whatever it does long before the downgrade happened.

R's,
John

---

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

The game is to close the hole not making it bigger because there is already a hole. Secondly, I wish people in this group aware of DMARC would have pointed the DMARC group to this upcoming standard. This would have avoided late minute disruptive discussions.

It is was me, the spec for from: would be to contain one and one only mailbox.

I have not yet encountered some uses of the mailbox list syntax, if it is not for buggy MTAs when doing out of band bounces.

I would classify the mailbox-list syntax as deprecated, but I understand IETF prefers in general to extend than restrict.

As for banqofamerica.com its reputation is different from bankofamerica.com and that would be sufficient for emails not reaching the mailbox if needed. Secondly the end user can read the difference, with an empty from this is not possible anymore.

Printed on recycled paper!

---

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

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

> The game is to close the hole not making it bigger because
> there is already a hole.

Personal opinion only...

I don't think anyone has suggested that.  What I would suggest
(others might disagree) is that filtering on the details of what
appears in "From:" (banqofamerica.com notwithstanding) is a
fairly weak approach.  If nothing else, it seems to share the
properties of several other techniques (DNSSEC itself included)
that ultimately rely on the integrity and good behavior of
domain name registrars in handling names.  That isn't a
particularly good assumption.

That is not to suggest that it cannot be useful.  For those who
believe that the solution to Spam lies in destination- or
near-destination filtering, anything that produces a noticeable
decrement in the number of "bad" messages that are caught is
probably worth investigating and maybe implementing.  But unless
such a technique (maybe in combination with others) really is
the FUSSP, many of us are going to be very resistant to reducing
email functionality in the hope of stopping a few more "bad"
messages.

> Secondly, I wish people in this group
> aware of DMARC would have pointed the DMARC group to this
> upcoming standard. This would have avoided late minute
> disruptive discussions.

But, if your comments are indicative of the position of the
DMARC group, it merely would have resulted in the discussion
appearing earlier.  Several people have given you the reasons
why the WG made the decisions that it did and explained the
difficulties with your counterproposal (a variation of which was
considered by the WG and was actually in an early draft of the
spec).   As far as I can tell, you haven't offered a single new
refutation of counterargument to those decisions, so I don't
believe the outcome would have been and different.

> It is was me, the spec for from: would be to contain one and

Now _that_ discussion occurred on, I think, the 822 list some
months ago.  The community was fairly strongly against a change
for reasons that parallel my explanation earlier today.  The
discussion was certainly not "hidden" in the EAI WG.

> I have not yet encountered some uses of the mailbox list
> syntax, if it is not for buggy MTAs when doing out of band
> bounces.

I'd encourage you to search the archives, but 

   From: [email-masked], [email-masked]

is actually a very useful construction.  It may not be really
common, but parallels the occasional need for two of more people
to sign a paper letter.  Remember, this isn't the envelope we
are talking about.   If you care more about the message sender
than the originator(s), you should be looking at "Sender:" in
the presence of "From:" information that is more complex than
you would like.  Of course, that won't help with the group
issue, but they are really separate problems.  If you want to
use mail header fields as validators, your protocol really needs
to understand and follow the mail specs, not try to reinvent
them in a way that would be more convenient for you.

> I would classify the mailbox-list syntax as deprecated, but I
> understand IETF prefers in general to extend than restrict.

I'd argue that has not been the case with email when reducing
flexibility increases interoperability without significantly
reducing functionality.  You might find it helpful to review the
rather extensive Section 4 of RFC 5322 to calibrate statements
like the assertion you make above.
 
> As for banqofamerica.com its reputation is different from
> bankofamerica.com and that would be sufficient for emails not
> reaching the mailbox if needed. Secondly the end user can read
> the difference, with an empty from this is not possible
> anymore.

One can argue about differences in quality of heuristics, but
any classification test based on the contents of a "From:" field
is ultimately a heuristic that will work better in some cases
than others.  If you wanted to classify a message that uses
group syntax in "From:" (or "Sender:") on the public Internet as
at high risk of being garbage, I don't think anyone would fault
that as a heuristic (although some people might get concerned if
you started silently dropping messages on that basis).  It would
also be completely consistent with the "don't do that" language
in Barry's revised text.

So I'm unsure what you are still concerned about.  If you want
to explain further, please start that explanation with answers
to the questions Ned Freed raised.

best,
    john

---

From: Franck Martin <[email-masked]>
Date: Sun, 9 Sep 2012 22:37:30 +0000

>discussion was certainly not "hidden" in the EAI WG.

Never claimed it was hidden

>them in a way that would be more convenient for you.

It is indeed not common at all. It is nice to have the capability in
theory but in practice, we may gain by not having it. To be noted this is
my opinion and not the one of the DMARC group, as there is an obvious
solution to the presence of several mailboxes in the From:

Note, the group did consider to use the Sender: header but this was
rejected.

>like the assertion you make above.

I think moving From to as single mailbox reduce flexibility increases
interoperability without significantly reducing practical functionality
and increase security.

>to the questions Ned Freed raised.

You mean Barry?

I'm just probing around to gain understanding.

---

From: Franck Martin <[email-masked]>
Date: Sun, 9 Sep 2012 22:54:35 +0000

>- To what extent do you think DMARC (or ADSP) will be applied *in

I think the ultimate goal is to display in the MUA the domain vouching for
the email. Some does already with DKIM. A domain that is protected by
DMARC or ADSP could have a higher confidence.

As you know, we are not UI designers and we can only recommend what the
MUA should do, or use what the MUAs already do (display the email address
of the From: header).

>herself to look carefully at the "from" domain?

DMARC should reject the email at the injection, so this is not the way it
would work. The user should be suspicious of an email because it looks
like a know mailer but the domain is not the one commonly used by the
mailer. I think this kind of capability may take time to do in software,
but is better in wetware.
 
>suffice, that the user will not be able to look at the 2047-decoded

The Friendly From is certainly an issue.

Consider the sending of such email:
From: "Paypal " <UT8@UTF8>

>clients that are updated to conform to it also implement EAI?

It means that DMARC MUST be installed on an MTA that does SMTPUTF8?

Even so there is still an issue, I think:

SMTPUTF8MTA1----downgrade---USASCIIMTA---SMTPUTF8MTA2.

This email should be transmitted but it allows the injection of anything
to SMTPUTF8MTA2 by design despite increased warning in the specs.

---

From: John C Klensin <[email-masked]>
Date: Sun, 09 Sep 2012 19:10:59 -0400

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

>...
> This email should be transmitted but it allows the injection
> of anything to SMTPUTF8MTA2 by design despite increased
> warning in the specs.

This is a non-case, as I and others have explained several
times.  The USASCIIMTA will not advertise SMTPUTF8 (because it
has never heard of it and certainly doesn't support it or it
would be an SMTPUTF8-MTA).

Assuming that the message actually requires SMTPUTF8 capability,
SMTPUTF8MTA1 _MUST_ reject the message at that point (or do
whatever it does in lieu of rejection).  That is an envelope
issue and fundamental to the SMTP extension model.  The message
will _never_ reach USASCIIMTA, and (obviously, I hope) it won't
reach SMTPUTF8MTA2 _in any form_ unless whatever sent the
message to SMTPUTF8MTA1 generates a new (and different),
ASCII-only/ 5321-conforming, message and sends it.  

If you don't believe this is explained adequately in RFCs 5630
and 5631, I'd personally welcome suggestions for improvement
(and I'm confident that Yangwoo and Jiankang would too).  But it
is just not an issue for the IMAP/POP specs that are now in Last
Call... and it has absolutely nothing to do with Group syntax.

   john

---

From: "John R Levine" <[email-masked]>
Date: 9 Sep 2012 20:31:30 -0400

> The game is to close the hole not making it bigger because there is 
> already a hole. Secondly, I wish people in this group aware of DMARC 
> would have pointed the DMARC group to this upcoming standard. This would 
> have avoided late minute disruptive discussions.

The reason I didn't mention this to DMARC is that it is completely 
irrelevant.  No matter how much you want DMARC to be a FUSSP, it is not 
one, it cannot be one, and there is no chance whatsoever to make all mail 
do what DMARC wants, any more than we can make it do what SPF or DKIM 
wants.

Perhaps after you've fixed the lookalike domain "hole", come back and tell 
us how you did it, and we'll think about it.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

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

...
> but is better in wetware.

In other words, this really has nothing to do with DMARC.  You're
concerned that users should be shown the purported From domain, and
that in this one, specific, limited "downgrade" scenario they won't
be.

And I'm saying that you seem to understand neither the downgrade
situation nor the mechanism.  See below.

> From: "Paypal " <UT8@UTF8>

In that case, the downgraded result will show "Paypal" in the
"friendly" text and "UT8@UTF8" in the group name.  In clients that
will show both, the user will still see both (but won't be able to
reply to it).  In clients that will only show the friendly name,
"Paypal" is all that will appear in any case.  So the "downgrade"
situation is still showing the desired information to the user (modulo
things like font support, of course).

The whole point of the "downgrade" is to try to provide as much of the
original information as possible to the user agent, without giving the
user agent stuff it can't handle (such as UTF8 in the local-part).

> It means that DMARC MUST be installed on an MTA that does SMTPUTF8?

No; I said "clients", because I'd understood your complaint to have to
do with DMARC in clients.  Because it doesn't, then this question and
its answer don't apply.

> to SMTPUTF8MTA2 by design despite increased warning in the specs.

This is why I say you don't understand the downgrade scenario.  What
you show above is not valid.  The Experimental specs included an
experimental downgrade stage as you show above.  The experiment failed
-- it was determined to be unworkable -- and it is not in the
Standards Track specs.  As John says, the step that says "downgrade"
in your chain above will now be "bounce", and the message will go no
farther.

Please read *all* of the Standards-Track versions of the EAI specs and
understand how it works.  Start with the Framework doc, RFC 6530,
which will explain the system as a whole.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 10 Sep 2012 10:50:05 +0100

On 07/09/2012 16:43, John C Klensin wrote:
> First, let's see if others agree (or at least don't object).
"Surrogate" is Ok with me. It seems slightly better than "synthetic", 
but I have no strong opinions either way.
> If