Subject: Re: [EAI] Downgrade simplifications

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 6 Aug 2009 10:34:40 +0800

----- Original Message ----- 
From: "Ernie Dainow" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 04, 2009 11:25 PM
Subject: [EAI] Downgrade simplifications

>I think there are a number of things we can change to make Downgrade 
> simpler and have less impact on existing email systems yet still provide 
> the key backward compatibility that many people feel is important to the 
> success of EAI.
> 
> The current design of Downgrade is very comprehensive. A lot of clever 
> things were done to provide Downgrade in every possible situation and to 
> provide a complete audit trail through the use of new Downgraded headers 
> that also provide the ability to reconstruct the original UTF8 address 
> information (Downgraded display). We can greatly simplify Downgrade by 
> limiting the design goals to support only essential cases and make clear 
> that Downgrade is an interim feature, is not perfect and does not 
> provide a complete audit trail.
> 
> 1. As recommended in 4.2 of  draft-ietf-eai-email-clients and in various 
> emails on the EAI list, we should consider downgrade of forward-pointing 
> (recipient) addresses as a configuration error and not something that 
> Downgrade needs to support. Then we can remove Alternate Addresses for 
> recipients. I think this would also allow us to redesign Downgrade 
> without the double angle bracket syntax which seems to be the source of 
> a lot of compatibility and security concerns.

this is a good idea. I also wonder whether we need the downgrading for recipient.

in practise, only "downgrade from address" may be useful.

> 
> 2. Implementation of Downgrade is currently an option for MUA, POP/IMAP. 
> Consideration of these cases in draft-ietf-eai-email-clients (3.1.1, 
> 3.2) is that these are unusual configurations. The standard should be 
> explicit and state that Downgrade is only done by MTAs.

this issue need more discussions.

> 
> 3. While an audit trail and ability to display original UTF8 addresses 
> from a Downgraded message is a nice feature, some people consider the 
> case in which this is useful to be a configuration error (an EAI MUA, 
> POP or IMAP behind a non-EAI MTA.). In any case, it is not an essential 
> feature within the revised design goals outlined above. If it is 
> dropped, then all the added "Downgraded-" headers can be dropped.

I remeber that the WG decided to have no upgrading after downgrading.

> 
> 4. Alternate Addresses for the sender can be handled in the "Accounts" 
> setting of the MUA. They can also be provided by the SMTP server, as in 
> draft-yao-eai-deployment. Since there is no interface for the MUA to 
> find out from the server if it needs to provide Alternate Addresses or 
> not, this ambiguity may lead to unexpected behavior in terms of which 
> Alternate Address gets used if it is provided by both. 

+1

the possible phising will be reduced if the alternate address is only provided by smtp server.
if the alternate address is provided by MUA, the user can put any address they want such as [email-masked] or [email-masked] . 

>While the server 
> solution offers a certain amount of transparency to the end user, the 
> MUA solution is more general in that it supports a legacy ASCII Address 
> that may be on a different email provider. 

when you register an email account, you can apply both the ascii email account and non-ascii email account from the same company or organization.

>The standard should resolve 
> this ambiguity and specify that Alternate Address for the sender is 
> provided by the MUA and not the server.

if we decide to have no downgrade issue in RFC5336 5335, then you are right. otherwise, we may consider that only by server, not by MUA.

> 
> 5. Capturing UTF8 addresses in empty groups when Downgrading should be 
> dropped. This has numerous interoperability problems with existing mail 
> clients (3.2.1 in draft-ietf-eai-email-clients).
> 
> To make a clean line between Downgrade and the rest of the EAI standard, 
> so that we can move ahead with standards track of the latter while 
> continuing to work on experimental track Downgrade, all normative 
> requirements relating to Downgrade should be pulled out of the EAI 
> documents and moved into the Downgrade document. So for example, the 
> ALT-ADDRESS parameter should be moved from RFC 5336 to the Downgrade 
> document and the addr-spec for double angle brackets moved out of RFC 
> 5335 into the Downgrade doc (or dropped if 1. above can be achieved).

+1.

I personally agree this suggestion.

Yao Jiankang
CNNIC

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Aug 2009 14:00:58 -0400

--On Thursday, August 06, 2009 10:34 +0800 YAO Jiankang
<[email-masked]> wrote:

>... 
> the possible phising will be reduced if the alternate address
> is only provided by smtp server. if the alternate address is
> provided by MUA, the user can put any address they want such
> as [email-masked] or [email-masked]. 

Do you mean the submission server?  If it is provided by a
random SMTP (relay) server, I think we are in for deeper
problems as well as a need to relax current requirements of 5321
about not changing messages in transit.

But, even if it is the submission server, it seems to me that
what you accomplish by moving responsibility there (rather than
in the MUA) is to:

-- Make it harder for users of many systems to provide alternate
addresses, since few Submission Servers support the relevant
databases for supplying alternate addresses today.  At minimum,
we would have to advise that RFC 4408 servers be updated to
maintain databases of, and insert, that information.

-- Prevent casual users and vandals from supplying alternate
addresses that have nothing to do with the primary (EAI) ones
but not provide a barrier higher than minor inconvenience to any
serious attacker.  Such an attacker could, in principle, use a
compromised MSA.  Of course, EAI downgrading increases an
existing problem only slightly -- nothing prevents my sending
out a message "From" [email-masked] or [email-masked]
today.. EAI alternate addresses might serve to hide the fact
that I had done that, but only with an MUA that tended to hide
those addresses (and not others).

>> While the server 
>> solution offers a certain amount of transparency to the end
>> user, the  MUA solution is more general in that it supports a
>> legacy ASCII Address  that may be on a different email
>> provider. 
> 
> when you register an email account, you can apply both the
> ascii email account and non-ascii email account from the same
> company or organization.

We have had that conversation before.  You are assuming a
particular model of how MUAs, Submission Servers, and mail
providers generally interact.  It may be the best such model,
but it isn't the only one and there is nothing, anywhere, that
standardizes it or makes it a requirement for EAI implementation
or deployment.  There are also some useful examples of
situations in which it may not be the right model.  For example,
assume that my Russian had not deteriorated from fluency to
non-existent in the last 50 years.  I might maintain a personal
address of 
   [email-masked]
but want to have the mail sent to a business-address mailbox if
it could not be delivered there, say
   [email-masked]
That would give my From: field a structure like
   From: <[email-masked] <[email-masked]>>

Which definitely do not reflect the same domain and might or
might not reflect the same server.

>...

   john

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 11 Aug 2009 10:19:59 +0800

----- Original Message ----- 
From: "Ernie Dainow" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 04, 2009 11:25 PM
Subject: [EAI] Downgrade simplifications

snips
> 5335 into the Downgrade doc (or dropped if 1. above can be achieved).

In this wg list, we have discussed a lot about EAI downgrade simplifications.
I totally agree with Dainow's suggestion above.

In our original design, the downgrade method with alt-address is supposed to be transitional.
In the long term, the alt-address will hurt the email system although the alt-address may help the deployment of EAI system in the short term.
Considering the tradeoff, we may suggest the following changes to the originnal RFC of EAI WG. 

RFC 4952bis framework document updates some material about the downgrading, such as that "if smtp server does not support the utf8smtp authorizied by RFC5336bis, the sender may  consider the method described in the RFC5504bis".
 
RFC5336bis remove ALT-ADDRESS parameter to the RFC5504bis 
RFC5335bis  remove the addr-spec for double angle brackets into the RFC5504bis.

the suggested category is that
RFC4952bis [informational]
RFC5336bis [standard track]
RFC5335bis [standard track]
RFC5504bis [experimental]
any comments are welcome.

Yao Jiankang

---

From: Joseph Yee <[email-masked]>
Date: Tue, 11 Aug 2009 09:54:32 -0400

If we took this approach,  EAI will get on standard track while  
Downgrade may be in experimental forever.  And I doubted that how many  
will look back to downgrade again once EAI gets on standard track.

And the split approach means that we need 2 ESMTP keywords, something  
like UTF8SMTP and UTF8SMTP=ONLY to identify 2 different MTA  
behaviors.  And we are creating more versions if to create downgrade  
capable instance afterwards.

I'm not entirely against it, but I hoped we all aware (and accept) of  
the issues of doing so.

We are facing the delivery dilemma of backward-compatible vs filtering.

Emails delivery in modern day are subject (or at mercy) of firewall  
and content filter.  Before these 2 updated for EAI, there will always  
be some aggressive filtering on
	1. 8 bit in address and header (MIME encoding requirement gone,  
except binary file attachment)
	2. not realized the new address format and new header type
	3. considered mails in foreign languages are spams

To the whole WG:
1. How valuable is backward compatible?
2. At what condition do we consider success on EAI message passing  
thru firewall & content filter?  (Someone asked similar question  
during the last IETF meeting)

Best Regards,
Joseph Yee

On 10-Aug-09, at 10:19 PM, YAO Jiankang wrote:

> In the long term, the alt-address will hurt the email system  
> although the alt-address may help the deployment of EAI system in  
> the short term.
> RFC 4952bis framework document updates some material about the  
> downgrading, such as that "if smtp server does not support the  
> utf8smtp authorizied by RFC5336bis, the sender may  consider the  
> method described in the RFC5504bis".
>

---

From: Joseph Yee <[email-masked]>
Date: Tue, 11 Aug 2009 11:35:08 -0400

On 11-Aug-09, at 10:57 AM, John C Klensin wrote:

>
>
> --On Tuesday, August 11, 2009 09:54 -0400 Joseph Yee
> <[email-masked]> wrote:
>
>> If we took this approach,  EAI will get on standard track
>> while Downgrade may be in experimental forever.  And I doubted
>> that how many will look back to downgrade again once EAI gets
>> on standard track.
>
> Actually, I thing EAI would get on Standards Track with an
> extremely narrowed-down version of Downgrade, probably also on
> Standards Track.  I just see no practical way to continue the
> current Downgrade document (RFC5504) as experimental without
> including the forward-pointing Alt-Address syntax in the base
> Headers document (RFC 5335).   If that syntax is in 5335bis as a
> "require to recognize" (at least), then we are stuck with it
> forever and, IMO, we need to demonstrate that it is not
> problematic.   If it isn't in 5335bis, then it is dead,
> regardless of the standards-track status of 5504bis.
>
> As I commented in an earlier note, I don't think Yao, Ernie, and
> myself disagree in any fundamental way, but we won't know until
> a strawman document is produced.  I definitely will not be able
> to produce that document in the next couple of weeks, but
> perhaps someone else will.  Otherwise, I'd be happy to try to
> take an active role in September.
>
>> And the split approach means that we need 2 ESMTP keywords,
>> something like UTF8SMTP and UTF8SMTP=ONLY to identify 2
>> different MTA behaviors.  And we are creating more versions if
>> to create downgrade capable instance afterwards.
>
> Perhaps my understanding of what is being proposed really does
> differ from Yao's -- or at least your reading of Yao's -- but I
> don't see a need for any such thing.   Remember that the current
> Downgrade model permits bouncing (or rejecting) a message that
> cannot be forwarded as an alternative to applying the Downgrade
> ritual.  We are just eliminating some of the Downgrade logic and
> some of the options.

I'm referring to removing downgrade entirely from all current doc and  
move forward to standard track.  I could misinterpret what brought up  
by Yao.

> RFC5336bis remove ALT-ADDRESS parameter to the RFC5504bis

I'm in favor of simplifying downgrade and push it to standard track  
along with all doc, but not leaving it behind in experimental.   
Looking up to your first paragraph first sentence is what I hope to be  
the way.

Joseph

[remove rest of content for better read]
...

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 Aug 2009 10:57:21 -0400

> I'm not entirely against it, but I hoped we all aware (and
> accept) of the issues of doing so.
> 
> Emails delivery in modern day are subject (or at mercy) of
> firewall and content filter.  Before these 2 updated for EAI,
> there will always be some aggressive filtering on
> 	1. 8 bit in address and header (MIME encoding requirement
> gone, except binary file attachment)

Both true whether we have Downgrade or not.  However, note that,
if everything is working correctly (including configurations)
those systems will never see EAI addresses or headers except,
possibly, as an isolated (comma-separated) backward-pointing
address that they don't know how to interpret or consider a
syntax error.

> 	3. considered mails in foreign languages are spams

I expect that filters based on "I can't read that language or
script, so anything arriving in it in my mailbox is unwanted"
will persist forever.  Nothing this WG can do, with or without
downgrading, will help with that.  It is also not an EAI problem
-- there are several languages written with Latin characters
that I might reasonably specify filters to reject because there
is no hope of my reading the text even if my machine can render
all of the characters.

> 1. How valuable is backward compatible?

Speaking personally, I think extremely valuable if we can make
it happen.  But <addr <addr2>> is the exact opposite of backward
compatibility and reliance on a collection of new headers that
are at least slightly order-sensitive isn't a great deal better.

> 2. At what condition do we consider success on EAI message
> passing thru firewall & content filter?  (Someone asked
> similar question during the last IETF meeting)

Please separate firewalls and content filters that have been
upgraded from those that have not and note the comment about
content filters above.  The root of several of our comments is
that, if an EAI message hits a non-upgraded one of these things,
then either there is a configuration error or something is badly
broken, or both and that the Internet has never needed an
explicit "if this address doesn't work, try that one" capability
in SMTP.

     john

---

From: SM <[email-masked]>
Date: Wed, 12 Aug 2009 01:39:14 -0700

>the suggested category is that

[snip]

>RFC5504bis [experimental]

Does the WG need more time to determine whether the experiment is a 
success or not?  Once the other specifications are moved to Standard 
Track, there won't be any effort to do something about RFC5540bis.

>1. How valuable is backward compatible?

It's better to also consider what can be done to favor successful 
delivery of the message.   Having backward compatibility as the 
constraint affects that.

>during the last IETF meeting)

That depends on whether the receiving side has an incentive to fix the problem.

>are at least slightly order-sensitive isn't a great deal better.

In terms of backward compatibility, that syntax might be viewed as a 
mistake by people unfamiliar with EAI.

At 05:02 11-08-2009, John C Klensin wrote:
>(4) We encourage the use of
>    From: addr1, addr2
>as a representation of
>    MAIL FROM:<addr1>, ALT-ADDRESS="addr2"
>Doing so requires that we accept the fact that the semantics are
>a little different and the observation that multiple "From:"
>fields are not well supported.   We may have to encourage better
>support, think about whether clarifying language in RFC 5322bis
>is needed about what replies to such messages means, and so on.
>But support for multiple From-address syntax has been specified
>and required for many years (so no new syntax).  I note that
>there is, properly, no multiple-address syntax for "Sender:",
>but think we can live with that.   Using "From:" that way really
>is a transition mechanism-- when it ceases to be useful, it
>disappears.

There has been some discussion outside this WG about multiple "From:" 
addresses.  In comparison, it is less problematic than the new 
syntax.  It is worth considering the option to change the semantics.

There may be some problems with the "Reply-To:" header because of the 
way it is used by mailing lists.  There are also some MUAs which do 
not emphasize that it is optional.  Note that "Reply-To:" has a 
multiple-address syntax.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2009 08:10:29 -0400

--On Wednesday, August 12, 2009 01:39 -0700 SM <[email-masked]>
wrote:

>...
> There may be some problems with the "Reply-To:" header because
> of the way it is used by mailing lists.  There are also some
> MUAs which do not emphasize that it is optional.  Note that
> "Reply-To:" has a multiple-address syntax.

Could you elaborate on the first part of this?  I can imagine
several problem scenarios, but am wondering about which ones you
have experienced and/or have in mind.

As was briefly discussed in Stockholm, I think that, quite
independent of these other issues, we have a big problem moving
forward unless the mailing list issues are well-understood and
documented.  While there may be disagreement within the WG about
how perfect the mailing list solution needs to be (I don't know
whether there is or not), I think that clear documentation and
explanations are a very important requirement.

    john

---

From: SM <[email-masked]>
Date: Wed, 12 Aug 2009 16:28:25 -0700

Hi John,
>have experienced and/or have in mind.

I'm exploring a scenario where we have a multiple-address syntax in 
the "From:" as follows:

   From: EAI-addr, ASCII-addr

The above specifies the mailboxes responsible for the writing of the 
message.  Note that for EAI purposes (this is _not_ in the existing 
specifications), there is only one author.

We can set a preference for the reply by including a "Reply-To:" 
header as follows:

   Reply-To: EAI-addr

If the EAI-addr is removed because of a downgrade, we still have an 
address (ASCII-addr) to reach the author of the message.

When a message goes through an EAI-aware mailing list, it can happen 
that the "Reply-To:" header gets stripped as some mailing lists set 
an explicit reply to the list. We lose the preference set by the 
author of the original message and we may have to generate a reply to 
both addresses.

If the mailing list is not EAI-aware, we have to downgrade by 
removing the EAI-addr.  We end up with one email address in the 
"From:" (ASCII-addr) and the "Reply-To:" header is removed.

The main question about mailing lists which are EAI-aware is how to 
handle the subscription request.  Some software use the address from 
the (envelope) "MAIL FROM:".  As we can distinguish between the 
address and alt-address in there, it's not an issue.  However, if the 
"From:" is used with a multiple-address syntax, we might end up with 
two subscription requests.  It may be possible to get around that by 
using the address in the "Reply-To:" header as long as it only 
specifies one address.

We could also use the same "mechanism" to determine whether the 
message is from an existing subscriber if the mailing lists restricts 
postings to existing subscribers.  That is also applicable for 
requests to unsubscribe from the mailing list.

For List-* headers, we could use two URLs, one with a "mailto:" to an 
ASCII-addr and the other to an EAI-addr.  Even if those headers are 
downgraded wiith the removal of the EAI component, there will still 
be a valid address.

The is an off-topic comment.  I came across a case where a message 
was sent from A to B (an automated agent) with a "Reply-To:" header 
containing two addresses, A and C.  B generated a reply to A and C.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2009 20:25:29 -0400

--On Wednesday, August 12, 2009 16:28 -0700 SM <[email-masked]>
wrote:

>> several problem scenarios, but am wondering about which ones
>> you have experienced and/or have in mind.
> 
> I'm exploring a scenario where we have a multiple-address
> syntax in the "From:" as follows:
> 
> The above specifies the mailboxes responsible for the writing
> of the message.  Note that for EAI purposes (this is _not_ in
> the existing specifications), there is only one author.

To be more precise, the existing specification doesn't specify
the relationship among the From: addresses at all.  So it could
be two addresses for one author, addresses for two authors, etc.

> We can set a preference for the reply by including a
> "Reply-To:" header as follows:
> 
>    Reply-To: EAI-addr
> 
> If the EAI-addr is removed because of a downgrade, we still
> have an address (ASCII-addr) to reach the author of the
> message.

Yes.   Of course, if we had no Reply-to header field at all,
most (but not all) MUAs would assume the contents of the From:
field, so, at least for those MUAs,
      From: EAI-addr, ASCII-addr
      Reply-To: EAI-addr, ASCII-addr
and the From: field with no Reply-to would be equivalent.
 
> When a message goes through an EAI-aware mailing list, it can
> happen that the "Reply-To:" header gets stripped as some
> mailing lists set an explicit reply to the list. We lose the
> preference set by the author of the original message and we
> may have to generate a reply to both addresses.

Yes.  And now I see what you are getting at.  Sorry for being
slow.

> removing the EAI-addr.  We end up with one email address in
> the "From:" (ASCII-addr) and the "Reply-To:" header is removed.
 
> The main question about mailing lists which are EAI-aware is
> how to handle the subscription request.  Some software use the
> address from the (envelope) "MAIL FROM:".  As we can
> distinguish between the address and alt-address in there, it's
> not an issue.  However, if the "From:" is used with a
> multiple-address syntax, we might end up with two subscription
> requests.

If I were writing mailing list software, I'd take serious
exception to the idea of subscribing the From: address if there
were more than one of them.  Indeed, that is exactly what I did
many years ago -- multiple "From:" addresses implied that one
needed to specify  the address one wanted to subscribe
explicitly.  I assume that some mailing list packages don't do
that.

> It may be possible to get around that by using the
> address in the "Reply-To:" header as long as it only specifies
> one address.

I think subscribing a Reply-to: address would be a really bad
idea.  One would need either a single address in the "From:"
header field (ideally, one that exactly matched the address in
the MAIL command), or one would need a command to the mailing
list manager that specifies the relevant address.

Again, this is an area in which our giving explicit advice would
probably be welcome.  And we need to get the mailing list
document done.

> We could also use the same "mechanism" to determine whether
> the message is from an existing subscriber if the mailing
> lists restricts postings to existing subscribers.  That is
> also applicable for requests to unsubscribe from the mailing
> list.

Modulo the above, yes.

> For List-* headers, we could use two URLs, one with a
> "mailto:" to an ASCII-addr and the other to an EAI-addr.  Even
> if those headers are downgraded wiith the removal of the EAI
> component, there will still be a valid address.

Yes.

> The is an off-topic comment.  I came across a case where a
> message was sent from A to B (an automated agent) with a
> "Reply-To:" header containing two addresses, A and C.  B
> generated a reply to A and C.

Unless I'm missing something, I think that is the correct
behavior... unless B is automated at the MTA level and falls
under the rules that require it to generate   
   MAIL FROM:<>
in which case I think it should be using the return-path address.

   john

---

From: SM <[email-masked]>
Date: Thu, 13 Aug 2009 03:46:09 -0700

Hi John,

Yes.

>and the From: field with no Reply-to would be equivalent.

In the example I gave, there was only an EAI-addr in the 
"Reply-To:".  That was to suggest to the recipient to use the EAI 
address instead of the two addresses from the "From:" (see above 
description of MUA behavior).

>explicitly.  I assume that some mailing list packages don't do

I tested that case with two non-EAI addresses by sending a request to 
a mailing list handled by a widely used package.  The reply was sent 
to the first email address specified in the "From:" of the original 
message.  The message body seems to have been generated using the 
(envelope) "MAIL FROM:".  I haven't read the source code to determine 
whether this is an unusual behavior due to the use of sub-addressing 
or if it was actually the address detail of the first "From:" address 
being removed when the address was parsed.

>list manager that specifies the relevant address.

Based on the example you provided above, we would not be able to 
subscribe as we do usually.  We can subscribe by providing the email 
address as a parameter to the subscribe command.  If the mailing list 
manager is not EAI-aware, then it may require a second request if the 
email address provided in the first instance was an EAI one.

>probably be welcome.  And we need to get the mailing list

Agreed.

>in which case I think it should be using the return-path address.

B and C are automated agents operating at the MDA level.  I'll 
categorize them as service responders.  The addresses in the 
"Reply-To:" field should not have been used by B for the 
response.  In this case, that caused B to generate a message for 
C.  I'm not focusing on the correct behavior in this particular case 
as it may be more appropriate to discuss about that in a different 
forum.  The point is more about understanding the response behavior 
when a multiple-address syntax is used.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Aug 2009 07:36:02 -0400

Agree on all comments.

   john

--On Thursday, August 13, 2009 03:46 -0700 SM <[email-masked]>
wrote:

>> the relationship among the From: addresses at all.  So it
>> could be two addresses for one author, addresses for two
>> authors, etc.
> 
> Yes.
> 
> "Reply-To:".  That was to suggest to the recipient to use the
> EAI address instead of the two addresses from the "From:" (see
> above description of MUA behavior).
> 
>> exception to the idea of subscribing the From: address if
>> there were more than one of them.  Indeed, that is exactly
>> what I did many years ago -- multiple "From:" addresses
>> implied that one needed to specify  the address one wanted to
>> subscribe explicitly.  I assume that some mailing list
>> packages don't do that.
> 
> I tested that case with two non-EAI addresses by sending a
> request to a mailing list handled by a widely used package.
> The reply was sent to the first email address specified in the
> "From:" of the original message.  The message body seems to
> have been generated using the (envelope) "MAIL FROM:".  I
> haven't read the source code to determine whether this is an
> unusual behavior due to the use of sub-addressing or if it was
> actually the address detail of the first "From:" address being
> removed when the address was parsed.
> 
> Based on the example you provided above, we would not be able
> to subscribe as we do usually.  We can subscribe by providing
> the email address as a parameter to the subscribe command.  If
> the mailing list manager is not EAI-aware, then it may require
> a second request if the email address provided in the first
> instance was an EAI one.
> 
>> Again, this is an area in which our giving explicit advice
>> would probably be welcome.  And we need to get the mailing
>> list document done.
> 
> Agreed.
> 
> response.  In this case, that caused B to generate a message
> for C.  I'm not focusing on the correct behavior in this
> particular case as it may be more appropriate to discuss about
> that in a different forum.  The point is more about
> understanding the response behavior when a multiple-address
> syntax is used.
> 
> Regards,
> -sm

---

From: Bill McQuillan <[email-masked]>
Date: Thu, 13 Aug 2009 09:57:28 -0700

> be two addresses for one author, addresses for two authors, etc.

<aside>
It occurs to me this ambiguity could have been addressed by clever use of
the languishing <group> syntax:

  From: _aliases_: EAI-addr, ASCII-addr;

but, for no reason I have been able to discern, the <group> capability has
been specifically excluded from the originator fields (From:, Reply-To) in
RFC 5322 and its predecessors.

I have long wondered why 

  From: The Bosses: [email-masked], [email-masked], [email-masked];

was thought not to be useful.

Oh, well.
</aside>

-- 
Bill McQuillan <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Aug 2009 13:24:57 -0400

--On Thursday, August 13, 2009 09:57 -0700 Bill McQuillan
<[email-masked]> wrote:

>...
> <aside>
> It occurs to me this ambiguity could have been addressed by
> clever use of the languishing <group> syntax:
> 
> but, for no reason I have been able to discern, the <group>
> capability has been specifically excluded from the originator
> fields (From:, Reply-To) in RFC 5322 and its predecessors.
> 
> I have long wondered why 
> 

I'm not quite ready to propose it and, given how badly group
syntax has been supported in the areas where it is permitted, it
may not be a good idea. But it seems clear to me that

would do far less violence to the general syntax model than
     From: <EAI-addr <ASCII-addr>>

Interesting...

    john