Subject: Re: [Asrg] Please take a look at the blacklist BCP draft

From: Hal Murray <[email-masked]>
Date: Wed, 27 Oct 2010 03:12:15 -0700

...
> It's intended to be a summary of DNSBL best practices.  Take a look,
> please.  If we mostly agree that it's right, or we agree what changes are
> needed to make it right, I can send it along and say there's RG consensus
> on it.
...

> https://datatracker.ietf.org/doc/draft-irtf-asrg-bcp-blacklists/ 
Guidelines for Management of DNSBLs for Email

I'd be happy if it was published as is.  There is a lot of valuable 
information in there that isn't readily available anyplace else.

On the other hand, I think it could be a lot better.

Section 1.2, Guidance for DNSBL Users, is buried in the 
Introduction.  That looks important enough to be a top level section.  
Perhaps I'm expecting more than just Management (from the title).  How about 
Management and Usage?

Section 2.2.2 A Direct Non-Public Way to Request Removal ... seems more like 
an Operatonal detail (section 3) rather than a Policy issue.

Overall, much of it seems tailored to lists like the CBL that are highly 
automated.  Would it be worth discussing lists with a lot of manual work?

Do any mail server packages periodically check that the DNSBLs they are using 
are working right and tell the postmaster/sysadmin if something is wrong?  
(If not, is anybody working on that?  Working code and all...)

Things that might be worth discussing.  These aren't MUST/SHOULD type ideas, 
but things that users and/or implementers might want to consider.
 
  Whitelisting
    Maybe needed even with conservative lists.
    Easy whitelisting allows more aggressive filtering.
  Use URL or short-timeout Email address in rejection text.
    Needed to request whitelisting.
  Freemail providers
  Snowshoe spammers
  Low cost web farms
  Rogue ISPs
  Blocking whole countries
  Deep Receive header inspection
    Catches mail from Nigera via freemail or phish

Dynamic vs Generic confusion.

A company might want to block login from out-of-country IP Addresses to 
reduce the damage from phished credentials.  This obviously needs a way to 
bypass checking for people who do travel out of the country (if you have any) 
and maybe only when they are traveling.

URL shorteners need aggressive anti-spam procedures or they will get listed. 

Check DNSBLs before you rent IP-Addresses from an ISP, both their overall 
reputation and the specific addresses you will get.

ARIN, RIPE, and such should park blocks that get returned long enough for 
them to age out of block lists.  (or at least well run ones)  So should ISPs.

Perhaps ARIN and such should announce when blocks are returned and block 
lists should watch for those announcements and automatically delist returned 
blocks.  (Including private lists.)

It might we worth reminding everybody that their abuse@ mailbox should work 
and that whois info for CIDR blocks should include abuse contact info.  This 
is both a way to avoid getting on block lists as well as a way for the block 
list operator to contact you.

Overall, I can't come up with a good suggestion for a top level organization. 
 My straw man would be:
    Introduction
    Policy
    User side
    Server side
But it might need another section with more background between Intro and 
Policy, for example more discussion of the breadth of reasons for listing and 
how lists are used (envelope vs payload scanning)

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 28 Oct 2010 01:59:17 -0400

> Perhaps I'm expecting more than just Management (from the title).  How about

I'd been thinking about doing this a bit, but I've promised myself that 
if this BCP can actually go forward to something useful without too much 
(more) aggro, I'd write another more general BCP on spam filtering in 
general - that might be more palatable all the way up into the IETF than 
this BCP will likely be, and more prominently cover all these issues and 
more, and be far less aggro.  That's probably a better place for 
promoting the subject, because it is far more general issue than just 
DNSBLs, and less political.

The "Guidance" section is more of an introduction of what DNSBL users 
should think about as an introduction to DNSBL policy/operational 
considerations than a series of IETF-ish SHOULDS/MUST NOTs etc.

Besides, after all this time, I don't have the lifespan for yet more 
major revisions ;-)

> an Operatonal detail (section 3) rather than a Policy issue.

No, that's definitely a policy item put there deliberately.  SPEWS and 
APEWS style "go start a flame war in NANAE, you can't contact us no way 
no how, nyaa, nyaa" policy is what we were trying to discourage.

I've seen a lot of instances where listees simply won't do it, no matter 
how legitimate their claim is.  Especially those who know about NANAE ;-)

IOW: a serious DNSBL should recognize that professionally handling 
queries via non-broadcast channels, and getting recognition for it (as 
some do), can only be of benefit to the list's accuracy, reputation and 
acceptance.  Which can only improve the DNSBL user's experience.

> automated.  Would it be worth discussing lists with a lot of manual work?

I think the existing is sufficiently generalized to cover both highly 
automated and highly manual, with individual callouts where useful.

> but things that users and/or implementers might want to consider.

The following topics are far better handled in either the existing ASRG 
web page survey of techniques, or a more generalized spam filter FAQ.
> blocks.  (Including private lists.)

Actually they do publish this information.  You need to know it exists 
and how to use it.

I pull the CIDR/ASN allocation data for ARIN and the other RIRs from 
Potaroo to derive country codes on ASNs (but you can do it at the CIDR 
level too).  You can tell when an allocation returns to ARIN, and when 
it goes back out again.  Tho, I'm sure that Potaroo would be unhappy if 
everybody did it.

> list operator to contact you.

I don't want to make this BCP a squidlike mess of references to other 
documents.  It can become obsolete far faster that way.

It needs to stay on focus at a higher level than these, which are really 
not DNSBL-specific.