ietf-asrg
[Top] [All Lists]

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

2008-03-31 01:29:47
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?

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

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.

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(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg

<Prev in Thread] Current Thread [Next in Thread>