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.

Related Posts

January 2016: The Month in Email

Jan2016_blogHappy 2016! We started off the year with a few different “predictions” posts. As always, I don’t expect to be right about everything, but it’s a useful exercise for us to look forward and think about where things are headed.
I joined nine other email experts for a Sparkpost webinar on 2016 predictions, which was a lot of fun (see my wrap up post here), and then I wrote a long post about security and authentication, which I think will be THE major topic in email this year both in policy and in practice (see my post about an exploit involving Trend Micro and another about hijacked Verizon addresses). Expect to hear more about this 2016 continues.
My other exciting January project was the launch of my “Ask Laura” column, which I hope will prove a great resource for people with questions about email. Please let me know if you have any questions you’d like to see me answer for your company or your clients — I’ll obscure any identifying information and generalize the answers to be most widely applicable for our readers.
In other industry news, it’s worth noting that Germany has ruled it illegal to harvest users’ address books (as Facebook and other services do). Why does that make sense? Because we’re seeing more and more phishing and scams that rely on social engineering.
In best practices, I wrote about triggered and transactional emails, how they differ, and what to consider when implementing them as part of your email program. Steve describes an easy-to-implement best practice that marketers often ignore: craft your mails so the most important information is shown as text.
I re-published an older post about SMTP rules that has a configuration checklist you might find useful as you troubleshoot any issues. And a newer issue you might be seeing is port25 blocking, which is important if you are hosting your own email senders or using SMTP to send to your ESP.
Finally, I put together some thoughts about reporting abuse. We work closely with high-volume abuse desks who use our Abacus software, and we know that it’s often not worth the time for an individual to report an incident – but I still think it’s worthwhile to have the infrastructure in place, and I wrote about why that is.

Read More

Spam complaints… ish


I know a lot of folks working at ESPs. For those I know well, I will usually send in reports. Sometimes they’re not spam reports per se. Often it’s just “hey, this sender shouldn’t have my address, might want to poke them.”
Sometimes it’s even more specific. A few years ago I spoke at a user conference for an ESP. I stayed at the hotel for one night, and the hotel now has my email address. Not a big deal, they’re on the coast and an easy drive from here. They’ll run specials for the locals, and I like it.
Enter in hotel B. I’ve never stayed at hotel B. I’m not sure who hotel B is. They’re also local and may be the same management. I don’t know.  They sent me email to the address I’ve only given to hotel A. Not only that, the message is completely unreadable. Dark blue on brown… not exactly a great design choice.
I wasn’t going to send anything in to the ESP, but then I noticed that at the bottom of the email there is a notice that says “This email was sent to: %%emailaddr%%.” That looks suspiciously like this was an accidental send. The ESP folks there are colleagues, so I sent them an email into abuse@.

Read More

The Blighty Flag

Back in the dark ages (the late ’90s) most people used dialup to connect to the internet. Those people who had broadband could run all sorts of services off them, including websites and mail servers and such. We had a cable modem for a while handling mail for blighty.com.
At that time blighty.com had an actual website. This site hosted some of the very first online tools for fighting abuse and tracking spam. At the same time, both of us were fairly active on USENET and in other anti-spam fora. This meant there were more than a few spammers who went out of their way to make our lives difficult. Sometimes by filing false complaints, other times by actually causing problems through the website.
At one point, they managed to get a complaint to our cable provider and we were shut off. Steve contacted their postmaster, someone we knew and who knew us, who realized the complaint was bogus and got us turned back on. Postmaster also said he was flagging our account with “the blighty flag” that meant he had to review the account before it would be turned off in the future.
I keep imagining the blighty flag looking like this in somebody’s database.

That is to say, sometimes folks disable accounts they really shouldn’t be disabling. Say, for instance:

This was an accident by a twitter employee, according to a post by @TwitterGov

Read More