OK now I get it. What you are saying is that spammers might attack DKIM by
attaching nonsense signatures and that it would be useful to have a cheap way
of determining that this is the case.
I do not agree that this saves you signature verification cycles since your
attempt to pull the key record will fail first. But saving DNS lookups is
certainly likely to be a benefit.
The other advantage might well being allowing more accurate identification of
likely spambots.
This is a policy issue I would be happy to leave to a phase II but its not a
major implementation cost. All that is needed is a tag NO-DKIM. Since I don't
anticipate a need for policy to be more than fifteen pages I won't argue
strenuously against it.
-----Original Message-----
From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
Sent: Friday, March 02, 2007 1:00 PM
To: Hallam-Baker, Phillip
Cc: ietf-dkim
Subject: Re: Comment on RE: [ietf-dkim] 1365 yes/no
On Mar 2, 2007, at 9:02 AM, Hallam-Baker, Phillip wrote:
I don't see how 'never sends DKIM mail' is of any value
since there is
a precedence order here. The key record information takes priority
over the policy record.
So if I get mail with a valid signature I never bother to check for
the policy.
I'll wager dollars to doughnuts that when email acceptance is
based upon a DKIM signature, it will be done in conjunction
with some type of accreditation. This saves the expense of
checking signatures where validity simply does not matter.
For high profile companies that have opted to use web based
messaging, any DKIM signed email spoofing their domain
creates queries for some random key, and when that fails,
then for their policy record. Hector could be right about
which will come first, but components of a policy records can
be republished with accreditation to eliminate unnecessary
traffic generated by perhaps absorbent levels of fraud. A
message that appears to be signed when studied in the raw
might mislead enough recipients, where this tactic could
become common. Not all providers will ensure these messages
are blocked.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html