On Wed, Mar 19, 2025, at 10:08, Murray S. Kucherawy wrote: > 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 other downside of this approach is that, if this data isn't retained in the message content somewhere, future hops are unable to validate the signature any more because they don't know all the inputs to the hash. So it breaks multi-hop. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
