Hi,
(This is my first post here. I've reviewes this subject in the archives
quite a bit, but not exhaustively. If I've missed something obvious,
please smack me down.)
The procedure I've seen outlined here for policy discovery is deeply
flawed. As I understand it, you look at the From domain, and
check it, if you find nothing you check the pointer, and if you
find nothing then there's no policy.
Here's the problem: foobar.com expects that all of it's
mail will come from foobar.com, and sets a policy at _dkim.foobar.com
that states that everything coming from there will be signed.
Some spammer forges mail from joe(_at_)subdomain(_dot_)foobar(_dot_)com, with
no DKIM
headers. The mail is sent somewhere that carefully checks all DKIM
signatures. The policy of subdomain.foobar.com is checked, and no
policy is found, therefore mail is sent through regular spam filters, and
accepted.
The real problem here is that conceptually, policy should always always
always come from the top. If the top-level policy wants to say that
sub-domains can set their own policy, that's fine, but it should be part
of the policy structure. If a top-level policy wants to say that
sub-domains can NOT set their own policy, DKIM should give them that
power - without dictating how freely they manage administration of
subdomain DNS.
To accomplish this, the policy should include information on overriding:
override-depth=0 (no overriding)
override-depth=1 (sub-domains only, not sub-sub-domains)
override-list=baz,cows,a.b.c (short list of subdomains that can override)
Note that for short lists, you can put in something like a.b.c, but you
don't have to. You could just put in "a", and then let a's overriding
policy include "b", and b could include "c", allowing for complex
overriding without massive exception lists. On the other hand, if
a.b.c can be fit into the policy at the top, then two levels of policy
checking can be skipped, and you can directly check the policy of
a.b.c.foobar.com.
So when you get mail from host.foobar.com, or even from
a.b.c.d.e.f.......z.foobar.com, you should check for a policy at
foobar.com.
If the policy says no overrides, then whatever policy you find, you're
done, and you don't have to look up any more. If there's no policy,
you assume a default of override-depth=1 (or at most 2), and walk down
one step. If no policy is found there, then you're done, and policy
is null.
The default depth prevents spammers from coming up with bogus, many-dotted
host names that would be slow to process. And it wouldn't be too onerous
because it gives managers lower down the tree two (or three) different
levels above that it can go to try to get an override policy put in place for
them to implement DKIM on their own.
Using this method, we get:
* Large organizations can set a firm policy that can not be overridden
thru negligence, malice, or mistakes, and that results in very fast
policy lookup.
* Large incompetent organizations have one or two levels of recourse below
the top for sub-managers to implement DKIM, where the top level has failed
to do so.
* Large competent organizations can also be highly flexible in managing
the policies of subdomains, trusting only those sub-domains worthy of
trust.
Even if a default override-depth of 2 were chosen, then there would be
at most three DNS lookups for domains with no policy, which is the same
as the current proposal.
tom
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html