On Fri, 2008-04-11 at 04:50 +0000, John Levine wrote:
that any reasonable "outsider" will look at a spec that doesn't allow
him to specify in one step (rather than hopefully-correctly attached to
every single zone entry now and through all future changes) "Acme Corp's
email is ALL signed, or it's not ours" and wonder what the spec authors
were thinking.
Huh? The DNS doesn't provide any way to do anything to an entire zone
other than AXFR.
You're confusing "commercial" concerns about [anti-]spoofing with
"engineering" concerns about what the DNS infrastructure can do.
The concern that I'm raising is about likely perceptions by people who
do _not_ have a detailled working knowledge of DNS and the
potentially-surprising consequences of its federated architecture. As it
stands, it looks absurd. I am not advocating making ADSP do something
that DNS cannot do, merely that an apparently astonishing oversight be
addressed. At this point, this probably amounts to a non-normative
paragraph making clear the rather limited cover/protection that ADSP
will, albeit with good cause, be able to provide.
The only way to cover an entire zone with ADSP is to create an ADSP
tree parallel to all of the names in the zone, i.e. for every
foo.bar.example.com put in a _adsp._domainkey.foo.bar.example.com. If
the existing tree has any wildcards, you can't do it.
I'll address this, but not because I'm advocating the alternatives,
merely because they're design choices that have apparently been
rejected:
- Another way to have ADSP to cover an entire hierachy is to allow a
policy specified at any level in the hierachy override policy specified
at any higher level. The [entirely sound] basis for rejecting this is
that it requires a tree-walk, albeit a limited one (O(n), but the
requirement is O(k)).
- Another way to have ADSP cover an entire hierachy is to use knowledge
about rarely-changing registrar practices to work out where in the tree
the highest "delegated to an organisation" node is and to query just
that node for ADSP. (See also the tables of such practices maintained by
web-browsers to limit the cross-domain propogation of cookies.) This
meets the O(k) requirement, causes the spec to do what non-engineers are
likely to expect of it ("if anyone sends email purporting to be from our
'domain' but which we didn't send, the receiver will be able to realise
that with certainty") but imports a requirement for implementors to use
a database of information about registrar practices which (a) adds
complexity, (b) adds a little fragility in that this may change without
notice and (c) may well exclude this sort of cover from some domains
entirely. (Actually, (c) is not so bad; it's akin to the impossibility
of getting SSL certs for domains under some ccTLDs because of registrar
behaviour/situation.)
The question that I haven't seen addressed directly is why it's so
important to provide ADSP for domains that don't exist. Doing a DNS
lookup to see if the domain in a putative sending address exists has
been a useful anti-spam trick for a long time, far predating DKIM.
Mail filters often do that even though they don't check DKIM and don't
check ADSP. So what's the point of importing it into ADSP?
ADSP's adoption as it stands will provide an incentive to locate A
records which, through administrator error, lack an associated ADSP
entry. This is not to say that a protocol should survive all
administrator errors, but introducing this sort of fragility is
unfortunate.
My strong preference would be to take out all of the tree walking and
existence checking, and replace it with a note pointing out that ADSP
only applies to domains that exist.
Quite. This works for RealMail (we see ADSP as a means to put teeth onto
whitelists), but I suspect that it will harm ADSP's adoption more
generally.
- Roland
--
Roland Turner | Product Manager, RealMail | BoxSentry Pte Ltd
3 Phillip Street, #13-03 Commerce Point, Singapore 048693
Mob: +65 96700022 | Skype: roland.turner | Fax. +65 65365463
roland(_dot_)turner(_at_)boxsentry(_dot_)com | www.boxsentry.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html