Alessandro Vesely wrote: > I wonder why the idea of binding messages' signatures to their > destination domains hasn't been considered before. As Ian pointed > out, this would limit replay attacks to a single destination domain.
One suggestion a few years back when I was doing DSAP was a "target" expectation scenario that might play a role under a SSRA (Special Signer/Receiver Arrangement) where the DKIM signer has a way to confirm the target address receiver is DKIM ready. Related, I am considering of add subscriber page information regarding ADSP and DKIM. But without a doubt, with the next 24 hours or so, our List Server will be ADSP ready and will preempt any subscriber with a ADSP domain at the subscriber page and during a submission to the list. It will explore an ADSP extension tag called ASL "Allowable Signer List" with the verifier already supports. For example, for the ISDG.NET the ADSP record is: dkim=all; asl=googlegroups.com,mipassoc.org; > A different, though possibly related, idea is to use sequence numbers > of some sort. For example, coupled with monotonically increasing > "Message-Id"s, signatures can identify message streams consistently. > This would require stateful verifications, though. I seem to recall a small discussion regarding recording the b= hash or the entire DKIM-Signature for tracking/tracking and/or for dupe checking. But many already do this with message-id and if you binding the message-id, then that serves the same purpose. Honestly, all is these ideas are great - but it means nothing is we don't have a consistent following in verifiers - just imagine we don't have a sender policy that says "all mail is signed by anyone." This would raise the bar to eliminate legacy domain spoofers/phishers that don't sign or are totally ignorant of DKIM. Once a signature is valid, 1st or 3rd party, we always ends up back to a reputation or trust layer. But we need to deal with the faults first. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html