Check your abuse addresses

Even if you have excellent policies and an effective, empowered enforcement team you can still have technical problems that can cause you to drop abuse mail, and so lose the opportunity to get a bad actor off your network before they damage your reputation further.

It’s not quite as simple as “We’re seeing email in our abuse ticketing system, so everything must be fine.”

How many abuse addresses have you published? Do all of them work? Them being deliverable but not routing to your compliance desk may be worse than them bouncing.

What abuse addresses might people expect to exist? Do they exist and deliver to the right place?

And do any of your abuse addresses discard mail about spam? It seems ridiculous that they would, but a surprising number of abuse addresses are behind the same content filters as the other email addresses in a domain, meaning that reports of spam get content-filtered.

What abuse@ addresses might a reasonable person expect to work?

• abuse@ your main domain; the one you advertise and where your website is
• Any abuse address listed in the OrgAbuseEmail (or the relevant point of contact on the web search form) field when you look up any of your network space at ARIN, or the abuse-mailbox field when you look them up at RIPE, or the equivalent at whichever regional registry you get your IP addresses from. (“whois -h whois.arin.net 10.11.12.13” will let you query american addresses at ARIN from a non-Windows commandline; use whois.ripe.net for europe, whois.apnic.net for asia-pacific, whois.afrinic.net for africa and whois.lacnic.net for latin america)
• If you’re a RIPE customer, then the result of “whois -h whois.ripe.net 10.11.12.13” might include a line that looks like “% Abuse contact for ‘10.216.128.0 – 10.216.159.255’ is ‘abuse@example.uk'” – that email address should work (and if it’s not the same as your abuse-mailbox field you might ask why).
• Many ESPs use domains for their infrastructure other than their main domain. If a hostname of yours appears in the Received headers of email you send (“mta24.lhr.example.co.uk”) then abuse@ the base domain (“abuse@example.co.uk”) should work. Making  abuse@mta24.lhr.example.co.uk deliverable (by creative use of a wildcard MX record at *.lhr.example.co.uk, perhaps) I’d be impressed by your infrastructure chops, but it’d be pretty pointless – anyone sending you a useful report will understand the concept of an organizational domain.
• The base domain of the right hand side of your bounce address should provide a working abuse address – e.g. “Return-Path: bounces@bounce.example.de” means that abuse@example.de should work
• abuse@ the base domain of your clickthrough domain should work
• abuse@ the base domain of your image hosting domain should work
• If you’re using custom domains for customers, then you should at least know where abuse@ those domains delivers to for those domains
• If you mention a contact address in your acceptable use policy, privacy policy, affiliates policy or anything similar then not only should that email address (“privacy@example.ie”) work but so should abuse@ the same domain (“abuse@example.ie”)
• The email addresses listed for your domains at abuse.net (there’s a web lookup form and you can also query it via whois or dns)
• Any email address you use in the From field of mail you send as replies from your abuse desk should work too.

Some of these may seem a bit obscure, but some of the most immediately useful abuse reports sometimes come in via routes that aren’t easily connected to your main corporate domain.

As one example, it’s not unheard of for a spammer to use a demo account to send themselves a single copy of their spam, created in your message composition tool and using your image and clickthrough domains, and then blast that out via compromised machines or a throwaway server. This damages the domain reputation of domains that are common across most of the mail you send, damaging delivery for all your customers. If you spot it quickly and kill the images and redirectors they’ll go elsewhere next time. And you’re much more likely to be able to do that if a civic-minded recipient wants to tell you it’s happening – and can do so based on the links in the body of the message.

And it’s a contractual requirement to provide valid contact information when registering IP addresses, so any abuse aliases listed with ARIN or RIPE should be deliverable or the registration may be flagged as having invalid contact information. That doesn’t mean any action is likely to be taken, other than adding a note to your address registration saying something like “ARIN has attempted to validate the data for this POC, but has received no response from the POC since 2018-02-17”, but it might make for an awkward conversation next time you’re trying to acquire new network space, I guess?

What does “work” mean, when it comes to an abuse@ alias? Obviously, it shouldn’t bounce – either immediately or a week later when some internal forwarding fails. It should reliably deliver any mail sent to it to someone who can handle it in a timely fashion. That means that if the email contains content that’s “spammy” it shouldn’t be discarded, bounced, sent to a junk folder or replied to with a snarky autoresponse – as any useful spam report will contain a copy of the spam, and so will contain spam-like content. And if it delivers to your NOC, your postmaster team, your tier one support desk or your sales team (don’t laugh, I’ve seen that happen) they should make sure it’s forwarded appropriately (though if they do that all or even most of the time, maybe it’s being delivered to the wrong place). If your policy is to send automatic responses for abuse complaints it’s probably a good idea to send them consistently, whichever route they arrive via.

The only real way to tell whether all your abuse aliases work is to occasionally try and deliver mail to them, and see if it shows up in your ticketing system. Send it from somewhere not on your corporate network – in case the internal email address is working fine, but bitrot has set in somewhere on your external MX. Try and include some sort of spammy content in it – either something you pull out of your spam folder, or perhaps an artificial GTUBE spam test string. Include the email address you sent it to in the Subject line, so you can easily track which email addresses work and which ones bounce (and which ones just silently swallow mail).

If you don’t have a separate security group you might want to check that security@ aliases deliver to you too.

Aaaand while writing this I discovered that two of the listed abuse contacts for my personal domain bounce. Even if you’re trying to pay attention it’s really easy for bitrot to set in as your infrastructure ages, leaving old, non-working email addresses still published somewhere. Check they work everyso often and after any significant infrastructure change.