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. Envelope splitting will never occur, which would invalidate such a signature. The advantage of such a signature is that you can detect if the message was intended to go to this recipient when it was signed, because if the recipient is mutated or replaced, such a signature will no longer validate. The disadvantage is that this goes against advice that's been in RFC 5321 for a long time, and probably its predecessors, which prefers envelope packing when lots of recipients can appear as part of a single transaction. > If the idea is that it is somehow bound to the original rcpt-to, that > breaks a significant amount of use cases in the email architecture > (forwarding) so I sure hope it's not that. The draft does sort of imply > that a Bcc'd address will end up in the signature block, which > completely defeats the purpose of Bcc which sounds like a really bad idea. > Yes, this would not survive forwarding. If by "signature block" you mean the equivalent of the DKIM-Signature header field, then yeah, that would be a privacy problem. But I think it's more like this new mechanism will silently include the envelope recipient in the hash that gets encrypted to yield the signature. That is, the Bcc isn't exposed, but you still fail if the envelope recipient changes. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
