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.
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.
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.
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!
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 :)
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.
blocking-, particularly given comment 5.
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