Re: [Proposal/Patch] Replacing libesmtp in Balsa

[Peter Bloomfield <PeterBloomfield bellsouth net>]

Pushed to master--many thanks!  Peter

On 02/07/2017 01:53:41 PM Tue, Albrecht Dreß wrote:
> 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.