Ipv6
Gmail / Apps authentication issues
I’ve seen several reports of unexpected rejections for unauthenticated email to Google over IPv6 today. Unauthenticated mail over IPv6 is a bad idea, but Google usually spam folders it rather than rejecting it.
The Gmail status dashboard is reporting an issue “Some messages sent to consumer Gmail accounts are being rejected due to authentication enforcement” so something isn’t working as intended.
IPv6 and authentication
I just saw a post over on the mailop mailing list where someone had been bitten by some of the IPv6 email issues I discussed a couple of months ago.
They have dual-stack smarthosts – meaning that their smarthosts have both IPv4 and IPv6 addresses, and will choose one or the other to send mail over. Some domains they send to use Office 365 and opted-in to receiving mail over IPv6, so their smarthosts decided to send that mail preferentially over IPv6.
The mail wasn’t authenticated, so it started bouncing. This is probably going to happen more and more over the next year or so as domain owners increasingly accept mail over IPv6.
If your smarthosts are dual stack, make sure that your workflow authenticates all the mail you send to avoid this sort of delivery issue.
One mistake I’ve seen several companies make is to have solid SPF authentication for all the domains they send – but not for their IPv6 address space. Check that all your SPF records include your IPv6 ranges. While you’re doing that keep in mind that having too many DNS records for SPF can cause problems, and try not too bloat the SPF records you have your customers include.
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.
IPv6 is big
IPv6 is big. Really big. You just won’t believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it’s a long way down the road to the chemist, but that’s just peanuts to IPv6.
Read More
Office365/EOP IPv6 changes starting today
Terry Zink at Microsoft posted earlier this week that Office365/Exchange Online Protection will have a significant change this week. Office365 uses Exchange Online Protection (EOP) for spam filtering and email protection. One of the requirements to send to EOP over IPv6 is to have the email authenticated with either SPF or DKIM. If the mail sent to Office365/EOP over IPv6 is not authenticated with SPF or DKIM, EOP would reject the message with a 554 hard bounce message. Most mail servers accept the 554 status code and would not retry the message. After multiple 5xx hard bounces to an email address, many mail servers would unsubscribe the user from future email campaigns. The update starting today April 24, will change the error status code for unauthenticated mail to EOP from a 554 hard bounce to a 450 soft bounce and a RFC-compliant and properly configured mail server would then retry the message.
Prior to April 24, 2015, EOP responds to unauthenticated mail with a status code of: “554 5.7.26 Service Unavailable, message sent over IPv6 must pass either SPF or DKIM validation”.
The death of IP based reputation
Back in the dark ages of email delivery the only thing that really mattered to get your email into the inbox was having a good IP reputation. If your IP sent good mail most of the time, then that mail got into the inbox and all was well with the world. All that mattered was that good IP reputation. Even better for the people who wanted to game the system and get their spam into the inbox, there were many ways to get around IP reputation.
Every time the ISPs and spam filtering companies would work out a way to block spam using IP addresses, spammers would figure out a way around the problem. ISPs started blocking IPs so spammers moved to open relays. Filters started blocking open relays, so spammers moved to open proxies. Filters started blocking mail open proxies so spammers created botnets. Filters started blocking botnets, so spammers started stealing IP reputation by compromising ESP and ISP user accounts. Filters were constantly playing catchup with the next new method of getting a good IP reputation, while still sending spam.
While spammers were adapting and subverting IP based filtering a number of other things were happening. Many smart people in the email space were looking at improving authentication technology. SPF was the beginning, but problems with SPF led to Domains Keys and DKIM. Now we’re even seeing protocols (DMARC) layered on top of DKIM. Additionally, the price of data storage and processing got cheaper and data mining software got better.
The improvement in processing power, data mining and data storage made it actually feasible for ISPs and filtering companies to analyze content at standard email delivery speeds. Since all IPv4 addresses are now allocated, most companies are planning for mail services to migrate to IPv6. There are too many IPv6 IPss to rely on IP reputation for delivery decisions.
What this means is that in the modern email filtering system, IPs are only a portion of the information filters look at when making delivery decisions. Now, filters look at the overall content of the email, including images and URLs. Many filters are even following URLs to confirm the landing pages aren’t hosting malicious software, or isn’t content that’s been blocked before. Some filters are looking at DNS entries like nameservers and seeing if those nameservers are associated with bad mail. That’s even before we get to the user feedback, in the form of “this is spam” or “this is not spam” clicks, which now seem to affect both content, domain and IP reputation.
I don’t expect IP reputation to become a complete non-issue. I think it’s still valuable data for ISPs and filters to evaluate as part of the delivery decision process. That being said, IP reputation is so much less a guiding factor in good email delivery than it was 3 or 4 years ago. Just having an IP with a great reputation is not sufficient for inbox delivery. You have to have a good IP reputation and good content and good URLs.
Anyone who wants good email delivery should consider their IP reputation, but only as one piece of the delivery strategy. Focusing on a great IP reputation will not guarantee good inbox delivery. Look at the whole program, not just a small part of it.
World IPv6 launch day
Today is world IPv6 launch day. A group of ISPs, network hardware manufacturers and web companies permanently enabled IPv6 for their products and services.
What’s this got to do with email? According to a post on the NANOG mailing list the very first email to arrive at the Comcast IPv6 mailserver was received a minute after the server was turned on. This email was spam and was caught by Cloudmark’s filters.
Comcast goes on to assure readers that more mail came in and not all of it was spam.
But, yes, the first email sent to Comcast over IPv6 was spam. Welcome to the future.
Yes, we have no IP addresses, we have no addresses today
We’ve just about run out of the Internet equivalent of a natural resource – IP addresses.
Read More