Re: [Proposal/Patch] Replacing libesmtp in Balsa

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

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.

Sect. 5. "Security Considerations", inter alia, notes that

[...] 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 

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]