Hi Peter: Am 06.02.17 01:53 schrieb(en) Peter Bloomfield:
Thank you so much for this effort! The documentation and unit tests are great--would that the rest of the code was as professional.
Thanks a lot, I'm glad you like it!
It builds with no hiccups and I already sent one test message--this one will be the second! I feel that we should push this to master and get everyone to test it.
That would be cool. My feeling is that there /will/ still be some new bugs buried in the code, and more testers are always helpful. BTW, I forgot to mention that due to shifting to the "new" security options, the default is now "smtp with starttls required". Maybe some people have to re-check it. Furthermore, clear text authentication (plain, login) over unencrypted connections is disabled. Also something which might need some review.
A long time ago there was some discussion about whether bcc recipients should get a bcc header, and there may be some comments on that on one of the RFCs. One suggestion was to include it when there is exactly one bcc-holder, but it had to be a second submission, as the non-bcc recipients should see a message with no bcc header. Stripping all bcc headers is far more straightforward, and also RFC-acceptable, I believe.
Ah, reading the RFC *before* making changes in the code sounds like a good idea... :-/ Actually, RFC 5322, sect. 3.6.3, says <quote> There are three ways in which the "Bcc:" field is used. In the first case, when a message containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is removed even though all of the recipients (including those specified in the "Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a separate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.) [...] Which method to use with "Bcc:" fields is implementation dependent, but refer to the "Security Considerations" section of this document for a discussion of each. </quote> Sect. 5. "Security Considerations", inter alia, notes that <quote> [...] if using the first method described in section 3.6.3, where the "Bcc:" line is removed from the message, blind recipients have no explicit indication that they have been sent a blind copy, except insofar as their address does not appear in the header section of a message. Because of this, one of the blind addressees could potentially send a reply to all of the shown recipients and accidentally reveal that the message went to the blind recipient. </quote> I.e. we fulfil the RFC requirements by using method #1. However, IMO it would be good if we would warn the user if the identity is not in the list of to: or cc: addresses, something like "Your identity is not in the list of To: and Cc: recipients, so you are likely a Bcc: recipient. Replying to the message may reveal your identity. Continue yes/no". However, as the /sending/ chooses the Bcc: method, we cannot rely on a Bcc: header being present anyway. Method #2 above, though, implies that /every/ Bcc: recipient must get a separate copy, and the receiving MUA still must check the identity. I.e. its no guarantee that the user does /not/ accidentally reply to it. My personal feeling is that everything but method #1 is somewhat over-engineered, as it does not really protect against errors. Cheers, Albrecht.
Attachment:
pgpnCoZ0KP2F3.pgp
Description: PGP signature