Do you have an abuse@ address?

I’ve mentioned multiple times before that I really don’t like using personal contacts until and unless the published or official channels fail. I don’t hold this opinion just about resolving delivery issues, but also use official channels when reporting spam to one of my addresses or spam traps.
My usual complaints contain a plain text copy of the mail, including full headers and a short summary of the email address it was sent to. “This is an address that was part of a leak from…” or “This is an address scraped off my website. It’s been removed from the website since 2004” or “This address isn’t used to sign up for any mail.”
Sadly, there are a number of “legitimate” ESPs that don’t have or don’t monitor their abuse address. In some cases it’s an oversight or a break down of internal mail handling. But in most cases, it’s a sign that the ESP doesn’t actually handle abuse.
It’s frustrating to watch an ESP post long blog posts about “best practices” and “effective delivery” and “not spamming” and yet not be able to actually stop their own customers from spamming. It’s not even that I necessarily want them to disconnect their spamming customers (although that would be nice) but suppressing the address that I’ve told them was a spamtrap seems trivial. And yet, a month after my first complaint and weeks after escalating to a personal contact, I’m still getting spam.
The 5 things every ESP should do to handle spam complaints.

  1. Create an abuse address for mail domains. This includes abuse@corporate domain, abuse@ MTA domains, abuse@ return path domain. If it’s in the headers and it accepts mail, it should have an abuse@ address. 
  2. Confirm the abuse@ addresses get to the correct team. I’ve talked with some ESP reps who just have no idea where abuse@ one or more of their domains go. In some cases, they just get lost inside the company.
  3. Customize filters on the abuse@ addresses so reports of spam don’t get bounced with “blocked for spam.” Yes, I know it’s spam, it came from that network and I’m telling you. Telling me it’s spam is not a surprise. Not accepting the spam back, though, is just rude.
  4. Suppress the addresses of people who complain. Even if the customer isn’t disconnected, there is no reason to keep spamming someone who has sent in a complaint.
  5. Pay attention to people who actually tell you the addresses are spamtraps. Put those traps in upload and send filters. I am pretty open about a number of my traps here on the blog and on some mailing lists. When I get spam from companies that I know have reps on those lists, I just think the companies don’t care that their customers spam.

Handling complaints about abuse or spam from a network is part of being a good service provider. Don’t leave the handling to chance, actually test abuse@ addresses. Feedback loops are great and all, but a number of us still send hand crafted abuse complaints because we think a company will act on them. When the company consistently ignores complaints and lets customers continue to spam they eventually turn into just another spam supporter.

Related Posts

Where do you accept reports?

One of the things that is most frustrating to me about sending in spam reports is that many ESPs and senders don’t actively monitor their abuse address. A few months ago I talked about getting spam from Dell to multiple email addresses of mine.
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.

Read More

Spamtraps

There is a lot of mythology surrounding spamtraps, what they are, what they mean, how they’re used and how they get on lists.
Spamtraps are very simply unused addresses that receive spam. They come from a number of places, but the most common spamtraps can be classified in a few ways.

Read More

We only mail people who sign up!

I get a lot of calls from clients who can’t understand why they have spamtraps on their lists. Most of them tell me that they never purchase or rent lists, and they only mail to people who sign up on their website. I believe them, but not all of the data that people input into webforms is correct.
While I don’t have any actual numbers for how many people lie in forms, there was a slashdot poll today that asked readers “How truthful are you when creating web accounts?”. The answer seems to be “not very” at least for the self-selected respondents.

Read More