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

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

 



Theodore mentioned:

#Let me get this straight.  It's OK to block e-mail messages on the
#basis of unauthenticated rumors, 

Most DNS block lists are based on empirical factors, not rumors.

For example, in the case of manual anti-spam block lists, like the
Spamhaus SBL, typically listings include spam samples, although other 
block lists may use different empirical criteria (for example, the 
Day Old Bread list looks at the age of domain names in determining 
its coverage). Other lists may identify hosts from dynamic IP address
ranges, etc.

#but now you are complaining that it's somehow dirty pool to block 
#a standard based on the same thing?  

Block lists aren't going to go away if this standard isn't 
published; block lists have broad community acceptance in and of 
their own right.

On the other hand, without standards, block lists may be run in ways 
that will primarily disadvantage those who end up blocked by them.

Standards for block lists provide a basis for evaluating block
list operational practices, and a standard against which poorly
run block lists can (and should!) rightfully be pilloried.

As such, I think it is unfortunate that some have elected to oppose
this draft.

#Questions like, "so how does this work in the face of the expanded
#IPv6 address space", ideally should be addressed earlier during the
#standardization process, and not in last call (where, "oh well, we'll
#just block the whole /48 or /32" might have unfortunate side effects
#not forseen yet) --- but which don't make sense if the goal is to
#document existing practice.

I'm not aware of DNS block lists which cover IPv6 address spaces at
this time, probably in part because IPv6 traffic remains de minimis 
(see http://asert.arbornetworks.com/2008/8/the-end-is-near-but-is-ipv6/
showing IPv6 traffic as constituting only 0.002% of all Internet traffic).

#There's a big difference between "use" and "Use".  If a spamassassin
#configuration (by default) uses a DNSBL to add a point or a fraction
#of a point to a spam score, where it might take a spam score of 10-15
#before spam is dropped, that's a very different usage model than
#someone who, on the unsubstatiated word of SORBS or APEWS, drops the
#e-mail on the floor where it is never seen again.

Distinguish two types of spam filtering:

-- filtering at connect time, where a message that doesn't get accepted
   for delivery can signal that rejection to the system that's
   *still connected* to the rejecting MTA

-- filtering post connect time, as with SpamAssassin, where a message 
   that ends up scored as spam may (at best) end up filed in a spam 
   folder

DNS block lists can be used in either model, but they work best for
filtering at connect time because in that model, the delivering host
knows that a message has been accepted or rejected.

Post connect time filtering means that a message which has apparently
been accepted for delivery may never be seen (e.g., if it has been
spam foldered or deleted).

That critical difference is one reason why DNS blocks lists, used at
connect time, are vastly preferable to other non-deterministic
approaches, although things like SpamAssassin (particularly with 
SURBL rules) unquestionably play a crucial role in stopping some types 
of spam that can't be addressed by connect time DNS block lists. 

But let me just mention one other pragmatic reason why I believe DNS 
block lists used at connect time are preferable to some other 
alternatives, such as site-by-site local anti-spam rules. 

Consider a sending site that may have a temporary spam problem, perhaps 
due to a compromised user account, or an accidental system 
misconfiguration. Having emitted spam, that site ends up being blocked. 

If it is blocked by one (or two, or some small number <N>) DNS block 
lists, after that site has fixed its problem, there's one (or two, 
or some small <N>) places they need to go to get unblocked. Moreover,
DNS block list operators typically do a nice job of explaining how
to get in touch with them, and what sort of process is involved in
getting delisted. 

On the other hand, if thousands or tens of thousands of sites employ 
unannounced local blocks to deal with that temporary spam problem, you 
may be trying for months (if not years!) to get all those private 
site-by-site blocks removed.

#And for those who would argue that it's not their problem how the
#DNSBL is used, since after all that's the responsibility of the folks
#using the DNSBL, 

DNS block listings are the DNS block list operator's expression of an 
opinion about a site's email traffic. Just like a food critic's 
opinion about a restaurant, people can choose to pay attention to
that critic's opinions, or not.

If the critic likes undercooked tainted and bland food poorly presented 
by surly wait staff, and that aligns well with your dining preferences, 
by all means follow that critic's reviews. Most diners, however, with 
more conventional preferences, will quickly learn to discount or
ignore that commentator's recommendations.

Better critics, critics with lasting followings, will do careful research
and objectively report their findings, and become trusted guides and
opinion leaders. And that's what the best of the blocklists, such as 
Spamhaus, represent for much of the email community today. 

Are their other bad block lists out there? Sure, in part because the 
community lacks professional standards that lay out the concrete steps 
required to run a block list well. *That's* what I'd like to see fixed. 

Regards,

Joe St Sauver (joe@xxxxxxxxxxxxxxxxxx)
http://www.uoregon.edu/~joe/
Disclaimer: speaking of opinions, all opinions expressed are strictly 
my own.
_______________________________________________

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]