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.
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp