Re: "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.

Our MTA still generates it by default, but it's easily disabled.

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

Assuming what you put in the for clause is in fact the initial RCPT TO (more on
that below), it's a bit more complex than this. For a given output message
copy, there are four cases:

(0) The message copy is associated with a single recipient, which
    originated from a single RCPT TO.

(1) The message copy is associated with multiple recipients, but they
    originated from a single RCPT TO.

(2) The message copy is associated with a single recipient, which
    originated from multiple RCPT TOs.

(3) The message copy is associated with multiple recipients from
    multiple RCPT TOs.

(3) is clearly the do not generate case, (0) and (1) are OK to generate.

The odd case is (3). Treating it as a do not generate case seems reaonable to
me, but OTOH aside from possible confusion I'm not seeing a strong reason not
to generate.

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

Case (1) above. However, this again assumes what's being logged in
the for clause is the original RCPT TO. Neither RFC 5321 nor its
predecessors actually require this, and it's not what we do: Since
we defer Received: field generation to the point at which the message
copy is created, we use a "nearly" final version of the address, which
can be completely different from the RCPT TO.

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

I've seen syntactically invalid stuff, but not, AFAICR, multiple
addresses.

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

That's one of the reasons why we wait - we want to take full advantage
of any splits that occur. And there are lots of things that can
trigger a 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.

Unfortunate but true. The text implies that what's recorded has
something to do with RCPT TO fields, but that's as far as it goes.

We probably should fix this in 5321bis.

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

Email addresses are commonly classified as Personally Identifiable Information
(PII). Improper disclosure of PII is most definitely a privacy issue, although
whether or not this dictates email system behavior in general or 
this case in particular is unclear.

There's another security issue lurking in all this: If the  system inserts a
"for" clause when there's only one recipient, and doesn't when there are more
than one, the absence of the field is itself an indication that there's another
recipient, which may allow someone to infer a Bcc: is involved.

Note that this last consideration applies to any field whose generation
is conditional on there being only one recipient,

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

Good point.

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

I think a statement to the effect that the value of the for clause must contain
one of the addresses that caused the message to be routed to the recipient of
this message copy. Discussion of which value to use - if we want to go there -
is an AS matter.

And while the security issue I pointed out may be a bit obscure - although I
have used it myself on several occasions - I thkn it needs to be
mentioned.

				Ned