> On Aug 15, 2016, at 8:39 AM, Eliot Lear <[email protected]> wrote: > > Hi Steve, > > > > On 8/15/16 5:30 PM, Steve Atkins wrote: >>> On Aug 14, 2016, at 10:11 PM, Eliot Lear <[email protected]> wrote: >>> >>> >>> >>> On 8/14/16 6:46 AM, Steve Atkins wrote: >>>> If there were a protocol that said "if you receive mail signed by this >>>> domain / this key and the recipient isn't in the To: or Cc: field, >>>> block it", or some similar protocol that signed the envelope >>>> recipient, that would pretty much eliminate DKIM replay as a threat in >>>> some cases. >>> That would be a DKIM flag, right? >> Yes, part of the DKIM-Signature header, probably (though that's not a >> requirement, just one obvious implementation). > > Ok. >> >>> And you don't want to block- you just >>> want the signature treated as invalid. >> That's one option, and likely the more useful one. > > Ok. Then the next question is if we do such an option would it help > fastmail.fm, especially in conjunction with ARC?
Only if a significant fraction of mailboxes implemented it. Or, more accurately, if a significant fraction of mailboxes that do per-domain reputation tracking based on d= of DKIM signed mail. If it were to simply invalidate the DKIM signature then the effect it would have on forwarding would be minimal in the simple cases. Interaction with ill-advised DMARC records could be more problematic - I don't think the problems would be too serious, but it'd take a bit more thought about how it could affect some typical delivery paths. Whether those risks - and the significant deployment effort - are justified as a response to DKIM replay attacks is much less clear. Having 1e-8 of traffic define your protocol is seldom a good idea. Cheers, Steve _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
