John Levine:
I think I'm not the only one making assumptions here.
Of course not.
I'm honestly trying to figure out whether any mail systems treat mail
from sub.foo.com as being from foo.com when they make decisions about
sorting, filtering, and so forth. That's why I'd really appreciate
some actual examples if there are any. I'm not trying to be
confrontational here, I'm trying to gather data.
As far as I can tell, nobody does, but the whole issue of the tree
walk is predicated on this assumption. If the assumption is indeed
untrue, the treewalk (in any of its varieties) serves no purpose and
we can just get rid of it.
We're trying to solve two different problems at the same time.
Question 1: What do real DNS deployments look like? Seems no-one
can answer that here. Everyone is concerned that ADSP introduces
unnecessary barriers for deployment, but discussions about
random real or fictitious pain symptoms are not the best way
to define a solution.
This is an argument to avoid ugly ad-hoc hacks like the two-level
DNS dance, because they lack a sound foundation.
Question 2: What would the "bad guys" do to side-step DKIM/ADSP,
for some particular set of ADSP implementation details? I can
answer that with confidence. They will do everything that gets
their email through the filters. Unlike ADSP implementors,
spammers are not bound by the rules of the RFC. Our lack of
imagination should not give us a false sense of security.
This is an argument to have some "safety net" mechanism like
the ugly two-level dance that automagically covers all nodes
at the same DNS level; nailing non-existent domains at lower
DNS levels is already trivial without ADSP.
As fas a I'm concerned someone can toss the coin and be done with
it. I'd rather have something that mostly works now, than something
that will be perfect for one microsecond. No system can be perfect
permanently with respect to constantly changing threats.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html