kodus / mail

Simple, modern library of services for sending UTF-8 e-mail
38 stars 5 forks source link

don't send a BCC header #10

Closed close2 closed 6 years ago

close2 commented 7 years ago

BCC headers schould not be added by a MUA.

The bcc addresses should only be used for RCPT TO:

Some MTAs strip those headers but many don't.

mindplay-dk commented 7 years ago

Sorry, but I don't know what you mean.

To my knowledge, the RCPT TO command does not distinguish between To, CC and BCC receivers - they're all just recipients in that sense.

I don't think an SMPT server cares if the receiver is in the To, CC or BCC list?

Can you be more specific about the problem and what it is you think that should be changed?

close2 commented 7 years ago

Hi,

sorry, I didn't have much time writing the issue.

I think that https://github.com/kodus/mail/blob/4684bdd2151e9898b60b4bfd7fcdbf078983c1af/src/MIMEWriter.php line 43 is incorrect.

HOWEVER I haven't tested your library!

I am working on my own mail/smtp library and we did send a bcc header as well.

If I am not mistaken a mail client should not add this header. BCC recipients should only ever be used during the SMTP RCPT TO commands. By adding the bccs as header as well those recipients may be seen by other recipients as well because not all / no MTAs remove this header.

Again: if somewhere in your library the bcc header is removed again, or if I am mistaken and BCC headers should be removed by MTAs this is if course not a bug.

(I did test this with our library and could see the BCCs, but I might have confused the different recipient addresses / mails.)

mindplay-dk commented 7 years ago

This answer seems to agree with you:

http://stackoverflow.com/a/2750359/283851

What I don't understand is, why is the Bcc header even part of the MIME mail specification, if you're never supposed to send it...?

mindplay-dk commented 7 years ago

Okay, RFC2822 confirms what you said:

´´´ The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains addresses of recipients of the message whose addresses are not to be revealed to other recipients of the message. 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.) ´´´

It sounds like the Bcc header is just meta-data, e.g. may be used locally by a client to keep track of Bcc recipients, but should not be sent by the client when it posts the message.

I guess I'm still not sure if we should use the first or second sending strategy, but the the first would be trivial - just remove the Bcc header. Let's start there.