ietf-asrg
[Top] [All Lists]

Re: [Asrg] Round 2 of the DNSBL BCP

2008-04-01 16:59:54
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg