Responding to complaints

I sent in a complaint to an ESP earlier today. This was mail from a major UK retailer to an address that is not used to sign up for mail. It’s part of an ongoing stream of spam related to UK services and products. I believe most of this is because one of the data selling companies has that address associated with someone who is not me.

I did explain I believed this was a purchased address but I’m wondering if I will get a response. The address isn’t one of those I regularly use so there isn’t a connection between “Laura, deliverability person” and “Laura, spam victim.” There are some industry folks who go out of their way to respond to my complaints. That’s always rewarding.
On a more theoretical level, I can make good arguments for responding and good arguments for not responding.

Why not respond?

  • It takes too much time. Back when I was managing the abuse desk for a large network provider, I had 3 people working under me. Between the 4 of us, we could handle a little over 2000 complaints per month. We tried to respond to all complaints, but it did slow down the amount of time it took to process issues. We were also stuck reading and responding to complaints that came in after we’d fixed the problem. This led to an important design point for Abacus: it should be easy to respond to all complaints about an issue and there should be an automatic response to people reporting closed issues.
  • Blowback. Not every from address is valid and the abuse desk may end up spamming. This happens when people don’t trust the abuse desk to correctly handle the complaint. Or when they think the address might be simply list washed. An abuse desk should not send mail automatically to forged email addresses.
  • Complainants want to argue. This particularly happens when a complainant wants one action to happen, but the abuse desk doesn’t do that. There is also a segment of the population who will argue word choices – like using double opt-in vs. single opt-in. The reporter is angry and wants to take it out on someone and, hey, the abuse desk answered so that is who they are going to argue with.
  • Publicity. Bad PR is never fun and “poor” responses can go public. Back when I was abuse, I remember one situation where someone I knew and thought was trustworthy sent in a complaint. I handled the complaint and actually sent him back a response explaining what we did and what we were unable to do. Next thing I know, the email I wrote is published to USENET and boss is calling me on the carpet. What I failed to notice is that buried in the 5th paragraph of the email, after the 4 pages of whois and trace route data, the complainant said they might make any response public. I didn’t read that far, because I saw the headers, knew the issue, handled it and didn’t need all the details. That was one of the last times I responded to anyone, even if I “knew” them.  

Why respond?

  • Politeness. This is really specific to manual complaints. The complainant has taken the time to compose an email alerting you to a problem. It’s just polite to respond.
  • Publicity. Handling abuse issues can be good publicity for a company. There are still some old timers who fondly remember the emails from Afterburner and his crew of minions. Those emails were great publicity and gave the ISP a good reputation in the anti-abuse community.
  • Transparency. Transparency in abuse handling lets the wider community know that issues are taken seriously. Without responses, the reporters are left wondering if their report was received or read.

Often the only response people get from a complaint is that the mail stops. That’s not bad, I mean, that’s usually what they wanted. But there are a small number of people who are not reporting spam to make their own mail stop, but instead are reporting spam to help the overall email ecosystem. I don’t know how to separate A from B but it would be nice if there were a way to do so.

Related Posts

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.

Read More

Services, abuse and bears

A couple weeks ago I wrote a post about handling abuse complaints. As a bit of a throwaway I mentioned that new companies don’t always think about how their service can be abused before releasing it on the unsuspecting internet.
Today’s blog post by Margot Romary at the Return Path In the Know blog reminds me that it’s not always new companies that don’t think about abuse potential before launching services.

Read More

Random thoughts on reporting abuse

stop_atOn IRC today, someone mentioned an Ars Technica article discussing how a research team tried to contact Xfinity about a security flaw in their home security system.

Read More