-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <746bd827-77d0-4991-ba67-507d84566...@mtcc.com>, Michael Thomas <m...@mtcc.com> writes >
>>>> simplicity ... at the point at which an email is being signed it is not >>>> possible to know how many recipients the receiving MTA will accept after >>>> each MAIL FROM >>> Why is that "simple"? >> because if you don't know which recipients will be grouped together you >> cannot construct the rt= part of the DKIM2 header field. It also avoids >> the MTA having to assess which recipients are only bcc'd > >I dunno, if the To: header is all to the same domain, say, and they match the >rcpt-to like with an email conversation, you know that it's safe to group >them. when you get to SMTP time you may find that you are sending multiple emails (because of limitations on RCPT TO counts) and those emails may not go to the same server ... so how is the recipient going to do any sensible assessment of whether a replay has occurred ? >Another point is that these proposed mf= and rt= could potentially be useful >for >other uses. We never considered such a thing back then, but if we're going to >go >there we should also make explicit whether the sender wants the receiver to >enforce anti-replay behavior rather than implicitly through the presence of >some >other tags. the bad guys do not want to enforce anti-replay and they are the people who construct the emails that get replayed. Not wishing to have replay is something that a receiver wants not a sender. >>> If an MTA wants to sign, why should it care how >>> many rcpt-to's it sends? >> because the receiving MTA is on the lookout for unexpected copies of the >> email and will reject them as being part of a replay attack > >Except they aren't "unexpected" in the general case. as I pointed out a while back the "general case" today is one recipient per email. >>> It intend each of the recipients, after all. I >>> don't get what the supposed security property is of limiting it to a >>> single rcpt-to. Is there one? >> yes > >Sorry this is not helpful at all. Being dismissive is not a good way to get >consensus at IETF. sorry ... I should have said "yes, see above" - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBZ9nJy2HfC/FfW545EQJieQCglKwa1NWVgagD/B9Of9iS0OM7/YoAn2T1 BplyGyNCRmdGMdnXZv138oMK =ZuFl -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
