On Wed, Mar 19, 2025 at 1:30 AM Michael Thomas <m...@mtcc.com> wrote:
> On 3/5/25 9:14 PM, Murray S. Kucherawy wrote: > > On Wed, Mar 5, 2025 at 1:08 PM Michael Thomas <m...@mtcc.com> wrote: > >> I've been reading the draft mentioned in the charter re: replay and >> rcpt-to and don't understand why that changes anything wrt replay. If >> there is a message that a spammer has discovered passes a recipient's >> spam filter, what difference does it make if it's a single smtp >> transaction or multiple transactions? >> > > If it's a single recipient message, you can include the recipient in the > signed part of the message. > > You could if there were two -- or n for that matter. There may be > practical limits to including a big list of rcpt-to's it into the > DKIM-Signature, but that presupposes that it needs to be encoded in the > signature block which doesn't have to be the case if we don't want to. That > is, we could invent a new trace header called : > > Envelope-Information: mf=xxx; rt=yyy > > and just sign that header the usual way. > One of my long-ago drafts on this topic included the envelope as part of what gets fed to the hash, and thus signed, but never adds it to the signature or any other header field. That binds the signature to the envelope recipient without ever revealing it. I think it also provided that if there were many recipients, they should be sorted before being hashed. The downside of keeping it all in one signature is that somewhere down the line, some MTA might decide "these N recipients are going to MX-A, and these other M recipients are going to MX-B" and split the envelope, and if there's a single signature that has all of them, it's now been invalidated for all deliveries. There's no way for the signer to know for sure that that is [not] going to happen downstream, so the only thing that's sure to survive such action would be a 1:1 mapping between recipients and signatures (and, hence, transactions). -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
