Not good. Just the sort of urgent, high-risk issue that ISP abuse desks really want to hear about. I sent email about it to the ISPs involved, including a copy of the original email. One of them went to iWeb, a big (tens of thousands of servers) hosting company.

This was the response:

<abuse@noc.privatedns.com>: host mott.privatedns.com[174.142.252.34] said: 554 rejected due to spam content (in reply to end of DATA command)

That’s iWeb’s main abuse address for their address space, as registered with ARIN. They even have a comment in their network registration that says “Please use abuse@noc.privatedns.com for abuse issues”.

For email related abuse (spam, malware email, botnets, phishing, viruses, …) almost all valid, actionable abuse reports will include a copy of the email involved. And that’s exactly the sort of content that content-based spam filters do their best to block. That means that putting content-based spam filters on your abuse or security role addresses will prevent you seeing most reports about abusive traffic coming from your network.

There are some companies that have an intentional policy of rejecting most spam reports sent to them so that their abuse metrics look better, and they don’t have to pay for abuse desk staff to handle the high volumes of abuse reports their customers provoke. “Mistakenly” putting spam filters on their abuse alias is one way of doing that – others include using non-standard abuse aliases, demanding reports come in only via web forms, requiring abuse reports be sent in non-human-writable formats while discarding all others, and many more. If you don’t want to behave responsibly it’s easy enough to dodge those reports.

Legitimate companies really want to know about abusive traffic sooner rather than later, so they can shut it down and mitigate the damage as quickly as possible. Email systems are complex, though, and it’s quite easy for an upgrade to spam filtering at a companies main mailserver to mistakenly by applied to abuse@ and security@ aliases – especially when spam filtering or email services are outsourced. And if you’re a company that uses dozens of domains it’s easy to lose track of where mail to abuse@ some of those domains ends up.

If you’re responsible for email, abuse or security at your organization it’s worth occasionally checking that your role accounts actually work. Find yourself a fairly obvious bit of spam, then forward it to your abuse@ role address (with a sentence or two telling your abuse desk that you’re just testing, and can they reply to your mail so you know they received it).

Real spam sent directly to abuse@ role addresses can be a severe problem, but content-based filtering is not the way to deal with it. One approach that we suggest to our Abacus users is to prioritize reports that mention a URL or an IP address on your network, so that legitimate, actionable reports will “bubble up” above any spam.

What I didn’t talk about was how badly broken the ESP was in handling my complaint. The ESP was, like many ESPs, an organization that grew organically and also purchased several smaller ESPs over the course of a few years. This means they have at least 5 or 6 different domains.

The problem is, they don’t effectively monitor abuse@ for those different domains. In fact, it took me blogging about it to get any response from the ESP. Unfortunately, that initial response was “why didn’t you tell us about it?”

I pointed out I’d tried abuse@domain1, abuse@domain2, abuse@domain3, and abuse@domain4. Some of the addresses were in the mail headers, others were in the ESP record at abuse.net. Three of those addresses bounced with “no such user.” In other words, I’d tried to tell them, but they weren’t accepting reports in a way I could access.

Every ESP should have active abuse addresses at domains that show up in their mail. This means the bounce address domain should have an abuse address. The reverse DNS domain should have an abuse address. The d= domain should have an abuse address.

And those addresses should be monitored. In the Dell case, the ESP did have an active abuse@ address but it was handled by corporate. Corporate dropped the ball and never forwarded the complaint to the ESP reps who could act on the spam issue.

ESPs and all senders should have abuse@ addresses that are monitored. They should also be tested on a regular basis. In the above case, addresses that used to work were disabled during some upgrade or another. No one thought to test to see if they were working after the change.

You should also test your process. If you send in a complaint, how does it get handled? What happens? Do you even have a complaint handling process outside of “count and forward”?

All large scale senders should have appropriate abuse@ addresses that are monitored. If you don’t, well, you look like a spammer.

I checked with some people who have Google hosted domains and they have confirmed that abuse@ and postmaster@ addresses can be set up by creating a group. When you create the group you can then add yourself to the group and get the mail that comes into abuse@ and postmaster@.

It’s even better when the spam advertises the filter busting abilities of the spammer. I get a warm, fuzzy feeling to know that the spammer is going to be looking for a new host in the immediate future.

In the recent past, I was dealing with a client’s SBL listing. We were talking about how their fairly clean subscription process ended up with multiple Spamhaus spamtraps on the list. They mentioned bounce handling, and that they’d not been correctly managing bounces for some period of time. Their bounce handling system was broken and no one noticed.

Last year, I was working with another client. They were looking at why some subscribers were complaining about unsubscribes not taking. A bit of poking at different forms and they realized that one of their old templates pointed to an old website. Their unsubscription form had broken and no one noticed.

Another client insisted that their engagement handling removed any addresses that didn’t open or click on mail. But after ignoring their mail for 6 months, they still hadn’t stopped mailing me. Their engagement handling was broken and no one noticed.

Periodic monitoring would have caught all of these things before they became a big enough problem to result in a Spamhaus listing, or recipient complaints, or lawsuits for failure to honor CAN SPAM. Unfortunately, many companies don’t check to make sure their internal processes are working very often.

Email marketing is not set and forget. You need to monitor what is happening. You need to make sure that your processes are still in place and things are still working.

“SPAMHAUS BLOCKS GOOGLE!!!” the headlines scream.

My own opinion is that Google doesn’t do enough to police their network and their users, and that a SBL listing isn’t exactly a false positive or Spamhaus overreaching. In this case, though, the headlines and the original article didn’t actually get the story right.

Spamhaus blocked a range of IP addresses that are owned by Google that included the IP for www.gmail.com. This range of IP addresses did not include the gmail outgoing mailservers.

Spamhaus says

Some Google-owned server IPs hosting severe malicious spam problems – specifically Google’s “Google Docs” service – do get rightly listed in the Spamhaus SBL when Google does not take action fast enough to stop the serving of malicious sites via Google Docs. Such listings act as pointers to the abused resource but do not in any way affect Google’s Gmail service or any Google outbound mail service.

Spamhaus goes on to talk about the responsibility providers have to police their userbase and the fact that large providers who are not policing their users are cost shifting to the rest of us.

We at Spamhaus surely understand the challenges that the cloud service providers face. These problems are not easy to solve and the scale and complexity of the systems involved certainly does not make things easier. What we are puzzled by is how the rest of the internet has to keep carrying the burden of this abuse. The companies that host these services all without exception make hundreds of millions of dollars each year. They employ some of the best and brightest engineers. Surely they can spend a little of their immense resources on making the internet they rely on for their business, a better and safer place.

Unfortunately, Google doesn’t seem to see any value in policing their customers and users. If they can’t make a buck at it, then it doesn’t get done. And if Google’s costs of doing business are shifted to other companies, so much the better. Good for Spamhaus for standing up and pointedly telling Google they can’t keep supporting spam and spammers.

Should you ever contact someone who made an abuse complaint about your newsletter to find out why

My answer was: It depends, but it’s too complicated to explain in 140 characters.

I don’t suggest responding to people who hit the “this is spam” button as a way of complaining. FBLs are complaints, but they are people who don’t necessarily want to engage with you. If they wanted to engage they would have contacted you.

It’s a little trickier when you get complaints directly from recipients. There are a number of reasons people might send you a complaint directly: to honestly engage in a discussion about your mail, to try and track down who might be selling or signing up their email address or to vent their anger at bulk mailers in general.

You can’t always identify which type of recipient just from their initial email, but there are some hints. Complaints cc’d to dozens of email addresses generally aren’t looking for a response, they just want those evil spammers disconnected. Responses to this group of complainers will often be published on mailing lists, newsgroups or on websites. Attempting to engage them usually ends badly for everyone but the complainer.  (Example 1, Example 2, Example 3, Example 4)

On the other hand, there are folks who are contacting you because they think you care about your network and will want to stop abuse from happening. My complaints, for instance, are often only sent to places I think will care. I’m not going to waste my time sending in a complaint to some place that just deletes them. So they tend to be very short and it can be productive to engage with them.

The reason we built Omnivore was because we wanted to change the way we think about abuse. The project involved so much data crunching that it resulted in some interesting byproducts. Our subject line suggester is one example, as well as the engagement ranking and segmenting tools we mentioned earlier.

[...]Omnivore is learning more every day, and is actually getting good at predicting not just bad behavior, but good behavior too.

Some delivery folks also work the abuse desk, handling complaints and FBLs and actually putting blocks on customer sends.

I think the compliance part of the delivery job description that is often overlooked and severely downplayed. No one likes to be the bad guy. None of us like handling the angry customer on the phone who has had their vital email marketing program shut down by their vendor. None of us like the internal political battles to convince management to adopt stricter customer policies. All of these things, however, are vital to delivery.

Despite the lack of emphasis on compliance and enforcement they are a vital and critical part of the deliverabilty equation.

That’s mostly there to protect you, by making sure that someone else can’t get feedback loop messages for your domain. And it’s not too difficult to do, as you should already have an abuse@ and postmaster@ alias set up, and have someone reading the abuse@ alias.

But maybe you’re using Google Apps to host your corporate email, and that’s the domain you need to use for your feedback loops. So you go to create abuse and postmaster users, but it won’t let you – you just get the error Username is reserved for email list only. Uhm, what?

Google want to police use of domains hosted on their service, so they automatically set up abuse and postmaster aliases for your domain, and any mail sent to them is handled by Google support staff. You may well be happy with Google snooping on your abuse role account, but you really need to be able to read the mail sent to it yourself too.

So what to do? Well, the way Google set things up they actually create invisible mailing lists for the two role accounts, and subscribe Google Support to the lists. In older versions of Google Apps you could make those mailing lists visible through the user interface by trying to create a new mailing list with the same name, then simply add yourself to the mailing list and be able to read your abuse@ email.

But Google broke that functionality in the latest version of the Google Apps control panel, when they renamed email lists to “groups”. If you try and create a new group with the email address abuse@ your domain you’ll get the error Email already exists in this domain, and no way to make that list visible.

So, what to do?

Well, there’s a workaround for now. If you go to Domain Settings you can select the “Current Version” of the control panel, rather than the “Next Generation” version. That gives you the old version of the control panel, where all this worked. Then you can go to User Accounts, create a new email list delivering to abuse@ and add one of your users to the mailing list. You can then set the control panel back to “Next Generation” and have access to the mailing lists via Service Settings → Email → Email Addresses.

Hopefully Google will fix this bug, but until they do here’s the step-by-step workaround:

1. Go to Domain Settings, select the Current Version of the control panel and hit Save Changes
2. Go to User Accounts and click Create email list
3. Enter “abuse” as the name of the list, and one of your users as the recipient, and press Add recipient
4. Do the same thing again to create your postmaster list
5. Go to Domain Settings, select the Next Generation of the control panel and hit Save Changes
6. Go to Service Settings → Email → Email Addresses and you’ll see the two mailing lists, and you’ll be able to add and remove recipients from those lists

And then you should have working abuse@ and postmaster@ aliases. Before you need to rely on them, test them by sending mail to them from somewhere other than your Google account.