Wietse Venema wrote:
0 - No policy (status quo).
1 - All mail from this domain is signed (valid).
2 - Some mail from this domain is signed (equivalent to [0]).
3 - This domain sends no mail (effectively equivalent to [1]).
4 - No-one else can sign my mail (invalid, it attempts to control
recipient behavior where the recipient is, for example, a
mailing list, or a user at a DKIM-signing ISP who bounces an
email message to another site).
5 - Mail from this domain is never signed (inconsistent, it implies
that a valid signature is invalid; and invalid, as per [4]).
This analysis is correct (strictly speaking) given the current description
of how things work.
I think this is the source of confusion - you can check the certificate
without checking the policy (or perhaps, you're required to check
the certificate first). The EXISTENCE of a certificate is taken as
an implied policy that this particular message is supposed to be signed.
The more complicated arrangements some people are suggesting here will
only work if you know the policy before you look for a certificate.
Now I could argue that we should be doing it this way, but I'm
not going to do that right now.
Even in the context of the current specification, it's a simple matter
of optimization that implementations WILL be cacheing the policy lookups
for a short period of time. IF a receiver has a policy cached, and
IF we have the more complex policy descriptions, it may be possible in
some cases to bypass the certificate lookup and subsequent attempt
at verification, which can be a signicant savings, and one could argue
that it can prevent denial of service attacks from a bad actor.
So even without policy first in the spec, we will often have policy
available upon receipt of a message.
tom
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html