Should abuse mailboxes have quotas?

For the last couple of weeks, every single abuse mail I've tried to send
to networks in a very short list of countries has bounced back with
"mailbox exceeds quota". I take this to mean that there isn't someone
actively reading, acting on, and deleting e-mail from abuse@<whomever>.

So my new rule is this: bounce an abuse e-mail message, sent to an
abuse address announced for the netrange, and the ENTIRE NETRANGE gets
put in my "reject forever" firewall. I've ask all my customers about
this action, and all agree that it's reasonable, because an
administration with an active abuse desk shouldn't ever have their abuse
mailbox overflow. (Especially in this day of terabyte disks.)

Or they need more people on their abuse desk.

Or they need to eliminate the problem that generates so many abuse
e-mails that it fills up their should-be-enormous mail queue.

I'm tired of blatantly uncaring administrations.

it's also totally possible that in some cases the mailbox for abuse@ got
moved behind some orgs other mail systems... This happened numerous times
at $PREVIOUS_EMPLOYER. When moving around ~200k mailboxes 1 special unicorn
often gets mishandled :frowning:

we wouldn't find out until someone called in all complainy about how 'you
never care about email... blah...' "Sure we care, but our mail-admin team
sometimes breaks us, whoops!"

ascribing malice is often unhelpful... Also, of course it's your network
you can balkanize from the rest of the internet as much as you please.

In a message written on Thu, Oct 27, 2016 at 08:03:11AM -0700, Stephen Satchell wrote:

For the last couple of weeks, every single abuse mail I've tried to send
to networks in a very short list of countries has bounced back with
"mailbox exceeds quota". I take this to mean that there isn't someone
actively reading, acting on, and deleting e-mail from abuse@<whomever>.

Are there any ISP's left that read and respond to abuse@ in a timely
fashion? I haven't seen one in at least a decade. Maybe I e-mail the
wrong ones.

Are there any ISP's left that read and respond to abuse@ in a timely
fashion? I haven't seen one in at least a decade. Maybe I e-mail the
wrong ones.

Or maybe you send reports that they can't act on. Mine are all in ARF
format and ISPs reply and tell me they've acted on them all the time.

In many cases they reports go into ticketing systems, so they'll get
acted on but you don't get an answer from a person. That's fine with
me, I'd rather they spend time swatting bad guys than composing mail
by hand.

R's,
John

Lots. There are also quite a lot that don't.

There are also many who you can't easily tell. Mail to abuse@ doesn't
bounce, their abuse issues aren't horrific relative to the size of their
customer base, so they're doing something right. And yet they have
persistently abusive customers who sit on their networks for years.
I've met the abuse staff at quite a few of those, and they're doing good work,
but it's only visible statistically, not on a per-incident level.

If mail to abuse@ doesn't bounce, give them the benefit
of the doubt until statistics say otherwise.

Cheers,
  Steve

to answer the actual question:

all abuse mailboxes have quotas, either implicitly or explicitly.
the amount of storage available to any given mailsystem is finite.

technically correct. it's the best kind of correct.

:slight_smile:

t

not so much malice as gross incompetence.

running spamfilters on your abuse@ mailbox, really? that is, for those which actually have an abuse mailbox that doesn't bounce outright.

-Dan

I give them a couple weeks/months. The vast majority of them ignore, and allow the abuse to continue.

It's amazing how quickly they respond when they get SBL'd though! Lightning quick.

-Dan

FWIW abuse@whatever seems to be a favorite in many spammers' lists.

I doubt that's their intent, seems like a good way to draw attention
to the spam from people with access to blocking lists etc, so I'll
guess they just blindly harvest web sites etc and abuse@whatever shows
up frequently.

That certainly doesn't help with the volume, some of that slips thru
spam filters, it adds up.

I will admit, it's one of the faster ways I pick up on phishing campaigns against our users. So I'm not entirely against it.

I'm in the camp of not replying to every report.

I was in that camp, too, when I was mail admin for a web host company.
I wanted to spend my time fixing the flood, without having to take the
time to reply.

I figure the best reply is when the spamming stops. I have about 30
mail endpoints of my own that I monitor, so it becomes obvious real
quick when someone takes action. :slight_smile:

not so much malice as gross incompetence.
running spamfilters on your abuse@ mailbox, really? that is, for those which
actually have an abuse mailbox that doesn't bounce outright.

Sorry about that, many networks do perform standard filtering on
messages to Abuse contacts based on DNS RBLs, SPF/DMARC
policy enforcement, virus scans, etc, and do send a SMTP Reject on
detected spam or malware.

If your own mail server's IP appears on Spamhaus, then, Yes, you should
expect any abuse reports you attempt to submit have a likelihood of being
rejected as spam.

Abuse/contact mailboxes are not special in this regard, and it would not be
a good practice to leave unprotected. If anything.....:

For many networks; files sent to abuse mailboxes are likely aliased to the
normal mailbox of sysadmins who have access to high privileges. As such,
these mailboxes may require even stronger protection than other accounts,
because of increased risk (when a mistake is made).

There is a reason that phone numbers, and not just e-mail addresses are listed
in the WHOIS records......

If you get a SMTP reject, then call the the Abuse POC of the organization you
need to report abuse from.....

Not when the mailbox-full bounce is from a network in China, or India,
or Pakistan, or Russia. Or a couple of other countries that seem to be
spam havens.

What is my ROI on the cost of the phone call. MUCH cheaper to put in
netrange blocks, and less time, not to mention the language barriers. I
can't run a telephone call through Google Translate...

It's NOT MY JOB to accept packets from people who can't seem to follow
the accepted rules of the Internet. I pine for the old NSF days, when a
sysadmin had to be a BOFH to keep the local network connected to the
'Net at large. I don't want to suppress innovation as much as the next
guy, but not at the expense of having to deal with childish morons and
greedy bastards who think they can do what they want. Because no one
disconnects them, they are sent the wrong message about what's permissible.

(I'm grumpy because a couple of days ago I got tangled up in some
medical gear, and ended up slamming my knee squarely into a marble
floor. It hurts, it does.)

Sorry about that, many networks do perform standard filtering on
messages to Abuse contacts based on DNS RBLs, SPF/DMARC
policy enforcement, virus scans, etc, and do send a SMTP Reject on
detected spam or malware.

I'll disagree, here. Sure, there are some basic considerations - but some of the major
types of role accounts should have specific exceptions to allow the issues to actually
reach the appropriate party.

not so much malice as gross incompetence.
running spamfilters on your abuse@ mailbox, really? that is, for those which
actually have an abuse mailbox that doesn't bounce outright.

Sorry about that, many networks do perform standard filtering on
messages to Abuse contacts based on DNS RBLs, SPF/DMARC
policy enforcement, virus scans, etc, and do send a SMTP Reject on
detected spam or malware.

This is a good way to get your block listed on RBLs.

For many networks; files sent to abuse mailboxes are likely aliased to the
normal mailbox of sysadmins who have access to high privileges. As such,
these mailboxes may require even stronger protection than other accounts,
because of increased risk (when a mistake is made).

If anyone actually does this, it is incompetence beyond comprehension.

There is a reason that phone numbers, and not just e-mail addresses are listed
in the WHOIS records......

If you get a SMTP reject, then call the the Abuse POC of the organization you
need to report abuse from.....

Again, good way to end up on RBLs. I encourage competitors to heavily filter their POCs.

Oh yes, and also be sure your phone numbers are out of date.

-Dan

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.