Best practices for abuse@ mailbox and network abuse complaint handling?

Sun May 13 03:57:18 UTC 2007

On 5/11/07, Suresh Ramasubramanian <ops.lists at gmail.com> wrote:
> 1. Mitigate [port 25 management, walled gardens and such]
> Cut down on the number of abuse causing issues

I believe we are doing a good job of mitigating abuse events
originating from our network, but when it does happen, I want to know
about it.

We get perhaps one "real" abuse issue a month, plus a bunch of
complaints from customers who signed up for the website and the
confirmed-opt-in marketing email, and then decided that they were
being spammed when they got exactly what they had signed up for.  And
then there are the people who receive spam where a company owned
domain is primitively spoofed as the sender or as a header.

Luckily the only time my group is involved in email abuse and spam
issues is when an irate customer decides to make threats against the
company or company infrastructure in their complaint (actually
happened just last week, which is part of why I started this thread).

On 5/11/07, william(at)elan.net <william at elan.net> wrote:
> On Fri, 12 May 2007, John Levine wrote:
> >> The issue I see with most of the options (abuse.net, spamcop, etc)  is
> >
> > Hey, leave abuse.net out of this, please.  It's just a database of
> > contact addresses.

And it does a fine job at being a database of DOMAIN contact
addresses, but  what abuse.net doesn't do is provide any information
on NETWORK contacts, it will only look up names,  not IPs -- for those
the victim need to be clueful enough to know what an ASN is and how to
look up the ASN contact details...

I was hoping that there would be someplace like abuse.net where we
could register our IPs and ASN, so non-NANOGers could know to contact
network-abuse@ when they think our network is attacking them?

> I think he was asking about reporting abuse and not handling
> abuse desk complaints.

I'm asking how to make sure that my team receives the non-spam-related
incoming complaints when a remote network operator feels they are
"under attack" by our IPs, how to effectively make a separate POC for
network-abuse@ without having a human  watch the abuse@ mailbox and
forward network related issues to network-abuse@ where I can follow
up.

Right now there isn't much of an abuse desk to handle complaints, and
I cannot depend on the messaging group to manually read through all
the abuse@ mail, pick out real network incidents, and forward them to
the operations/security/CERT team in a timely manner.

And don't get me started on the L1 "help" desk.

On 5/11/07, Suresh Ramasubramanian <ops.lists at gmail.com> wrote:
> Separate POCs as far as possible (postmaster for block related issues,
> abuse for spam related issues, and a block interface like the one we
> have around - http://spamblock.outblaze.com/ip.add.re.ss), and quick,
> automated escalations

Aside from making sure ASN whois and ARIN are pointing to a
network-abuse@ mailbox, how do I get victims to use separate POCs?

Or can anybody point to an outsourced service which will do effective
triage on abuse@ complaints, dealing with the forged headers and other
simple problems, and forwarding real events and LE requests to the
appropriate company POCs?

> Personally I generally report non-spam complaints to same abuse
> designated mailbox (it is abuse after all) but also CC data from
> abuse contacts from ASN whois.

That's exactly the problem -- non-spam complaints end up going to the
same abuse designated mailbox, but outside of NANOG nobody even knows
what ASN stands for.

Kevin