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