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

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

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

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