Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[Disclosure: I am the leader of the dnswl.org project; I provided some
input into the DNSxL draft as far as it concerns whitelists.]

Keith Moore schrieb:

> These incidents happen one at a time.  It's rarely worth suing over a
> single dropped message, and yet the aggregate amount of harm done by IP
> based reputation services is tremendous.

I would not want to reduce the situation to blacklists only. You use the
correct term - IP based reputation services - but fail to mention that
this includes whitelists, and that decisions other than "drop" can be
made based upon data returned by such services.

Regarding the "dropped message": While outside the scope of the DNSxL
draft, it is pretty much consensus that messages should not be dropped
in the sense of deleted or "stored in a seldomly reviewed quarantine
folder", but that a clear SMTP 5xx error code should be returned.

DNSBLs in conjunction with SMTP 5xx error codes actually increase the
value of the overall email system by enhancing it's reliability.

> receive.  But they're not as likely to know about messages that they
> never receive because of false positives, so of course they're less
> likely to complain about them.  And the cost (to sender or recipient) of
> a message blocked for bogus reasons can be far higher than the cost to
> the recipient of a spam.   

I believe it is generally agreed that false positives are the main risk
with spam filter solutions. This applies both to individual tools like
DNSxLs and to the "filtering machine" as a whole as perceived by the
recipient (and the sender). No automated solution can guarantee the
absence of false positives.

On the other hand, the manual solution is far worse in terms of false
positives, in my experience - the human error rate is pretty high when
eg a spammy inbox must be reviewed manually.

It is true that many spam filter solutions are short on "ham rules"
which would offset erroneous (or bogus, as you chose to call it) "spam
rules". The reason is obvious: most ham rules would be trivially to
forge for a spammer -- something which is not practical with IP
addresses. That's why IP addresses are so important for spam filter
decisions, both for black- and for whitelisting.

> And the relative number of complaints is not
> a reliable indicator of those costs.

It's probably the best indicator available?

-- Matthias, for dnswl.org
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]