Catchall domains accept any mail to any email address at that domain. They were quite common, particularly at smaller domains, a long time ago. For various reasons, most of them having to do with spammers, they’re less common now.
Most folks think catchall domains are only used for spamtraps. As a consequence, many of the address verification tools will filter out, or recommend filtering out, any address that goes to a catchall domain. They test this by trying to send emails to random addresses like email@example.com.
But not all catchall domains are used for spamtraps. Every client here at WttW gets a domain assigned to them and those domains are catchalls. Emails to those domains go into a database for analysis. Clients (and I!) can create any LHS on the fly to test signups, look at mail flows. Having a catchall means we don’t have to actually configure any address so I can test multiple signups and encode the data about the signup in the to: address.
This works most of the time, at least until verification services mark those addresses as bad and they don’t get imported into the client’s processes. We have some workarounds, and can still get mail despite the services making assumptions.
Congrats to the folks at SendGrid for raising over 130 million in their IPO yesterday. Also, cool stock symbol, bro.
A number of people have mentioned over the last couple weeks that they’re seeing a spike in Yahoo rejecting mail with
554 delivery error: dd Requested mail action aborted
Discussions on various mailing lists indicate these messages are related to inactive accounts. Addresses that bounce at Yahoo with these codes should be handled as inactive addresses and removed from future mailings.
Two of the very first posts I wrote on the blog were about permission (part 1, part 2). Re-reading those posts is interesting. Experience has taught me that recipients are much more forgiving of implicit opt-in than that post implies.
The chance in recipient expectations doesn’t mean, however, that permission isn’t important or required. In fact, The Verge reported on a chatbot that will waste the time of spammers. Users who are fed up with spam can forward their message to Re:Scam and bots will answer the mail.
I cannot tell you how tempted I am to forward all those “Hey, just give me 10 minutes of your time…” emails I get from B2B spammers. I know, those are actually bots, but there is lovely symmetry in bots bothering one another and leaving us humans out of it.
Speaking of those annoying emails, I tweeted about one (with horrible English…) last week. I tagged the company in question and they asked for an example. After I sent it, they did nothing, and I continued to get mail. Because of course I did.
These types of messages are exactly why permission is so critical for controlling spam. Way more companies can buy my email address and add me to their spam automation software than I can opt-out of in any reasonable time frame. My inbox, particularly my business inbox, is where I do business. It’s where I talk with clients, potential clients, customers and, yes, even vendors. But every unsolicited email wastes my time.
It’s not even that the mail is simply unwanted. I get mail I don’t want regularly. Collecting white papers for my library, RSVPing to events, joining webinars all result in me getting added to companies’ mailing lists. That’s fair, I gave them an email address I’ll unsubscribe.
The B2B companies who buy my address are different. They’re spamming and they understand that. The vendors who sell the automation filters tell their customers how to avoid spam filters. Spammers are told to use different domains for the unsolicited mail and their opt-in mail to avoid blocking. The software plugs into Google and G Suite account because very few companies will block Google IPs.
I’ve had many of these companies attempt to pay me to fix their delivery problems. But, in this case there’s nothing to fix. Yes, your mail is being blocked. No, I can’t help. There is nothing I can say to a filtering company or ISP or company to make them list that block. The mail is unwanted and it’s unsolicited.
The way to get mail unblocked is to demonstrate the mail is wanted. If you can’t do that, well, the filters are working as intended.
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.
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.
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.
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 was a busy month. In addition to on boarding multiple new clients, we got new desks, I went to Toronto to see M3AAWG 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.
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
Twitter needs a blighty flag.