On 10/27/2010 6:12 AM, Hal Murray wrote:
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?
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 ;-)
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.
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.
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?
I think the existing is sufficiently generalized to cover both highly
automated and highly manual, with individual callouts where useful.
Things that might be worth discussing. These aren't MUST/SHOULD type ideas,
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.
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.)
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.
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.
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.
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)
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg