Of late, I have found many large ISPs that are employing anti-spam filters on their abuse@ addresses. Needless to say, they seem surprised that their customers have any abuse issues involving spam at all :-) I know that there was a Abuse Desk BCP working group started a few years ago. Can anyone give me an update on BCP practices that I can refer ISPs to? --
On Tue, 30 May 2006 15:02:21 PDT, Dave Rand said:
Of late, I have found many large ISPs that are employing anti-spam filters on their abuse@ addresses.
Needless to say, they seem surprised that their customers have any abuse issues involving spam at all :-)
Paging Randy Bush - one of your competitors is on the phone... :)
I know that there was a Abuse Desk BCP working group started a few years ago. Can anyone give me an update on BCP practices that I can refer ISPs to?
http://asrg.sp.am/subgroups/bcp.shtml says: "Previous BCP subgroup has been active from September of 2003 until December of 2003 when it was shutdown due to lack of active members. This subgroup is currently in formation, will be restarting as soon as we have enough interested participants." Oooh... Kaay.. Really though, all the BCP you need is: 1) Make sure the 'postmast@' and 'abuse@' addresses accept mail and actually go to live people that can take action (rather than routing to /dev/null or bouncing because the mailbox is full). 2) Don't put a spam filter in front of the spam reporting address. 3) Take *meaningful* action that actually fixes the problem. 3a) Don't send back a "this spam isn't from us" canned message when the headers clearly show it came from you, etc.... 3b) No pink contracts. 3c) Do a basic check on new customers. http://www.spamhaus.org/Rokso/ is a good start. 3d) Make sure your ToS allows nuking a spamming/abusive host. 3e) Then *use* that clause in the ToS when needed.
On 5/31/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
Paging Randy Bush - one of your competitors is on the phone... :)
I know that there was a Abuse Desk BCP working group started a few years ago. Can anyone give me an update on BCP practices that I can refer ISPs to?
http://asrg.sp.am/subgroups/bcp.shtml says:
"Previous BCP subgroup has been active from September of 2003 until December of
There's a maawg bcp or two on this in development, and if you're going to be at the Brussels MAAWG mtg (www.maawg.org) next month I'll be doing a bof on just that, 6/27 evening. srs
Subject: Re: BCP for Abuse Desk
(various good stuff deleted for brevity)
3d) Make sure your ToS allows nuking a spamming/abusive host. 3e) Then *use* that clause in the ToS when needed.
Each of the ISP's I worked for had such a clause. I felt it was a double edged sword. The only choices were to use it or not to use it, and on non-clear cut cases the business side of a company may be reluctant to heave a paying customer out the door. I would advocate service contracts that allow a graduated response including, but not limited to, getting rid of the customer. That way, there are penalties available even in cases of "unintentional" network abuse.
On Tue, 30 May 2006 20:51:55 CDT, you said:
3d) Make sure your ToS allows nuking a spamming/abusive host. 3e) Then *use* that clause in the ToS when needed.
Each of the ISP's I worked for had such a clause. I felt it was a double edged sword. The only choices were to use it or not to use it, and on non-clear cut cases the business side of a company may be reluctant to heave a paying customer out the door. I would advocate service contracts that allow a graduated response including, but not limited to, getting rid of the customer. That way, there are penalties available even in cases of "unintentional" network abuse.
As I said, "when needed". As you correctly noted, sometimes it's more helpful to the bottom line if it remains an unmentioned stick while you find a carrot to wave at the customer. If a well-phrased phone call or two and a helpfully informative e-mail can get the problem resolved, you obviously didn't *need* to nuke. :)
I've found that the reserving the right to nullroute an offending host's IP address for repeated spam offenses is a good intermediate step between simple notifications and contract/circuit termination. It lets the customer know you mean business while still preserving the customer's account status; if the offender is a web hoster, it winds up being a particularly effective tool, as the threat of collateral damage from other sites hosted on the same IP is pretty compelling. Of course, it's important to be willing to remove the nullroute as soon as the customer confirms that the problem has been dealt with, otherwise it does effectively become a partial termination of services. -C Valdis.Kletnieks@vt.edu wrote:
On Tue, 30 May 2006 20:51:55 CDT, you said:
3d) Make sure your ToS allows nuking a spamming/abusive host. 3e) Then *use* that clause in the ToS when needed.
Each of the ISP's I worked for had such a clause. I felt it was a double edged sword. The only choices were to use it or not to use it, and on non-clear cut cases the business side of a company may be reluctant to heave a paying customer out the door. I would advocate service contracts that allow a graduated response including, but not limited to, getting rid of the customer. That way, there are penalties available even in cases of "unintentional" network abuse.
As I said, "when needed". As you correctly noted, sometimes it's more helpful to the bottom line if it remains an unmentioned stick while you find a carrot to wave at the customer. If a well-phrased phone call or two and a helpfully informative e-mail can get the problem resolved, you obviously didn't *need* to nuke. :)
On 31 May 2006, at 00:02, Dave Rand wrote:
I know that there was a Abuse Desk BCP working group started a few years ago. Can anyone give me an update on BCP practices that I can refer ISPs to?
Not a BCP but we have a section for ISP Abuse Desks at http:// www.spamhaus.org/isp/ with useful info including a FAQ for Abuse Issues and Handling, Feedback Loops, Port 25 blocking, etc., plus an online AUP builder. These are at: ISP Abuse Issues FAQ: http://www.spamhaus.org/faq/answers.lasso?section=ISP%20Spam%20Issues ISP Acceptable Use Policy builder: http://www.spamhaus.org/isp/create_aup.lasso Steve Linford The Spamhaus Project http://www.spamhaus.org
participants (6)
-
Chris Woodfield -
dlr＠bungi.com -
Mark Borchers -
Steve Linford -
Suresh Ramasubramanian -
Valdis.Kletnieks＠vt.edu