Murray S. Kucherawy wrote in
<CAL0qLwatb6-egZ8+-LxE=4wc5q1xfr3xRwAjV=95vhgzwgx...@mail.gmail.com>:
|On Wed, Aug 9, 2023 at 2:54 AM Laura Atkins <[email protected]> \
|wrote:
|> If there are multiple BCCs that implies that whatever is creating \
|> the mail
|> must make individual copies of the message with only the BCC recipient in
|> that line before it’s signed with DKIM. So for a message with 3 BCCs, \
|> there
|> are 4 separate copies of the message to be created, one with no BCC \
|> header
|> and 3 for each of the BCC recipients. Then each message must be
|> individually signed.
|>
|> I’m not sure how that’s going to work in practice.
|
|I have heard, but have not verified, that some MLMs do this
|one-recipient-per-copy thing already, despite RFC 5321 encouraging the
|opposite. If true, I don't know whether this was done to allow
|per-instance signing or because it allows for better tracking and
|association of bounces, or for some other reason. It occurs to me that
|unless the Date field changes for each instance, the DKIM signature would
|be the same for each instance anyway.
All these problems are long known to (and "solved" by) the OpenPGP
(and S/MIME) communities, no?
In OpenPGP you can either encrypt-to a single or many recipients.
(With at least GnuPG you can also "hide" those recipients:
‐‐hidden‐recipient name
‐R Encrypt for user ID name, but hide the key ID of this user’s
key. This option helps to hide the receiver of the message and
is a limited countermeasure against traffic analysis. If this
option or ‐‐recipient is not specified, GnuPG asks for the user
ID unless ‐‐default‐recipient is given.
). (Also GnuPG just recently introduced a "company-super-key" like
thing, as it seems many work groups etc. need to encrypt to each
member, and then the communication must be archived, with the
possibility to decrypt years later. But, eh, only for
completeness.)
The MUA i maintain (which yet can only S/MIME), and however,
encrypts messages per-recipient only (and yet). Ie, specific
encryption per recipient.
But this is, of course, only a tiny spot of the internet, nothing
like Google and myriads of messages that fly by and need to be
(verified and) DKIM signed.
Isn't this discussion about Bcc: off-topic and solely RFC 5322?
I have never seen a MUA implementation which does anything else
but "throwing recipients into" To:/Cc:/Bcc:. And then there is
"undisclosed-recipients", where anything is consciously not part
of IMF/5322, but only in SMTP/5321, but still per-recipient DKIM
should work out, then.
I mean, the same people who as of today cannot see their address
in any of To:/Cc: continue to do so, but still have received their
personalized DKIM signature?
It seems to me that adding a per-recipient DKIM "sub-signature"
can be accomplished very cheaply, and "scales to
super-parallelism".
The fully prepared, DKIM-signed message is constant data, and then
a single per-recipient header line is prepended into the output
flow, but which' presence has been flagged in the normal DKIM
signature of the message.
'Could be that this is as easy as having a "struct iovec" with
a vector slot reserved for this per-recipient line, that is then
passed through to the POSIX/Linux writev(2) system call.
Of course, if i send to a dozen receivers with @gmail.com
addresses, as of today the MTA can bundle these in a single RFC
5321 SMTP "transaction", and use multiple "RCPT TO:<>" when
contacting @gmail.com. With per-recipient DKIM on SMTP level it
would have to sent the same message multiple times, one
"transaction" per "RCPT TO:<>". With RFC 2920 SMTP pipelining.
I mean it would be possible to add an ESMTP DKIM= extension, so
that this could then be reduced again to one transaction with
"RCPT TO:<> DKIM=SIG" SMTP commands, resulting in a single
transmission of messages over the network, incurring the I/O cost
on the receiver's MTA only, which then could locally act like
written when feeding filters, milters, etc.
Other than that, and thinking about it, and since DKIM applies
only to the MTAs, it could be a per-recipient-domain signature
instead of a per-recipient signature. Then a message that is to
be sent to multiple recipients at @gmail.com would get only
a single [email protected] DKIM signature, and that would be it.
|However, if it is already the case that MLMs generally produce a copy per
|recipient, then any Bcc scheme would work, and much of the fragility with
|the "include the recipient in the signature" approach vanishes.
|
|-MSK, participating
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
