Al Iverson wrote:
I don't grasp the technical bits to provide a coherent explanation of
how to do what I want. But I have to say, without any sort of domain
blanket/coverage option, it seems like something is really missing
here. Without any sort of assumption or ability to limit what's
allowed under spamresource.com, I think ADSP is much less useful. My
concern is that if I can't restrict or cause failures automatically
outside of a specific subdomain or host, it does me little good to
sign on signed.spamresource.com when a phisher can fake
signed2.spamresource.com and not automatically be failed by checking
sites.
If I'm understanding the issues at hand. The thread is a bit difficult
to follow. I gather from some friendly offlist explanation that Jim
advocates a domain-wide signing policy that would go 1-2 sublevels
deep and no deeper. Jim, is that basically correct?
You have it right, but it's only one sublevel. In other words, if you
publish an ADSP record for example.com, it would apply to any names in
the immediate subdomain that don't have their own ADSP record (perhaps
ns.example.com, www.example.com, etc.), but no deeper than that (i.e.,
not foo.eng.example.com).
The application of records to an immediate subdomain can also be turned
off by the t=s flag in the ADSP record.
I'd love an
example or two of how this works with 1-2 level deep signed and
spoofed fqdns, and what happens with levels deeper (no opportunity for
DKIM? or ADSP?)
Of course, any domain name, no matter how deep in the hierarchy, can
sign with DKIM by publishing a key record in one of the appropriate
places. So xyz.marketing.example.com could publish a selector at, for
example, april2008._domainkey.xyz.marketing.example.com, and sign
messages using d=xyz.marketing.example.com. A parent domain could also
sign, for example using a key at brisbane._domainkey.example.com and
using d=example.com and
i=(_at_)xyz(_dot_)marketing(_dot_)example(_dot_)com(_dot_)
For ADSP, let's consider the following domain, example.net:
MX record pointing to mail.example.net and mail2.example.net
NS records pointing to ns.example.net and ns2.example.net
A records for mail, mail2, ns, ns2, www, gateway, and a DHCP pool
consisting of host1 through host100.
NS records for finance.example.net pointing to ns.example.net and
ns2.example.net
A records for larry.eng.example.net, curly.eng.example.net, and
moe.eng.example.net (published as A records in the same zone)
A records for a DHCP pool consisting of host1.finance.example.net
through host50.finance.example.net (published in a separate zone)
MX records for finance.example.net pointing to mail.example.net and
mail2.example.net
So, as currently specified in the latest ADSP draft (-ssp-03), an ADSP
record published at _asp._domainkey.example.net will provide coverage
for mail sent from the following domains: example.net,
mail.example.net, mail2.example.net, ns.example.net, ns2.example.net,
www.example.net, gateway.example.net, the hosts host1.example.net
through host100.example.net, and finance.example.net.
It does not provide coverage for the hosts host1.finance.example.net
through host50.finance.example.net. To get this coverage, one could add
an ADSP record at _asp._domainkey.finance.example.net.
It also does not provide coverage for the hosts larry.eng.example.net,
curly.eng.example.net, and moe.eng.example.net. To get this coverage,
one could add an ADSP record at _asp._domainkey.eng.example.net.
Of course, one could always publish individual ADSP records for the hosts.
Hope this makes things clearer.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html