deiva shanmugam wrote:
Hi,
Thanks Doug for the clarification.
So, eventhough the DKIM RFC explicitly doesn't mention the use of policy
record in the verification side, still we should query for the policy
record.
Thanks,
Deiva Shanmugam
I believe that is an implementation question who may be policy centric
and wishes to supports DKIM related policy concepts to help protect
domains, and today, with protection as defined in the recently IETF
published RFC 5617 (ADSP) standard.
I'm sure you will follow up on the new ADSP RFC, I wish to comment on
a few highlights:
The ADSP lookup key:
_adsp._domainkey.domain.example
where domain.example is the domain in the 5322.From: field.
ADSP has three policies:
dkim=unknown ---> equivalent to Domainkey policy o=~
dkim=all ---> equivalent to Domainkey policys o=-
dkim=discardable
discardable is the same as all but with an explicit author domain
authorization for receivers to discard/reject an invalid author domain
signature, including no signatures found. No 5321 Bounce Requirement
is required for failure to deliver after accepting a message - the
message is "discarded!"
Regarding DNS lookup overhead, as you noted in section 8.4, I believe
many of the DNS people here do believe and stated that there is little
concern with policy lookups as most systems already do many DNS
queries for many mail related, anti-spam reasons for anonymous
incoming domains. Today DNS clients and Server caching resolves many
of theses issues however it was recognized initial adoptions phases
could yield a higher degree of policy lookup failure. I personally
like to use SPF as an example, I don't think the system broke down
when SPF was first introduced and was growing, and I believe SPF does
have a higher processing overhead than a primitive DKIM policy record
lookup where there is no recursion overhead unless SPF.
Nonetheless, RFC 5016 (Policy Requirements), attempts to assist here
by providing a requirement for policy lookup in section 5.3 item 9:
9. SSP MUST NOT be required to be invoked if a valid
first party signature is found.
It probably helps a little in reducing 1st party signature policy
lookups. But IMV, it won't play a significant role in a world where
there is a high degree of fraudulent legacy messages with no
signatures, and as the roll out expands, a world with increased failed
1st and 3rd party fraudulent valid signatures. In such a case, it
could be that wasteful DKIM rehash processing (which does include 1
DNS lookup anyway) could out pace any concerns over DNS Policy lookups
which in a good bit of the transactions there would be no need for a
DKIM KEY lookup, just a DKIM policy lookup.
Anyway, ultimately, of course, we need to see how ADSP is adopted. I
am more optimistic than most here. IMV, ADSP will it limited offerings
is still useful to many, especially the millions of small to large
private domains who IMV want exclusivity in there transactions and
would like a first level of defense at a wider range of receivers
using discardable domain fraud protection.
---
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html