aiosmptd is treating Bcc as a TO field

[TBAIKamine]

Bcc are supposed to be hidden ! but aiomptd is showing them in the "To" field.
no problem with normal CC.
I sent using php version 8. Cc fields and Bcc fiels in headers.
I have th elatest aiosmpt using python 3.10

[pepoluan]

aiosmtpd shouldn't be able to modify the email body.

The "To:" field is part of the email body.

[waynew]

I'll double check the RFCs but IIRC BCC should be up to the implementation. My implementation splits the BCC out and delivers individual messages - you would simply need to implement your own handler(s)

[waynew]

Well, RFC 822 says:

This field contains the identity of additional recipients of
the message. The contents of this field are not included in
copies of the message sent to the primary and secondary reci-
pients. Some systems may choose to include the text of the
"Bcc" field only in the author(s)'s copy, while others may
also include it in the text sent to all those indicated in the
"Bcc" list.

While 1123 says:

The SMTP envelope is constructed at the originating site, typically by the User Agent when the message is first queued for the Sender-SMTP program. The envelope addresses may be derived from information in the message header, supplied by the user interface (e.g., to implement a bcc: request), or derived from local configuration information (e.g., expansion of a mailing list). The SMTP envelope cannot in general be re-derived from the header at a later stage in message delivery, so the envelope is transmitted separately from the message itself using the MAIL and RCPT commands of SMTP.

And 5321 says:

Addresses that do not appear in the message header section may appear in the RCPT commands to an SMTP server for a number of reasons. The two most common involve the use of a mailing address as a "list exploder" (a single address that resolves into multiple addresses) and the appearance of "blind copies". Especially when more than one RCPT command is present, and in order to avoid defeating some of the purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the header section, either as part of trace header fields or as informational or private- extension header fields. Since this rule is often violated in practice, and cannot be enforced, sending SMTP systems that are aware of "bcc" use MAY find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command.

I didn't spend enough time with the RFCs to say for sure that we shouldn't implement this behavior, but I also don't see any RFC saying that we MUST. In fact, it even shows that the rule can't necessarily be enforced and it's up to sending systems to be aware of the BCC fields 🤔 .

EDIT: https://stackoverflow.com/a/2750359/344286 also suggests:

46

The BCC addresses are not stripped off at the destination email server. That's not how it works.

[waynew]

Okay, yep, I just spent a while more reading RFCs. I do NOT think that this is a bug in aiosmtpd - in fact I think it's considered generally accepted behavior. In other words:

MAIL FROM: foo@example.com
RCPT TO: person@example.net
RCPT TO: bob@example.com
DATA
From: foo@example.com
To: bob@example.com
Bcc: person@example.net
Date: Thu, 12 Oct 2023 21:35:34 -0500
Subject: Reply to issue #382

This is *not* a bug, but expected behavior that person@example.net would, in fact, 
receive the full message, with 'To' and all. As would bob@example.com

.

It is not a requirement that aiosmtpd does anything for this scenario, aside from deliver the message to both recipients (assuming they're both valid).

And they would both get the contents of the DATA command in all its glory - bob knowing that person received the mail and vice versa. OTOH,

RCPT TO: person@example.net
RCPT TO: bob@example.com
DATA
From: foo@example.com
To: bob@example.com
Date: Thu, 12 Oct 2023 21:35:34 -0500
Subject: Reply to issue #382

In this case, bob MUST NOT know that the mail was delivered to person@example.com -- at least with our default implementation.

All of that being said - I'm fine with accepting a feature request where we allow something like strip_bcc_headers as an argument that gets provided to a handler... though I'd actually just prefer to add a recipe to our cookbook/examples for how to add this to your own handler implementation.

[pepoluan]

AFAIK an email relay should refrain from doing edits to the mail body (everything between DATA and <CRLF>.<CRLF>)

See RFC2821 § 3.7:

As discussed in section 2.4.1, a relay SMTP has no need to inspect or act upon the headers or body of the message data and MUST NOT do so except to add its own "Received:" header (section 4.4) and, optionally, to attempt to detect looping in the mail system (see section 6.2).

It should be the email client's responsibility to strip out Bcc from the mail body, but keeping RCPT TO: to the bcc recipients.

Enabling mail body processing will cause problems if the email is signed.