Office365

Deferrals at Microsoft

If you’re seeing a lot of “451 4.7.500 Server busy. Please try again later” from Office365 this morning you’re not alone.

Authentication at Office365

This is a followup from a post a few weeks ago about authentication changes at Office365. We have some more clarity on what is going on there. This is all best information we have right now.

A c/p from an email I sent to a mailing list.
I think we’re seeing a new normal, or are still on the pathway to a new normal. Here’s my theory.
1) Hotmail made a lot of underlying code changes, learning from 2 decades of spam filtering. They had a chance to write a new codebase and they took it.
2) The changes had some interesting effects that they couldn’t test for and didn’t expect. They spent a month or two shaking out the effects and learning how to really use the new code.
3) They spent a month or two monitoring. Just watching. How are their users reacting? How are senders reacting? How are the systems handling everything?
3a) They also snagged test data along the way and started learning how their new code base worked and what it can do.
4) As they learned more about the code base they realized they can do different and much more sophisticated filtering.
5) The differences mean that some mail that was previously OK and making it to the inbox isn’t any longer.
5a) From Microsoft’s perspective, this is a feature not a bug. Some mail that was making it to the inbox previously isn’t mail MS thinks users want in their inbox. So they’re filtering it to bulk. I’ll also step out on a limb and say that most of the recipients aren’t noticing or caring about the missing mail, so MS sees no reason to make changes to the filters.
6) Expect at least another few rounds of tweak and monitor before things settle into something that changes more gradually.
Overall, I think delivery at Microsoft really is more difficult and given some of the statements coming out of MS (and some of the pointed silence) I don’t think they’re unhappy with this.

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.

Troubleshooting and codes

Microsoft is still in the process of rolling out new mail servers. One thing that is new about these is some new codes on their error messages. This has led to questions and speculations as to what is going on.

Engagement filters for B2B mail

While I was doing some research for a client today I rediscovered Terry Zink’s blog. Terry is one of the MS email folks and he regularly blogs about the things MS is doing with Outlook.com and Office 365.
The post that caught my eye was discussing the Microsoft Spam Fighter program. The short version is that in order to train their spam filters, Microsoft asks a random cross-section of their users if the filters made the right decision about email. This data is fed back into the Microsoft machine learning engine.
As Terry explains it:

Microsoft changes

There’s been quite a bit of breakage and delivery failure to various Microsoft domains this month. It started with them changing the MX for hotmail.co.uk, then the MX for hotmail.fr… and both these things seem to have broken mail. I also saw a report this morning that some of the new MXs have TLS certificates that don’t match the hostnames.

Catching up from MAAWG SF

Had a great time a M³AAWG last week. So many familiar faces and a lot of new ones, too. I’ve got a lot of interesting stuff that I can share with readers over the next few days.
One of the things I have received permission to share is the new Office 365 IP delisting link. I botched the first time I posted it, so I’m going to try again. Office 365 IP Delisting Page. Many thanks to the Microsoft guys for getting this together for people.
While I’m talking about Microsoft, there is a bit of a problem with folks signing up with their FBL. Some people are finding that the process gets stuck and FBLs aren’t enabled. MS is aware of the issue and they are working on fixing it. As I know more I’ll share.
Unsurprisingly, authentication was a big topic of conversation, both in the hallways and in the sessions. There were some strong opinions stated. I think, though, that we’re pretty clear that we’re going to get to a more authenticated world. But we have some different opinions on how and how fast that’s going to happen.

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.

Filtering more than spam

The obvious application of machine learning for email is to send spam to the junk/bulk folder. Most services use some level of machine learning for filters. Places like Gmail have extensive machine learning filters to filter spam and unwanted mail away from their users.
Some organizations are taking the filtering process a step further. Almost every mail client more advanced than PINE has the ability for users to create rules to sort mail into folders. Late last year, Office 365 rolled out a feature, Clutter that tracks how a user interacts with mail and filters unimportant mail. This allows each user to have their own filters, but without the overhead of having to create the filters.
The Clutter engine looks at both how the user interacts with mail and things it knows about the organization. For example, if Exchange is tied into Active Directory, then mail from a manager will be prioritized while mail from a co-worker may end up in the clutter folder.
Email is a critical business tool. A significant number of companies rely on email for internal and external communication. Many users treat their inbox as a todo list, prioritizing what they work on based on what’s in their mail box. Despite the needs of users, the mail client hasn’t really changed.
Over the last few years, we’ve seen different online services attempt to build a more effective email client. Some of these features were things like tabs and priority inbox at Gmail. Microsoft created the “sweep” feature for Outlook/Hotmail users to manage inbox clutter. Third parties have created services to try and improve the mailbox experience for their users.
Many of the email filters, up to this point, have really been focused on protecting users from spam and malicious emails. Applying that filtering knowledge to more than just spam, but to the different kinds of emails makes sense to me. I’ve always had a fairly extensive set of filters, initially procmail but now sieve, to process and organize incoming mail. But I kinda like the idea that my mail client learns how I filter messages and do the right thing on its own.
I’d love to see some improvements in the mail client, that make it easier to manage and organize incoming email. It remains to be seen if this is a feature that takes off and makes its way to other clients or not.

April 2015: The Month in Email

We started the month with some conversations about best practices, both generally looking at the sort of best practices people follow (or don’t) as well as some specific practices we wanted to look at in more depth. Three for this month:

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”.

Office365 checking DMARC on the inbound

According to a recent blog post, Office365 is starting to evaluate incoming messages for DMARC. I talked a little bit about DMARC in April when Yahoo started publishing a p=reject message.