On Mar 19, 2007, at 7:58 PM, Andrew Sullivan wrote:
One thing that popped for me during your presentation today, Andrew,
is that you say that the stupid things people are doing with the
reverse zone have to work. This isn't true.
Yikes. If that's the way I put it, my apologies; it certainly isn't
true.
What I think _is_ true (and what I was meaning to say) is that some
people say that some uses of the reverse tree are useful for them. In
order for those uses to work, the reverse lookups have to work. Or,
to put this another way, for the reverse tree to be widely useful, it
has to be fairly widely implemented; and to the extent people stop
implementing reverse mappings, the reverse tree in general gradually
becomes less useful.
Interesting, I can see where the disconnect is happening. I see
what I said and what you said you meant (rather than what I said) as
the same thing. See, if it doesn't matter that the broken things
people are doing with the reverse tree work, then you can't say that
the reverse tree has to work for them to use their broken things,
because we don't want them to use their broken things. So whether
or not they need the reverse tree to work is irrelevant to us, the IETF.
The obvious case is disagreement on using reverse mapping as a
hint in
spam-candidate scoring. Some users report that, based on the analysis
of their own traffic, some sort of reverse mapping test is a useful
indicator. Others correctly point out that such a rule runs the risk
of false positives and also does not catch all spam.
This is perfectly reasonable, because what you are doing is catching
them in a lie. You don't know that the data in the reverse tree is
correct just because the forward tree agrees with it, but if they do
not agree, then you have detected a lie (or, to be charitable, a
mistake), and that is information - it would be wrong to say that it
is not. On the other hand, plenty of scoring systems that use the
reverse tree can't be described so charitably.
My (editorial) view on this is that, given there are uses where some
people who understand the limitations of the facility nevertheless
claim there is utility in their own case, in the absence either of
numbers to show that the wrong empirical conclusion has been drawn or
that the use case is implicitly broken, then such a use is not
obviously stupid.
Actually, there is one reason to consider it stupid: I might have
control over my forward tree, but not over the reverse tree for the
IP address I have. That doesn't mean I'm a spammer - it just means
I have a lousy ISP. And, sad to say, that's most ISPs. So in this
case, it is a broken configuration, for some value of broken, but
it's not my fault that it's broken, and I can't fix it, so it's not
really fair to score me as a liar. Fortunately, in a spam scoring
system, as long as you don't use this as your exclusive score, it's
probably okay - hopefully other indicators will tell you a different
story.
So, the intent of the text is precisely to say, on the one hand, that
someone who is trying to use reverse mappings needs to understand the
limitations of the implementations on the Internet; and on the other
hand, that network operators should implement the reverse mappings in
the absence of strong counter considerations, because the
implementation is needed for these various use-cases to work.
So how many of the examples you give are reasonable, in the sense of
detecting a lie or misconfiguration and using it in a scoring system,
and how many are unreasonable, like my ssh example? If the number
of the latter is not zero, that might explain the pushback you've
been seeing.
Does that clarify my remark?
It doesn't matter. What matters is whether your document is
clear. And what I'm trying to point out is that what I've noticed
may be a reason why it's not clear to some readers. The cure is for
us to think about this and modify the document accordingly, not for
you to explain here on the mailing list what you meant.
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
