On 26/03/2025 09:18, Wei Chuang wrote:
On Tue, Mar 25, 2025 at 9:43 AM Wei Chuang <wei...@google.com> wrote:
On Tue, Mar 25, 2025 at 3:06 AM Alessandro Vesely <ves...@tana.it> wrote:
On Mon 24/Mar/2025 20:49:32 +0100 Wei Chuang wrote:
To support that use case and other scenarios where the recipient is not
explicitly declared in the RFC5322 message e.g. some mailing lists, the sender
can populate a DKIM2-Signature "rt=" tag. Note that "rt=" here still only
supports a single recipient.
Why such single recipient limitation?
In this strawman, the "rt=" single recipient construct is meant to support
Bcc and other privacy sensitive cases where it only makes sense to have a
single recipient. Declaring multiple recipients that are not privacy
sensitive is done through RFC5322 address headers. As you point out, it's
easy to extend it to also support multiple recipients. The advantage of
the approach you propose is that the signed recipient list is conveniently
in the DKIM2-Signature "rt=" and can better represent the recipients that
will be in the SMTP envelope. The advantage of the approach of using the
RFC5322 address headers is that they are already there without duplication
of the addresses.
Two other considerations.
First a way to view the pros and cons for single vs multiple recipients is
the implementation tradeoff. Single recipients will require additional
message splitting by recipients. Multiple recipients will require signing
and verifying envelope recipients in the message header somewhere, be it in
the "rt=" or in the RFC5322 address headers. Which of these is easier to
adopt by open source DKIM and SMTP packages? Might splitting all
recipients be a simple config already in those open source SMTP?
Second is a smaller worry about the effects of a long DKIM2-Signature
header. If the "rt=" lists all envelope recipients, what is the effect of
the maximum number of recipients possible e.g. Gmail supports
<https://support.google.com/a/answer/166852?hl=en> up to 2000 recipients.
I would imagine this reduces readability.
Looks good. It's very elegant because by making rt= optional, it
minimizes the surface differences with DKIM1.
However, I'd still allow multiple rt= recipients, in case forwarders
resend messages to multiple recipients at a time. AFAIK, most or all
mailing lists send single messages, otherwise they couldn't do VERP, but
I'm not sure it's a universal rule.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
