[#1398] Further thoughts

I was sufficiently intrigued (and frustrated) by this problem that I delved into the relevant sources (SecureMailHost, SMTPlib etc.) and went back to what the standards say about Bcc (revisiting days long ago when I used to 'do' email stuff). Semantically, Bcc headers are supposed to be removed before delivery, but it's not very clear how/where this should be done. RFC2821 draws a strict separation between envelope recipients and header recipients and requires that SMTP systems do not try and relate the two. But it also provides a recommended way of deducing envelope recipients from headers (if no envelope info is provided) which includes the deletion of the Bcc header. Unfortunately, secureSend doesn't implement this: it builds the message headers from the recipient lists provided, and th
 en builds the envelope recipients from the resulting headers, but does not then remove the Bcc header. This is a bug in secureSend. So if ZWiki mailout wants to guarantee that the Bcc field is suppressed (as it probably should), then it shouldn't use secureSend (until it's fixed). 

A simple workaround is to modify secureSend so that it deletes the Bcc header, but we don't really want to recommend messing with other people's libraries here, do we? But just in case you do want to do it, add "del msg['bcc']" after line 231 of SecureMailHost.py (actually this isn't really good enough, because the RFC says that if removing the Bcc leaves no recipient headers at all (To, Cc etc.), you should add back an empty Bcc header (but my python isn't up to this, yet ...)).

A remaining puzzle: why did anyone ever think secureSend worked with Bcc's? the only answer I can think of is that they tested it with mailhubs which removed the Bcc header further down the line (although I think they aren't supposed to do that, though RFC2822 is not very clear on this...)
--
forwarded from http://zwiki.org/1398BCcOnMailoutAgain#[email protected]