no, it "just" means that the MTA has to transmit multiple copies of
the same message to the same SMTP server, differing only in their
signature and bcc header field.
My understanding is that BCC should not be seen in SMTP transmission,
except first hop when SMTP is used in place of SUBMIT.
The Bcc header field serves two purposes:
1. To communicate to Bcc recipients why they received the message (i.e.
"you received this message because the sender bcc'ed you")
2. In some systems that use RFC[2]822 as a mail submission protocol, to
indicate which recipients should receive blind copies of the message.
In those systems, the bcc field is removed from the copies of messages
sent to non-Bcc recipients. It may be retained in the copies of
messages sent to Bcc recipients. Exact behavior varies from one
implementation to another - some delete the Bcc field, others keep it,
others generate a separate copy of the message for each recipient with a
Bcc field for just that recipient.
This does NOT apply to submission using SMTP or SUBMISSION protocols.
My understanding is that automated signatures like DKIM are expected
to be added by MTA after the message has been submitted and therefore
BCC field would not be present in such a message (the address
previously in BCC would be one or only address in envelope RCPT TO).
Therefore I do not understand how can MTA possibly transmit multiple
copies "differing in their signature and BCC heaader field".
Let me put this a different way:
If DKIM were to be extended to allow it to sign envelope addresses, an
agent (whether MTA or MUA) that signs a message should not include any
envelope addresses in the signature that are not exposed in some
recipient field of the message header (to, cc, bcc, resent-to,
resent-cc, resent-bcc), unless that signed message is sent to only one
recipient. So any copies of the message that were sent to envelope
addresses not listed in a recipient field of the message header would
need to be sent separately to each such recipient, with a separate
signature that included only that recipient.
Keith
_______________________________________________
ietf-dkim mailing list
http://dkim.org