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. > > -Wei > 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. -Wei > > >> >> > Sender Example:: >> > header: >> > >> > To: user....@example.com >> > Cc: user....@example.com >> > DKIM2-Signature: h=to:cc >> >> >> To: user....@example.com, user....@example.org >> Cc: user....@example.com >> DKIM2-Signature: rt=user....@example.com:user....@example.com >> >> >> Now SMTP in the transaction with example.com's MX stays the same: >> >> >> > SMTP >> > >> > RCPT TO: user....@example.com <mailto:user....@example.com> >> > RCPT TO: user....@example.com <mailto:user....@example.com> >> >> >> That assumes the MTA is DKIM2-aware. If you don't have that, you're >> better off >> splitting all messages to single recipient. >> >> >> Best >> Ale >> -- >> >> >> >> >> >> >> _______________________________________________ >> Ietf-dkim mailing list -- ietf-dkim@ietf.org >> To unsubscribe send an email to ietf-dkim-le...@ietf.org >> >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
