Subject: Re: MUA support for multiple from addresses
From: Douglas Otis <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: Mark Andrews <[email-masked]>, Steve Atkins <[email-masked]>, SMTP Interest Group <[email-masked]>
Date: Tue, 13 Mar 2012 15:51:21 -0700
List-Id: <ietf-smtp.imc.org>

On 2/28/12 3:10 AM, John C Klensin wrote:
> --On Tuesday, February 28, 2012 11:31 +1100 Mark Andrews
> <[email-masked]>  wrote:
>
>> ...
>> Well with paper mail you can have mail from multiple people.
>> Someone has to physically post it, but it can have multiple
>> signatures. There should be no reason for email to not support
>> it.  Note SMTP doesn't need to support it.
> Indeed.   And, yes, the SMTP backward-pointing address in the
> MAIL command is really a sender address, not a from address.
>
> I agree with Ned -- deprecating features that poor
> implementations handle poorly would leave us without email.  It
> is far more worthwhile to spend energy telling people to fix
> their garbage implementations than to start deprecating features
> that are very useful on occasion, even if lots of folks don't
> use them and aren't aware they are there.    The use of "+" in
> subaddresses is at least an equally good example: lots of folks
> don't know it is possible; a number of MUAs, a larger number of
> web interfaces of various flavors, and a few MTAs treat it is
> invalid; but, still...
>
>       john
>
> p.s. it has been a while, but I've occasionally used
> multiple-address "From:" on IETF mailing lists when I wanted to
> make it completely clear that a message was produced jointly,
> e.g., from WG co-chairs.
Dear John,

The use of multiple From addresses might become popular.  John Levine 
proposed vouch-by-reference headers and DNS queries where (when a 
reference is trusted) receiver query what might be a third-party domain 
to obtain a TXT resource record confirming domain authorizations.  This 
scheme has a few basic problems:

1) vbr header is not seen by users.
2) vouching domains may not be authoritative.
3) reliant information may not have been signed.

Spoofing remains a security threat when basing acceptance on 
signatures.  Assumed domain authority is yet another security threat.  
This becomes a concern when dealing with potentially unsigned header 
fields containing third-party domains.  DKIM verification only requires 
the last From header field be signed when it is likely only the first 
that is displayed.  DMARC strengthened DKIM compliance by requiring one 
 From header field.

See http://dmarc.org/draft-dmarc-base-00-01.html#receiver_domain

The Authorized Third-Party Signatures (ATPS) draft, 
http://tools.ietf.org/html/rfc6541 has been published and implemented in 
open source versions of DKIM.  ATPS allows third-party domains to be 
compliant with ADSP.  ATPS provisions should also be included with DMARC 
for multiple From email address entries.

From: [email-masked], [email-masked] would be a 
visible method to safely assert affiliations without waiting for 
adoption and enforcement of new headers or exclusion of improperly 
assumed domain relationships.

Outsourcing publication of the _atps zone can use either zone delegation 
or DNAME.  When two different domains appear in the From header field, 
ATPS within a single transaction can determine whether the domain has 
been authorized without risking reliance on unsigned data or 
non-authoritative sources as could be the case with Vouch-by-Reference.

Regards,
Douglas Otis

Date: Sun, 4 Mar 2012 17:31:28 -0600
From: Pete Resnick <[email-masked]>
To: "Carl S. Gutekunst" <[email-masked]>
CC: <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

On 3/1/12 1:51 PM, Carl S. Gutekunst wrote:

> Going back to the original thread, Dave CROCKER wrote:
>> Well, this is sad:
>>
>>    V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
>>
>> http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html 
>>
>
> This rebuttal article in TechDirt is useful for its links to other 
> articles.
>
> http://www.techdirt.com/articles/20120222/11132917842/how-guy-who-didnt-invent-email-got-memorialized-press-smithsonian-as-inventor-email.shtml 
>

And the Post has issued apologies:

http://www.washingtonpost.com/blogs/omblog/post/origins-of-e-mail-my-mea-culpa/2012/03/01/gIQAiOD5kR_blog.html

Well done, Dave and all.

pr

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

Date: Thu, 01 Mar 2012 11:51:53 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: [email-masked]
CC: SMTP Interest Group <[email-masked]>
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

Going back to the original thread, Dave CROCKER wrote:
> Well, this is sad:
>
>    V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
>
> http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html 
>

This rebuttal article in TechDirt is useful for its links to other articles.

http://www.techdirt.com/articles/20120222/11132917842/how-guy-who-didnt-invent-email-got-memorialized-press-smithsonian-as-inventor-email.shtml

<csg>

Date: Thu, 01 Mar 2012 19:07:50 +0100 (MET)
From: Francesco Gennai <[email-masked]>
Subject: Re: "proper" handling of BCC
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Francesco Gennai wrote:
> >

> >> I'd actually rather have an extension that worked the opposite way: Construct
> >> the headers from an appropriately decorated envelope and add them to the
> >> message, and if handling error results from RCPT TO is an issue for clients
> >> have a means to require that only outright syntax errors be reported as a
> >> command result and report all other errors later with a DSN.
> >
> > I would add to this discussion a possible (new?) need about the BCC handling
> > (that come out in some scenario, see below) that is to forbid at MSA level
> > the use of a BCC.

> My Opinion:

> After rethinking this, at first I would agree but I don't quite see
> how this would fall under SMTP (as an extension) due to the wide agree
> of  how the integrated systems are done, i.e. the presumption as I
> read  SMTP would be processing the headers once it is accepted.  

You're right. 
The extension will not solve the problem because I will need to 
check for messages coming from clients that doesn't support it.
 
> Maybe a internal (local vs remote) router will, perhaps even a gateway or a
> mail importer who may be already doing final clean up (i.e. stripping
> Return-Path or old uucp/slip "From " headers are no longer necessary).

> > In this case I agree with the Ned approach (based on a SMTP extension)
> > versus the one that currently we are using in the Italian Certified email
> > system, where we are parsing the TO and CC headers and comparing the result
> > with the list of RCPT-TOs (many platforms have been adapted to be compliant
> > with such MSA requirement).

> Interesting and curious for the genesis of that logic. The two don't
> need to match. The offline MUA used did not do the separation?

I suspect the most of the MUAs just sent only a copy with no BCC header.
 
But in the case that a MUA should generate more than a copy
there could a problem in managing such requirement by just comparing
TO/CC with RCPT-TO (the copy without any BCC address could be accepted.... ) 

....

Francesco

> --
> Sincerely

> Hector Santos
> http://www.santronics.com
> jabber: [email-masked]

Date: Thu, 1 Mar 2012 07:16:01 -0800
To: Ned Freed <[email-masked]>, Randall Gellens <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: "proper" handling of BCC
CC: <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>, Ned Freed <[email-masked]>, Tony Hansen <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 10:58 PM -0800 2/29/12, Ned Freed wrote:

>>  The most useful thing, in my view, is a BCP on how MUAs should
>>  generate messages with BCC recipients, and how MUAs should recognize
>>  when a received message is a result of a BCC, and how to handle
>>  replies etc. in such cases.
>
>  I agree that this is more important than having an extension to offload
>  Bcc: processing to the MSA.
>
>>  I'm intrigued by the behavior mentioned earlier of the originating
>>  MUA mucking with the To and Cc header fields when sending a BCC
>>  version, as an indication of this and to avoid unthinking
>>  reply-to-all actions.  I'm not sure I'm a huge fan of the "[To:]"
>>  business, but enclosing the contents in parens to form a comment
>>  might work.
>
>  I don't think that just having a comment is valid by RFC 5322 rules. That
>  could be an issue.

Good point; list notation might be a better choice.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Everything is controlled by a small evil group to which,
unfortunately, no one we know belongs.

Date: Thu, 01 Mar 2012 10:04:48 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

Francesco Gennai wrote:
> 

>> I'd actually rather have an extension that worked the opposite way: Construct
>> the headers from an appropriately decorated envelope and add them to the
>> message, and if handling error results from RCPT TO is an issue for clients
>> have a means to require that only outright syntax errors be reported as a
>> command result and report all other errors later with a DSN.
> 
> I would add to this discussion a possible (new?) need about the BCC handling 
> (that come out in some scenario, see below) that is to forbid at MSA level 
> the use of a BCC.

My Opinion:

After rethinking this, at first I would agree but I don't quite see 
how this would fall under SMTP (as an extension) due to the wide agree 
of  how the integrated systems are done, i.e. the presumption as I 
read  SMTP would be processing the headers once it is accepted.  Maybe 
a internal (local vs remote) router will, perhaps even a gateway or a 
mail importer who may be already doing final clean up (i.e. stripping 
Return-Path or old uucp/slip "From " headers are no longer necessary).

> In this case I agree with the Ned approach (based on a SMTP extension) 
> versus the one that currently we are using in the Italian Certified email 
> system, where we are parsing the TO and CC headers and comparing the result
> with the list of RCPT-TOs (many platforms have been adapted to be compliant 
> with such MSA requirement).

Interesting and curious for the genesis of that logic. The two don't 
need to match. The offline MUA used did not do the separation?

It always helped me to view this in three parts (perhaps four, trace 
lines) regarding the format or network:

    Network Control Headers
    Display Headers
    Context

The network control lines basically that deals with ensuring routing 
and replies are possible and correct.  Display headers are basically 
those no longer important for networking.

In our system, the operator decides how he mail is stored in preserved 
mode (RFC5322) or converted to the backend default format, which 
includes extraction and storage of attachments prepare it for online 
viewing, keeping only the network control lines as hidden meta fields.
(Some user are allowed only online access, some have POP access, and 
for them he MAY preserves the RFC5322 storage to make sure there is no 
degrading of end to end originality. For some users, he operator may 
have a policy to protect the less savy user so he may get just plain 
text).

Perhaps what I can see here is agree that am existing BCC header 
should be forbidden from the standpoint that who ever massages the 
mail either for final delivery or for further routing that it simply 
strips the BCC from the headers on the presumption there is already a 
separate independent message/transport to the target BCC address done.

There is also the consideration regarding displaying.  The MUA may 
want to inform the BCC recipient to the privacy nature of the message:

     NOTE: THIS IS A BLIND COPY TO YOU. THE OTHER RECIPIENTS LISTED IN 
THE
     TO/CC DISTRIBUTION ARE NOT AWARE OF YOUR RECEPTION OF THIS MESSAGE.

As you probably see, this will help avoid a possible mistake the BCC 
recipient is unaware of the BCC nature the the message and he jump 
into the conversion to the surprise of others the "boss" was listening.

IMV, only the offline MUA can do this when it separates BCC 
distribution from the rest for its SMTP client.  The RFC-based offlne 
MUST always be aware of this responsibility because there is no 
current expectation the SMTP/MSA will. If that isn't already written 
somewhere, perhaps it needs to be done.

But I do agree the backend should do a "Double Check" to remove the 
BCC from public set of messages. Not sure if that is a SMTP issue. 
Maybe RFC 4409?

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

Date: Thu, 1 Mar 2012 14:38:31 +0000
From: Tony Finch <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked], "Robert A. Rosenberg" <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

Ned Freed <[email-masked]> wrote:

> > http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rcpthdr.html
>
> As you might expect, I have a *lot* of problems with this approach.

I should probably say that this isn't a very serious proposal, since it
doesn't actually solve any real-world problems, and it prevents the MUA
from using SMTP extensions that require RCPT parameters. It's more of a
what-if about where the boundaries might be drawn between MUA / MSA / MTA.

> It also requires parsing headers and extracting addresses from them, something
> I'd prefer to avoid and which other approaches do not require.

MSAs should probably be doing this anyway, to avoid propagating malformed
messages.

> But the biggest problem is the approach to consuming Resent-* fields, in
> particular its dependency on header ordering as well as requiring the presence
> of Received: field separators. This is an incredibly fragile way to do it.

In that part I was essentially trying to be explicit about what is already
implied by the existing specifications (822 and 2822) and running code.
This logic has to exist to support things like the `sendmail -t` command,
and in the MUA so that it can display messages correctly (though it can
probably avoid the complexity when sending).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: Southwest, but cyclonic at first in
Cromarty, veering north or northeast, veering east or southeast later, 4 or 5,
increasing 6 at times in Forties and Cromarty. Slight, occasionally moderate
in Forties and Cromarty. Occasional rain. Moderate or good, occasionally poor.

Date: Thu, 01 Mar 2012 10:31:18 +0100 (MET)
From: Francesco Gennai <[email-masked]>
Subject: Re: "proper" handling of BCC
To: [email-masked]
Cc: Tony Finch <[email-masked]>, [email-masked], "Robert A. Rosenberg" <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

> > [email-masked] <[email-masked]> wrote:
> > >
> > > It's certainly possible to have the MSA make the message copy, but we'd
> > > need to define an extension for that. No such extension exists AFAIK.

> > http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rcpthdr.html

> As you might expect, I have a *lot* of problems with this approach. For one
> thing, it mandates what I regard to be the suboptimal way to handle BCC by
> completely deleting the field; as I have previously stated, not having a clear
> indication that you got the message as a Bcc: risks exposure when someone
> mistakenly does a reply-all.

> It also requires parsing headers and extracting addresses from them, something
> I'd prefer to avoid and which other approaches do not require.

> The draft doesn't specify how to handle errors resulting from invalid
> recipient addresses nearly well enough, but this is a correctable problem,
> not a fundamental issue with the approach. (The batch SMTP specification
> already covers most of this so I know it's possible to do.)

> But the biggest problem is the approach to consuming Resent-* fields, in
> particular its dependency on header ordering as well as requiring the presence
> of Received: field separators. This is an incredibly fragile way to do it.

> I'd actually rather have an extension that worked the opposite way: Construct
> the headers from an appropriately decorated envelope and add them to the
> message, and if handling error results from RCPT TO is an issue for clients
> have a means to require that only outright syntax errors be reported as a
> command result and report all other errors later with a DSN.

I would add to this discussion a possible (new?) need about the BCC handling 
(that come out in some scenario, see below) that is to forbid at MSA level 
the use of a BCC.
In this case I agree with the Ned approach (based on a SMTP extension) 
versus the one that currently we are using in the Italian Certified email 
system, where we are parsing the TO and CC headers and comparing the result
with the list of RCPT-TOs (many platforms have been adapted to be compliant 
with such MSA requirement).

We will have a slot at the next IETF meeting (APP area WG) to bring attention 
on the CEM systems scenario where there could be quite strange (or 
interesting?) requirements (such as to forbid the BCC) that I think should be 
addressed and discussed by the IETF community.
References: 
http://datatracker.ietf.org/doc/draft-gennai-appsawg-cem/
http://datatracker.ietf.org/doc/rfc6109/

Francesco
  
> 				Ned

From: [email-masked]
Cc: [email-masked], "Robert A. Rosenberg" <[email-masked]>, Ned Freed <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Date: Wed, 29 Feb 2012 22:58:48 -0800 (PST)
Subject: Re: "proper" handling of BCC
To: Randall Gellens <[email-masked]>
Sender: [email-masked]

> The most useful thing, in my view, is a BCP on how MUAs should
> generate messages with BCC recipients, and how MUAs should recognize
> when a received message is a result of a BCC, and how to handle
> replies etc. in such cases.

I agree that this is more important than having an extension to offload
Bcc: processing to the MSA.

> I'm intrigued by the behavior mentioned earlier of the originating
> MUA mucking with the To and Cc header fields when sending a BCC
> version, as an indication of this and to avoid unthinking
> reply-to-all actions.  I'm not sure I'm a huge fan of the "[To:]"
> business, but enclosing the contents in parens to form a comment
> might work.

I don't think that just having a comment is valid by RFC 5322 rules. That
could be an issue.

				Ned