The requirement for domain name holders to provide a working abuse@example.com email address comes not only from tradition, but also from RFC 2142. It's interesting to note that that RFC doesn't address itself to just ISPs, it goes for any entity on the Internet.

So do your postmaster, info, NOC, hostmaster, webmaster, abuse, security, ... email addresses actually work ?

Having been on both sides of the fence when it comes to abuse@isp.net let's look at some misconceptions:

• "let's use an auto-reply": auto-replies are in my book evil. But they are also an insult to somebody trying to do their best in making the Internet a better place and reporting on such a thing. Sure submitters will appreciate a short note that their complaint has been dealth with and thanking them for their time, but do so after you processed it. Worse are auto-responders that give a whole bunch of instructions on how to submit things that just aren't relevant.
  
• "filter the spam": I've seen an abuse departments demand a copy of the spam be attached to the email and running a spam filter that bounced the message due to it being detected as spam if the spam was attached. Guess how many valid spam reports they got.
• "form letter reply": While I think form letters are in fact good for responding to abuse notifications, you need a bunch of them, not just one. E.g. I've received form letters asking for an attachment of the spam I was supposedly complaining about while submitting a defaced website hosting some malware to an ISP. The range of complaints is always wider than what your form letters can encompass and submitters have better things to do than wade trough overly long form letters anyway. So keep them short and to the point.
  
• "automate it": While there are abuse reports that can be automated (e.g. the motion picture lawyers use a xml attachment that can easily be automated to trace back your peer2peer copyright abusers), trying to widen this to encompass all complaints just will not work for the same reason as your form letters don't always work.
• "web form": The horror method for reporting entities. You write up everything they need in a neat email and get a rude auto-reply to please use http://obscure.web.example.com/silly.form instead.
  
• "abuse is helping users/customers": Abuse is actually more the one wielding the whip, kicking out unwanted elements based on the AUP (Acceptable Use Policy) or ToS (Terms of Service) or other policies. Helpdesks typically are streamlined to help users to take care of customers. Mixing the two roles into one group can cause abuse to become very inefficient at kicking out the unwanted elements. Abuse helps the outsiders getting the users/customers under control.
• "abuse kicks out our good customers": Yes, abuse will trigger processes to kick out misbehaving customers. But they aren't the nice customers and if you do not deal with those misbehaving customers your really nice customers as well as yourself will face consequences as your neighborhood is fast becoming a bad neighborhood on the Internet.
  

So what does work for both sides?

• Handle the incidents, make sure the users/customers know you are strict as it leads to less abuse. Have policies that have teeth and can bite, and let them work even when external. This will result in a very short time in less incidents to handle as once you take a few harsh measures you eliminate the really bad apples and the word will spread so that the rest starts to behave a bit.
• Have forms letters for:
• Thanking submitters and letting them know it's been dealt with (where I live you cannot -legally- give details of what you did).
• Asking for more details, but be specific what you need extra for the case at hand.
• Warning users/customer they are breaching policy
• Escalating incidents to be investigated further
• If you get easy to automate requests: sure process them, but keep a human supervision to it to make sure it doesn't get abused itself.
• Do not filter the abuse email with anti-spam software, people will forward spam messages originating from your users/customers, so you need to let it in. Yes, you'll have to delete the regular crop of spam.
  
• Handle the queue manually. Somebody put time into writing up the compliant, you should too.

Some examples of bad replies:

• Somebody reporting a defaced website spreading malware: "Thank you for submitting a report to the [X] Network Abuse Department. Unfortunately, your submission does not contain sufficient information to determine the nature of your issue.  Evidence to Abuse should always include at least the IP address of the offending party and a valid timestamp, which includes time, date and timezone."
  If you host the website or if your customer hosts it, they will have better timestamps then the submitter. You really need to accept incidents and work with them on a minimal basis, if you need more you can always ask for more later on, but e.g. in this case the website is defaced "now", just check it and act on it. [BTW: checking a website distributing malware: take care with that browser ...]
• "Thank you for submitting a report to the [X] Network Abuse Department. Unfortunately, we are unable to investigate the email you forwarded because it does not appear to have originated from the [X] network." Well perhaps the automation missed the ball completely here. There was an attached email (actually an auto-reply from the organization itself). There are two problems however:
• The assumption that any attached email is what is being complained about. What if it was (as in this case) a clarification of the failing reporting process.
• The email did originate from the organisation itself. Interpreting email headers is not easy. If you cannot detect normal email headers reliably, don't even try to interpret spammed email headers (spoofed information).
  

With thanks to Chris, a very good Samaritan out there trying to make the Internet a better place and being plagued with well below par reponses from the big ISPs out there, yet still motivated enough to share his experiences.

Success!

--
Swa Frantzen -- Section 66