May I add the following:
While the author does a good job of listing the negative aspects of
certain domain name based blacklists, he omits the advantages relative to
other spam suppression techniques. A balanced discussion would consider
both advantages and disadvantages.
The first advantage of DNBLs I want to mention is a private benefit for
the mail transfer operator, his users, and their corespondents.
The typical mailserver using DNSBLs for spam suppression REJECTS suspected
bad mail, while a typical content based scanner DISCARDS suspected spam,
or leaves it in a spam folder. In the case of a false positive This is a
significant advantage to the DNSBL, because the actual sender will get a
notice of refusal from the DNSBL based refusal, but no notice at all of
the discard from the content based system. A user or MTA operator might
place much greater weight on lost mail than rejected mail, as lost mail
may be the source of ill feeling or financial loss, while rejected mail is
merely an inconvenience.
Notice that a content scanner can't reasonably return DSNs for discarded
mail, since the majority of such mail will come from forged addresses, but
the DNSBL rejection occurs during the SMTP control phase, and is returned
to the sender by the originating MTA, if the mail is legitimate.
The second advantage for the DNSBL I want to mention is the public benefit
to all email users when MTA operators administer their sites to discourage
the output of spam from their shared MTAs. In the present legal
environment, the existence of DNSBLs is the primary motivation for such
efforts. Without DNSBLs, many large ISPs and hosting companies would lose
interest completely in suppressing spam spewage from their MTAs and IP
addresses. With the resulting increase is spam messages, content analysis
would become increasing difficult.
Without consideration of the advantages of the DNSBL, or the disadvantages
of content scanning the author has come to a foregone conclusion. An IETF
document deprecating a superior solution is unfortunate.
I am aware that some content based scanners are able to reject mail, and
that some MTAs using DNSBLs discard mail, but both situations are unusual,
and the former is technically difficult. In any case, placing suspected
spam in a spam folder seems like more of a way to avoid legal liability
than to improve the user experience.
I am aware that some MTA operators are frustrated by their inability to
get off certain DNSBLs, and I do not have a cost free solution. I have
referred such operators in the past to my page at
http://www.nber.org/sys-admin/smarthost.html
which suggests that they obtain mail relay service from an operator of an
unlisted MTA and provides some sources. Most complainants are operating
MTAs on dynamic addresses. It would perhaps make more sense for the IETF
to deprecate that practice than to deprecate the DNSBL.
Lastly, the draft refers to no quantitative evidence that DNSBLs are more
likely to reject valid mail than content scanners. This is not my
experience with Google Mail, or Spamassassin. Perhaps other scanners would
be more effective, but by the same token, there is variation among DNSBLs
too.
Perhaps the IETF could publish a "Best Practices" for DNSBL operators
instead of deprecating them.
Thank you for this opportunity to comment.
Daniel Feenberg
IT Director
National Bureau of Economic Research
Cambridge MA, USA
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg