Mailkit: BCC is always removed

Created on 16 Jun 2016  路  22Comments  路  Source: jstedfast/MailKit

In general, when I send an email using BCC, the BCC recipient receives can see his name in BCC field, for example with Gmail:

2016-06-16_084605

But, MailKit SMTP always removes it as you can see in SmtpClient.Send()

2016-06-16_085515

Is this behavior expected? is there an elegant solution to make MailKit work as Gmail does?

question

All 22 comments

This is expected behavior. If MailKit did not remove the Bcc header, then everyone would be able to see the blind-carbon-copy recipients. (It's blind because users aren't supposed to see it)

But, when destination (RCPT TO) is the same than BCC header, it should be not removed, at least Gmail does not remove it as you can see in my screenshot.

In any case, I need override this behavior. I am really interested in know your opinion, as MailKit developer and maintainer, about how should it be implemented, for example, do you think that it is a good idea to clone SmtpClient class and related internal dependencies? or maybe is there a better alternative?

If you are only going to send to 1 person, why not use the To header instead?

If you want them to always be visible, why not use the Cc header?

I understand, but others (for example Gmail) do not think the same.

Imagine that I want to send the email to A and a hidden copy to B.

Of course A should not receive BCC header, but B should. Suppose that _B person_ stores emails from different sources in the same _folder_, it is useful to know what was the hidden destination.

How do you suppose your example will work? Would you remove the Bcc header or not?

Remember: The SMTP server will push the email that you upload to it raw, all it will do is add a Received header at the top. It won't change anything else.

You do not get to dictate how each recipient sees their message. They see the same exact message.

If you think that not hiding the Bcc header will make your scenario work as you expect, you are wrong.

Instead, what will happen is that _both_ users will see the Bcc header.

I think that the way to do it is open two different SMTP connections: one for A and anther for B. In the first one, do not include _BCC header_, but include it in the second one.

To do this I will need create a custom implementation copying your SmtpClient class and _internal_ dependencies, I do not like to do it very much.

I understand that you are not interested in implement this behavior in MailKit, but I will attach some images to be clear about what is the behavior that I want to reproduce:

Sent Message:

sentmessage

Message received by A:

messagereceivedbya

Message received by B:

messagereceivedbyb

Message received by C:

messagereceivedbyc

And last, but not least, I want to thank you for the great work you're doing with MimeKit and MailKit and also by your quick and kindly responses.

It would probably be easier to just use a single SmtpClient, but send 2 copies of the message (you can send multiple messages per connection, no need to dispose and re-connect it).

Thanks!

Ok I'll share my scenario:

All the emails in the system are saved in the database instead of being directly sent. Then an independent service checks db for emails periodically and tries to send them.
I want to be able to track cc and bcc e-mails as well (not track but make sure they've been sent).
In order to do that i use the MailTransport.SendAsync that takes IEnumerable recipients. This will prevent the lib to send mails to cc and bcc on its own, it will send only to whoever is in recipients collection. Now I just create separate emails for all cc and bcc. Here come the hard part - i need exactly what is described in the original post here. For CC it's easy. But since you hide the BCC header for some strange reason... i can't do that. Just add a boolean that can turn this off. It's not like we're asking some impossible feat of programming.

BCC headers are always supposed to be removed. All mail clients do that. If you are going to leave them in, then they belong in the CC header, not the BCC header.

BCC is Blind-Carbon-Copy which means it will be removed so that the recipients cannot see who is in that list.

I'll try to explain this as simply as possible. Not sure if I am a moron or you're stuck in a one way street.

I wanna send email to Alpha with BCC to Beta and Gamma.
Alpha receives an email with NO bcc header.
Beta receives an email with BCC header containing ONLY their name (beta).
Gamma receives an email with BCC header containing ONLY their name (gamma).

If you will say that BCC header should ALWAYS be deleted again - please point me to a reference from the appropriate RFC standard.

Oh, you are going to take a message like this:

From [email protected]
To: [email protected]
Bcc: [email protected], [email protected]

And send the following 3 messages:

This one will be sent only to [email protected]:

From [email protected]
To: [email protected]

This one will be sent only to [email protected]:

From [email protected]
To: [email protected]
Bcc: [email protected]

This one will be sent only to [email protected]:

From [email protected]
To: [email protected]
Bcc: [email protected]

How exactly do I track the CC/BCC in this case? How can I be sure cc and bcc have been sent? You can read my first comment again.

I don't understand what you are asking. The SMTP server accepts a raw message and delivers it, unmodified, other than adding tracking headers (such as Received). It doesn't do any magic with the BCC header(s).

This is why I said you have to send multiple messages, each crafted slightly differently, so that no one sees any address in the BCC header unless it is their own.

I'm doing exactly that. I send a different message for everyone in CC and BCC exactly as described. But you delete the BCC header internally! Literally, the whole thread here explains exactly that over and over again.

I will try to explain in detail tonight when I get home. Thanks for paying attention to this.

Hopefully this change doesn't break existing software...

Thank you so much!

@andresmoschini I tried to reproduce this behavior with gmail and was unable to. Maybe they have changed how this works?
@BojidarStanchev what you're saying makes sense, especially when you look at a received email and the To is for someone else it can look like the email was sent to the wrong place.

This issue is resolved. I tried it. All correct now.

Was this page helpful?
0 / 5 - 0 ratings