Potential exposure of "Bcc:" list
John H Meyers
in the absence of a "To:" header in a message,
will create a "To:" header for you,
inserting all recipients given by "RCPT TO" commands (of the SMTP protocol),
which could thus expose one's entire "Bcc:" list,
via that list being converted to an explicit "To:" header.
Although this potential for "private" address exposure,
whenever a "To:" list is optional in an email client (MUA),
may be said to be a fault of SMTP servers,
and is recommended against by RFC2821 section 7.2 "Blind" Copies
(only via "should not," rather than "must not"),
a number of email clients counter this possibility
by generating a "To:" header of their own,
whenever none is supplied by the sender,
often of a perfectly legal form such as:
To: "Recipient list suppressed":;
Opera (9.27/8841/Win32), however, not only doesn't generate such a header,
but even if I manually type such a header myself,
refuses to include it in my outgoing message!
It thus appears impossible for anyone to take this "standard precaution,"
even if they are fully aware of the issue and attempt to rectify it
by trying to create their own "To:" header like that above.
--
Tim Altman
[<jhme...@nomail.invalid> wrote:
>SMTP servers reportedly exist which,
>in the absence of a "To:" header in a message,
>will create a "To:" header for you,
Do you have more information about this?
--
Tim Altman
Desktop QA
Opera Software
Remove NO SPAM from e-mail address to reply
John H Meyers
> SMTP servers reportedly exist which,
> in the absence of a "To:" header in a message,
> will create a "To:" header for you,
On Tue, 22 Apr 2008 16:06:21 -0500, Tim Altman wrote:
> Do you have more information about this?
I don't know specifically whose servers may be doing this,
and don't recall seeing it, but note
http://www.ietf.org/rfc/rfc2821.txt section 7.2:
7.2 "Blind" Copies
Addresses that do not appear in the message headers may appear in the
RCPT commands to an SMTP server for a number of reasons. The two
most common involve... and the appearance of "blind copies".
Especially when more than one RCPT command is present,
and in order to avoid defeating some of the purpose of these mechanisms,
SMTP clients and servers SHOULD NOT
copy the full set of RCPT command arguments into the headers.
...
Since this rule is often violated in practice, and cannot be enforced,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sending SMTP systems that are aware of "bcc" use MAY find it helpful
to send each blind copy as a separate message transaction
containing only a single RCPT command [as is reiterated in RFC2822]
...
There is no inherent relationship between either...
or "forward" (RCPT) addresses in the SMTP transaction ("envelope")
and the addresses in the headers. Receiving systems
SHOULD NOT attempt to deduce such relationships
and use them to alter the headers of the message for delivery.
The popular "Apparently-to" header is a violation of this principle
as well as a common source of unintended information disclosure
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and SHOULD NOT be used. [note that "should not" is not imperative,
per http://www.ietf.org/rfc/rfc2119.txt ]
Suggestions that this may actually happen:
'if there is no To: or Cc: or Lcc: address in the message,
Pine will automatically generate and place in the To: field
a pseudo-address of "Undisclosed recipients:;"
or whatever string has been specified in the "empty-header-message" variable.
...
The reason for this is to avoid embarrassment caused by
some Internet mail transfer software that interprets a "missing"
To: header as an error and replaces it with an Apparently-to: header
that may contain the addresses you entered on the Bcc: line'
http://www.helpdesk.umd.edu/topics/applications/email/pine/385/
Other references to potential similar "leaks":
http://lists.virus.org/bugtraq-0204/msg00316.html
http://www.perlmonks.org/index.pl?node_id=360464
http://www.perlmonks.org/index.pl?node_id=360985
http://support.microsoft.com/kb/821260
http://support.microsoft.com/kb/895588
Besides the above, however, it is also reported
(e.g. on http://www.outlook-tips.net/archives/2007/20070308.htm )
as well as in our own experience, that
"While you can send BCC messages without the To field filled in,
these messages are more likely to be flagged as spam."
This is yet another reason why one wants to be able to create
a "To:" header, even if it contains no actual email address
(nor even a "fake" address, which would get replied to by a "reply all,"
as well as potentially generating message refusal or bounces).
The common (and legal) forms:
To: "Undisclosed Recipients":;
To: "Recipient list suppressed":;
Etc.
are one style that is normally allowed (or even generated)
by other email clients
[To: (any comments) is another legal form]
but I have not been able to persuade Opera
to include a "To" header without an address,
because it ignores all the above legal forms,
even when _manually_ inserted, even though they are valid,
and are suggested as useful for more than one reason
(both to avoid rejection as spam and to avoid potential Bcc exposure).
One might say that as long as one must include a "From" header,
the message might as well be "To" the same address, but this is
also undesirable, in part because replies to the "From" address
may be re-directed via a "Reply-to" header, while "reply all"
can not avoid replying to the "To" address, and also because recipients
who see "To: someone_else" may well incorrectly pay less heed to the message,
and in our experience may even call us up and say "why did I receive
mail addressed to someone else" :)
---
Not directly related, but perhaps interesting:
Encryption to BCC recipients with S/MIME [to hide BCC list]
(US Patent Issued on November 6, 2007 to Microsoft Corporation)
http://www.patentstorm.us/patents/7293171-claims.html
--
Tim Altman
<jhme...@nomail.invalid> wrote:
>On Thu, 17 Apr 2008 01:01:51 -0500:
>
>> SMTP servers reportedly exist which,
>> in the absence of a "To:" header in a message,
>> will create a "To:" header for you,
>
>On Tue, 22 Apr 2008 16:06:21 -0500, Tim Altman wrote:
>
>> Do you have more information about this?
>
>I don't know specifically whose servers may be doing this,
>and don't recall seeing it, but note
>http://www.ietf.org/rfc/rfc2821.txt section 7.2:
Fair enough. Please file a bug report.