Keith Moore wrote:
I think you're missing the point.
Oh, no, I fully understand the point. In contrast, I think you're
relying on false dichotomies.
For example:
Better "interoperation" of a facility that degrades the reliability of
email, by encouraging an increased reliance on dubious filtering
criteria and rumors, is not a desirable goal.
There is no such thing as a filtering mechanism that is 100% accurate,
and hence all are dubious to one degree or another. Every technique
relies upon factors that are based on intuition and experience, rather
than physical law. A demonstrable assertion that "IP x is demonstrably
infected with Srizbi and anything it emits is probably crap" and
communicated by DNS is much less dubious than "this combination of
random content fragments makes it look like a Nigerian 419, sorta,
marginally".
Indeed, experience shows that a correctly chosen set of DNSBLs is often
not only more effective than other techniques in correctly identifying
malicious email, can often have far fewer false positives than just
about any other mechanism.
It certainly is counterintuitive that "source reputation" might be more
accurate than "per email evaluation". But, experience in the field
demonstrates the true reality - the current state of the art is that
intelligently chosen DNSBLs (the aforementioned BCP is intended to help
that) often work much better than complete reliance on the latter.
Furthermore, incorrect DNSBL listings are easier to cope with than, say,
random combinations of SpamAssassin scores that just happen to zap a
desirable email.
This is not specific to SA. It's just as applicable to other things
like Bayesian.
We run DNSBLs and SpamAssassin here on the MXes. The former catches 10
times as much as the latter, FPs less, and is a lot easier to explain
and remediate than the latter. We _hate_ SA FPs, because it's so much
more difficult to ensure that it doesn't repeat.
[The obvious Bayesian/SA remediation (whitelisting email addresses)
isn't good enough. Virtually all malicious email is forged. Thus,
whitelisting senders leaves you wide open to getting zapped by forgeries.]
Even assuming that there's some benefit in having third-party reputation
services (which IMHO is not well-established),
Again, a false dichotomy: DNSBLs are not necessarily third-party, and
other perfectly reputable techniques (eg: outsourcing your spam
filtering to a spam filtering company or relying on your ISPs filtering)
are third party by definition. Indeed, running your own copy of
SpamAssassin on your own mail box is just as much giving away "control"
of your filtering to a third party with their own evaluations techniques
of greater or lesser dubiousness.
Is it not third party because you can tweak the rules of SA? You can
also locally whitelist around DNSBL entries.
The only way you can get away from "third party" is to write your own
filters from scratch, and ignore everybody else's heuristics.
I generate several DNSBLs for use here only. Why shouldn't there be a
standard so that mail server software I buy/lease/license will
interoperate with DNSBLs I create?
"Not well-established"? You don't seem to have any idea how prevalent
the use of DNSBLs is. It's probably the industry's dirty little secret
because of the occasional media event. But there have been similar
media events about other filtering techniques that aren't 3rd party, nor
source reputation.
The reality is: almost everybody uses DNSBLs, and ALL of the very big
sites do.
use of DNS to communicate
such reputation, and basing such reputation on IP addresses, is itself
very dubious.
You may think it dubious, but it is usually more reliable and effective
than any other, and its popularity alone means it needs to be standardized.
Rejecting the standardization of DNSBL protocols because the entries of
a specific DNSBL _might_ be dubious is in itself a dubious position.
The problem isn't just the rumor passing mechanism, but
the mechanism is indeed part of the problem.
It's not as if we're arguing about whether to standardize a facility
that is widely believed to work well.
It is widely believed to work well. That's part of the point.
We're arguing about whether to
standardize a facility that causes problems for everyone.
No more so than filtering in general.
Back when I started working with email, getting a message reliably
delivered was something of a black art, because you had to know how to
thread your message through the hodgepodge of Internet, uucp, BITNET,
DECnet, fidonet, and whatnot. That was in some sense understandable
because Internet access was not widely available, and there wasn't
really any common network that everybody could tap into.
Today, getting a message reliably delivered is once again a black art.
But today, it's not for lack of standards or network connectivity. It's
because so many messages are filtered for dubious reasons, or on the
basis of what are essentially unsubstantiated rumors, or because of
over-reliance on IP source addresses as identifiers.
DNSBLs exist and their use is extremely widespread because the industry
_does_ believe in them. There is a very large number of efforts to
demystify DNSBLs and deal with DNSBL issues. DNSBLs used to provide
positive reputation, not just negative. It is no longer the black art
of that hodgepodge of networks both you and I remember trying to support
way back then. It is well-established and has evolved a long way from
Vixie's original RBL.
We have to get our heads out of the sand and put it on a solid standards
footing to finish the job of de-black-arting it.
As for capricious/rumors and so on, please refer to the proposed BCP I
mentioned earlier.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf