Should abuse mailboxes have quotas?

Fri Oct 28 15:06:08 UTC 2016

No.  They should not.  (Nor should they have spam or malware filters,
since of course that's one of the things that people will forward as
part of their complaints.  Anyone using a sensible email client on
a sensible platform will of course incur zero risk by handling either
of those.)

That said, and since abuse mailboxes have come up in the context
of the ongoing IoT/DDoS discussion, let me point out that a fair
amount of traffic on this list, on mailop, on dns-operations,
on outages-discussion, on other lists, consists of queries of
the form "how can I contact X about Y?"   The traffic exists because X
either has never read RFC 2142 or has just ignored it.  A *lot*
of our collective time has been wasted asking/answering these queries,
and no doubt they represent the tip of the iceberg, as many folks
don't bother (having found those addresses non-existent) or don't
know where to ask.

So now: A Rant (albeit a considered one, after two (2) cups of coffee):

This is unacceptable.  If you don't maintain the basic role addresses
and pay attention to what shows up there, you're not a professional.
You're not even a competent amateur.  Of all the things we have to do,
from unsnarling switches to diagnosing psychotic web/mail servers to
dealing with WTF-grade announcements, maintaining role addresses is
one of the easiest.  It's also one of the best things to do, because
traffic arriving there is quite often trying to tell you about problems
that you have that you really, REALLY ought to be curious about.

And in a time when we're all facing myriad threats, and relying on
each other to communicate about them and address them in as close
to real time as we can manage, it's inexcusable not to have at least
the basics in place.  (abuse@, hostmaster@, postmaster@, webmaster@,
etc. as applicable to the services you provide)  Other people are often
doing your job for you *for free* and are sharing the results with you:
you should be listening.  Intently.

I've heard all the whining excuses...and I dismiss them:

"We get too much traffic @abuse" -- gosh, stop emitting/facilitating so
much abuse and so many attacks, it'll decrease.

"We can't reply to everything" -- see previous point.  And learn how
to use a real mail client.

"We get too much spam" -- use procmail to bin incoming reports
and triage the most likely non-spam ones first. [1]

"People send us malware" -- to a very good first approximation, there
are no such things as "email viruses".  There are "Outlook viruses".
Learn how to use a real mail client.

"We don't speak language X" -- run it through Google translate, take
your best shot at it.  Most reports will be in your language anyway.
(Note: if you are a multi-mega-million dollar company, then hire abuse
and postmaster and hostmaster &etc. staff fluent in multiple languages.
This is more important than your on-site massage therapist and gourmet chef.)

"We don't have the time/personnel/budget" -- but magically you have
the time, personnel, and budget to run an operation that's causing
problems for other people.  Also you have a market capitalization
of $7.65 gazillion dollars and a gym on the second floor, so please
spare me this one.

"But X isn't doing it either" -- the "we're no worse than anyone else"
excuse and subsequent race to the bottom.

"You can call us on the phone" -- yeah, at 3 AM your local time,
that'll work.  Also I'll be dictating the contents of an email
message, including the full headers.  No, I don't mind trying to
explain a hijacked network problem to your front-line support staff
who will read their from their script and tell me to reboot the Windows
box I've never had.  Good use of my time.

"We have a web form" -- that lets me paste 500 characters into
a tiny box and requires 9 kinds of Javascript and captchas and other
crap and doesn't allow me to keep copy of the message and doesn't
facilitate a conversation and doesn't even work because my network
is on fire (thanks in part to you) while email will at least get
queued and retried at intervals.  I also appreciate having to
figure this out 14 times for 14 different operations rather than
being able to just BCC the same message to all of them and get back
to trying to put the fire out.  Another good use of my time.

"Another tired excuse here" -- if you invested the time you spend
coming up with excuses into just doing it, you wouldn't be reading
this rant.

Mail to your role accounts is often coming either from (a) people your
operation is attacking/abusing and/or (b) people who are graciously
and generously trying to help you, despite (a).

You owe them:

	(1) acknowledgement
	(2) investigation
	(3) action, if indicated
	(4) response/explanation
	(5) apology, if indicated
	(6) a thank-you

You owe yourself:

	(7) remedial action to try to forestall a repeat occurrence
	and thus the need to keep repeating 1-6 ad infinitum

This isn't hard.  It's not complicated.  We all solve problems far more
difficult than this six times a day.  If you don't do this, then YOU,
and YOUR operation, are the problem.  You're why we can't have nice things.

And finally, if this appeal to basic professionalism and cooperation and
responsibility hasn't gotten through, let me try self-interest:
You should be doing this anyway because you're going to need other
people to do it for you.  Maybe not today.  But tomorrow or the
next day, when you're the target and you're desperately trying to
get 37 other operations to see what's happening and stuff a sock
in it before your stuff melts down, you're going to need it.

And when that day comes, do you want to be thought of as the responsive,
helpful, alert entity that helped others...or the blackhole that ignored
role account email for years (or didn't even bother to accept it)?
As the cooperative professional who discharged your basic responsibility to 
the Internet or as the worthless parasite who was happy to leech off
everyone else's efforts but refused to make any of your own?

I maintain role addresses.  I pay attention to them.  Every operation
I've touched this century does the same, even the ones I'm no longer
involved with. (And they'd better, because I check up on them, and if
one day I find they're not, I will go back and kick their asses
individually, thoroughly, AND in alphabetical order...because Wowbagger
the Infinitely Prolonged is my role model.)

If you need help: ask.  I've done this a bunch of times, and so have
other people.  None of the solutions are perfect, but they don't have
to be.  They just have to work.

End Rant.  For now.  More coffee is brewing.

---rsk

[1] Procmail makes it pretty easy to winnow a lot of the wheat from
the chaff.  It's not perfect, but it's functional enough and when
it's incrementally refined over time, it can be made to successively
approximate the hypothetical "correct".  Experience indicates that
even if it misses (that is: fails to file some incoming traffic
as a legitimate report) that enough other reports about the same
problem will be filed correctly making it possible (a) to do steps
1-6 above and (b) improve the procmail rules for next time as part
of step 7.

The (b) part is important.  Every investment in it makes the entire
process better and thus reduces future workloads.

A rather effective role-account-handling pipeline can be built on a single
box using the 'nix OS and MTA of your choice, plus fetchmail, procmail,
and Mailman.  And a quality mail client: I strongly recommend mutt,
as it's lightweight, fast, full-featured, and about as impervious
to attack as a mail client can be, which is a good thing when you're
handling a lot of known-hostile email.

Hint: a procmail ruleset built from the email addresses of
everyone who's sent something to nanog, mailop, dns-operations,
outages-discussion, etc. over the last five years is a good start.
A decent second pass includes the role addresses found in SOA records
and the putative/likely role addresses of domains found in the first pass.
Yes, that's a lot of procmail rules.  Yes, that's what INCLUDERC is for.
No, it's not a big deal: I'm running a procmail filter here with nearly
3000 rules *on a laptop* and the performance impact is negligible.