Recent Posts

Today is one of those days I just want to argue with all the subject headers of the marketing email I get.
Read More

Subscription bombing and abuse prevention

A few weeks ago ProPublica was the victim of a subscription bomb attack. Julia Angwin found my blog post on the subject and contacted me to talk about the post. We spent an hour or so on the phone and I shared some of the information we had on the problem. Julie told me she was interested in investigating this further problem further. Today, ProPublica published Cheap Tricks: the Low Cost of Internet Harassment.
For those of us deeply involved in the issue, there isn’t too much that comes as a surprise in that article. But it’s a good introduction to folks who may not be aware of the existence of subscription bombing.

Julia does mention something I have been thinking about: abuse and anonymity online. Can we continue to have anonymous or pseudonymous identities on the Internet? Should we?
One of the challenges a lot of companies are struggling with is that anonymity can protect oppressors as well as their targets. How do we support “good” anonymity without enabling “bad” anonymity? I’ve always thought anonymity was an overall good and the fact that it’s abused sometimes didn’t mean it should be taken away. Banning anonymity online might seem to fix the problem of abuse, except it really doesn’t and it comes with its own set of problems.
Let’s be honest, these are hard questions and ones that do need to be addressed. A lot of the tools abuse and security desks currently have rely on volume of complaints. This can result in the targets getting shut down due to false complaints while the perpetrators keep their accounts open. It means subscription bombs can target a few individuals and occur undetected for months.
Big companies in Silicon Valley love to rely on their algorithms and machine learning and AI and code to automate things. But the automation only works after you create working processes. Throwing code at the problem doesn’t work unless you have a picture of the scope of the problem. And a reliance on code ends up with Facebook asking people to upload nudes of themselves to prevent nudes on Facebook. Likewise, throwing cheap labor at the problem isn’t a solution, either.
I don’t have the answers, I don’t think anyone does. But we need to think harder about these problems and address them sooner rather than later. The internet is too important to let abusers break it.

Interacting in professional fora

There are a bunch of online communities – mailing lists, Slack channels, etc. – where “people who do email” interact.
Some of them are open to anyone to subscribe, some of them are semi-private and require an invitation, others are closed and only available by invitation and yet others are associated with trade associations and only open to their members.
Many of them include representatives from ISPs, ESPs, reputation providers and technical specialists. They also – especially the open lists – have participants with no particular role in the industry, but very strong opinions on what others should do.
They’re a useful place to keep up to date on current issues and industry trends, and to get help when you need it. But … quite a lot of people reduce their chance of getting timely help by the way they behave there. Don’t be like those people.
Some of the things you should and shouldn’t do are specific to mailing lists. Some are specific to professional fora. Some are specific to entreating others for help. Here, in no particular order, are some suggestions:

DO: Be friendly. Be patient. Be welcoming. Be considerate. Be respectful.
DO: Be careful in the words that you choose.
DON’T: Be a dick.

DON’T: Be wildly unprofessional. If you think sexist or racist behaviour isn’t wildly unprofessional, leave the email industry. Ditto for unwanted sexual attention, personal insults, sexualized language or imagery.
DON’T: Harass people. If someone wants you to stop, then stop.

DO: Follow the community norms. Different communities have different styles and traditions – try and pick up on what they are, and avoid violating them.
DO: Follow the community norms for replying to messages, quoting them and trimming threads. If you’re not sure what they are then snipping out parts that aren’t relevant and replying in-line isn’t likely to offend anyone.
DO: Follow the level of formality of the community. Some are very formal, and should be treated much the same as a business meeting. Others much less so, and blend professional discussion with blowing off steam, ranting about idiot clients and social banter between friends.
DO: Lurk on the list for a day or three before posting to get a feel for how the community works (unless there’s a “welcome to the new person” thread). If you’ve joined because you have an immediate emergency you’re looking for help on, say so and be polite – maybe even a little apologetic – about it. Maybe spend five minutes checking the list archives first.
DON’T: Lurk except when you have a problem. Interacting with others when you’re not asking for help builds up relationships and karma. If you only appear when you’re looking for help, people are less likely to be helpful.

DO: Be clear about what company or organization, you’re affiliated with. That might mean using a corporate email address, mentioning it in a sig file or in a “Hi, I’ve just joined the group” message. Or it might mean including the relevant company name when asking for help. If, for political reasons, you absolutely cannot admit to your affiliations it’s still useful to know that you work for an unnamed major US cable company or an email provider based in Switzerland – particularly when you’re offering help or advice where your insight is coming from your experience in that role.
DO: Remember that the vast majority of the people you’re interacting with aren’t being paid to be there. They’re sharing their time and expertise in return for benefiting from others. Try to both give and take.
DO: Remember that a representative from a large ISP probably doesn’t have answering your questions or helping with your problem in their job description.

DON’T: Aggressively demand help. Nobody owes you anything.

DO: Read responses carefully. Someone may not be able to publicly join the dots on an issue for you, but may point out which dots you might want to look at.
DO: Understand limits. If someone says “our lawyers say this is the process you must follow” then follow that process. And don’t push that person to do things that their lawyers say they can’t do.
DO: Be aware that you’re interacting with people, not company representatives. They almost certainly have opinions that don’t reflect those of their organizations.
DO: Remember that nobody owes you support. Be nice. And if someone doesn’t volunteer help or stops responding, don’t badger them.

DO: Follow the community style for how you present your message. But … in general, mostly plain text won’t offend anyone, heavy use of rich text will annoy some people.
DON’T: Rely on rich text for meaning. It may not be visible to some people or not visible when quoted. “Look at the log lines highlighted in yellow” isn’t a good approach.
DON’T: Warlord. There’s no need for long legal disclaimers on your mail. Nor for more than four lines of signature – we don’t need to know your life history. Graphics are cheesy, even if they’re your employers professionally drawn logo. Even colour can be distracting if it’s not used carefully.

DON’T: Assume that you’re the best representative of your organization to interact with a community. If you’re a senior manager and you have a smart employee who is actively working in the area – they may be a better rep than you are.

DO: Be aware of how public a community is. Does it have a public archive that’s indexed by Google? Is it open subscription? Be aware of how public things you say are.
DO: Be aware of what is expected from you in terms of information distribution. Can things you learn from the community be shared elsewhere? With attribution, or not? If you’re not sure, don’t share information unless the person providing it OKs that – it’s always OK to ask if you’re not sure. Terms you might see are Traffic Light Protocol or Chatham House Rule.

DO: Assume good faith.

DO: Provide relevant information when looking for help or asking “has anyone else seen this?”.
DO: Check unread mail to a list before posting. If someone else is already talking about an issue, join that thread rather than starting your own.
DO: Check the archives first, if you can. The answer to your problem might be in there. And if it’s not, including a mention of “this looks similar to what Yahoo was doing in October” signals that you’ve done a little work before asking for help and might trigger someone’s memory of what happened last time.
DO: Include relevant IP addresses and hostnames, if you’re asking about a delivery issue.
DO: Include exact error or rejection messages – “blocked at AOL” isn’t particularly useful, “554 RLY:B1” is much more so.
DO: Mention what sort of email it is, especially if you think the problems may be content related.
DON’T: Obfuscate.
DO: If you’re asking about a problem, say how long it’s been going on and what you’ve already tried to fix it.
DO: Respond promptly if someone asks for more details.
DON’T: Expect help if you’re not prepared to share data.
DON’T: Vanish once you resolve the problem. Share what you did, even if it’s just “it cleared up around 3pm”.

DO: Be prepared to take conversations that only you and one other person, out of hundreds, are interested in to direct message or private email.

DO: Stick around and help others. Share what you know.
DON’T: Post off-topic stuff people aren’t going to be interested in. It’s great that your kid is selling girl scout cookies or you’re doing a charity 5k, but unless you’re absolutely sure that this is a good place to fundraise, it almost certainly isn’t.
DO: Keep conversation on a mailing list, on the mailing list. There’s no need to Cc everyone involved – they’re on the mailing list too.

DON’T: Email angry. If someone has made you mad, wait before responding.

Proofpoint acquires Cloudmark

Major industry news today as Proofpoint and Cloudmark announced a major acquisition deal. Proofpoint agreed to pay $110 million in cash to acquire Cloudmark. Prior to this acquisition, Proofpoint focused on business filters. Cloudmark’s focus was selling into large ISPs, including large cable providers, and mobile carriers. Proofpoint assured investors they will continue to supporting and developing the Cloudmark filters. At the same time they’re incorporating the Cloudmark Global Threat Network into their Nexus platform.
A few things came to mind when I saw the announcement.
Both companies focused on different types of email filtering. Proofpoint developed products for business, building filters that address spam but they did a lot more. Many of the filter features have nothing to do with blocking mail, but instead focus on other business critical functions like protecting intellectual property and maintaining compliance with various laws and regulations. Cloudmark, on the other hand, created filters that businesses could deploy to protect consumers as well as use in their business
With this acquisition we’re starting to see a consolidation of functionality. The distance between business filters and consumer filters continues to close.
Filtering isn’t just about spam, though.
This acquisition improves Proofpoint’s ability to filter things other than spam. Their announcement specifically calls out spear phishing and business email compromise (BEC) as problems. They are. Criminals steal billions of dollars from businesses through email attacks. These same types of attacks were employed in the 2016 US elections against candidates and parties.
It feels like we’re embarking on a new phase of security and compliance. Those tools we built to deal with spam and protect the internet from abuse generally worked. Our mail infrastructure isn’t falling down due to spam. Now we need to look forward to handling different kinds of abuse. The same people who stepped up to the plate in the early 2000’s to address spam are now looking at how to protect individuals online.
It’s a nice internet we’ve got here. Let’s see if we can keep it.

October 2017: The Month in Email

October was a busy month. In addition to on boarding multiple new clients, we got new desks, I went to Toronto to see M³AAWG colleagues for a few days, and had oral surgery. Happily, we’re finally getting closer to having the full office setup.

What is an office without a Grover Cat? (he was so pleased he figured out how to get onto it at standing height).

All of this means that blogging was pretty light this month.
One of the most interesting bits of news this month is that the US National Cybersecurity Assessments & Technical Services Team issued a mandate on web and email security, which Steve reviewed here.
In best practices, I made a brief mention about the importance of using subdomains rather than entirely new domain names in links and emails and even DKIM keys.
We’ve talked about engagement-based filters before, but it’s interesting to note how they’re being used in business environments as well as consumer environments.
We also put together a survey looking at how people use Google Postmaster Tools. The survey is now closed, and I’ll be doing a full analysis over the next couple of weeks, as well as talking about next steps. I did a quick preview of some of the highlights earlier this week.
Finally, a lot of industry news this month: Most notably, Mailchimp has changed its default signup process from double opt-in to single opt-in. This caused quite a bit of sturm und drang from all ends of the industry. And, in fact, a few days later they announced the default double-opt-in would stay in place for .eu senders. I didn’t get a chance to blog about that as it happened. In other news, the Road Runner FBL is permanently shuttered, and Edison Software has acquired Return Path’s Consumer Insight division. Also worth noting: Microsoft is rolling out new mail servers, and you’ll likely see some new — and potentially confusing — error codes.
My October themed photo is behind a cut, for those of you who have problems with spiders.

The Blighty Flag

Back in the dark ages (the late ’90s) most people used dialup to connect to the internet. Those people who had broadband could run all sorts of services off them, including websites and mail servers and such. We had a cable modem for a while handling mail for blighty.com.
At that time blighty.com had an actual website. This site hosted some of the very first online tools for fighting abuse and tracking spam. At the same time, both of us were fairly active on USENET and in other anti-spam fora. This meant there were more than a few spammers who went out of their way to make our lives difficult. Sometimes by filing false complaints, other times by actually causing problems through the website.
At one point, they managed to get a complaint to our cable provider and we were shut off. Steve contacted their postmaster, someone we knew and who knew us, who realized the complaint was bogus and got us turned back on. Postmaster also said he was flagging our account with “the blighty flag” that meant he had to review the account before it would be turned off in the future.
I keep imagining the blighty flag looking like this in somebody’s database.

That is to say, sometimes folks disable accounts they really shouldn’t be disabling. Say, for instance:

This was an accident by a twitter employee, according to a post by @TwitterGov

Gmail survey rough analysis

I closed the Google Postmaster Tools (GPT) survey earlier today. I received 160 responses, mostly from the link published here on the blog and in the M³AAWG Senders group.
I’ll be putting a full analysis together over the next couple weeks, but thought I’d give everyone a quick preview / data dump based on the analysis and graphs SurveyMonkey makes available in their analysis.
Of 160 respondents, 154 are currently using GPT. Some of the folks who said they didn’t have a GPT account also said they logged into it at least once a day, so clearly I have some data cleanup to do.
57% of respondents monitored customer domains. 79% monitored their own domains.
45% of respondents logged in at least once a day to check. Around 40% of respondents check IP and/or domain reputation daily. Around 25% of respondents use the authentication, encryption and delivery errors pages for troubleshooting.
10% said the pages were very easy to understand. 46% said they’re “somewhat easy” to understand.
The improvements suggestions are text based, but SurveyMonkey helpfully puts them together into a word cloud. It’s about what I expected. But I’ll dig into that data.
10% of respondents said they had built tools to scrape the page. 50% said they hadn’t but would like to.
In terms of the problems they have with the 82% of people said they want to be able to create alerts, 60% said they want to add the data to dashboards or reporting tools.

97% of respondents who currently have a Google Postmater Tools account said they are interested in an API for the data. I’m sure the 4 who aren’t interested won’t care if there is one.
47% of respondents said if there was an API they’d have tools using it by the end of 2017. 73% said they’d have tools built by end of Q1 2018.
33% of respondents send more than 10 million emails per day.
75% of respondents work for private companies.
70% of respondents work for ESPs. 10% work for retailers or brands sending through their own infrastructure.
That’s my initial pass through the data. I’ll put together something a bit more coherent and some more useful analysis in the coming week and publish it. I am already seeing some interesting correlations I can do to get useful info out.
Thank you to everyone who participated! This is interesting data that I will be passing along to Google. Rough mental calculation indicates that respondents are responsible for multiple billions of emails a day.
Thanks!

Google Postmaster Tools: Last Chance!

I’ll be closing down the Google Postmaster Tools survey Oct 31. If you’ve not had a chance to answer the questions yet, you have through tomorrow.
This data will be shared here. The ulterior motive is to convince Google to make an API available soon due to popular demand.

Edison acquires part of Return Path

Today Matt Blumberg announced that Edison Software acquired Return Path’s Consumer Insight division, current customers and some Return Path staff.
Congrats to everyone involved.

Mailchimp changes signup process

As of October 31, 2017 signup forms and popup boxes provided by Mailchimp will no longer default to a double / confirmed opt-in process.