Road Runner is no longer providing a FBL starting today. Earlier this morning a couple ESPs were reporting a decrease in FBL messages from the RR FBL. A few hours later, a senior technical account manager confirmed on mailop that the FBL was ending today.
While the announcement says that folks can expect reports to trickle, at least one ESP has reported zero reports today.
Thus ends 2 hours of rampant speculation, emails, and gossip among the deliverability community. We can all go back to work now.
The US National Cybersecurity Assessments & Technical Services Team have issued a mandate on web and email security, including TLS+HSTS for web servers, and STARTTLS+SPF+DKIM+DMARC for email.
It’s … pretty decent for a brief, public requirements doc. It’s compatible with a prudent rollout of email authentication.
- Set up a centralized reporting repository for DMARC failure and aggregate reports.
- Within 90 days, turn on opportunistic TLS, deploy SPF records, deploy DKIM and set up DMARC with p=none and an email address for reporting.
- Within 120 days, disable weak TLS ciphers.
- Within one year, migrate to p=reject.
The TLS requirements are sensible, and should be easy enough to roll out – and there’s likely enough time to work with vendors when it inevitably turns out that some servers can’t comply.
Best, it allows for a period of up to nine months of sending email with DMARC in monitoring-only mode with p=none. That, combined with a centralized repository for DMARC reports means that they should have enough visibility into issues to be able to resolve them before migrating to p=reject.
It all suggests a more realistic approach to DMARC timescales and issue monitoring during rollout than many organizations have shown.
They also have one of the clearer layman introductions to email authentication I’ve seen at https://cyber.dhs.gov/intro/.
Much of the content is well worth borrowing if you’re planning your own authentication upgrades; it’s all released CC0 / public domain (and the markdown source is at github).
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.
host outlook-com.olc.protection.outlook.com [18.104.22.168] said: 550 5.7.1 Unfortunately, messages from [10.10.01.01] weren’t sent. Please contact your Internet service provider since part of their network is on our block list (AS3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
This particular error code caused all sorts of confusion because AS#### is a way of identifying networks (autonomous system number). AS3150 identifies network space owned by NTT America and reading the error message seems to indicate that Microsoft is blocking all of NTT. They’re not.
AS means “Anti-Spam” and the numeric code is for Microsoft to troubleshoot things on their end.
Another example of one of the new error messages is:
451 4.7.500 Server busy. Please try again later from [<ip-address>]. (AS843) [<someserver>.prod.protection.outlook.com]
There appear to be a number of these codes. I’ve seen specific mention of codes like AS3140, AS3160 and AS844. All of these are intended for internal use at Microsoft. If you’re filling out the sender support form, absolutely include that number. I don’t know for sure that it will help speed things up, but it cannot hurt. Plus, you’ll look like you know what you’re talking about if/when you need to escalate things.
A number of senders have asked if MS will be sharing what the different codes are. I haven’t seen any answer other than “they’re for internal troubleshooting.” That doesn’t mean they won’t be listed specifically, but I expect updating the postmaster website documentation is low down the list of things to do during the transition.
In any case, I wouldn’t focus on the specific AS codes for delivery troubleshooting until and unless MS releases them to the public. Focus on the codes that are public on the Postmaster website.
- Hotmail / Outlook / Microsoft isn’t blocking NTT America / AS3150.
- The new AS codes stand for AntiSpam
- The numbers are intended for internal, not external, troubleshooting
- Check the postmaster site for the codes intended for external troubleshooting.
One of the things I hear frequently is that folks really want access to Google Postmaster Tools through an API. I’ve also heard some suggestions that we should start a petition. I thought a better idea was to put together a survey showing how people are using GPT and how high the demand is for an API.
They’re a data company, let’s give them data.
I’ve put together a survey looking at how people are using GPT. It’s 4 pages and average time to take the survey is around 7 minutes. Please give us your feedback on GPT usage.
I’m planning on leaving the survey open through the first week in November. Then I’ll pull data together and share here and with Google.
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:
These votes from all the users across the entire Spam Fighters program are combined, and the messages combined to create a corpus, and then Smartscreen learns across numerous features within a message – sending IP, sending domains, authentication status, headers, body of message, attachments, encodings, and so forth. This feeds into our IP reputation, and into the Smartscreen spam filtering algorithm. This algorithm is what does the filtering for spam, malware, and phishing as well as legitimate email. It’s updated multiple times per day.
The SmartScreen filter is a source of pain for many senders. But, Microsoft checks it’s accuracy on an ongoing basis. When Microsoft says that SmartScreen data tells them this mail is unwanted, they are getting that information directly from the subscribers of the email. If the subscribers don’t want mail, it’s nearly impossible to get ISPs to deliver that mail.
Engagement based filtering is standard in the consumer space. The primary mailbox providers focus on providing their users with the mail that they want, while protecting them from malicious mail. Things are different in the business space as most business filters don’t care if the user engages with the mail or not. For businesses email is a tool and sometimes we don’t like our tools.
However, as Microsoft merges the backend for Hotmail/Outlook and Office365 engagement filtering may become more relevant at those domains hosted on Office 365. I don’t expect those filters to be identical – again these are different user bases with different priorities. But Smart Screen filters may start acting on business email in the future.
Our first real company purchase was a big. solid pair of desks. See, we owed a lot of money to the IRS, but if we bought some equipment we could decrease the amount we had to pay the IRS. So we invested in very nice, wooden desks that would hold heavy CRT monitors.
Things have changed over the years and we don’t have CRTs any more. And maybe it’s time to upgrade or replace our desks. We got my desk assembled this weekend and I have to say, I’m really pleased.
Steve wrote about our experiences Autonomous.ai‘s purchase process. I have to say I’m impressed with the build quality of the desks.
I’ll be happy when our office is rebuilt and everything is back in its place, but even now I’m enjoying working at my new desk.
Happy October! ‘Tis the season for “the scariest costumes to wear to an inbound marketing Halloween party”. Terrifying, right? A perfect occasion for spam-infused mai tais!
In other news from the blog in September, I wrote several posts about the Equifax breach, starting with the announcement of the compromise on September 7th and their utterly inadequate response, followed by more incompetence when they sent people to the wrong site to get assistance. I also noted some of the discussion around the various educational paths people working in information security have and why these are the wrong questions to ask.
Speaking of the various paths people take towards careers in email, I wrote a followup post on Shiva Ayyadurai, whose defamation suit around his claims to being the inventor of email was recently dismissed.
I wrote a few posts about Gmail, including a guide to improving Gmail delivery, and some specific advice on how to warm up your Gmail mailstream, which is somewhat different than other warmup processes. In other news on mail providers, it’s worth noting some recent changes Microsoft has made to various domains.
In best practices, Steve wrote about a nice series of emails we received following an online purchase and I wrote about properly monitoring your DMARC reports.
Every now and then, I like to return to the basics. My post on 10 Things Every Mailer Must Do is a handy overview to share with your team (or your customers, if you’re an ESP). If you’re having delivery challenges and haven’t tackled these top ten best practices, this is where you need to start. I wrote up some additional thoughts on how we think about deliverability that you might find useful as well.
Had an all too short trip to M3AAWG. It was great to see old friends and meet new folks. I have lots to talk about and a poll to get into the field once I get caught up on client work.
While I’m deep in the depths of my inbox, I thought I’d share a bit of insight into the question of new domain vs. subdomain that often comes up.
I can’t stress this enough. subdomain.example.com can/should/will inherit things like reputation and history and other good (or badness) from example.com, where as somethingnew-example.com starts at ground zero and looks suspect/phishy/killit with fire to anti-abuse eyes. I can’t tell you how badly my kill it with fire instinct was twitching when I saw the Equifax breach domain name. Guy who Writes the Filters at an ISP you Know.
Equifax’s domain choice was so bad their own customer support folks were sending concerned consumers to the Wrong Domain. DNS is a hierarchy. Use it!
Subdomain. Always subdomain. ALWAYS. A different ISP rep said much the same recently – subdomains inherit some reputation from the parent domain.