ietf-asrg
[Top] [All Lists]

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

2010-10-27 05:14:20

...
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.



_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg