Re: [Asrg] New draft draft-irtf-asrg-bcp-blacklists-01.txt

[Andrew Kirch <trelane at trelane.net>]

Douglas Otis wrote:
> This message is posted on behalf of Dave Rand.
> ---
>
> This is Dave Rand again, again - I am not part of this mailing list,  
> and am responding via this forum simply to provide facts, figures and  
> current status.  I continue to be available for questions, comments  
> and backing data.
>
> There are several different kinds of lists, and in my previous email,  
> I referred specifically and only to the RBL(tm).
>
> Al Iverson, the originator of the RSS (which is *not* the RBL) brings  
> up a good point, and that would be that automated re-testing of  
> certain types of blackholing *can be* a good thing.  I will point out  
> that automated re-testing was, in the day, considered abuse by  
> itself.  The current RSS contains only about 500 confirmed open relays  
> which have sent spam - the oldest of which (listed by Al himself) is  
> about 8 years old.  This oldest listing is still open, still running  
> at the same IP address, still has the same in-addr (and, as far as I  
> know still running in the same closet without any system  
> administration at all).  The Open Relay Plauge is pretty much over,  
> and the RSS was certainly responsible for curing many systems, and we  
> have Al to thank for that.
>
> The RSS (which looks at open relays) and OPS (which looks at open  
> proxies) are examples of semi-automated blackholing lists.  In the  
> early days, MAPS demanded that a human look at each and every spam  
> prior to testing, so that systems were not tested without cause.  I  
> know I looked at an awful lot of spam, prior to unleashing the RSS  
> tester on systems.  Regardless, we got a *lot* of complaints from  
> people because "we were attempting to break into their system" -  
> despite the spam coming from their systems.
>
> There just aren't a lot of open relays any more.
>
> The RBL(tm) is a *fully manual* process.  No automation.  It is the  
> "list of last resort".  It is used to stop spam coming from  
> *persistant* spam sources - ones that have been brought to the  
> attention of the service providers, and that the service provider has  
> ignored.
>
> If you want to put in the draft that "fully or semi-automated lists  
> should have a retest interval", that's fine with me.  In fact, this  
> would help blocklist providers defend against "you are cracking our  
> system!" complaints. Define the retest interval to be something  
> reasonable, and I'm certain that all reputation providers doing  
> automated listing will help.
>
> Automatic expiration for automated lists?  Well, we know that 8 years  
> isn't long enough.  I don't know what it should be.  20 years?
>
>   

I agree here that there should not be a defined maximum, even under the
weight of a SHOULD directive.  I would note that in general it is a best
practice to automate the removal of anything automatically added.  We
automate open proxies, spamtrap data, open relays, and rhsbl data.  We
have automated the removal of all but the last.  (We're still working on
a weighting system to increase the removal penalty, and provide an out
of band contact to manually remove false positives (especially for those
institutions that are victims of Phishsing and other forgery based scams).
> But fully manual lists, where details of the of issue have been  
> communicated to the service provider, and the service provider given  
> an opportunity to respond?  Sorry.  If you are advertising routes for  
> your customers, and cashing their cheques, then you have an obligation  
> to deal with the complaints.  Yes, I know you don't control their  
> gear, but you *do* control their connection, and you *can* apply  
> filters, or apply wire-cutters as appropriate.
>
> I don't have the stats for the XBL/CBL, but I do have long term (10  
> year+) stats for the MAPS data, and I know that *in general*,  
> addresses that send spam *do not* get better until some action is  
> taken.  I do see cycles of inactivity - but with 100M+ compromised  
> hosts out there, that's not surprising at all.  But the spam almost  
> always comes back, until the root problem is addressed - securing the  
> network (usually by blocking port 25, by the service provider).
>
> Service providers will continue to be held accountable for *dealing  
> with the complaints*.  No, I'm not suggesting, in any fashion, that  
> you have to monitor connections 24x7 for "illegal or immoral  
> activity", but once a complaint has been registered, and found to be  
> valid, then the service provider has an obligation to deal with it.  I  
> know they don't want to deal with complaints, and many efforts in the  
> last few years have been for certain Service Providers to find ndotis at mail-abuse.org  
> ways to evade this responsibility.
>
> If the service providers can find a way to make full, accurate,  
> customer-contact information available to the list operators, then we  
> can work out a way to share the burden for complaints.  In many  
> countries, however, this is either illegal, or not workable, so the  
> Service Provider is the only one with valid contact information (well,  
> they know how to get hold of them when the bill isn't paid, anyway :-)
>
> Perhaps I am mis-reading this, or perhaps I'm just confused about the  
> intent of the draft to insulate service providers from any requirement  
> of action.  If I am, I apologize to the group.  Again, I am *all for*  
> automated re-testing of automated listings.  I, and Trend Micro, is  
> completely against automated removal of any reputation data, without  
> the Service Provider's guidance.
>
>   
I think you've misread to some extent here, and I have contacted the
authors privately requesting that this be clarified.  I assume good
faith here from two long-term members of the anti-spam community who
have not had direct experience running a blacklist, and don't perceive
anything in the draft as any sort of attempt to insulate service
providers.  The draft itself is designed to establish best common
practices for us the DNSBL maintainers, so it really won't speak much to
providers responsibilities, or requirements.  This can, and should be in
another draft.
> Guys, have a look at https://nssg.trendmicro.com/nrs/reports/rank.php
>
> No surprise that the top 10 service providers also have some of the  
> largest number of RBL listings.  And if *just* the top 10 service  
> providers did *anything* to reduce the amount of spam that their  
> customers generate, we would be dealing with at least an order of  
> magnitude less spam on the network.
>
> So, once again, I call on the service providers to put the reputation  
> providers out of business:  Stop the spam, at the source.  I know you  
> can, and you know you can too.  Just in the last year, 3 networks have  
> gone from the top-10 to off-the-list.  Your network could be next.   
> Your network should be next.
>   
Here, here!
> This pattern has been repeated since the dawn of the RBL.  Service  
> providers have changed their policies, and stopped spam coming from  
> their networks.
>
> Again, I am available off list for questions or comments.  I've taken  
> arrows, rocks and bomb threats for years, too, so please not too many  
> of these.
>
> ---
>
> -Doug
> _______________________________________________
> Asrg mailing list
> Asrg at ietf.org
> https://www.ietf.org/mailman/listinfo/asrg
>   

Andrew
AHBL.org
_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www.ietf.org/mailman/listinfo/asrg