Recent Posts

Phishing costs company $46 million

Brian Krebs posted about a tech firm that lost $46M dollars due to fraud. The company reported in its SEC filings that the money was lost when someone impersonated an employee and directed the finance department to transfer money to outside accounts.
This is becoming more common. In some cases, DMARC authentication may stop this kind of fraud. But DMARC has a lot of deployment challenges and can cause real mail to fail delivery. In other cases, criminals are using lookalike domains and they can be authenticated and pass DMARC.
This isn’t really a bulk mail issue. And it’s certainly not a deliverability issue. But it is a security issue and I think it’s important that folks are aware of this kind of online crime. Coincidentally, as I’m writing this, I’m chatting online with a compliance person at a cloud hosting company who is brainstorming policies to block phishing URLs on their site. Email is a major vector for abuse and those of us who manage sending need to be a part of the solution.

More Yahoo! Challenges

A lot of people are reporting they’re not getting confirmation emails when signing up for the new Y! FBL program. This is causing problems with folks attempting to transfer domains to the new FBL.
Will update when I hear anything.

Continuous Testing

HubSpot recently posted an blog article comparing which was better for engagement, plain text emails or HTML emails. In a survey they sent out in 2014, 64% of the responses said they preferred the HTML and image-based emails. It seems pretty straight forward, recipients say they want HTML emails over text based emails but through their A/B testing, the text versions had a higher open rate.
They also reported:

Monitoring Your Mail Stream

One of the most important things for any mail sender to do is monitor their mail stream. There are a number of things that every mailer should pay attention to. Some are things to monitor during delivery, some are things to monitor after delivery. All of these things tell senders important information about how their mail is being received by their recipients and the ISPs.

July 2015: The Month in Email

Once again, we reviewed some of the ways brands are trying (or might try) to improve engagement with customers. LinkedIn, who frequently top lists of unwanted-but-legitimate email, announced that they’ll be sending less mail. Josh wrote about giving subscribers options for both the type and frequency of messages, and about setting expectations for new subscribers. In each case, it’s about respecting that customers really want to engage with brands in the email channel, but don’t want the permission they’ve granted to be abused. I also wrote a brief post following up on our June discussion on purchased lists, and as you’d predict, I continue to discourage companies from mailing to these recipients.

Ongoing Yahoo delays

I’ve been hearing from folks over the last few days that they’re seeing an uptick in deferrals from Yahoo! The deferrals are not uniform. ESPs report they’re seeing some, but not all, customers affected. Other ESPs aren’t seeing any changes.
It’s not just you. But it would be very worthwhile to dig into engagement and other stats. It’s possible this is a new normal at Yahoo! and they’re tightening filters to catch mail that doesn’t fit their standards but was previously difficult to filter.

Are botnets really the spam problem?

Over the last few years I’ve been hearing some people claim that botnets are the real spam problem and that if you can find a sender then they’re not a problem. Much of this is said in the context of hating on Canada for passing a law that requires senders actually get permission before sending email.
Botnets are a problem online. They’re a problem in a lot of ways. They can be used for denial of service attacks. They can be used to mine bitcoins. They can be used to host viruses. They can be used to send spam. They are a problem and a lot of people spend a lot of time and money trying to take down botnets.
For the typical end user, though, botnets are a minor contributor to spam in the inbox. Major ISPs, throughout the world, have worked together to address botnets and minimize the spam traffic from them. Those actions have been effective and many users never see botnet spam in their inbox, either because it’s blocked during send or blocked during receipt.
Most of the spam end users have to deal with is coming from people who nominally follow CAN SPAM. They have a real address at the bottom of the email. They’re using real ISPs or ESPs. They have unsubscribe links. Probably some of the mail is going to opt-in recipients. This mail is tricky, and expensive, to block, so a lot more of it gets through.
Much of this mail is sent by companies using real ISP connections. Brian Krebs, who I’ve mentioned before, wrote an article about one hosting company who previously supported a number of legal spammers. This hosting company was making $150,000 a month by letting customers send CAN SPAM legal mail. But the mail was unwanted enough that AOL blocked all of the network IP space – not just the spammer space, but all the IP space.
It’s an easy decision to block botnet sources. The amount of real mail coming from botnet space is zero. It’s a much bigger and more difficult decision to block legitimate sources of emails because there’s so much garbage coming from nearby IPs. What AOL did is a last resort when it’s clear the ISP isn’t going to stop spam coming out from their space.
Botnets are a problem. But quasi legitimate spammers are a bigger problem for filter admins and end users. Quasi legitimate spammers tend to hide behind ISPs and innocent customers. Some send off shared pools at ESPs and hide their traffic in the midst of wanted mail. They’re a bigger problem because the mail is harder to filter. They are bigger problems because a small portion of their recipients actually do want their mail. They’re bigger problems because some ISPs take their money and look the other way.
Botnets are easy to block, which makes them a solved problem. Spam from fixed IPs is harder to deal with and a bigger problem for endusers and filters.

Give Recipients Options

A few years ago I subscribed to a financial website that emails out articles about investing as well as a recap of your investments. For the first few months I enjoyed reading these emails but as time went on, I found them less valuable and receiving them every other day they turned into a burden to clean up and deal with.
My options were to either unsubscribe or I could create a rule in Outlook to file away the emails to possibly read them later.
options What I would really like is the option to define how often I would receive the updates. If I’m actively looking to change my investments, I would want to receive the emails daily. I would also like to have the option for either a weekly or monthly email.
The frequency of mailings should be tailored to the subscriber. Buying a new car? I may want to see emails and reviews daily. Just bought a new blender? I want to receive emails for the first few days learning about the different features and recipes. The idea is to present options to each subscriber on what they prefer. It’s better to treat subscribers as individuals rather than sending the same message to your entire list.
The newsletter I was receiving does not provide me with any type of control over how many times I receive the updates. The newsletter is also lacking a working unsubscribe link leaving me no alternative to clicking “this is junk”.
Senders should consider providing recipients with options:

Google Postmaster Tools

Earlier this month Google announced a new set of tools for senders at their Postmaster Tools site. To get into the site you need to login to Google, but they also have a handy support page that doesn’t require a login for folks who want to see what the page is about.
We did register, but don’t send enough mail to get any data back from Google. However, the nice folks at SendGrid were kind enough to share their experiences with me and show me what the site looked like with real data, when I spoke at their recent customer meeting.
Who can register?
Anyone can register for Google Postmaster tools. All you need is the domain authenticated by DKIM (the d= value) or by SPF (the Return Path value).
Who can see data?
Google is only sharing data with trusted domains and only if a minimum volume is sent from those domains. They don’t describe what a trusted domain is, but I expect the criteria include a domain with some history (no brand new domains) and a reasonable track record (some or all of the mail is good).
For ESPs who want to monitor all the mail they send, every mail needs to be signed with a common d= domain. Individual customers that want their own d= can do so. These customers can register for their own access to just their mail.
ESPs that want to do this need to sign with the common key first, and then with the customer’s more selective key.
How does it work?
Google collects data from DKIM and/or SPF authenticated mail, aggregates it and presents it to a Google user that has authenticated the domain.
How do I authenticate?

IPv6 Email is a little different

On Monday I talked about how big IPv6 address space is, and how many IPv6 addresses will be available to end users. We’re mostly an email blog, though, so what’s the relevance to sending email?
If the recipient you’re sending to has an IPv6 mailserver you can send mail to them over IPv6, if you choose to. If they only have an IPv6 mailserver, with no IPv4 mailserver at all then you have to send over IPv6 to reach them.
For a long time I was pretty sure that IPv6-only mailservers were unlikely to be an issue any time soon – as IPv6 rolls out end users will get IPv6 addresses, and that will free up a huge number of IPv4 addresses that can then be used where they’re more valuable, for webservers and mailservers. As I’ve watched IPv4 addresses run out and the rise of a secondary market I’m begining to think that hoarding may make IPv4 addresses effectively unavailable or prohibitively expensive for small companies and individuals in some regions. If so, then a few IPv6-only mailservers will encourage others to support sending and receiving email over IPv6, which will in turn make IPv6-only servers more viable.
And you might want to use IPv6 even if the recipient has a dual-stack IPv4+IPv6 mailserver. As one example, Gmail accepts mail on IPv6 – and scuttlebutt is that right now their IPv6 servers are somewhat more forgiving for properly authenticated email, which is interesting. And if you’re running short of IPv4 addresses yourself, routing all your gmail recipients over IPv6 instead might free up some capacity and save you from having to go IPv4 address shopping.
But there are a few things to know before starting to send over IPv6.
IPv6 to IPv4 fallback
If you turn on IPv6 support on a mailserver it is likely to prefer IPv6 when sending mail to dual-stack recipients. That’s great if everything is set up perfectly, but if your IPv6 network configuration is flakey, or your authentication is not good enough for IPv6 mail, or the recipient has an IPv6-specific configuration problem then your delivery over IPv6 might fail. How to choose an MX for delivery – and how to fall back to an IPv4 MX – isn’t terribly well defined so there’s some risk of delivery of a message failing repeatedly. You should check how your smarthosts handle this sort of delivery failure.
There’s no legacy IPv6 to support
There are twenty year old servers sending email over IPv4, so attempts to enforce better authentication both of mailservers and messages have moved very slowly so as not to disrupt mail from those old servers.
IPv6 is a whole new world, though. Any mailserver set up to send via IPv6 has been set up relatively recently and it’s much more reasonable to expect it’s operators to follow best practices (PDF). If you want to send mail to Google over IPv6 you have to have “good” reverse DNS, and you have to authenticate the mail you send with at least one of SPF or DKIM. Google are much less tolerant of violations of those requirements for mail sent over IPv6, more likely to mark messages as spam or reject them altogether compared to delivery attempts over IPv4.
What does “good” reverse DNS mean? The IP address you’re sending from must have reverse DNS that resolves to a hostname, and that hostname must resolve back to the sending IP address. (You’ll sometimes see that described as “FCrDNS”.)
One customer, one /64
As I mentioned on Monday a consumer end user should be allocated no less than a /64 of IPv6 space. If you’re in the IPv4 mindset of addresses being scarce and valuable you might decide that you don’t need to do that with your customers, maybe assigning each of them a/124 to send their mail through. 16 IP addresses is plenty, right?
A large hosting company did that recently, assigning each of their customers a small range of IPv6 addresses out of a single /64 – and they discovered why it’s a terrible idea. They had no more than the usual level of email delivery problems on IPv4, but all of their IPv6 mail was blocked at a lot of destinations. Because a /64 is the smallest recommended range to assign to a user it’s also the smallest quantum that reputation services and blacklists will block by. Bad behaviour by one of their customers got the /64 that customer was sending from blocked – along with all the other customers sending from other parts of that /64.
So don’t do that.