[Asrg] Round 2 of the DNSBL BCP

[Matthew Sullivan]

Rich Kulawiec wrote:
>   
>>    When choosing to adopt a DNSBL, a DNSBL user SHOULD keep the
>>    following questions in mind:
>>     
> [...]
>   
>>    2.   Does the list have a web site?
>>    3.   Are the list's policies stated on the web site?
>>     
> [...]
>   
>>    5.   Does the web site function properly, e.g., hyperlinks?
>>    6.   Are web pages for removal requirements accessible and working
>>         properly?
>>     
>
> I'd like to see this changed to include other mechanisms that can be
> used to communicate policy or handle removals. For example, a number
> of DNSBLs have -announce lists which are used to communicate information
> about outages (planned and unplanned), policy changes,
> zone additions/removals, and so on.
>
> Another angle: I think a web site may well be the best currently available
> option for general information, but for at least some DNSBL users (like me),
> subscribing to the -announce list is a much better way to keep apprised
> of important news.
>   


Mandatory condition of anyone using SORBS Rsync servers is they 
subscribe to at least one of the SORBS mailing lists.  The 
sorbs-announce@ mailing list will feed to all the other public lists.



>> 2.2.1.  Listings SHOULD Be Temporary
>>     
>
> I very strongly disagree with this statement in the case of domains.
> Once a domain is known to operated by a spammer, there's no reason to
> ever de-list it if the list's policy equates to "we list spammer domains". 
>
> I would agree with
>
> 	Listings MAY be temporary or permanent
>
> followed by discussion of why some (let's say, temporarily open relays
> that are repaired) should be temporarily and why some (again, spammer-owned
> domain) may be permanent, if that's the policy of the RHSBL maintainer.
>   

I concur -  I have heard the argument that if the reason behind the 
listing changes then delisting should be removed, but I don't 
necessarily agree.  If a spammer has stopped being spammer, doesn't mean 
their listing should be temporary.


>
>   
>>    The shutdown procedure should have the following properties:
>>
>>    1.  MUST NOT list the entire Internet
>>     
>
> I somewhat disagree.  As we're seeing again with ORDB, this is often
> the only way for DNSBL operators to reclaim resources.  I don't like it,
> it shouldn't be necessary, it has negative consequences, it's bad,
> but sadly, it appears to be the only way to reach people who have
> done their best to ignore all the communication methods listed in
> the prior section.  I don't think DNSBL operators -- having done
> their best to shut down services gracefully -- should be perpetually
> saddled with a burden they no longer want.
>   


I concur, however it needs to be mentioned/addressed in some way as it 
should be a last resort only.  Also we must not forget what happens if 
the DNSbl domain is left to expire.


>>    3.  SHOULD, perhaps through increased delays, indicate to the Mail
>>        administrator that the DNSBL is no longer functional.
>>     
>
> I agree with this in spirit: it should work.  But it doesn't seem to.
>
>
>   
>>    5.  The base domain name SHOULD be registered indefinately, so as to
>>        ensure that the domain name doesn't represent a "booby trap" for
>>        future owners, and/or provide a means by which a new owner could
>>        list the entire Internet.
>>     
>
> I agree with this, but suggest that wording be added to indicate that
> DNSBL operators SHOULD attempt to notify the community if they lose
> control of the domain or domain's DNS due to registrar, ISP, or
> hosting issues.
>   

My comments above, but how about if you get *.registrar (or ICANN etc) 
to make a domain perm....?  Wouldn't work because every man and his dog 
would say 'I'm running this DNSbl' to avoid expiry.


/ Mat