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.

We attempted to contact anyone responsible for the security of Xfinity home security devices at the following addresses: security@xfinity.com; secure@xfinity.com; support@xfinity.com; info@xfinity.com; abuse@xfinity.com, but we did not get a response to our attempt to disclose the issues to the vendor.

I’m not surprised they didn’t get a response from those addresses, there’s no mail server there. What I do question is a “security” group that doesn’t check their email bounces. Of course, it could be the mail is sitting in a queue somewhere waiting for it to time out due to lack of DNS resolution.
Thinking about how to find the right email address led me down the path of considering manually reporting problems or spam to groups. What is the right way to do it? I’ll be honest, I’ve mostly stopped reporting abuse to senders I don’t know, and in many cases I only report abuse as a favor to colleagues.
There isn’t a standard for how to accept abuse reports. Yes, yes, yes I know about RFC2142. I’ll just point out that’s a nearly 20 year old RFC that’s still “standards track” and hasn’t been updated or improved since it was initially published.
Historically, the internet was very different when 2142 was published. In 1997 the web was still new. Not every company even had a website. Abuse problems were much simpler. Those companies that had a website tended to have one website, on one domain. The sent mail from the same domain, with links pointing to the same domain. A single abuse@ address maintained at the domain could accept reports about a lot of different things.
Today, email is much more complex. Many organizations have dozens of different domains for different purposes and different . Even a company as small as Word to the Wise has different domains for different things. Many of them are just websites, no email services provided. Larger organizations have different domains for different divisions. They have domains that never receive email and never send email, but are present in email sends. Should a company maintain a server on that domain, with all the associated costs and hassle, just to get the occasional complaint?
In some ways it doesn’t matter that these ESPs can’t get individual abuse reports because enforcement at most ESPs is an issue of numbers. Either they get enough FBL emails to justify action or they don’t. The individual complaints don’t matter and don’t move the needle.
Even in the case were companies care and want those individual complaints there are barriers that prevent reports from getting to the right place.

Legacy Domains

Companies have lots of legacy domains from acquisitions and mergers. Some of these domains are maintained and used, some of them aren’t. In any case, abuse handling isn’t always considered when merging companies and making sure reports get to the right place.

Complex Ownership and Responsibility

Sometimes the company that “owns” an IP doesn’t actually control the IP or the users of that IP.  Some of this is a consequence of merger and acquisitions. Not all of it is, though. Sometimes it’s a business partnership that may not be completely visible to the outside. To anyone outside the IPs look like they’re managed and owned and provisioned by provider A but they’re actually the responsibility of provider B. Earthlink broadband is one example that comes to mind – that was a maze of twisty little providers.

Filters

It’s near impossible to run a mail server without any filters these days. Any decent filter will catch spam, including forwarded spam. Companies that run abuse@ on their primary domain can often filter out reports. In many filters it’s hard, if not impossible, to special case specific addresses. Larger companies can.

Hosting Intercepting “special” boxes

Many email hosting platforms, like Google Apps, prohibit role accounts like abuse@ or postmaster@. This means companies using Google Apps often cannot monitor abuse complaints at the standard addresses.
It’s not always easy to necessarily contact “the right people” to get a security repot handled. Particularly if you’re not a part of the community and your report is something unusual. But if the company wants reports there are usually ways to get to the right person. Sometimes this involves calling the switchboard and leaving messages. Sometimes it involved poking around on a website. Sometimes it means joining a mailing list (like NANOG, or mailop, or one of the security lists) and asking for help. Generally if you’re polite, show some clue and share as much info as possible, someone will reach out and help you find the right person to talk to.
In the Xfinity case, the researchers have no excuse for not contacting Comcast directly. They sent mail to a non-existent domain. They never noticed the mail bounced? Even so, as there was no response, they should have worked a little harder to get a response from Xfinity. For instance, while writing this post I found a toll free number directly into Comcast’s security desk. I visited the page that the researchers said “had no useful information”. I went to the bottom and saw “security”, which takes you to https://constantguard.xfinity.com. I clicked on the giant “HELP” link and found:

The Customer Security Assurance organization has been established to ensure a safe and secure online experience for Comcast customers. This team is a dedicated group of security professionals who respond to issues pertaining to phishing, spam, infected computers (commonly referred to as bots), online fraud and other security issues.

  • Business Hours: 6:00am – 2:00am EST, 7 days a week
  • Contact: 1-888-565-4329

Xfinity Security Help Page

(Full disclosure: I know some of the folks who handle that 1-888 number).
It’s not always easy. But it is a very rare case where I haven’t been able to get in touch with someone willing to talk to me about an issue with persistence and work. It’s usually not worth the time, but it’s generally not as hard as reported.

December 2015: The month in email
Facebook scams move to LinkedIn

Related Posts

Peeple, Security and why hiding reviews doesn't matter

There’s been a lot of discussion about the Peeple app, which lets random individuals provide reviews of other people. The founders of the company seem to believe that no one is ever mean on the Internet and that all reviews are accurate. They’ve tried to assure us that no negative reviews will be published for unregistered users. They’re almost charming in their naivety, and it might be funny if this wasn’t so serious.
The app is an invitation to online abuse and harassment. And based on the public comments I’ve seen from the founders they have no idea what kind of pain their app is going to cause. They just don’t seem to have any idea of the amount of abuse that happens on the Internet. We work with and provide tools to abuse and security desks. The amount of stuff that happens as just background online is pretty bad. Even worse are the attacks that end up driving people, usually women, into hiding.
The Peeple solution to negative reviews is two fold.

Read More

Back from M3AAWG

Last week was the another M3AAWG meeting in San Francisco. The conference was packed full of really interesting sessions and things to learn. Jayne’s keynote on Tuesday was great, and brought up a lot of memories of just what it was like to be fighting spam and online abuse in the mid to late 90s. It’s somewhat amazing to me that many of the people I first met, or even just heard about are still actively working to fight abuse and make the Internet safer.
Wednesday was another great keynote from Facebook, discussing security. Facebook is committed to sharing threat information and has started the ThreatExchange website as a hub for sharing data among large companies.
One thing that was amusing was during one talk someone mentioned YubiKey for managing logins. They said many people were sharing long strings of random keys that sometimes happen because someone has accidentally triggered the one time passcode. YubiKey is awesome, if sometimes ccccccdkhjnbitklrrtnhjrdfgdlhektfnfeutgtdcib inscrutable.
As has become a bit of a M3AAWG tradition lately, Wednesday was also kilt day. There may be pictures. For those of you planning to go to Dublin, Wednesday will be kilt day as well.
The conference was great, but ended on a bit of a down note. We received word that Wednesday night a long time friend, Ellen R., passed away due to complications from a stroke. The conference held a moment of silence for her at the end. Ellen was a friend as well as a colleague. She was around on IRC when we started this crazy experiment called Word to the Wise and was always helpful and insightful. She volunteered with, and then worked for, Spamcop and then volunteered with Spamhaus. Ellen will be very missed.
I started off the conference remembering all the friends I made back in the late 90s and ended it remembering and missing those who are no longer around. Email has been one amazing journey, and doesn’t look like it’s going away anytime soon.

Read More

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