"for" and Deliever-to: (draft-crocker-email-deliveredto))

Viktor,

This sort of got lost in the other discussion... sorry.  I'm
adjusting the subject line.

--On Tuesday, August 17, 2021 11:48 -0400 Viktor Dukhovni
<[email protected]> wrote:

> On Tue, Aug 17, 2021 at 11:03:50AM -0400, John C Klensin wrote:
> 
>> Once upon a time, "for" was very heavily used, not just in
>> single-recipient messages but to trace address
>> transformations.
> 
> The issue disappears once we correctly define single-recipient.
> Provided single-recipient means single *input* envelope
> address, (e.g. single "RCPT TO" in SMTP or SUBMIT), no extant
> MTA I'm aware of adds a "for" clause recording one of many or
> multiple envelope recipients of the same message (envelope)
> that then ends up disclosing "Bcc" recipients to other
> recipients, ...
> 
> Of course the "single" recipient might subsequently expand to
> multiple recipients that all receive copies of the original
> "single-recipient" message, that's fine and expected.
> 
> Do you have any evidence of extant MTAs recording "for"
> clauses that violate the above?  If you find misguided use of
> "for" in a vintage MTA snapshot from the 1980s, I might not be
> surprised...

My (vague) recollection involved some systems trying to put in
multiple addresses (when there were multiple RCPT commands a
very long time ago.  But I would be more than mildly astonished
if any extant MTA was doing it, especially because the extant
embedded, pre RFC 1425 and 2721, that are using dedicated MTAs
(maybe Submission Servers in today's language and still speaking
821) are definitely single-address.  As far as anything I know
of that is contemporary, my understanding and your analysis
agree.

>> It was, however, never very popular for multi-recipient
>> messages.
> 
> The "for" clause should never appear for messages with
> multiple envelope recipients, unless "for" is added on
> delivery (after the envelope splits) rather than on input
> (prior to envelope split).  It should never record any
> recipient address that wasn't the address that caused the
> message to be routed to the receiving user.

While I agree, the specs are not nearly that specific.  See
below.

>> That was mostly at a time when we didn't pay much attention to
>> privacy of envelope information
> 
> Discloure of unrelated Bcc addresses that did not lead to the
> recipient reading the mesage is not a privacy issue, it
> violates the expected semantics of the message, and is a bug
> in any MTA that does it.

That is really a separate question.  Remembering that something
with the functionality of a submission server is likely to know
the difference between "To:", "Cc:" and "Bcc:" recipients (even
if an NTA receiving RCPT commands does not), _if there were no
other issues_ a "for" clause that showed more than one (or
all)of the "To:" and "Cc:" would be perfectly reasonable from
the standpoint of information disclosure to the recipients,
which is what I think you are talking about.

>> As sensitivity to privacy of that information increased, the
>> use of "for" decreased.
> 
> Perhaps because Microsoft never implemented it in Exchange,
> rather than any privacy concern.

Perhaps.  But if every email feature that was not implemented,
or implemented incorrectly, in Exchange had dropped out of
contemporary usage, the world would probably look a lot
different.

>> Coming back to the document after that long digression, if we
>> think that confusion between the intended use of "for" and the
>> intended use of "Delivered-to:" is important, it might be
>> useful to include somewhat more text than is now present to
>> explain the difference between the intent and application of
>> the two.  I'll leave to others whether that is worth the
>> trouble in a to-be-Experimental text that has been kicking
>> around this long.
> 
> If "for" should be clarified, let's do it in a document that
> is separate from "Delivered-To".  This feels like proper scope
> for 5321bis, and not a document specifying the "Delivered-To"
> field.

Agree completely.  My working hypothesis is that 5321bis/5322bis
are ok but that a variations of your explanation above might be
useful in the A/S.  If you (or anyone else) think something is
needed, please go to EMAILCORE and open a ticket.  I brought
"for" up in my note only because it is an element of the "what
is an additional header field needed for and what are the
semantics of its content" question.

   john