532982 - mail composed with bcc: recipients only, and sent via "Send Later" or with mailnews.sendInBackground=true can disclose bcc: recipients

Status: RESOLVED INVALID

(MailNews Core :: Composition, defect)

Description

[Wayne Mery (:wsmwk)]

reference bug 510531 and bug 16499

mail composed with bcc: recipients only, and sent via "Send Later" or with mailnews.sendInBackground=true can disclose bcc: recipients if the ISP has issues described in bug 16499.  messagses sent via these mechanisms lack 
  To: undisclosed-recipients:;
implemented by bug 16499

I haven't checked whether this is a regression. It could be, or it might have always existed in the code path of Send Later.

setting blocking-tb31? because of suggestions of shipping bug 510531 in v3.1. Might even want to deliver in 3.0 because of privacy issues.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

This doesn't sound like a blocker to me, since it sounds like it's mostly a workaround for a sendmail bug in a version which seems unlikely to still be widely deployed.  If there's more subtlety here that I'm not understanding, feel free to renominate with a more detailed explanation.

Comment 2

[Wayne Mery (:wsmwk)]

dmose, http://en.wikipedia.org/wiki/Sendmail indicates sendmail is the leading mail agent and per Dan, our mail admin, "We are running the most recent free version (8.14.4), which is probably a bit newer than the release deployed with most linux versions since they usually have an older version."

Perhaps Dan.S can comment on whether there is an effective workaround/option in sendmail. If not, this will be a problem for us.
 
bug 510531 was probably a misleading/not a useful reference. And I no longer remember why I closed it INVALID rather than INCOMPLETE.  Was probably a judgment call.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

If this is still a problem in current versions of sendmail (I'm having a hard time figuring out whether that's true from comment 2), please renominate!

Comment 4

[Wayne Mery (:wsmwk)]

via wireshark... we found that thunderbird is sending the message without a Bcc: line. (and of course also without To: undisclosed-recipients:;)  And we found sendmail.cf has NoRecipientAction=add-to, which according to http://www.sendmail.org/m4/tweaking_config.html 
  "adds a To: header with all the known recipients (which may expose blind recipients)"

Indeed, the combination results in all addresses being exposed. Literally
 Bcc: <all addresses>
gets sent as
 To: <all addresses>

apparently we've had that setting for years. 
sendmail default is NoRecipientAction=none.

When Bcc: <addresses> is sent with the message data the problem does NOT happen with either NoRecipientAction setting because sendmail strips out all addresses given during the protocol setup, for addresses that are found in the Bcc list. The result is "Bcc:" in the message the recipient sees.

So ...
a) can we safely assume that only sendmail is impacted?  (do we totally trust bug 16499)
b) are there many older sendmail installations with "the bug"?  (if we believe bug 16499 circa 1999 that there was a real bug in sendmail)
c) should Thunderbird be totally omitting the recipients in the data it sends?  In other words, should Bcc: be sent in the data?
d) but perhaps more importantly, should send-in-background be allowed to behave differently from send-in-foreground in this way, or *any* way?

So in answer to comment 3 I don't have any answers except that sendmail is the leading patch, and with respect to "d", I think we would want to say "no" because we shouldn't have two code paths with different results. Which would mean either fix this bug, or remove the special casing done in send-in-foreground.

renominating blocking for decision :)

Comment 5

[Wayne Mery (:wsmwk)]

found good reference in http://www.sendmail.org/documentation the upshot of which is, we probably shouldn't need to worry about sendmail. But who knows for sure :)

-------- 8.8.7/8.8.7 1997/08/03 ------------------
In some cases, NoRecipientAction=add-bcc was being ignored, so the
    mail was passed on without any recipient header.  This could
    cause problems downstream.  Problem noted by Xander Jansen
    of SURFnet ExpertiseCentrum.

--------- 8.7/8.7   1995/09/16 ---------------------------------
Add NoRecipientAction option to handle the case where there is
    no legal recipient header in the message.  It can take
    on values:
      None      Leave the message as is.  The
          message will be passed on even
          though it is in technically
          illegal syntax.
      Add-To    Add a To: header with any
          recipients that it can find from
          the envelope.  This risks exposing
          Bcc: recipients.
      Add-Apparently-To Add an Apparently-To: header.  This
          has almost no redeeming social value,
          and is provided only for back
          compatibility.
      Add-To-Undisclosed  Add a header reading
          To: undisclosed-recipients:;
          which will have the effect of
          making the message legal without
          exposing Bcc: recipients.
      Add-Bcc   To add an empty Bcc: header.
          There is a chance that mailers down
          the line will delete this header,
          which could cause exposure of Bcc:
          recipients.
    The default is NoRecipientAction=None.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

blocking-, particularly given comment 5.

Comment 7

[Wayne Mery (:wsmwk)]

https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=anywordssubstr&emailcc1=1&emailreporter1=1&short_desc=bcc&field0-0-0=short_desc&resolution=---&resolution=INVALID&classification=Client%20Software&classification=Components&emailtype1=substring&query_format=advanced&short_desc_type=allwordssubstr&email1=vseerror%40Lehigh.edu&type0-0-0=nowords&value0-0-0=count%20counts&field1-0-0=short_desc&product=MailNews%20Core&product=Thunderbird does not show any new reports of this issue. So finalizing resolution as INVALID