If the encryption cert for a bcc address was included, the bcc identity could be inferred from the emails in the cert.
My understanding is: - the smtp sending code opens only a single connection to the server, regardless how many recipients - the smtp server cares for delivering to everyone, and removes the bcc line before sending. If we wanted to support this feature perfectly, we had to prepare and send out different enveloped message in multiple steps, right? If yes, does it make sense to start small, and just warn the user when trying to combine bcc with s/mime, or just forbid this combination at all?
I think that not including the encryption certificate for any of the bcc address is the right thing to do. The rational for including all the encryption certs, is to allow all recipients to do a "reply all" on the received message and have all the certs in the original message to complete the task (as long as the ca chain is trusted.) Not including the encryption cert for any of the bcc address doesn't in anyway prevent any of the recipients, not even the bcc recipients (who presumably have their own cert) to reply to all (the set of non-bcc recipient). There is no need for a warning. The only trick part is that we need to be able to identify email addresses that are only on a bcc line. Scott, is there any issue with that?
I just that the summary is different from what I imagined it would say. Note that for real privacy, leaving out the encryption certs is not enough. An smime message is encrypted with a symmetric message encryption key. That message encryption is encrypted for each recipient. For each recipient, be it a BCC, CC or TO recipient, there is a separate entry. In order for BCC recipients being able to read the message, there must be such an entry for them contained in the message. However, the existence of those entries gives a hint to the real recipients of the message. I think we should do all or nothing. If we decide we really want to hide the information about BCC completely, we need to be complete and remove the "encrypted decryption keys for each BCC recipient" from the message. But that in effect means, different versions of the smime message needs to be sent out. And to make things even more complicated, if multiple people are on BCC, no single BCC recipient must be able to find out who else was on the BCC list. In fact that means, if the number of BCC is "nbcc", we need to produce "nbcc+1" different versions of the smime message, and send out each one with a separate SMTP transaction.
>The only trick part is that we need to be able to identify email addresses that >are only on a bcc line. Scott, is there any issue with that? That should be easy for us to figure out. In nsMsgComposeSecure::BeginCryptoEncapsulation we pass in a nsIMsgCompFields object which has methods for accessing the bcc recipients.
S/MIME bugs are automatically nsbeta1 candidates. (this is a bulk update - there may be some adjustment of the list).
I think this is an important S/MIME issue. I agree with Kai's comment #4, and I think we should implement the approach of sending nbcc + 1 S/MIME messages.
Bug 119545 also has a requirement to send out multiple different S/Mime messages for different recipients.
I'm changing the topic of this bug. I'm changing the proposed solution. In order to make an encrypted message readable for recipients on the BCC list, their keys must be included inside the message header. This can make it obvious that additional recipients were involved. A TO/CC recipient might be able to derive who the BCC recipients are. Bug 119545 cites rfc2633, which requires that multiple separate emails must be send, when BCC is instended. In my opinion, we should help the user to clear this confusion, and for the sake of simplicity, we should require users to do it on their own. In other words, my new proposal is: Whenever a user has at least one BCC recipient, and at the same time the "encrypt message" feature is in use, and the user attempts the message, then: - don't send the message - explain to the user that this combination does not make sense - ask the user to either - remove BCC - change BCC into CC - don't encrypt If we wanted to be really smart (but this requires more work, and should therefore be postponed to a separate bug), then we could offer a fourth option: - remove BCC, then forward a copy of the message to the BCC people In other words, this 4th option would: - remove the BCC people - send the message (to everyone except BCC) - copy to sent folder (if configured in options) - open a new message window, which is intended to forward the original message - for each formerly removed BCC recipient, add a TO recipient to this message - keep the new message open The user could then inspect the message, if desired add additional information (e.g. "For your information, I just sent this message, see the attachment"), and can hit "send" on their own.
The user intends to send the message, encrypted, to all the people in To, CC, BCC, in such a way that nobody knows who in the BCC list received the message. Assuming that we have certificates for all the recipients, this is totally possible and we should just do what the user intends. We should only prompt the user to do something different when there is no way to satisfy his expectations (e.g. we are missing at least one encryption certificate.) IIRC, Outlook does this correctly, at least when used with Exchange. In fact, the unencrypted case has exactly the same issue, because some servers are reported to not strip the BCC header. In other words, the "nbcc+1" solution should be done whenever BCC is used, regardless of whether encryption is present.