John C Klensin <john+smtp(_at_)jck(_dot_)com> writes in gmane.ietf.smtp:
--On Monday, 30 April, 2007 10:23 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
...
Previous standards (RFC 821, 822) did not allowed several
addresses, so is these multiple mailboxes on "for" clause
never implemented?
If it's implemented it's not better than Apparently-To, as
noted in 2821 4.4, but the Apparently-To got a "SHOULD NOT".
Why allow an in essence identical damage in the for-clause ?
Whether one has a single address in a "for" clause or three, the
information disclosure risk is identical. If the address(es)
in "for" are identical to, or a subset of, the forward-pointing
addresses in the headers, then there is no information
disclosure and no problem whether there is one address or more
than that. If anything in the "for" is not in the
forward-pointing address set in the headers, then there is a
disclosure that could be problematic.
Looking from another angle:
If mail have just one envelope recipient and
that is copied to "for" clause, that does not disclose
possible Bcc: recipients (only possible BCC recipient
for that copy of mail is just that recipient of mail.)
Not quite. The exposure occurs not when the for clause is present but when it
is absent. If the recipient knows that his mail system inserts a for clause
whenever there's only one recipient but does not do so when there are more than
one, they can use the lack of a for clause as an indicator that there was
another recipient. And if they are the local user listed in the headers that's
close to a confirmation that a bcc operation was done. They can't tell who the
bcc recipient was but they can tell that there was one.
Mind you, I think this is enough of a concern compared with the value of having
for clause for debugging purposes that we ship with settings that insert a for
clause when there's only one recipient, but we do provide a way to turn it off
for sites that are sufficiently concerned about bcc exposures.
It's even possible for the presence of a legitimately generated for clause to
reveal a bcc recipient, but it's such an obscure and bizarre case that it isn't
worth worrying about. Here's how it would work: Suppose you have a setup where
a user agent creates an alias on the server that expands to a normal recipient
and to a bcc recipient, then sends the mail to the alias while listing on the
normal recipient in the headers it creates. But only only does this not make
sense from a practical perspective - why on earth would anyone do something so
bizarre - but it also has "layering violation" and "other nasty security
implications" written all over it.
If there is several envelope recipients on mail and
these are copied to "for" clause, possible BCC recipients
are disclosed. Avoiding of that requires that
envelope recipients are matched to addresses on header
section.
The problem I see with the matching approach, aside from the obious overhead,
is while you can assume that a successful match to, say, a To: field means it
is OK to expose that recipient address in a for clause, not finding any matches
doesn't mean the address has bcc semantics. So you end up presenting the subset
of the active recipient list that happen not to have been transformed by
forwarding/routing activites in ways that prevent matching. The result makes
for clause disppear in prcecisely the cases where it is most useful for
debugging purposes: When transformation of the recipient addresses by
forwarding/routing has led to a mismatch between what's in the header and
what's in the envelope.
At least judging from the DRUMS discussion, the problem with
Apparently-to is that it was supplied on precisely those
occasions on which the forward-pointing envelope address did not
match any of the forward-pointing header addresses, so, almost
by definition, it was a disclosure problem.
john
Apparently-To: was generated when mail was no address headers.
Right, which never made some to me in that it didn't actually correct the
syntax error of not having at least one recipient field. (Yes, I know this is
no longer an error in 2822, but it was with 822.)
Ned