ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] "for" and Deliever-to: (draft-crocker-email-deliveredto))

2021-08-18 13:20:30
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
<ietf-dane(_at_)dukhovni(_dot_)org> 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

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>