Subject: Re: "proper" handling of BCC
From: [email-masked]
To: Tony Finch <[email-masked]>
Cc: [email-masked], "Robert A. Rosenberg" <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Date: Wed, 29 Feb 2012 21:57:12 -0800 (PST)
List-Id: <ietf-smtp.imc.org>

> [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.

				Ned

From: [email-masked]
Cc: [email-masked]
Date: Wed, 29 Feb 2012 18:24:54 -0800 (PST)
Subject: Re: MUA support for multiple from addresses
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

> On 02/29/2012 12:22 AM, John Levine wrote:
> > That's the problem.  What's special about the From: line?

> It's what all receiving MUAs show.

> Sender, the smtp sender and so on may be shown, From is universally shown.

Which is exactly why, if you expect send-on-behalf to work in any sort of
meaningful way, it is essential that you allow From: field overrides.

And as for the importance of send-on-behalf-of, it is not at all uncommon for
us to see support for it as a client requirement.

				Ned

From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 29 Feb 2012 18:17:35 -0800 (PST)
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
To: "Carl S. Gutekunst" <[email-masked]>
Sender: [email-masked]

> [email-masked] wrote:
> >> > ... but as it happens there is a pretty clear and simple model for
> >> > the semantics that attach to bcc.
> >
> >> X.400 documented this pretty clearly. If we're going to discuss a model
> >> for Internet Mail, it'd be worth at least using that as a starting
> >> point.
> >
> > Gonna have to disagree with you there... yes, the documents expand a
> > large number of
> > words documenting something they called a model, but the term "clear"
> > definitely did not apply. If it had then none of the various operational
> > profiles of X.400 like GOSIP (which added another three inch of paper
> > to the
> > pile) would have been wanted or needed.
> I was only referring to BCC, which (in the dusty corners of my memory) I
> recall being one of the very few features of X.400 that I liked better
> than what we were doing on Internet Mail, if only because it actually
> defined it.

The problem is the pure definition is so short it isn't worth bothering with,
and the larger scope of how it was implementing isn't really compatible with
Internet mail, even if you consider it to be a good idea, which it wasn't.

				Ned

Date: Wed, 29 Feb 2012 14:00:21 -0800
To: <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: "proper" handling of BCC
CC: Ned Freed <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>, Tony Hansen <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 9:18 AM -0800 2/29/12, <[email-masked]> wrote:

>  Absent an extension, the MUA has no way of knowing if this parameter even
>  exists in the MSA, let alone how it is set.

Yes, exactly.

>  That's another reason why you need an extension - you absolutely do need a
>  parameter so that the MSA only does this stuff if the MSA requests it.

Yes, exactly.

>  I also think this is the wrong way for it to work. The problem with
>  this approach is that it forces the MSA to parse and modify headers,
>  and compare the addresses extract from those headers with the
>  various envelope addresses. That's inherently risky.

Yes, exactly.

>  It's much safer to have the MUA send a message without any of these 
> headers in
>  it and to have the MSA simply add the Bcc: field to message copies as needed.
>  This can be done with a BCC parameter on the RCPT TO:. The value of that
>  parameter can be the personal name phase to add to the address. This
>  way the only thing the MSA has to do is decode the parameter value,
>  concatentate some strings and add a header field containing the result.
>
>  Alternately, the value of the BCC parameter could be the entire Bcc: field
>  value. This would provide support for stuff like group constructs, 
> assuming we
>  want to allow that. (I can argue it either way.) This is even simpler because
>  now all the MSA has to do is decode the parameter and stuff it into a new
>  header field.

Two good approaches.

>  Remember, the target audience here has to be more than just a bunch of
>  geeks or this doesn't stand a chance of deploying.

Right.

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'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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Q: How many surrealists does it take to screw in a light bulb?
A: A Fish.

Date: Wed, 29 Feb 2012 13:50:37 -0800
To: "Robert A. Rosenberg" <[email-masked]>, Ned Freed <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: "proper" handling of BCC
CC: "Robert A. Rosenberg" <[email-masked]>, Tony Hansen <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 1:44 AM -0500 2/29/12, Robert A. Rosenberg wrote:

>  At 15:11 -0800 on 02/28/2012, Ned Freed wrote about Re: "proper" 
> handling of BCC:
>
>>   > Ways it can be handled is for the MUA to submit the BCC header to the
>>>   MSA and have it remove the header while cloning the message to create
>>>   one master and one copy for each BCC listing only the Address, have
>>>   the MSA scan the To and CC assuming that any RCPT-TOs not there are
>>>   BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do
>>>   the cloning. Not that the first 2 alter the MSA while the last alters
>>>   both the MSA and MUA.
>>
>>  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.
>
>  No extension needed.

An extension would be useful but is not needed.  It would be useful 
in the same way that the future-delivery extension is useful: it 
offloads work to the MSA.  The extension isn't needed because the MUA 
can implement best practice on its own (by sending n+1 copies).

>  So long as the MSA has the code to clone (and inject the BCC into) 
> a submitted message that has more RECPT-TOs than the sum of the 
> addresses in TO and CC (ie: So long as it is not being submitted by 
> a Mailing List and thus had one or more BCC'ed addresses that only 
> the MUA knew of) you just need to make this the default via a parm 
> setting (This functioning is method 2  of 3 above). This is similar 
> to having a MSA or MTA clone multi-addressed messages that would 
> normally be sent a one message with multiple RECPT-TOs going to the 
> same MTA by having a "DO NOT BATCH" parm. Since this is a setting 
> in the MSA/MTA code it just defines a default action not one that 
> only occurs when requested by the submitter.

Its ugly to tie default MSA action to the To/Cc headers.  At a 
minimum, the MSA needs to match the To/Cc addresses to the envelope 
addresses, not the count of how many addresses are in each.  Still, 
the MSA shouldn't do things differently by default -- the MUA may be 
sending multiple copies.  Any change in MSA behavior needs to be tied 
to an extension.

>   I acknowledge that an extension would be better so it only occurs 
> when the users asks. OTOH: One way to handle this is to define two 
> MSA addresses - One that works as now and one with this default 
> action code. If you want this to occur then just use a sending 
> persona that points at the 2nd MSA address.

Ooh, no, please.  One address per combination of behavioral 
differences?  Yikes!

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Teacher Strikes Idle Kids
--Newspaper headline

Date: Wed, 29 Feb 2012 11:05:10 -0800
To: Alessandro Vesely <[email-masked]>, SMTP Interest Group <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: MUA support for multiple from addresses
Sender: [email-masked]

At 4:19 PM +0100 2/28/12, Alessandro Vesely wrote:

>  On 28/Feb/12 13:05, Arnt Gulbrandsen wrote:
>>
>>  3. We'll restrict From and the smtp sender addresses to ones
>>  explicitly connected to the SASL/Submit user.
>
>  IMHO, forcing the login ID to match any world-readable outgoing header
>  field is not a tremendous security improvement.  Most MUAs allow to
>  configure From: with whatever (unverified) address.

This is my concern as well.  I often set the 'From' header field to a 
one-off or a user-detail or even someone else's address (when using 
Eudora redirect).  As long as I'm authenticated to the submit server, 
and the message can be tracked back to me in case I abused it, what I 
put in the 'From' header field shouldn't matter.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Some days you feel like Schrodinger's cat.   --M. S. Hutchenreuther

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

> At 15:11 -0800 on 02/28/2012, Ned Freed wrote about Re: "proper"
> handling of BCC:

> >  > Ways it can be handled is for the MUA to submit the BCC header to the
> >>  MSA and have it remove the header while cloning the message to create
> >>  one master and one copy for each BCC listing only the Address, have
> >>  the MSA scan the To and CC assuming that any RCPT-TOs not there are
> >>  BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do
> >>  the cloning. Not that the first 2 alter the MSA while the last alters
> >>  both the MSA and MUA.
> >
> >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.

> No extension needed.

Sorry, that incorrect. Without an extension how is an MUA supposed to know that
the MSA supports the extension? If an MUA assumes such an extension is present,
it actually isn't, and sends a message expecting the MSA to perform some sort
of Bcc: processing and selectively remove any Bcc: field(s) that are present,
you have just exposed the Bcc: recipient(s) to everyone.

And since no MSA out there currently does any of this stuff, this behavior will
be the rule, not the exception, until the extension actually deploys, assuming
it ever does. No MUA implementor in their right mind would implement this
behavior.
 
> So long as the MSA has the code to clone (and
> inject the BCC into) a submitted message that has more RECPT-TOs than
> the sum of the addresses in TO and CC (ie: So long as it is not being
> submitted by a Mailing List and thus had one or more BCC'ed addresses
> that only the MUA knew of) you just need to make this the default via
> a parm setting (This functioning is method 2  of 3 above).

Absent an extension, the MUA has no way of knowing if this parameter even
exists in the MSA, let alone how it is set.

> This is
> similar to having a MSA or MTA clone multi-addressed messages that
> would normally be sent a one message with multiple RECPT-TOs going to
> the same MTA by having a "DO NOT BATCH" parm. Since this is a setting
> in the MSA/MTA code it just defines a default action not one that
> only occurs when requested by the submitter. I acknowledge that an
> extension would be better so it only occurs when the users asks.

That's another reason why you need an extension - you absolutely do need a
parameter so that the MSA only does this stuff if the MSA requests it.

I also think this is the wrong way for it to work. The problem with
this approach is that it forces the MSA to parse and modify headers,
and compare the addresses extract from those headers with the
various envelope addresses. That's inherently risky.

It's much safer to have the MUA send a message without any of these headers in
it and to have the MSA simply add the Bcc: field to message copies as needed.
This can be done with a BCC parameter on the RCPT TO:. The value of that
parameter can be the personal name phase to add to the address. This
way the only thing the MSA has to do is decode the parameter value,
concatentate some strings and add a header field containing the result.

Alternately, the value of the BCC parameter could be the entire Bcc: field
value. This would provide support for stuff like group constructs, assuming we
want to allow that. (I can argue it either way.) This is even simpler because
now all the MSA has to do is decode the parameter and stuff it into a new
header field.

Of course the bigger part of all this from the MSA's perspective is the
messge splitting. But most MSA's always have code for that to handle other
cases; this extension can simply leverage that support.

> OTOH: One way to handle this is to define two MSA addresses - One
> that works as now and one with this default action code. If you want
> this to occur then just use a sending persona that points at the 2nd
> MSA address.

That's far too complex for users to deal with - even now service providers
spend far too much time dealing with support calls from users who cannot
set up even one persona in their client properly.

And besides, no service provider is ever going to deploy multiple MSA just to
support such functionality. The benefits don't come even close to outweighing
the costs.

Remember, the target audience here has to be more than just a bunch of
geeks or this doesn't stand a chance of deploying.

				Ned

Date: Wed, 29 Feb 2012 16:49:33 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: "Robert A. Rosenberg" <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Subject: Re: "proper" handling of BCC
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

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dogger, Fisher, German Bight: West or southwest 4 or 5. Slight or moderate.
Fog banks. Moderate or very poor.

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 29 Feb 2012 14:59:52 -0000
From: "John Levine" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: MUA support for multiple from addresses
Organization: 
Sender: [email-masked]

>> That's the problem.  What's special about the From: line?
>It's what all receiving MUAs show.

They show the subject line and body too.  I still don't understand
why it's vital to vet the From: line but not the rest of the message.

This appears to he be same old wrong idea about DKIM that the d=
domain has some mystical connection to the From: line or other domains
in the message.  It doesn't.  If you disagree, please point to the
relevant language in RFC 6376.

R's,
John

Date: Wed, 29 Feb 2012 05:56:40 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Ned Freed <[email-masked]>
CC: Paul Smith <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked], [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

On 2/28/2012 5:33 PM, Ned Freed wrote:
> Quite true, but neither do have have a specifications for a lot of other
> MUA-MUA behavior. Heck, we don't even have a clear specification for replies
> and forwards -

Exactly.

I didn't mean my comment on the lack to be taken narrowly.  It was merely 
referring to what popped up in front of us.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 29 Feb 2012 10:50:10 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: MUA support for multiple from addresses
Sender: [email-masked]

On 02/29/2012 12:22 AM, John Levine wrote:
> That's the problem.  What's special about the From: line?

It's what all receiving MUAs show.

Sender, the smtp sender and so on may be shown, From is universally shown.

> Do you
> check to ensure that signed mail doesn't contain viruses, or Ponzi
> schemes or hate speech or child pornography or any of a zillion other
> things that well run mail systems wouldn't want to send?

The answer to that is more yes than no, but IMO more irrelevant than yes.

Arnt

Date: Tue, 28 Feb 2012 23:47:57 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
CC: [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
To: [email-masked]
Sender: [email-masked]

Carl S. Gutekunst wrote:
> 
> [email-masked] wrote:
>>> > ... but as it happens there is a pretty clear and simple model for
>>> > the semantics that attach to bcc.
>>
>>> X.400 documented this pretty clearly. If we're going to discuss a model
>>> for Internet Mail, it'd be worth at least using that as a starting 
>>> point.
>>
>> Gonna have to disagree with you there... yes, the documents expand a 
>> large number of
>> words documenting something they called a model, but the term "clear"
>> definitely did not apply. If it had then none of the various operational
>> profiles of X.400 like GOSIP (which added another three inch of paper 
>> to the  pile) would have been wanted or needed.

> I was only referring to BCC, which (in the dusty corners of my memory) I 
> recall being one of the very few features of X.400 that I liked better 
> than what we were doing on Internet Mail, if only because it actually 
> defined it.

Yes, certainly a high usage usefulness to keep certain people in the loop.

To me, as I seem to recall, it became harder with the advent of 
gateways and store and forward, i.e. decentralization.

For example, in my old 80's Silver Xpress product, which I promoted as 
a "time shifted emulation of online hosting" supporting all the online 
security requirements in an offline fashion, there was some parts 
where the MUA can just push the mail with a BCC marker to the server 
and it knew how to handle it. The server was ready for it.  The reader 
was offline, but it 100% emulated how the host will manage the mail. 
With an RFC-Based offline MUA, it needed to separate the sending as 
different transactions because the SMTP host was not ready for BCC 
separation idea and in my view, this was better for mail network 
gateways didn't need to worry about it as well.

-- 
HLS

Date: Tue, 28 Feb 2012 23:44:55 -0800
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]> (by way of SM <[email-masked]>)
Subject: Re: MUA support for multiple from addresses
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

         Tony Finch <[email-masked]> (by way of Robert A. Rosenberg)

Not so, see From: header.

Regards,
-sm

Date: Wed, 29 Feb 2012 00:39:33 -0500
To: Tony Finch <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: MUA support for multiple from addresses
Cc: Randall Gellens <[email-masked]>, Peter Bowen <[email-masked]>, [email-masked]
Sender: [email-masked]

At 16:59 +0000 on 02/28/2012, Tony Finch wrote about Re: MUA support 
for multiple from addresses:

>Randall Gellens <[email-masked]> wrote:
>>
>>  ... when I use Eudora's "Redirect" feature (which re-sends a received
>>  message to someone else, preserving the original value of the From
>>  header field, but adding a "(by way of ...)" comment).
>
>Doesn't it use the standard Resent-* headers for this?

No - It uses the original sender's address and notes the Redirecter's 
Name (but not address) in parens. Here is what your query message 
would have shown as it's From if I had redirected it:

         Tony Finch <[email-masked]> (by way of Robert A. Rosenberg)

Date: Wed, 29 Feb 2012 01:50:30 -0500
To: Hector Santos <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: "proper" handling of BCC
Cc: [email-masked]
Sender: [email-masked]

At 18:45 -0500 on 02/28/2012, Hector Santos wrote about Re: "proper" 
handling of BCC:

>There is nothing more embarrassing, including legal, to have 
>mistakes of exposing blind copies to the other non-blind recipients.

Remember the MTA that when presented with only RECPT-TOs and no 
addresses in either the TO or CC headers injected the full list of 
recipients as APPARENTLY-TO headers. OOPS.

Date: Wed, 29 Feb 2012 01:44:00 -0500
To: Ned Freed <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: "proper" handling of BCC
Cc: "Robert A. Rosenberg" <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

At 15:11 -0800 on 02/28/2012, Ned Freed wrote about Re: "proper" 
handling of BCC:

>  > Ways it can be handled is for the MUA to submit the BCC header to the
>>  MSA and have it remove the header while cloning the message to create
>>  one master and one copy for each BCC listing only the Address, have
>>  the MSA scan the To and CC assuming that any RCPT-TOs not there are
>>  BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do
>>  the cloning. Not that the first 2 alter the MSA while the last alters
>>  both the MSA and MUA.
>
>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.

No extension needed. So long as the MSA has the code to clone (and 
inject the BCC into) a submitted message that has more RECPT-TOs than 
the sum of the addresses in TO and CC (ie: So long as it is not being 
submitted by a Mailing List and thus had one or more BCC'ed addresses 
that only the MUA knew of) you just need to make this the default via 
a parm setting (This functioning is method 2  of 3 above). This is 
similar to having a MSA or MTA clone multi-addressed messages that 
would normally be sent a one message with multiple RECPT-TOs going to 
the same MTA by having a "DO NOT BATCH" parm. Since this is a setting 
in the MSA/MTA code it just defines a default action not one that 
only occurs when requested by the submitter. I acknowledge that an 
extension would be better so it only occurs when the users asks. 
OTOH: One way to handle this is to define two MSA addresses - One 
that works as now and one with this default action code. If you want 
this to occur then just use a sending persona that points at the 2nd 
MSA address.

Date: Wed, 29 Feb 2012 00:32:24 -0500
To: Arnt Gulbrandsen <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: MUA support for multiple from addresses
Cc: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

At 13:05 +0100 on 02/28/2012, Arnt Gulbrandsen wrote about Re: MUA 
support for multiple from addresses:

>On 02/28/2012 01:11 AM, [email-masked] wrote:
>>  And as Randy points
>>  out, a lot of legitimate uses of it run afoul of incompetently designed
>>  security restrictions.
>
>As it happens I was involved in implementing exactly this restriction once.
>
>The chain of logic was like this: 1. We want to sign using DKIM. 2. For
>that we need to make sure each outgoing From address is something the
>domain owner is happy to sign for. 3. We'll restrict From and the smtp
>sender addresses to ones explictly connected to the SASL/Submit user.
>
>The DKIM design isn't incompetent, none of steps 1-3 seem obviously
>incompetent. Tell me what I overlooked?
>
>Arnt

If there are more than one From and/or the From and Sender are 
different AND all supplied addresses would be considered to be valid 
for your DKIM checking/validation logic if they were the only 
supplied address your implementation is IMO incompetently designed if 
it rejects immediately when it sees multiple from addresses or a 
From/Sender mismatch. It should only reject ONCE it is given an 
address that it would have rejected as a sole address.

Note that criteria 3 may need a white list associated with the submit 
address (ie: Address X is allowed to send using the SASL/Submit 
credentials).

From: [email-masked]
Cc: [email-masked]
Date: Tue, 28 Feb 2012 22:42:26 -0800 (PST)
Subject: Re: "proper" handling of BCC
To: Tony Hansen <[email-masked]>
Sender: [email-masked]

> I actually started writing such a doc about a year ago, but never
> finished it.

> Is it worth dusting off?

Sounds like a good idea to me.

				Ned

Date: Tue, 28 Feb 2012 19:52:50 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

[email-masked] wrote:
>> > ... but as it happens there is a pretty clear and simple model for
>> > the semantics that attach to bcc.
>
>> X.400 documented this pretty clearly. If we're going to discuss a model
>> for Internet Mail, it'd be worth at least using that as a starting 
>> point.
>
> Gonna have to disagree with you there... yes, the documents expand a 
> large number of
> words documenting something they called a model, but the term "clear"
> definitely did not apply. If it had then none of the various operational
> profiles of X.400 like GOSIP (which added another three inch of paper 
> to the
> pile) would have been wanted or needed.
I was only referring to BCC, which (in the dusty corners of my memory) I 
recall being one of the very few features of X.400 that I liked better 
than what we were doing on Internet Mail, if only because it actually 
defined it.

<csg>

From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 28 Feb 2012 18:24:20 -0800 (PST)
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
To: "Carl S. Gutekunst" <[email-masked]>
Sender: [email-masked]

> [email-masked] wrote:
> > ... but as it happens there is a pretty clear and simple model for
> > the semantics that attach to bcc. We didn't come up with it - in fact
> > it goes
> > all the way back to typewriters and hand manipulation of copies and
> > the carbons
> > between them - but it's a model nevertheless. And many if not most of the
> > technical details of how you implement this stuff follow directly from
> > this
> > model.

> X.400 documented this pretty clearly. If we're going to discuss a model
> for Internet Mail, it'd be worth at least using that as a starting point.

Gonna have to disagree with you there. Having spent literally hundreds of hours
poring over the X.400 documents and having done complete implementations of
both X.400-1984 and X.400-1988, yes, the documents expand a large number of
words documenting something they called a model, but the term "clear"
definitely did not apply. If it had then none of the various operational
profiles of X.400 like GOSIP (which added another three inch of paper to the
pile) would have been wanted or needed.

And even in the parts that were clear, they got an appalling number of details
either flat out wrong or made them dependent on deployment of other services
that was never going to happen. A good example of the former is the X.400
approach to media types - if you think our media type system has issues try
building one that names things with random OIDs and which imposes no
serialization requirement. (Every media type in X.400 is allowed to define it's
own ASN.1 structure and you have to know that structure to interpret it
properly.) To its credit, the EMA was working to address these issues by
setting up a registry and disallowing all but the use of a single octet string
to store the content, but X.400 faded away before any of that could be
implemented.
 
A good example of the latter is how read receipts in X.400 depend on being able
to correlate envelope and header addresses. That effectivey presumed the
existence of a global white pages service that allowed read access to
everyone's aliases, which pretty obviously was a nonstarter from the get-go.

In the specific case of the bcc model in X.400, my copies of the specifications
are at work so I cannot check them, but if memory serves the model, while being
fairly clear for once, called for this to be handled as part of P3 (the X.400
equivalent, more or less, of SUBMIT). In practice this was problematic if for
no other reason than P3 was rarely if ever implemented, so the semantics it was
supposed to provide didn't actually exist in most real world systems.

Another issue was the X.400 equivalent of the issue Randy brought up with "for"
clauses. In X.400 when a message is split information about all recipients is
retained in both message copies; the information for recipients in the other
copy is just marked inactive. The implications of that should be obvious. And
the rules in the model for when this information was supposed to be dropped
were ... unclear to say the least.

Anyway, I really need to stop remembering this stuff before, as they say, any
more of my gray cells hit the bug lamp.

				Ned

Date: Tue, 28 Feb 2012 18:01:30 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

SM wrote:
> At 10:17 28-02-2012, Tony Hansen wrote:
>> I actually started writing such a doc about a year ago, but never 
>> finished it.
>>
>> Is it worth dusting off?
>
> Yes. 

Please.

<csg>

Date: Tue, 28 Feb 2012 17:59:07 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

[email-masked] wrote:
> ... but as it happens there is a pretty clear and simple model for
> the semantics that attach to bcc. We didn't come up with it - in fact 
> it goes
> all the way back to typewriters and hand manipulation of copies and 
> the carbons
> between them - but it's a model nevertheless. And many if not most of the
> technical details of how you implement this stuff follow directly from 
> this
> model.

X.400 documented this pretty clearly. If we're going to discuss a model 
for Internet Mail, it'd be worth at least using that as a starting point.

<csg>

From: [email-masked]
Cc: Ned Freed <[email-masked]>, Paul Smith <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 28 Feb 2012 17:33:36 -0800 (PST)
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
To: Dave Crocker <[email-masked]>
Sender: [email-masked]

> On 2/28/2012 8:21 AM, Ned Freed wrote:
> > In short, this is an implementation quality issue. The MUA I'm using to
> > enter this messages handles all of this correctly.

> I'll make clear what I implied.  I think this is deeper than an implementation
> quality issue.

> We do not have a "protocol" specification for MUA-MUA (nevermind MUA/MSA, etc.)
> behavior involving BCC.

Quite true, but neither do have have a specifications for a lot of other
MUA-MUA behavior. Heck, we don't even have a clear specification for replies
and forwards - yes, RFC 5322 talks about it some, and even tries to break it
down into some specific use-cases, but falls far short of specifying the
specifics of how it is supposed to work.

> More generally, we do not have a clear model and technical details for group
> communication with email.

True as well, but as it happens there is a pretty clear and simple model for
the semantics that attach to bcc. We didn't come up with it - in fact it goes
all the way back to typewriters and hand manipulation of copies and the carbons
between them - but it's a model nevertheless. And many if not most of the
technical details of how you implement this stuff follow directly from this
model.

Of course this is no reason not to write this stuff down, if for no other
reason that to spare new implementors the pain of working it out for
themselves - and possibly working it out incorrectly.

> We have tidbits of mechanism.  They variously work and don't.  But we haven't
> defined a model and its details to form a solid, stable technical protocol basis
> for extended, group exchanges.

And I personally am dubious we could get consensus on one if we tried.

> Which makes the relatively high level of utility we get out of the current
> system for such communication modes pretty impressive...

Agreed.

				Ned

P.S. It's actually kind of fascinating how the implementation specifics of
email have determined which parts of the venerable "office memorandum" model
and structure we have kept intact, which ones we've discarded, and which ones
we've moved around. For example, the lack of a structured footer combined with
the relative ease of adding additional header fields caused the old
"auther-initials:typist-initials" convention to morph (or if you prefer, be
replaced by) our current From:/Sender: mechanism.

Date: Tue, 28 Feb 2012 15:38:55 -0800
To: Tony Hansen <[email-masked]>
From: SM <[email-masked]>
Subject: Re: "proper" handling of BCC
Cc: [email-masked]
Sender: [email-masked]

Hi Tony,
At 10:17 28-02-2012, Tony Hansen wrote:
>I actually started writing such a doc about a year ago, but never finished it.
>
>Is it worth dusting off?

Yes.

Regards,
-sm 

Date: Tue, 28 Feb 2012 15:27:48 -0800
To: SMTP Interest Group <[email-masked]>
From: SM <[email-masked]>
Subject: Re: MUA support for multiple from addresses
Sender: [email-masked]

At 07:59 28-02-2012, [email-masked] wrote:
>That's exactly the use-case I often encounter. It's actually a bit
>irrresponsible not to properly label such messages.

I was going to do that.  I vaguely recall that the message might be 
blocked by the IETF MLM.  If anyone has tried it recently, let me know.

BTW, the MLM for this list does not support multiple addresses in the 
from: header.

Regards,
-sm 

From: [email-masked]
Cc: Ned Freed <[email-masked]>, Paul Smith <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked], [email-masked], Dave CROCKER <[email-masked]>
Date: Tue, 28 Feb 2012 15:28:37 -0800 (PST)
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
To: Randall Gellens <[email-masked]>
Sender: [email-masked]

> At 8:21 AM -0800 2/28/12, Ned Freed wrote:

> > > (Not to mention that bcc "fields" should not exist anyway - that's the
> > >  whole point)

> >  Strongy disagree. The problem with implementations that cheat and implement
> >  Bcc: by generating a single message copy with the Bcc: addresses only
> >  appearing in the envelope is that those recipients do not get any sort
> >  of indication that that were Bcc:'ed. If they don't realize that and
> >  do a reply-all, the cat's out of the bad and the sender may be in big
> >  trouble.

> Another source of potential BCC leakage are MTAs, which might record
> all local recipients.  Most MTAs only record the recipient in a
> "Received:" header field if there is only one, but there have been
> some which record all.  If the MUA generates multiple message objects
> and transactions, it no longer relies on the MTAs also not letting
> the feline escape its confinement/concealment.

Good point. I haven't seen that particular leakage, but I have seen one case
where a for clause for only one recipient, selected who knows how, got inserted
into a multi-recipient message and the message wasn't split.

Of course the only way to be absolutely certain your bcc never leaks out is not
to send it. But a certain amount of prudence on the part of implementors in the
face of potential infrastructure issues is still a good thing.

				Ned

Date: Tue, 28 Feb 2012 18:45:33 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

There are many angles to all this, including one that there is a major 
difference in the types of MUAs, including in how it relates to the 
headers, the managed "privacy" control required for blind copies, etc, 
and in regards to the "Inventor" of email, in that era he was using a 
ONLINE MUA, not an store and forward, offline based MUA.

That is a major distinction in all this.  In fact, if you go the 
fellows web site, there is sad and hilarious picture showing him in 
front of what appears to be a DEC VT100/102 terminal and the caption 
says something to the effect

      if you look carefully, you can see the clear From/To/BCC UI 
evidence of the
      new EMAIL system.

It was saying "huh?"  I could even come close to seeing any readable 
characters or any fuzzy screen resolution whatsoever - but then again 
it could be my failing eyes.

Any hoo, for MUAs regardless of the network, gateway, etc:

o Online

The backend handles the separation when the frontend/GUI offers fields 
for this. When the post (clicks the Post/Send button) is made, the 
backend needs to handle the distribution for privacy requirements 
before putting/moving them into system's mail transport outbound 
queues and/or local storage user bins.

o Offline

The RFC-based offline MUA is responsible for separating the targets 
before SMTP sending for the following reasons:

First, there is no current SMTP solution, such as  "BCPT TO" state 
machine command option, and second, there is no expectation for SMTP 
receivers to parse for 822/2822/5322 headers to extract distribution 
targets.

In all case, backend or offline MUA needs to  make sure the separation 
for the privacy requirements are met.

There is nothing more embarrassing, including legal, to have mistakes 
of exposing blind copies to the other non-blind recipients.

Robert A. Rosenberg wrote:
> 
> At 13:17 -0500 on 02/28/2012, Tony Hansen wrote about Re: "proper" 
> handling of BCC:
> 
>> I actually started writing such a doc about a year ago, but never 
>> finished it.
>>
>> Is it worth dusting off?
>>
>>     Tony Hansen
>>
>> On 2/28/2012 12:24 PM, Dave Crocker wrote:
>>>
>>> On 2/28/2012 9:11 AM, Paul Smith wrote:
>>>>>
>>>> OK, I was wrong - but I've never seen a BCC handled in that way 
>>>> before... I've sometimes received messages with a 'BCC' field 
>>>> containing addresses who were NOT me (ie I shouldn't have known they 
>>>> existed), and most MUAs I've seen (in fact, all those I've 
>>>> investigated fully) just list those recipients in the envelope for a 
>>>> single copy of the message. So, I've never seen a BCC field in a 
>>>> message header, used 'correctly'.
>>>
>>> We have never really standardized BCC as an end-to-end construct, at 
>>> the MUA-MUA level.
>>>
>>> d/
> 
> Ways it can be handled is for the MUA to submit the BCC header to the 
> MSA and have it remove the header while cloning the message to create 
> one master and one copy for each BCC listing only the Address, have the 
> MSA scan the To and CC assuming that any RCPT-TOs not there are BCCs and 
> do the cloning, OR add a BCC indicator to the RCPT-TO and do the 
> cloning. Not that the first 2 alter the MSA while the last alters both 
> the MSA and MUA.
> 
> In any case there needs to be some way of indicating the BCC contents. 
> Note that  there needs to be a way of triggering the insertion/display 
> of the BCC listing only the recipient in the recipient's copy of the 
> message that WILL NOT get triggered by a normal Mailing List message. 
> Options 1 and 3 above qualify since there is a indication to the MSA to 
> clone the message with a BCC. Option 2 since it triggers via a mismatch 
> between the To/CC contents and that of the RECPT-TO will be the problem 
> since there would be no difference to the MSA between a BCC and a 
> Mailing List generated message.
> 
> Note that I am just winging it and may be missing something and I am 
> just doing some design spec thoughts above.
> 
> 
> 

-- 
Sincerely

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

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 28 Feb 2012 23:22:23 -0000
From: "John Levine" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: MUA support for multiple from addresses
Organization: 
Sender: [email-masked]

>The chain of logic was like this: 1. We want to sign using DKIM. 

So far so good.

>2. For that we need to make sure each outgoing From address is something the
>domain owner is happy to sign for.

That's the problem.  What's special about the From: line?  Do you
check to ensure that signed mail doesn't contain viruses, or Ponzi
schemes or hate speech or child pornography or any of a zillion other
things that well run mail systems wouldn't want to send?

I let my users change the From: line to whatever they want, and sign
it all with my main domain.  If the From: line happens to contain an
address in a domain for which I have a signing key, I also sign with
that.

R's,
John

From: [email-masked]
Cc: Tony Hansen <[email-masked]>, [email-masked]
Date: Tue, 28 Feb 2012 15:11:10 -0800 (PST)
Subject: Re: "proper" handling of BCC
To: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

> Ways it can be handled is for the MUA to submit the BCC header to the
> MSA and have it remove the header while cloning the message to create
> one master and one copy for each BCC listing only the Address, have
> the MSA scan the To and CC assuming that any RCPT-TOs not there are
> BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do
> the cloning. Not that the first 2 alter the MSA while the last alters
> both the MSA and MUA.

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.

Given the lack of such an extension at present, it's up to the MUA to do it.
With the understanding that the primary goal is to prevent other recipients
from being aware of the bcc, this inevitably leads to not mentioning the bcc
recipient in the header the other recipients see. The simple way that most (but
by no means all) user agents employ is to send a single copy and only have the
bcc recipient in the envelope. This can be improved on by sending (n+1) copies,
where n is the number of bcc recipients, one for all the other recipient and
one for each bcc with their address in a bcc field. 

As I said previouly, the choice between the two is primarily an implementation
quality issue. The additional bandwidth consumption involved is rarely if ever
worth worrying about, even for mobile devices. (And in the mobile case, if the
message is large it's likely being forwarded at least in part, and  we have
other ways to address that.)

> In any case there needs to be some way of indicating the BCC
> contents. Note that  there needs to be a way of triggering the
> insertion/display of the BCC listing only the recipient in the
> recipient's copy of the message that WILL NOT get triggered by a
> normal Mailing List message. Options 1 and 3 above qualify since
> there is a indication to the MSA to clone the message with a BCC.
> Option 2 since it triggers via a mismatch between the To/CC contents
> and that of the RECPT-TO will be the problem since there would be no
> difference to the MSA between a BCC and a Mailing List generated
> message.

There are all sorts of ways of doing it. The real question is whether
or not it's worth the bother at this late date, especially since
clients cannot count on the extension being present and therefore
have to have a fallback option. It won't do to expose bcc recipients
when the extension isn't available.

				Ned

Date: Tue, 28 Feb 2012 17:43:17 -0500
To: Tony Hansen <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: "proper" handling of BCC
Cc: [email-masked]
Sender: [email-masked]

At 13:17 -0500 on 02/28/2012, Tony Hansen wrote about Re: "proper" 
handling of BCC:

>I actually started writing such a doc about a year ago, but never finished it.
>
>Is it worth dusting off?
>
>     Tony Hansen
>
>On 2/28/2012 12:24 PM, Dave Crocker wrote:
>>
>>On 2/28/2012 9:11 AM, Paul Smith wrote:
>>>>
>>>OK, I was wrong - but I've never seen a BCC handled in that way 
>>>before... I've sometimes received messages with a 'BCC' field 
>>>containing addresses who were NOT me (ie I shouldn't have known 
>>>they existed), and most MUAs I've seen (in fact, all those I've 
>>>investigated fully) just list those recipients in the envelope for 
>>>a single copy of the message. So, I've never seen a BCC field in a 
>>>message header, used 'correctly'.
>>
>>We have never really standardized BCC as an end-to-end construct, 
>>at the MUA-MUA level.
>>
>>d/

Ways it can be handled is for the MUA to submit the BCC header to the 
MSA and have it remove the header while cloning the message to create 
one master and one copy for each BCC listing only the Address, have 
the MSA scan the To and CC assuming that any RCPT-TOs not there are 
BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do 
the cloning. Not that the first 2 alter the MSA while the last alters 
both the MSA and MUA.

In any case there needs to be some way of indicating the BCC 
contents. Note that  there needs to be a way of triggering the 
insertion/display of the BCC listing only the recipient in the 
recipient's copy of the message that WILL NOT get triggered by a 
normal Mailing List message. Options 1 and 3 above qualify since 
there is a indication to the MSA to clone the message with a BCC. 
Option 2 since it triggers via a mismatch between the To/CC contents 
and that of the RECPT-TO will be the problem since there would be no 
difference to the MSA between a BCC and a Mailing List generated 
message.

Note that I am just winging it and may be missing something and I am 
just doing some design spec thoughts above.

Date: Tue, 28 Feb 2012 10:45:35 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Ned Freed <[email-masked]>
CC: Paul Smith <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked], [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

On 2/28/2012 8:21 AM, Ned Freed wrote:
> In short, this is an implementation quality issue. The MUA I'm using to
> enter this messages handles all of this correctly.

I'll make clear what I implied.  I think this is deeper than an implementation 
quality issue.

We do not have a "protocol" specification for MUA-MUA (nevermind MUA/MSA, etc.) 
behavior involving BCC.

More generally, we do not have a clear model and technical details for group 
communication with email.

We have tidbits of mechanism.  They variously work and don't.  But we haven't 
defined a model and its details to form a solid, stable technical protocol basis 
for extended, group exchanges.

Which makes the relatively high level of utility we get out of the current 
system for such communication modes pretty impressive...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 28 Feb 2012 10:33:15 -0800
To: Tony Finch <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: MUA support for multiple from addresses
CC: Peter Bowen <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 4:59 PM +0000 2/28/12, Tony Finch wrote:

>  Randall Gellens <[email-masked]> wrote:
>>
>>  ... when I use Eudora's "Redirect" feature (which re-sends a received
>>  message to someone else, preserving the original value of the From
>>  header field, but adding a "(by way of ...)" comment).
>
>  Doesn't it use the standard Resent-* headers for this?

No, probably because Steve didn't trust the recipient MUA to notice 
that, and wanted the recipient user to be aware that it was resent.

>  Rockall, Malin, Hebrides, Bailey, Fair Isle, Faeroes: South or southwest 5 to
>  7, occasionally gale 8 in Bailey, perhaps gale 8 later in Rockall 
> and Faeroes.
>  Rough or very rough. Occasional rain or drizzle, fog patches. Moderate or
>  poor, occasionally very poor.

Sounds dreadful!

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I can tell you right now Washington, D.C. is wallowing in squalor,
suspicion, cynicism, and corruption.  Which is why I wouldn't live
anywhere else.     --Political satirist Mark Russell, April 1, 1998

Date: Tue, 28 Feb 2012 10:30:56 -0800
To: Ned Freed <[email-masked]>, Paul Smith <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
CC: Randall Gellens <[email-masked]>, <[email-masked]>, <[email-masked]>, Dave CROCKER <[email-masked]>
Sender: [email-masked]

At 8:21 AM -0800 2/28/12, Ned Freed wrote:

>   > (Not to mention that bcc "fields" should not exist anyway - that's the
>>  whole point)
>
>  Strongy disagree. The problem with implementations that cheat and implement
>  Bcc: by generating a single message copy with the Bcc: addresses only
>  appearing in the envelope is that those recipients do not get any sort
>  of indication that that were Bcc:'ed. If they don't realize that and
>  do a reply-all, the cat's out of the bad and the sender may be in big
>  trouble.

Another source of potential BCC leakage are MTAs, which might record 
all local recipients.  Most MTAs only record the recipient in a 
"Received:" header field if there is only one, but there have been 
some which record all.  If the MUA generates multiple message objects 
and transactions, it no longer relies on the MTAs also not letting 
the feline escape its confinement/concealment.

>  And since users are careless, it really makes a lot of sense for MUAs
>  to check and see if they are doing a reply-all to a message that was Bcc:'ed
>  to them. That's only possible if a Bcc: field is present in their copy
>  of the message.

Good point.

>
>  In short, this is an implementation quality issue. The MUA I'm using to
>  enter this messages handles all of this correctly.
>
>  				Ned

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Politics offers yesterday's answers to today's problems.
                                     --Marshall McLuhan

Date: Tue, 28 Feb 2012 13:17:41 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

I actually started writing such a doc about a year ago, but never 
finished it.

Is it worth dusting off?

     Tony Hansen

On 2/28/2012 12:24 PM, Dave Crocker wrote:
>
>
>
> On 2/28/2012 9:11 AM, Paul Smith wrote:
>>>
>> OK, I was wrong - but I've never seen a BCC handled in that way 
>> before... I've
>> sometimes received messages with a 'BCC' field containing addresses 
>> who were NOT
>> me (ie I shouldn't have known they existed), and most MUAs I've seen 
>> (in fact,
>> all those I've investigated fully) just list those recipients in the 
>> envelope
>> for a single copy of the message. So, I've never seen a BCC field in 
>> a message
>> header, used 'correctly'.
>
> We have never really standardized BCC as an end-to-end construct, at 
> the MUA-MUA level.
>
> d/

Date: Tue, 28 Feb 2012 09:24:44 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Paul Smith <[email-masked]>
CC: Ned Freed <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

On 2/28/2012 9:11 AM, Paul Smith wrote:
>>
> OK, I was wrong - but I've never seen a BCC handled in that way before... I've
> sometimes received messages with a 'BCC' field containing addresses who were NOT
> me (ie I shouldn't have known they existed), and most MUAs I've seen (in fact,
> all those I've investigated fully) just list those recipients in the envelope
> for a single copy of the message. So, I've never seen a BCC field in a message
> header, used 'correctly'.

We have never really standardized BCC as an end-to-end construct, at the MUA-MUA 
level.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 28 Feb 2012 17:11:11 +0000
From: Paul Smith <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Randall Gellens <[email-masked]>, [email-masked], [email-masked], Dave CROCKER <[email-masked]>
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

On 28/02/2012 16:21, Ned Freed wrote:
>> (Not to mention that bcc "fields" should not exist anyway - that's the
>> whole point)
> Strongy disagree. The problem with implementations that cheat and implement
> Bcc: by generating a single message copy with the Bcc: addresses only
> appearing in the envelope is that those recipients do not get any sort
> of indication that that were Bcc:'ed. If they don't realize that and
> do a reply-all, the cat's out of the bad and the sender may be in big
> trouble.
>
> And since users are careless, it really makes a lot of sense for MUAs
> to check and see if they are doing a reply-all to a message that was Bcc:'ed
> to them. That's only possible if a Bcc: field is present in their copy
> of the message.
>
> In short, this is an implementation quality issue. The MUA I'm using to
> enter this messages handles all of this correctly.
>
OK, I was wrong - but I've never seen a BCC handled in that way 
before... I've sometimes received messages with a 'BCC' field containing 
addresses who were NOT me (ie I shouldn't have known they existed), and 
most MUAs I've seen (in fact, all those I've investigated fully) just 
list those recipients in the envelope for a single copy of the message. 
So, I've never seen a BCC field in a message header, used 'correctly'.

Date: Tue, 28 Feb 2012 16:59:25 +0000
From: Tony Finch <[email-masked]>
To: Randall Gellens <[email-masked]>
cc: Peter Bowen <[email-masked]>, [email-masked]
Subject: Re: MUA support for multiple from addresses
Sender: [email-masked]

Randall Gellens <[email-masked]> wrote:
>
> ... when I use Eudora's "Redirect" feature (which re-sends a received
> message to someone else, preserving the original value of the From
> header field, but adding a "(by way of ...)" comment).

Doesn't it use the standard Resent-* headers for this?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides, Bailey, Fair Isle, Faeroes: South or southwest 5 to
7, occasionally gale 8 in Bailey, perhaps gale 8 later in Rockall and Faeroes.
Rough or very rough. Occasional rain or drizzle, fog patches. Moderate or
poor, occasionally very poor.

Date: Tue, 28 Feb 2012 08:33:31 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: BCC  (was: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian)
Sender: [email-masked]

On 2/28/2012 1:02 AM, Paul Smith wrote:
> So, apparently he should be remembered for writing something like:
>
> send("From: ");
> send (sendersAddress);
> send(CRLF);
>
> (Not to mention that bcc "fields" should not exist anyway - that's the whole point)

BCC is more interesting than usually appreciated, IMO.

At the architectural level is the distinction between a construct limited to the 
author's MUA, versus something with end-to-end properties.

As an MUA construct it lets an author note recipients that won't be indicated to 
other recipients.  Constrained to a UI mechanism, it's not really part of 
Internet Mail architecturally.  Its contents get added to the transport protocol 
list (RFC5321.rcptto).  The result looks rather like what a mailing list posts.

The tendency for MUAs has been to do only the above and thereby create only a 
single submission posting.  To do more requires at least one additional posting.

With separate postings, the MUA can submit variants of the email object.

What some MUAs do is a single additional posting, where the email object 
contains an empty rfc5322.bcc header field.  This can serve to alert the bcc 
recipient that they are, in fact, a bcc recipient.  One could have a receiving 
MUA handle such a message differentially, though I believe none do.

I've also seen an added posting per bcc recipient, where the individual bcc 
recipient's address is in their copy of the message.

There's a variant I did, but can't remember whether I got it done to the 
original MH (by Bruce Borden and later taken over by Marshall Rose at UC Irvine) 
or to MMDF while I was at UDel.

Anyhow, the enhancement was to prevent a Bcc recipient from unintentionally 
sending a reply that copied the primary recipients.  (This happens when a bcc 
recipient does a Reply All.)

As I recall, for the bcc posting, I modified the rfc5322.to and rfc5322.cc 
header field names to be: [To]:  and [cc]:

Visually, this could look quite natural to the recipient, but of course the 
Reply command wouldn't see them.

(the next person responsible for that code removed the feature.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: [email-masked]
Cc: Randall Gellens <[email-masked]>, [email-masked], [email-masked], Dave CROCKER <[email-masked]>
Date: Tue, 28 Feb 2012 08:21:23 -0800 (PST)
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
To: Paul Smith <[email-masked]>
Sender: [email-masked]

> (Not to mention that bcc "fields" should not exist anyway - that's the
> whole point)

Strongy disagree. The problem with implementations that cheat and implement
Bcc: by generating a single message copy with the Bcc: addresses only
appearing in the envelope is that those recipients do not get any sort
of indication that that were Bcc:'ed. If they don't realize that and
do a reply-all, the cat's out of the bad and the sender may be in big
trouble.

And since users are careless, it really makes a lot of sense for MUAs
to check and see if they are doing a reply-all to a message that was Bcc:'ed
to them. That's only possible if a Bcc: field is present in their copy
of the message.

In short, this is an implementation quality issue. The MUA I'm using to
enter this messages handles all of this correctly.

				Ned

From: "Murray S. Kucherawy" <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: RE: MUA support for multiple from addresses
Date: Tue, 28 Feb 2012 16:26:34 +0000
Accept-Language: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, February 28, 2012 7:54 AM
> To: Arnt Gulbrandsen
> Cc: SMTP Interest Group
> Subject: Re: MUA support for multiple from addresses
> 
> If you goal is to sign absolutely everything you send, I would dispute
> the notion that DKIM is actually competent for that. In particular,
> DKIM fails to handle the "send on behalf of" case. The proper way to
> handle that - and it's widely supported and commonly used - is to put
> the "on behalf of" address in the From: and the actual sender's address
> in the Sender:.

I think the DKIM protocol is orthogonal to this logic.  It's the software deciding what to sign and with which key that needs to have this logic, not DKIM itself.

-MSK

From: [email-masked]
Cc: Mark Andrews <[email-masked]>, Steve Atkins <[email-masked]>, SMTP Interest Group <[email-masked]>
Date: Tue, 28 Feb 2012 07:59:23 -0800 (PST)
Subject: Re: MUA support for multiple from addresses
To: John C Klensin <[email-masked]>
Sender: [email-masked]

> 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.

That's exactly the use-case I often encounter. It's actually a bit
irrresponsible not to properly label such messages.

				Ned

From: [email-masked]
Cc: SMTP Interest Group <[email-masked]>
Date: Tue, 28 Feb 2012 07:53:36 -0800 (PST)
Subject: Re: MUA support for multiple from addresses
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

> On 02/28/2012 01:11 AM, [email-masked] wrote:
> > And as Randy points
> > out, a lot of legitimate uses of it run afoul of incompetently designed
> > security restrictions.

> As it happens I was involved in implementing exactly this restriction once.

> The chain of logic was like this: 1. We want to sign using DKIM. 2. For
> that we need to make sure each outgoing From address is something the
> domain owner is happy to sign for. 3. We'll restrict From and the smtp
> sender addresses to ones explictly connected to the SASL/Submit user.

> The DKIM design isn't incompetent, none of steps 1-3 seem obviously
> incompetent. Tell me what I overlooked?

If you goal is to sign absolutely everything you send, I would dispute the
notion that DKIM is actually competent for that. In particular, DKIM fails to
handle the "send on behalf of" case. The proper way to handle that - and it's
widely supported and commonly used - is to put the "on behalf of" address
in the From: and the actual sender's address in the Sender:.

If you want to restrict the addresses people send from and allow this case,
that's actualy pretty easy: Check the Sender: if it is present, and if it
isn't check the From:.

This has nothing to do with multiple from addresses either, although it's
another case where Sender: is required and is the correct address for these
sorts of checks.

				Ned

Date: Tue, 28 Feb 2012 16:19:11 +0100
From: Alessandro Vesely <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: MUA support for multiple from addresses
Sender: [email-masked]

On 28/Feb/12 13:05, Arnt Gulbrandsen wrote:
>
> 3. We'll restrict From and the smtp sender addresses to ones
> explicitly connected to the SASL/Submit user.

IMHO, forcing the login ID to match any world-readable outgoing header
field is not a tremendous security improvement.  Most MUAs allow to
configure From: with whatever (unverified) address.

Date: Tue, 28 Feb 2012 13:05:15 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: MUA support for multiple from addresses
Sender: [email-masked]

On 02/28/2012 01:11 AM, [email-masked] wrote:
> And as Randy points
> out, a lot of legitimate uses of it run afoul of incompetently designed
> security restrictions.

As it happens I was involved in implementing exactly this restriction once.

The chain of logic was like this: 1. We want to sign using DKIM. 2. For
that we need to make sure each outgoing From address is something the
domain owner is happy to sign for. 3. We'll restrict From and the smtp
sender addresses to ones explictly connected to the SASL/Submit user.

The DKIM design isn't incompetent, none of steps 1-3 seem obviously
incompetent. Tell me what I overlooked?

Arnt

Date: Tue, 28 Feb 2012 11:29:22 +0000
From: Tony Finch <[email-masked]>
To: "Rolf E. Sonneveld" <[email-masked]>
cc: Peter Bowen <[email-masked]>, [email-masked]
Subject: Re: MUA support for multiple from addresses
Sender: [email-masked]

Rolf E. Sonneveld <[email-masked]> wrote:
>
> For sending with multiple addresses in the From field, TB doesn't support
> that, unless you set multiple addresses in your e-mail address in your
> profile. If you do that (profile setting) it seems TB picks only _one_ of them
> and puts that in the From address, but _all_ addresses show up in Return-Path
> lines. I double-checked the headers of the received message using Apple Mail
> and also Apple Mail shows multiple envelope From addresses, one for each
> address in the (original) From. Assuming that the MUA/MSA is not adding
> Return-Path headers, it could be that TB uses multiple From addresses in the
> 5321.MailFrom.

How come the message was not rejected as a syntax error?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth: Westerly or southwesterly 5 or 6, decreasing 3 or 4.
Slight or moderate. Mainly fair, fog patches in Forties. Moderate or good,
occasionally poor, occasionally very poor in Forties.

Date: Tue, 28 Feb 2012 06:10:30 -0500
From: John C Klensin <[email-masked]>
To: Mark Andrews <[email-masked]>, Steve Atkins <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: MUA support for multiple from addresses
Sender: [email-masked]

--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.

Date: Tue, 28 Feb 2012 11:43:31 +0100
From: "Rolf E. Sonneveld" <[email-masked]>
To: Peter Bowen <[email-masked]>
Cc: [email-masked]
Subject: Re: MUA support for multiple from addresses
Sender: [email-masked]

On 2/27/12 7:35 PM, Peter Bowen wrote:
> Mails are allowed to have multiple addresses in the from header as
> long as they also have a sender header.  However, in basic testing, I
> have yet to find a MUA that even displays multiple entries for from.

[Hmm, isn't this a question for the 822 mailing list?]

Thunderbird shows multiple addresses in the From header when the message 
is opened. In the mailbox view (overview of Inbox within column titled 
'From') only one of them is shown. Reply and Reply-All have the same 
effect: all addresses in the From appear as To addresses.

For sending with multiple addresses in the From field, TB doesn't 
support that, unless you set multiple addresses in your e-mail address 
in your profile. If you do that (profile setting) it seems TB picks only 
_one_ of them and puts that in the From address, but _all_ addresses 
show up in Return-Path lines. I double-checked the headers of the 
received message using Apple Mail and also Apple Mail shows multiple 
envelope From addresses, one for each address in the (original) From. 
Assuming that the MUA/MSA is not adding Return-Path headers, it could be 
that TB uses multiple From addresses in the 5321.MailFrom.

ThunderBird version is 10.0.2.

/rolf

From: Martijn Grooten <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Date: Tue, 28 Feb 2012 09:55:17 +0000
Subject: RE: MUA support for multiple from addresses
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Sender: [email-masked]

> Mails are allowed to have multiple addresses in the from header as
> long as they also have a sender header.  However, in basic testing, I
> have yet to find a MUA that even displays multiple entries for from.
> Has anyone seen such a user agent?

KMail (Linux MUA that probably not many people use - I don't) displays both of them. Reply goes to both as well.

Gmail only displays the first one, but sets both addresses as Reply-To - even if no such header was set.

> Functionally, should multiple from
> addresses be considered a deprecated feature?

Not sure. I am a little concerned about possible abuse of this feature though. If your anti-spam/-phishing filter runs a check against the From address, does it know how to interpret a From field "[email-masked], [email-masked]"?

Martijn.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

Date: Tue, 28 Feb 2012 09:02:19 +0000
From: Paul Smith <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: [email-masked], [email-masked], Dave CROCKER <[email-masked]>
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------090907040403020405070807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 27/02/2012 23:10, Randall Gellens wrote:
>
>     /The Smithsonian has acquired the tapes, documentation,
>     copyrights, and over 50,000 lines of code that chronicle the
>     invention of e-mail. The lines of code that produced the first
>     "bcc," "cc," "to" and "from" fields were the brainchild of
>     then-14-year0old inventor V.A. Shiva Ayyadurai./
>
>
> Which seems to miss several points (such as the difference between a 
> copyright and a trademark or patent, the difference between email in 
> general and one specific program called EMAIL, and when to/cc/bcc/from 
> came into use).
>

Of course, from the description above, it's the lines of code that 
produced the first bcc, cc, to and from fields which were his brainchild 
- not the design or specification for those codes.

So, apparently he should be remembered for writing something like:

send("From: ");
send (sendersAddress);
send(CRLF);

(Not to mention that bcc "fields" should not exist anyway - that's the 
whole point)

--------------090907040403020405070807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 27/02/2012 23:10, Randall Gellens wrote:
    <blockquote cite="mid:[email-masked]"
      type="cite">
      <style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style>
      <title>Re: V.A. Shiva Ayyadurai: Inventor of e-mail
        honored by Sm</title>
      <blockquote><i>The Smithsonian has acquired the tapes,
          documentation,
          copyrights, and over 50,000 lines of code that chronicle the
          invention
          of e-mail. The lines of code that produced the first "bcc,"
          "cc," "to" and "from" fields were the brainchild of
          then-14-year0old inventor V.A. Shiva Ayyadurai.</i></blockquote>
    </blockquote>
    <blockquote cite="mid:[email-masked]"
      type="cite">
      <blockquote><br>
      </blockquote>
      <div>Which seems to miss several points (such as the difference
        between a copyright and a trademark or patent, the difference
        between
        email in general and one specific program called EMAIL, and when
        to/cc/bcc/from came into use).</div>
      <br>
    </blockquote>
    <br>
    Of course, from the description above, it's the lines of code that
    produced the first bcc, cc, to and from fields which were his
    brainchild - not the design or specification for those codes.<br>
    <br>
    So, apparently he should be remembered for writing something like:<br>
    <br>
    send("From: ");<br>
    send (sendersAddress);<br>
    send(CRLF);<br>
    <br>
    (Not to mention that bcc "fields" should not exist anyway - that's
    the whole point)<br>
    <br>
    <br>
    <br>
    <br>
  <br></body>
</html>

--------------090907040403020405070807--

Date: Mon, 27 Feb 2012 22:16:23 -0800
To: <[email-masked]>, Steve Atkins <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: MUA support for multiple from addresses
CC: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

At 4:11 PM -0800 2/27/12, <[email-masked]> wrote:

>   If we're going to
>  deprecate everything that some client botches, we'll end up deprecating
>  email in its entirety.
>
>  Or maybe we should all switch to using V.A. Shiva Ayyadurai's EMAIL code - no
>  doubt he got all of this stuff right, what with him being the inventor of it
>  all ;-) (Sorry about that, but I just couldn't resist.)

Both of these lines cracked me up :-)

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
37% of Americans agree that while they would hate being British,
they wouldn't mind having a British accent.

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 28 Feb 2012 02:02:23 -0000
From: "John Levine" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: MUA support for multiple from addresses
Organization: 
Sender: [email-masked]

>> Mails are allowed to have multiple addresses in the from header as
>> long as they also have a sender header.  However, in basic testing, I
>> have yet to find a MUA that even displays multiple entries for from.
>> Has anyone seen such a user agent?  

Alpine lets you create them and displays them reasonably.

>I'm a bit vague on what their intended use is/was.

Any sort of message where a paper version would have two signatures.
It's always been there, rarely been used other than to prove that it's
possible, but there are a few people who passionately believe that
it's important.

Given how little it's used, I'd think it should have been deprecated
or deleted in 5322 in the interest of better interop, but that
apparently wasn't even on the table.

R's,
John

From: [email-masked]
Cc: SMTP Interest Group <[email-masked]>
Date: Mon, 27 Feb 2012 16:11:28 -0800 (PST)
Subject: Re: MUA support for multiple from addresses
To: Steve Atkins <[email-masked]>
Sender: [email-masked]

> On Feb 27, 2012, at 10:35 AM, Peter Bowen wrote:

> > Mails are allowed to have multiple addresses in the from header as
> > long as they also have a sender header.  However, in basic testing, I
> > have yet to find a MUA that even displays multiple entries for from.
> > Has anyone seen such a user agent?

> Mail.app on OS X displays multiple From: addresses correctly, highlights
> them as separate addresses with separate context menus correctly.

So does SeaMonkey. Since the mail component of SeaMonkey is based on
Thunderbird, I presume that means it does as well, although I haven't tried it.

I'm pretty sure Mulberry also supports this, although I don't seem to have a
copy handy to check.

> Reply and Reply All respond to just the first of the From: addresses,
> while Reply to Sender replies to both of them.

In SeaMonkey both reply and reply-all go to both addresses, which is the
behavior I would expect.

I send out messages with multiple froms fairly regularly. I do make sure to
include the Sender: client (actually, my client does it for me) and I also make
sure to list the primary author first, in case of client misbehavior. I can
think of only one time it caused a problem, and that was with the client Dave
Crocker happened to be using at the time (!).

I receive messages with them less often but occasionally nevertheless.

> So it seems to work fine, though given I don't really understand the
> intended semantics I'm not sure if they match that.

I could make an argument for those semantics being OK, but I think the ones in
SeaMonkey are a little better.

> > Functionally, should multiple from
> > addresses be considered a deprecated feature?

Seems like several pretty popular clients support it.

> I'm a bit vague on what their intended use is/was.

The idea is that if a message is written by multiple people, you put all the
author names in the From: field and the name of the person who actually sent
the message in the Sender:. Pretty simple, actually - the problem lies in
building a sensible UI to actually create such messages. And as Randy points
out, a lot of legitimate uses of it run afoul of incompetently designed
security restrictions.

I also frequently get replies - both automatic and manual - when the only place
where my address appeared is in the Sender: field of the original message. (And
no, there weren't any multiple From: addreses involved.) If we're going to
deprecate everything that some client botches, we'll end up deprecating
email in its entirety.

Or maybe we should all switch to using V.A. Shiva Ayyadurai's EMAIL code - no
doubt he got all of this stuff right, what with him being the inventor of it
all ;-) (Sorry about that, but I just couldn't resist.)

				Ned

To: Steve Atkins <[email-masked]>
Cc: SMTP Interest Group <[email-masked]>
From: Mark Andrews <[email-masked]>
Subject: Re: MUA support for multiple from addresses
Date: Tue, 28 Feb 2012 11:31:27 +1100
Sender: [email-masked]

In message <[email-masked]>, Steve Atkins writ
es:
> 
> 
> On Feb 27, 2012, at 10:35 AM, Peter Bowen wrote:
> 
> > 
> > Mails are allowed to have multiple addresses in the from header as
> > long as they also have a sender header.  However, in basic testing, I
> > have yet to find a MUA that even displays multiple entries for from.
> > Has anyone seen such a user agent?  
> 
> Mail.app on OS X displays multiple From: addresses correctly, highlights
> them as separate addresses with separate context menus correctly.
> 
> Reply and Reply All respond to just the first of the From: addresses,
> while Reply to Sender replies to both of them.
> 
> So it seems to work fine, though given I don't really understand the
> intended semantics I'm not sure if they match that.
> 
> > Functionally, should multiple from
> > addresses be considered a deprecated feature?
> 
> I'm a bit vague on what their intended use is/was.
> 
> Cheers,
>   Steve

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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Mon, 27 Feb 2012 15:10:28 -0800
To: <[email-masked]>, <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
CC: <[email-masked]>, Dave CROCKER <[email-masked]>
Sender: [email-masked]

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: V.A. Shiva Ayyadurai: Inventor of e-mail
honored by Sm</title></head><body>
<div>At 5:51 PM -0800 2/18/12, Dave CROCKER wrote:</div>
<div><br></div>
<blockquote type="cite" cite>For reference, I just sent this
message:</blockquote>
<div><br></div>
<div>The Washington Post article now has this text:</div>
<div><br></div>
<blockquote><i>Clarification: A number of readers have accurately
pointed out that electronic messaging predates V. A. Shiva
Ayyadurai's work in 1978. However, Ayyadurai holds the copyright to
the computer program called"email," establishing him as the
creator of the "computer program for [an] electronic mail system"
with that name, according to the U.S. Copyright
Office.</i></blockquote>
<blockquote><i><br></i></blockquote>
<blockquote><i>The Smithsonian has acquired the tapes, documentation,
copyrights, and over 50,000 lines of code that chronicle the invention
of e-mail. The lines of code that produced the first "bcc,"
"cc," "to" and "from" fields were the brainchild of
then-14-year0old inventor V.A. Shiva Ayyadurai.</i></blockquote>
<blockquote><br></blockquote>
<div>Which seems to miss several points (such as the difference
between a copyright and a trademark or patent, the difference between
email in general and one specific program called EMAIL, and when
to/cc/bcc/from came into use).</div>
<div><br></div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div><font color="#000000">Randall Gellens<br>
Opinions are personal;&nbsp;&nbsp;&nbsp; facts are
suspect;&nbsp;&nbsp;&nbsp; I speak for myself only<br>
-------------- Randomly selected tag: ---------------<br>
Resistance is futile! &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(If less than one ohm.)<br>
</font></div></body>
</html>

Subject: Re: MUA support for multiple from addresses
From: Steve Atkins <[email-masked]>
Date: Mon, 27 Feb 2012 14:36:51 -0800
To: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

On Feb 27, 2012, at 10:35 AM, Peter Bowen wrote:

> 
> Mails are allowed to have multiple addresses in the from header as
> long as they also have a sender header.  However, in basic testing, I
> have yet to find a MUA that even displays multiple entries for from.
> Has anyone seen such a user agent?  

Mail.app on OS X displays multiple From: addresses correctly, highlights
them as separate addresses with separate context menus correctly.

Reply and Reply All respond to just the first of the From: addresses,
while Reply to Sender replies to both of them.

So it seems to work fine, though given I don't really understand the
intended semantics I'm not sure if they match that.

> Functionally, should multiple from
> addresses be considered a deprecated feature?

I'm a bit vague on what their intended use is/was.

Cheers,
  Steve

Date: Mon, 27 Feb 2012 14:10:55 -0800
To: Peter Bowen <[email-masked]>, <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: MUA support for multiple from addresses
Sender: [email-masked]

At 10:35 AM -0800 2/27/12, Peter Bowen wrote:

>  Mails are allowed to have multiple addresses in the from header as
>  long as they also have a sender header.  However, in basic testing, I
>  have yet to find a MUA that even displays multiple entries for from.
>  Has anyone seen such a user agent?  Functionally, should multiple from
>  addresses be considered a deprecated feature?

Eudora for Mac (through v6 at least) has a setting allowing the From 
header field in a message composition window to be editable.  I have 
this option set (and very frequently edit the From address to be a 
one-off or something else that doesn't match a specific personality). 
I have on rare occasion set the From header field to be two 
addresses, although I don't know how the receiving clients display 
this.

These days, there is often a belief, mistaken in my view, that 
restricting the addresses people are able to use in the From header 
field improves security.  As an example, the message submission 
server I'm supposed to use rejects messages from an address it 
doesn't think I should be using, including any user-detail address, 
or when I use Eudora's "Redirect" feature (which re-sends a received 
message to someone else, preserving the original value of the From 
header field, but adding a "(by way of ...)" comment).

Given the lack of wide support for multiple addresses, and the 
increasingly restrictive view of From addresses, it may make sense to 
think about if this feature should be deprecated.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The irony of the Information Age is that it has given new
respectability to uninformed opinion.       --John Lawton

Date: Mon, 27 Feb 2012 10:35:38 -0800
Subject: MUA support for multiple from addresses
From: Peter Bowen <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Mails are allowed to have multiple addresses in the from header as
long as they also have a sender header.  However, in basic testing, I
have yet to find a MUA that even displays multiple entries for from.
Has anyone seen such a user agent?  Functionally, should multiple from
addresses be considered a deprecated feature?

Thanks,
Peter

Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
From: Paul Hoffman <[email-masked]>
Date: Sun, 19 Feb 2012 07:51:14 -0800
Cc: [email-masked]
To: [email-masked]
Sender: [email-masked]

On Feb 19, 2012, at 6:46 AM, Dave CROCKER wrote:
> I thought that perhaps he was just clueless, but the Time article makes clear
> that he knows he's not telling the truth.

This just shows that email has been subject to trivial spoofing attacks much longer than we have acknowledged.

Date: Sun, 19 Feb 2012 06:46:22 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

On 2/18/2012 9:22 PM, Pete Resnick wrote:
> It appears he is just a self aggrandizing liar.

I missed the Time article.

I thought that perhaps he was just clueless, but the Time article makes clear
that he knows he's not telling the truth.  Here's one paragraph of the note I
sent to the Post's Ombudsman:

>    "Then later, I think it was �81 or �82, the RFC protocol was changed to add
> the �from:�, the �cc:��those things."
 >
> His statement displays very specialized knowledge, but the claimed facts are
> wrong.  (RFCs are technical documents, including many Internet standards.) To
> point away from the proper "RFC" documents that would make his error clear,
> he points to the wrong one.  (POP is a secondary transfer protocol.  The one
> that is interesting in the 1982 timeframe was one I wrote -- RFC 822 -- but
> it was merely a revision of one I co-authored in 1977 and THAT was merely
> codifying practice going back to the early 70s.)

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sun, 19 Feb 2012 01:11:47 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Pete Resnick <[email-masked]>
CC: [email-masked], Dave CROCKER <[email-masked]>, [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

+1, that is what is so surprising.  Seems to me this guy, clearly was 
intelligent (a Westinghouse Science Award participant is not something 
to sneer at) and was smart enough to exploit the system.  Registering 
the copyright of this first and last 100 code lines under the term 
"EMAIL" well, I have to give him credit for some brilliance if the 
USPTO was too incompetent to question it.  I was very privy to many IP 
related issues of software at Westinghouse with many of the early 
conflicts and many early court precedence of what instituted software 
IP issues.

Just consider that when I send an article to PC MAG to get that $50 
illustrating how to do a TREE DIAGRAM of your directory, I was quickly 
called to the Pittsburgh HQ chief counsel and told, "You can't to that."

So consider that this KID, even if he should be recognized as the 
inventor of something, in that ERA, he would not be owner of the IP - 
but rather the company that he did it for.

This is strongly based on court precedence which in summary says, if a 
company is paying 80% or more of your compensation, they are the owner 
of any invention of your work.  This was very important for the era 
dealing with Consultants.  If the consultant "LIFE" was dependent on 
the company he was doing work for, the company own ALL the work.  He 
had to prove that the work compensation was not a life dependency.

He was a KID, clearly he was not funding any of his work on his own. 
He used some centralized system and simply wrote a nice UI.  So push 
comes to solve, if there are any claims of ownership would be the 
company he did the work for.

I know this because the lawyers I have are experts in making such 
people work at McDonald's for a few years due to violations of NDA and 
company IP contracts.

Pete Resnick wrote:
> 
> On 2/18/12 7:51 PM, Dave CROCKER wrote:
>> For reference, I just sent this message...
> 
> Apparently this is not the first time this guy has made up stuff and 
> told the press. This surfaced in Time magazine last year as well:
> 
> http://techland.time.com/2011/11/15/the-man-who-invented-email/
> 
> It appears he is just a self aggrandizing liar.
> 
> You might also want to send to [email-masked] or call 202.334.7582.
> 
> http://www.washingtonpost.com/patrick-b-pexton/2011/02/24/ABkLhYN_page.html
> 
> Incredibly poor fact checking and editing.
> 
> pr
> 

-- 
Sincerely

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

Date: Sun, 19 Feb 2012 00:33:29 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Russ Allbery <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

Russ Allbery wrote:
> Hector Santos <[email-masked]> writes:
> 
>>     This was the first database-driven system that translated all
>>     elements of an inter-office memorandum/mail, then in paper form,
>>     along with features of Inbox, Outbox and Folders, to an electronic
>>     mail format. In 1981, this system was recognized by the Westinghouse
>>     Science Talent Search receiving an Honors Award. Later, in 1982, the
>>     US Copyright Office issued him the first copyright of his system
>>     called â€œEMAILâ€.  [11][12]
> 
> [...]
> 
>> But he went ahead and copyrighted the term "EMAIL" and some how was
>> awarded the copyright.
> 
> Note that it says "copyright," not "trademark," so this isn't about the
> term.  The US Copyright Office doesn't care what you call things.

Good point, and at the time, the cheapest non-patented method (which 
was a high hurdle with just software) was to do a official copyright 
registration which requires the first and last 100 lines of code of 
your software to be filed at the copyright office.

But it it seems to be a confusion that the registered term "EMAIL" 
which erroneously implies an all encompassing "electronic mail" which 
clearly he has no rights too.

> Presumably he registered a copyright on the source code of his system,
> which happened to be called EMAIL.  

Right, and if I recall, the requirements was to provide the first and 
last 100 lines of code ( I feel I am correct about that). But short of 
doing this, the alternative was a Trade Secret registration.

> You can pay the US Copyright Office for a registered copyright on any creative work 
> you want provided you fill out the right forms.  

I think I understand your point, but I tend to feel at the time (the 
80s) there was more due diligence at the USPTO and that was one of the 
growing problems when cost cutting efforts began, including the brain 
drain (no expertise to do the reviews).

> It doesn't imply any approval or legal recognition;
> it's just helpful if you ever have to sue someone later over the
> copyright, since it means that there's an independent legal record of the
> date and the original creative material on file.

+1.  By law, the mere act of just WRITING is copyrighted material, 
i.e. this post is an official copyrighted message <g> but when there 
are challenges, an official registration is the only and clear way to 
get over challenges.

-- 
Sincerely

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

Date: Sat, 18 Feb 2012 23:22:37 -0600
From: Pete Resnick <[email-masked]>
To: <[email-masked]>
CC: Dave CROCKER <[email-masked]>, <[email-masked]>
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

On 2/18/12 7:51 PM, Dave CROCKER wrote:
> For reference, I just sent this message...

Apparently this is not the first time this guy has made up stuff and 
told the press. This surfaced in Time magazine last year as well:

http://techland.time.com/2011/11/15/the-man-who-invented-email/

It appears he is just a self aggrandizing liar.

You might also want to send to [email-masked] or call 202.334.7582.

http://www.washingtonpost.com/patrick-b-pexton/2011/02/24/ABkLhYN_page.html

Incredibly poor fact checking and editing.

pr

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

Date: Sat, 18 Feb 2012 20:45:29 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: SM <[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 2/18/2012 8:11 PM, SM wrote:
> RFC 733 was published in November 1977. That's a year before what is mentioned
> in the article. RFC 680, published in 1975, mentions the header fields.

There were a series of efforts, with RFC 733 being the culmination, not the start.

RFC 561, Standardizing Network Mail Headers,  was Sept, 73.

And then, of course, there's RFC 475, March, 73, specifying mail transport.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sat, 18 Feb 2012 20:11:04 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Cc: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

Hi Dave,
At 15:07 18-02-2012, 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>

RFC 733 was published in November 1977.  That's a year before what is 
mentioned in the article. RFC 680, published in 1975, mentions the 
header fields.

Regards,
-sm 

From: Russ Allbery <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Organization: The Eyrie
Date: Sat, 18 Feb 2012 19:53:33 -0800
Sender: [email-masked]

Hector Santos <[email-masked]> writes:

>     This was the first database-driven system that translated all
>     elements of an inter-office memorandum/mail, then in paper form,
>     along with features of Inbox, Outbox and Folders, to an electronic
>     mail format. In 1981, this system was recognized by the Westinghouse
>     Science Talent Search receiving an Honors Award. Later, in 1982, the
>     US Copyright Office issued him the first copyright of his system
>     called “EMAIL”.  [11][12]

[...]

> But he went ahead and copyrighted the term "EMAIL" and some how was
> awarded the copyright.

Note that it says "copyright," not "trademark," so this isn't about the
term.  The US Copyright Office doesn't care what you call things.

Presumably he registered a copyright on the source code of his system,
which happened to be called EMAIL.  You can pay the US Copyright Office
for a registered copyright on any creative work you want provided you fill
out the right forms.  It doesn't imply any approval or legal recognition;
it's just helpful if you ever have to sue someone later over the
copyright, since it means that there's an independent legal record of the
date and the original creative material on file.

(This doesn't keep various scammers from selling you information on how to
register your copyrights and how that will make you rich and cure
baldness, of course.  It's a common scam in the publishing business.)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
From: "Alex Bobotek" <[email-masked]>
Date: Sat, 18 Feb 2012 19:30:06 -0800
To: "Carl S. Gutekunst" <[email-masked]>
Cc: "John Levine" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

--Apple-Mail-113--872310130
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

He clearly is the 'inventor' of "EMAIL" but certainly not of email.  I wonde=
r if there's someone napping at the Smithsonian, or if it's just the Post co=
nfusing EMAIL with email.  The guy may be well worthy of recognition, just n=
ot for inventing email.  Perhaps an editor is to blame for the erroneous hea=
dline and denotation in the story.

Go get 'em Dave.  Have them publish a correction.   =20

Regards,

Alex=20

On Feb 18, 2012, at 5:42 PM, "Carl S. Gutekunst" <[email-masked]> wrote:

> John Levine wrote:
>>=20
>>> 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>=

>>>    =20
>>=20
>> It's more just strange.  Looking at the article and the pictures that
>> go with it, can anyone figure out what it was he was doing?
>=20
> https://en.wikipedia.org/wiki/Shiva_Ayyadurai
>=20
> EMAIL is the name of the software package he wrote while in High School. H=
e holds the patent for Auto-reply, among other things.
>=20
> <csg>
>=20

--Apple-Mail-113--872310130
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=utf-8

<html><body bgcolor="#FFFFFF"><div>He clearly is the 'inventor' of "EMAIL" but certainly not of email. &nbsp;I wonder if there's someone napping at the Smithsonian, or if it's just the Post confusing EMAIL with email. &nbsp;The guy may be well worthy of recognition, just not for inventing email. &nbsp;Perhaps an editor is to blame for the erroneous headline and denotation in the story.</div><div><br></div><div>Go get 'em Dave. &nbsp;Have them publish a correction. &nbsp; &nbsp;<br><br>Regards,<div><br></div><div>Alex&nbsp;</div></div><div><br>On Feb 18, 2012, at 5:42 PM, "Carl S. Gutekunst" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div>

John Levine wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">Well, this is sad:
   V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
<a class="moz-txt-link-rfc2396E" href="http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html">&lt;<a href="http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html">http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html</a>&gt;</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It's more just strange.  Looking at the article and the pictures that
go with it, can anyone figure out what it was he was doing?</pre>
</blockquote>
<br>
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Shiva_Ayyadurai"><a href="https://en.wikipedia.org/wiki/Shiva_Ayyadurai">https://en.wikipedia.org/wiki/Shiva_Ayyadurai</a></a><br>
<br>
EMAIL is the name of the software package he wrote while in High
School. He holds the patent for Auto-reply, among other things.<br>
<br>
&lt;csg&gt;<br>
<br>

</div></blockquote></body></html>
--Apple-Mail-113--872310130--

Date: Sat, 18 Feb 2012 22:21:39 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Carl S. Gutekunst" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

Carl S. Gutekunst wrote:
> John Levine 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> 
>>>
>>>     
>>
>> It's more just strange.  Looking at the article and the pictures that
>> go with it, can anyone figure out what it was he was doing?
> 
> https://en.wikipedia.org/wiki/Shiva_Ayyadurai
> 
> EMAIL is the name of the software package he wrote while in High School. 
> He holds the patent for Auto-reply, among other things.

Which is frivilous and really silly because RBM (Rule Based Messaging) 
was patented technology a long time go and probably around the time 
where the new TIMELINE was instituted where PRIOR ART was thrown own 
by these silly software method patents.

Just look at this way, his patent claims the idea for VACATION replies 
and mail filters using flexible rules you can create that include 
using body words triggers or more importantly long time CMS technology 
and help desk methods that 100% are based on body context.  That is 
just a few.

His patent is a prime example of the ills of the new Timelines in 
Software-Method Patents that essentials allows the ignorance of prior 
art for applying and when contested, allows him to simpler add 
reference to it in a patent update.

But he has no power to enforce it on people who can prove prior art 
implementation and thus why I don't worry about this silly crap.

-- 
Sincerely

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

Date: Sat, 18 Feb 2012 22:05:58 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

Dave, I hope you continue following up on this.  Even in his wikipedia 
(I presumed self created), he doesn't claim to be the inventor and 
pointed out there was existing systems. But he registered the 
copyright the term "EMAIL" and I guess from there, any layman may 
assume he invented email:

http://en.wikipedia.org/wiki/Shiva_Ayyadurai#EMAIL_management

     Prior to becoming a student at the Massachusetts Institute of 
Technology, while
     a high school student at Livingston High School, New Jersey, he 
implemented an email
     system at the medical school of University of Medicine and 
Dentistry of New Jersey (UMDNJ).
     Email had been previously sent on other networks such as AUTODIN, 
PLATO and ARPANet.
 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

But he is claiming as the first to tie a database:

     This was the first database-driven system that translated all 
elements of an
     inter-office memorandum/mail, then in paper form, along with 
features of Inbox, Outbox
     and Folders, to an electronic mail format. In 1981, this system 
was recognized
     by the Westinghouse Science Talent Search receiving an Honors 
Award. Later, in 1982,
     the US Copyright Office issued him the first copyright of his 
system called “EMAIL”.
     [11][12]

It is pretty silly to claim a "Database" tie in since early systems 
were essentially centralized and unless he was using systems like 
Fidonet, which I believe he is very aware of since his company need 
borrows the name "EchoMail",  each BBS system has its own database system.

He needs to be asked one question:

     If you claim to be the inventor of "Email," then want hosting 
system did you use?
     Did you also write your own Mail Hosting software and also Mail 
Transport System?

The then cyber space expansion really started with people as 3rd party 
developers, its how I started, and you had to work with some existing 
platform and if the existing platform already had a database tie on, 
then obviously he did not invent this natural law concept.  There is 
always a database or store of some kind.

But he seems to be taking credit for the UI and I am curious to know 
what package he had because if one thing was true, there was a lot of 
proprietary, contract work people did - that is how I started as well 
with the development of an smart terminal/PC X.400 Email Interface 
with the basic idea of printing out the email for your morning 
reviews.  That started for me in 81, but I recall during the late 70s 
during college, using Prime mini-computers to send/receive electronic 
mail. I don't remember the packages, but it was surely commercial.

This Westinghouse Science kid (I was associated with the selection 
committee as a Minority Representation and Speaker at High Schools, 
but didn't have any voting responsibility, just a token minority 
symbol) simply had exposure to existing commercial systems and perhaps 
wrote a fancy UI (had to be dial up) and got a big pat on the back and 
not surprising because it was really still new.   But he went ahead 
and copyrighted the term "EMAIL" and some how was awarded the 
copyright. Also, not surprising with the era but I am very surprised 
at what appears to be a Smithsonian lack of due diligence here.

--

Dave CROCKER wrote:
> 
> For reference, I just sent this message:
> 
> 
> 
> 
> Date: Sat, 18 Feb 2012 17:14:29 -0800
> From: Dave CROCKER <[email-masked]>
> Reply-To: [email-masked]
> Organization: Brandenburg InternetWorking
> To: Peggy Kidwell <[email-masked]>
> CC: Emi Kolawole <[email-masked]>
> Subject: V.A. Shiva Ayyadurai's purported invention of email
> 
> 
> Ms. Kidwell,
> 
> Hello.
> 
> I just saw the Washington Post article about V.A. Shiva Ayyadurai's work 
> being
> acknowledged by the Smithsonian as the invention of email.  In the video
> associated with the article, he cites contact with you.  So I thought 
> you might
> be appropriate to contact for possible followup through the Smithsonian. 
> I'm
> trying to copy Post article's author, but am guessing at her email address.
> 
> Unfortunately, Ayyadurai's work was not even close to the earliest email.
> 
> Email dates back to the 1960's with the earliest computer timesharing 
> systems,
> such as at MIT.
> 
> Networked email was invented by Ray Tomlinson at Bolt, Beranek & Newman 
> (BBN) in
> 1971; the email object from then looks remarkably similar to the basic 
> message
> that Internet Mail; the  service has actually been in continuous 
> operation since
> then.
> 
> Ray added inter-machine transfer -- ie, networking -- to the existing 
> "sndmsg"
> mail system on BBN's timesharing system and it already had To:, cc: and 
> From:.
> I don't recall whether it had bcc, but bcc was certainly in use shortly 
> after
> that.  For example, it was in the system that I built in 1976.  I've 
> attached
> some documentation about that system (MS).  This core functionality 
> pre-dates my
> own efforts; this is just the easiest way I can document it for you.  I 
> should
> also mention that Ray and I were given the IEEE Internet Award for our
> respective work on email.
> 
> Over the last year or so, Ayyadurai contacted me about with his claims.  I
> ignored them because they are so easy to disprove. (As one of my 
> colleagues just
> noted, try looking up email in Wikipedia.)  Again referring to the 
> attached Rand
> Report, note that the first paragraph in the Preface has the term 
> 'electronic
> mail'.  And again I'll note that mine was not original use of the term.
> 
> I'm glad to chat with you or anyone else about the real history of email,
> although I wasn't in at its actual start.  My own involvement did not begin
> until 1972...
> 
> 
> [attachment:  Framework & Functions of the MS Message System, Rand 
> Report R-2134]
> 

-- 
Sincerely

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

Date: Sat, 18 Feb 2012 17:56:40 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Carl S. Gutekunst" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

On 2/18/2012 5:39 PM, Carl S. Gutekunst wrote:
> He holds the patent for Auto-reply, among other things.

Yeah, he's characterizing it that generically.  The patent claims are rather 
more constrained.

I don't remember when auto-replying happened first, but I'm pretty sure it was 
the 70s.  Certainly sendmail enabled such capabilities.  Arguably so did MMDF. 
My guess it was in some earlier systems.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sat, 18 Feb 2012 17:51:38 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
CC: [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

For reference, I just sent this message:

Date: Sat, 18 Feb 2012 17:14:29 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Peggy Kidwell <[email-masked]>
CC: Emi Kolawole <[email-masked]>
Subject: V.A. Shiva Ayyadurai's purported invention of email

Ms. Kidwell,

Hello.

I just saw the Washington Post article about V.A. Shiva Ayyadurai's work being
acknowledged by the Smithsonian as the invention of email.  In the video
associated with the article, he cites contact with you.  So I thought you might
be appropriate to contact for possible followup through the Smithsonian. I'm
trying to copy Post article's author, but am guessing at her email address.

Unfortunately, Ayyadurai's work was not even close to the earliest email.

Email dates back to the 1960's with the earliest computer timesharing systems,
such as at MIT.

Networked email was invented by Ray Tomlinson at Bolt, Beranek & Newman (BBN) in
1971; the email object from then looks remarkably similar to the basic message
that Internet Mail; the  service has actually been in continuous operation since
then.

Ray added inter-machine transfer -- ie, networking -- to the existing "sndmsg"
mail system on BBN's timesharing system and it already had To:, cc: and From:.
I don't recall whether it had bcc, but bcc was certainly in use shortly after
that.  For example, it was in the system that I built in 1976.  I've attached
some documentation about that system (MS).  This core functionality pre-dates my
own efforts; this is just the easiest way I can document it for you.  I should
also mention that Ray and I were given the IEEE Internet Award for our
respective work on email.

Over the last year or so, Ayyadurai contacted me about with his claims.  I
ignored them because they are so easy to disprove. (As one of my colleagues just
noted, try looking up email in Wikipedia.)  Again referring to the attached Rand
Report, note that the first paragraph in the Preface has the term 'electronic
mail'.  And again I'll note that mine was not original use of the term.

I'm glad to chat with you or anyone else about the real history of email,
although I wasn't in at its actual start.  My own involvement did not begin
until 1972...

[attachment:  Framework & Functions of the MS Message System, Rand Report R-2134]

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sat, 18 Feb 2012 17:39:03 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: John Levine <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------070809030207050806030601
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

John Levine 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>
>>     
>
> It's more just strange.  Looking at the article and the pictures that
> go with it, can anyone figure out what it was he was doing?

https://en.wikipedia.org/wiki/Shiva_Ayyadurai

EMAIL is the name of the software package he wrote while in High School. 
He holds the patent for Auto-reply, among other things.

<csg>

--------------070809030207050806030601
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
John Levine wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">Well, this is sad:
   V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
<a class="moz-txt-link-rfc2396E" href="http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html">&lt;http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html&gt;</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It's more just strange.  Looking at the article and the pictures that
go with it, can anyone figure out what it was he was doing?</pre>
</blockquote>
<br>
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Shiva_Ayyadurai">https://en.wikipedia.org/wiki/Shiva_Ayyadurai</a><br>
<br>
EMAIL is the name of the software package he wrote while in High
School. He holds the patent for Auto-reply, among other things.<br>
<br>
&lt;csg&gt;<br>
<br>
</body>
</html>

--------------070809030207050806030601--

Date: Sat, 18 Feb 2012 20:35:03 -0500
From: John C Klensin <[email-masked]>
To: John Levine <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

--On Saturday, February 18, 2012 23:50 +0000 John Levine
<[email-masked]> wrote:

> 
>> Well, this is sad:
>>    V.A. Shiva Ayyadurai: Inventor of e-mail honored by
>>    Smithsonian
>> <http://www.washingtonpost.com/national/on-innovations/va-shi
>> vaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02
>> /17/gIQA8gQhKR_story.html>
> 
> It's more just strange.  Looking at the article and the
> pictures that go with it, can anyone figure out what it was he
> was doing?

Not a clue, especially since email was in very active use at MIT
over a decade earlier than his supposed invention (on CTSS) and
there was ARPANET FTP-based email in active use on ITS and
Multics in the first half of the 70s.

    john

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 18 Feb 2012 23:50:27 -0000
From: "John Levine" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Organization: 
Sender: [email-masked]

>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>

It's more just strange.  Looking at the article and the pictures that
go with it, can anyone figure out what it was he was doing?

R's,
John

Date: Sat, 18 Feb 2012 15:07:25 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: SMTP Interest Group <[email-masked]>
Subject: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
Sender: [email-masked]

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>

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 17 Feb 2012 20:13:48 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "[email-masked]" <[email-masked]>
Subject: Re: Implementations of RFC4405 (SUBMITTER)
Sender: [email-masked]

Murray S. Kucherawy wrote:
> Does anyone know of any MTAs that implemented the SUBMITTER extension, defined in RFC4405?
> 
> -MSK
> 

Our SMTP server (Wildcat! SMTP) supports RFC4405.

220 winserver.com Wildcat! ESMTP Server v6.4.454.1 ready
EHLO HDEV1
250-winserver.com, Pleased to meet you.
250-SIZE 10240000
250-8BITMIME
250-SUBMITTER  <--- RFC4405
250-ETRN
250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
250-AUTH=LOGIN
250-HELP
250 STARTTLS

I should note it was supported since it was first proposed and I have 
observed numerous clients over the years that will honor this SMTP 
extension and will send the 5321.MAIL FROM SUBMITTER= keyword.  Which 
client packages name wise? Impossible to really tell which ones, but 
it is definitely a significant adoption which can only be measured 
when the ESMTP SUBMITTER option is exposed.  Without a doubt, it is 
well adopted by spammers and eMarketering mail clients. See below.

The main design code implementation change was to make sure it was 
persistently passed on (i.e. included in the internal mail queue 
parameter storage along with the return path) for relays.

For our SMTP SPF implementation, the "check_host" shim (pcode hook) is 
passed SMTP process parameters:

    result = SPF_CHECKHOST(CIP, CDN, RP [, SUBM])

where

    CIP  - connection IP,
    CDN  - client domain name (EHLO/HELO domain),
    RP   - Return path,
    SUBM - extracted RFC4405 SUBMITTER= keyword, if any, and
    result is the final SMTP reply code to use.

Two key notes:

1) A key presumption, which may not be correct, is that a domain that 
is using SID also has a v=SPF1 record.  IOW, we only look for v=spf1 
records.  I am hoping SPF-BIF can discuss this, if warranted.

2) I don't think we can correlate client RFC4405 support to mean (same 
software) SMTP server extension RC4405 support.  There seems to be a 
strong possibility clients are adding it "blindly" especially by 
spammers (eMarketers) because I definitely see the waste of using it 
when the domain is the same as the MAIL FROM a majority of time.

IOW, they are trying to get some Sender-ID "Brownie Points" support 
illusion.  For example  the following list is just today's log 
collection of MAIL FROM session lines upto this moment of time. Note 
how the majority of them, if not all, the MAIL FROM and the SUBMITTER 
domains are the same. That is a waste in SPF terms.

00:32:25 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
01:24:35 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
01:43:26 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
02:09:56 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
04:00:45 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
04:05:29 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
05:05:22 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
06:26:18 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
06:47:18 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
06:52:29 C: MAIL 
FROM:<[email-masked]> 
SUBMITTER=[email-masked]
06:53:10 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
06:58:43 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
06:59:49 C: MAIL 
FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:01:53 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:06:20 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:07:34 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:10:05 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:11:03 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:15:17 C: MAIL 
FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:16:04 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:20:59 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:23:54 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:29:11 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:29:11 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:29:11 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:30:21 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:31:34 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
07:32:36 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:35:09 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:35:20 C: MAIL 
FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:37:17 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:42:40 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:46:24 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:48:37 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:59:13 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
07:59:30 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
08:05:52 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
08:13:45 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
08:16:42 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
08:29:18 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
08:30:22 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
08:38:03 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
08:48:25 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
08:50:29 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
08:52:47 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
08:58:18 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:02:44 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:04:31 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:13:36 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:13:58 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:14:31 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:18:26 C: MAIL 
FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:29:48 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:32:43 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
09:39:40 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:44:40 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:48:29 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:50:20 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:50:33 C: MAIL 
FROM:<[email-masked]> 
SUBMITTER=[email-masked]
09:56:06 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
09:59:19 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:01:00 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:05:36 C: MAIL 
FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:09:21 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:13:18 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:13:22 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:14:14 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
10:16:00 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:20:00 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:23:26 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:25:44 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:25:48 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:26:58 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:29:34 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:34:18 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:36:28 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:37:25 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:43:26 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:48:03 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
10:52:25 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:53:13 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
10:57:29 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
10:57:52 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:00:10 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
11:04:32 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
11:04:35 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:07:38 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:08:02 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:08:07 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:11:30 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:12:47 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:15:05 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:15:47 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:19:58 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:43:58 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:45:04 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:48:19 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:49:16 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:49:50 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
11:55:23 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:05:18 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
12:22:39 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:29:03 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:32:01 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:33:39 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:35:20 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:42:21 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:51:37 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:53:14 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:53:40 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:53:47 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
12:56:29 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
12:56:29 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
12:57:32 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:04:45 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
13:07:07 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:07:50 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:13:05 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:21:03 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:23:06 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:23:13 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:23:31 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:23:50 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:26:07 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:27:48 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:32:14 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:36:25 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:43:35 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
13:46:49 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
13:54:19 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
14:09:22 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
14:13:15 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
14:19:25 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
14:20:05 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
14:34:19 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
14:48:01 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
14:48:57 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
14:52:51 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
15:03:28 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
15:20:08 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
15:25:08 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
15:36:50 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
15:38:03 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
15:44:13 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
15:44:20 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
15:55:46 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
16:03:32 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
16:13:08 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
16:13:13 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
16:21:31 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
16:25:57 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
16:31:22 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
16:36:39 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
16:42:17 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
16:44:32 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
16:46:41 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
16:52:38 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
16:53:54 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
17:04:27 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
17:06:09 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
17:10:16 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
17:10:37 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
17:11:46 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
17:15:14 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
17:21:11 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
17:29:53 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
17:41:09 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
17:41:09 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
17:52:35 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
17:52:36 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
18:01:18 C: MAIL 
FROM:<bounce-2314-289727987-andrea.santos=[email-masked]> 
SUBMITTER=[email-masked]
18:03:34 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
18:12:46 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
18:15:54 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
18:26:51 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
18:32:29 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
18:38:34 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
18:43:00 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
18:55:32 C: MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]
18:55:50 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
19:31:48 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
19:51:03 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]
19:51:24 C: MAIL FROM:<[email-masked]> 
SUBMITTER=[email-masked]

-- 
Sincerely

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

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 17 Feb 2012 11:13:27 -0800
Subject: Implementations of RFC4405 (SUBMITTER)
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_F5833273385BB34F99288B3648C4F06F19C9A7DDF6EXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Does anyone know of any MTAs that implemented the SUBMITTER extension, defi=
ned in RFC4405?

-MSK

--_000_F5833273385BB34F99288B3648C4F06F19C9A7DDF6EXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Does anyone know=
 of any MTAs that implemented the SUBMITTER extension, defined in RFC4405?<=
o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNorma=
l>-MSK<o:p></o:p></p></div></body></html>=

--_000_F5833273385BB34F99288B3648C4F06F19C9A7DDF6EXCHC2corpclo_--