Terry Zink: Security Talk

I’m currently doing a bunch of work around making Outlook.com better, and one the things I’ve noticed is different is how you add to your Safe and Blocked senders list when you use a desktop client like Outlook, vs. when you use the web UX in either Outlook.com (our consumer email product) or Outlook Web Access (for your Office 365 account).

Outlook + Office 365

In Outlook, if you right-click on a message, or click the “Junk” option at the top, you have several options:

You can add to your Blocked and Safe senders list by picking one of those first three options. If your organization uses Directory Sync, this is pushed to Office 365 and then your list is respected by the service. Blocked senders go to your Junk folder, Safe senders are delivered to your inbox.

These right-click and drop-down actions are available regardless of whether or not the message is in the Inbox, or in the Junk Email folder.

Outlook.com

The situation is different in Outlook.com. In Outlook.com, if you are in the Inbox, there is no option for “Block sender”. There is only the option to mark as Junk or Phishing along the top status bar:

2017-01-31-outlook-dot-com-top

Or if you right-click, you can pick Mark as Junk, or select Move > Junk Email:

There isn’t currently a single-click option to add to the Blocked senders list. To do that:

First, you have to move the message to Junk using one of the options above
Second, navigate to the Junk Email folder. The option to “Block” will along the top status bar

Adding to Blocked senders in Outlook.com deletes messages from that sender instead of delivering them to Junk the way it does in Office 365. So beware – if you subscribe to a newsletter or get a message from some other sender, and you block them and then forget you did, you will be wondering why you’re not getting email from that sender.

The option for adding to Blocked Senders is to do it manually. You’ll need to copy the sender address you want to block, and then select the gear icon along the top, and then select Options:

Then navigate to Mail > Blocked senders and paste it in (or type it in).

Using Blocked senders isn’t that effective at stopping spam because most spammers will use throwaway email addresses; thus, what you add to your list will probably not stop the next spam attack. However, blocked senders does work well on some sketchy newsletters that you don’t want to hear from as long as they have a stable sending address. And it also works on some people you know that you don’t want to hear from either.

For spam, the best way to have it stop is to report it, per above. That goes into our automated training system so it can learn to recognize current and future spam attacks.

Outlook Web Access + Office 365

The web UX for OWA looks the same as Outlook.com, however, it behaves the same was as Outlook + Office 365. That is, adding to blocked senders sends the message to your Junk Email folder.

Outlook + other email services

What about Outlook + other email services?

I haven’t tested it so I’m not sure, but I think adding to Safe and Blocked senders will send those messages to your Junk Email folder. They don’t get synced to a free email service (e.g., Gmail, Yahoo Mail) so any blocking would be done in Outlook.

So, that’s how managing Safe and Blocked senders using Outlook or the web UX works in Outlook.com vs. Office 365.

I’ve been quiet on this blog for a couple of weeks, and that’s because I’ve been helping out addressing some of the spam complaints in Outlook.com.

The biggest issue we’ve seen recently is spam from invalid senders. This is an email where the From: address is not RFC compliant, and does one of two things:

It gets to the inbox, polluting user experience
.

It goes to Junk, but when a user goes to block it, they can’t. Instead, they get the following error:
.

There are all sorts of example malformed From: addresses like:

From: =?UTF-8?B?Q2Fz?==?UTF-8?B?aW5v?= <"<?<SK3OF@alt2.woanager.com>?>">

From: "CVS Reward Giveaway " <"<?<infofzhVqwg@mailin.shawbals.com>?>">

From: "CVS Reward Giveaway " <"<?<infoNKKWCGk@msgin.ejnerpa.com>?>">

From: Family Survival <"<info.rnK3ZXkAUDeI@trot-pulldown.shapesfarm.com>"@-->

The list goes on an on.
.

We had some issues with some of our feedback loops but they have been fixed. This now sends most of these types of messages to Junk. However, there are still some other spams that leak through due to spammers fast-adapting their sending IPs and message content.

Upon investigation, it turns out that mail systems send email in many, many, many different ways. Some include Display Names, some don’t. Some include angle brackets around the email address, some don’t. Some even reverse the email address and Display Name:

From: sender@example.com (John Doe)

I didn’t even know that was a thing.

So, for the past several days I have been furiously hard at work coming up with some validation of an email address. This is first getting rolled out as a series of rules, and then will be done in code. I’ve borrowed liberally from Wikipedia’s definition of an email address, but not matched it completely. Here are the guidelines (these are not difficult to adhere to, 99+% of valid email does):

A From: address must contain an email address, and the email address must contain a valid localpart@domain.

For the localpart:

A localpart MUST start with letters A-Z, or digits 0-9
.
A localpart MUST end with letters A-Z, digits 0-9, the underscore _, a dash -, a plus sign +, or an equal sign =
.
The middle characters may be letter A-Z, digits 0-9, or almost any special character (ampersand, tilda, dashes, semicolons, etc.) except the double quote
.
The dot character . may not be repeated sequentially in the localpart
.
If including double quotes, it may only be the first last and last characters in the localpart, e.g., “sender”@
.
The one exception is a phone number, in which case it should have a leading plus sign, e.g., <+15552032212@example.com>

For the domain:

A domain MUST start with letters A-Z, or digits 0-9
.
A domain MUST end with letters A-Z, or digits 0-9
.
For the middle characters, it may contain letters A-Z, digits 0-9, dot ., or dash -, provided there are not two dots in a row
.
Or, it can be an IP address literal, e.g., sender@[123.123.123.123]
.

If you’re including a Display Name, it is strongly recommended to do the following:

If including a Display Name, put angle brackets around the email address, From: John Doe <sender@example.com> and not From: “John Doe” sender@example.com
.
Put a space between the email address and the Display Name, From: “John Doe” <sender@example.com>, and not From: “John Doe”<sender@example.com>. I cannot emphasize this enough!
.
Don’t put a space between the angle brackets in the email address, so not this: From: “John Doe” < sender@example.com>
.
Don’t get fancy with double quotes. If using them, put them around the Display Name. Putting them into the email address may cause parsing issues
.
Display Names encoded in base 64 are fine

If you don’t, we may not be able to figure out the email address. That may cause problems.

Over the past two months, I have taken on a role to deal with deliverability and user complaints for Outlook.com (Hotmail). The main areas of focus are reducing user spam complaints, and helping to streamline the process for senders when they get blocked from delivering to Outlook.com. This includes fixing bugs in the spam filtering process, but also fixing bugs in the SNDS portal.From time to time, people ping me and ask to get unblocked from Outlook.com. The majority of senders know the existing process (probably better than I do!) but here’s how it works.

I’m going to try to give enough information to be helpful, but not so much as to give too many clues to malicious senders about how to get around the process.

We consider it our primary responsibility to protect our users from spam, malware, and phish

Outlook.com has multiple filters including sender IP reputation, content filtering, machine learning (Smartscreen), feedback loops, and user personalization. When senders exceed a threshold in parts of those categories, they get blocked. This is in order to protect the service because Outlook.com is under attack from spammers every single day.

However, we understand that sometimes legitimate senders get caught up in our filters. That is why we offer a variety of Support tools.

a) Outlook.com expects senders to self-service and use these tools, and it is up to senders to ensure that they have best sending practices. They can use the Hotmail/Outlook.com SNDS portal to measure their deliverability: https://postmaster.live.com/snds/index.aspx?wa=wsignin1.0
b) There are third party organizations that can help in deliverability. One is the ReturnPath Sender Score Certified which helps in deliverability when on their good IP list. Another is 250 OK and while they don’t have an IP reputation list, they do help you manage complaints and bounces. Driving those down usually helps in delivering to all receivers, including Outlook.com.

There may be others but I can’t think of them off the top of my head. We may also add more good IP reputation lists in the future.

c) For Office 365 customers, make sure you set up SPF, DKIM, and DMARC. For senders using Exchange on-premise (not Office 365) to send out email, I recommend that they install DKIM to add digital signatures to their outbound email. There is a DKIM agent for Exchange on GitHub, I haven’t used it but several other Exchange customers have and it works for them. https://github.com/Pro/dkim-exchange.

For all others, make sure your SPF, DKIM, and DMARC records are properly configured using whatever setup and infrastructure is supported.

This doesn’t guarantee delivery. But it can help (it certainly doesn’t hurt).

So what happens when you create a support ticket?

We understand that when senders create support tickets, they just want one thing and one thing only – to get unblocked. Or, sometimes people say “How do I get whitelisted at Hotmail?”

The answer is: There is no way to get whitelisted. Everyone goes through the same process. Even internal teams at Microsoft that want to send to Outlook.com have to do it. Even if you get on the ReturnPath IP reputation list, user personalization might still send messages to Junk.

You must create a support ticket using the SNDS/Postmaster portal to troubleshoot delivery. You can email me saying “Terry, my IPs are blocked! Help!” I’ll reply back saying “Please create a support ticket in the SNDS portal.” Everyone has to do that, even internal teams at Microsoft.

The Support process has multiple layers; there is some automation, a couple of layers of higher Tier Support, and then finally some Product Team support when required. Because of the overwhelming volume of support requests, and the fact that there are lots of spammers that try to game the support process, this is why we push so hard for people to use the self-service tools (the SNDS portal).

Once it gets through the support process, IPs are either approved for temporary blocking or throttling mitigation (i.e., IPs that were blocked will no longer be blocked [temporarily; if they generate poor reputation after a time limit they will get blocked or junked again]), individual sending limits may be lifted, or the request may be denied. I won’t go into the rationale for each of the decisions, but suffice to say, the Support folks do a good job such that we can scale the service given the volume of requests we receive.

That’s a brief overview of the Outlook.com sender support process. Hopefully you find it useful.

One of the problems with DMARC is how mailing lists deal with participants that publish p=reject records. The domain owner has published a policy to prevent spoofing, but all of the various participants on the mailing list may be affected. This includes people within an organization that previous were taking part in technical discussions, but suddenly find themselves unsubscribed, or seeing all of their messages going to Junk. Why does this happen?

Suppose that someone, John Doe , is on a technical discussion list. He is discussing Internet of Things Security, and the mailing list owner relays email from security-iot.org. When John sends to the discussion list, he sends an email this way:

SMTP MAIL FROM: <joe@example.com>
From: John Doe <joe@example.com>
To: Internet of Things Security
Subject: How are we going to deal with this?
DKIM-Signature: d=example.com

What's the latest on the next big vulnerability?

John is completely unaware that his messaging admin has set up DKIM-signing on his mail server. He just knows that he participates in a mailing list. The mailing list receives the message, and if it just ended up in the mailbox lists@security-iot.org, it would look like this:

Authentication-Results: spf=pass (sender IP is xx.xx.xx.xx)
 smtp.mailfrom=example.com;
 dkim=pass header.d=example.com;
 dmarc=pass action=none header.from=example.com
From: John Doe <joe@example.com>
To: Internet of Things Security
Subject: How are we going to deal with this?
DKIM-Signature: d=example.com

What's the latest on the next big vulnerability?

But, the message doesn’t stay there, it gets relayed out to the rest of the mailing list participants. The mailing list does many things to the message – it re-signs the message with a new DKIM-signature, it adds a footer to the message, and modifies the subject:

SMTP MAIL FROM: <lists@iot-security.org>
 From: John Doe <joe@example.com>
 To: Internet of Things Security <lists@iot-security.org>
 Subject: [Internet of Things Security Discussion] How are we going to deal with this?
 DKIM-Signature: d=security-iot.org
 DKIM-Signature: d=example.com

What's the latest on the next big vulnerability?

----------------------
 To unsubscribe from this list, click here: http://unsubscribe.example.com

When the message is replayed back to John, both SPF and DKIM pass. However, SPF passes with the mailing list’s domain, and DKIM passes with the mailing list’s DKIM-signing domain. The original DKIM signature from d=example.com no longer verifies because the message contents have been modified.

Since the domain in the From: address example.com does not align with either the domain that passed SPF (security-iot.org) or DKIM (also security-iot.org), it fails DMARC back at Joe’s email server:

SMTP MAIL FROM: <lists@iot-security.org>
 Authentication-Results: spf=pass (sender IP is yy.yy.yy.yy)
 smtp.mailfrom=security-iot.org;
 dkim=pass header.d=security-iot.org;
 dkim=fail (body hash failure) header.d=example.com;
 dmarc=fail action=none header.from=example.com
From: John Doe <joe@example.com>
To: Internet of Things Security <lists@iot-security.org>
Subject: [Internet of Things Security Discussion] How are we going to deal with this?
DKIM-Signature: d=security-iot.org
DKIM-Signature: d=example.com

What's the latest on the next big vulnerability?

----------------------
To unsubscribe from this list, click here: http://unsubscribe.example.com

As long as the DMARC policy is p=none, nothing bad happens [1]. John gets all his email from the mailing list.

The problem occurs when John’s messaging admin updates the DMARC policy from p=none to p=quarantine, and then the problem becomes even worse when the policy is p=reject.

Why?

Because when the policy is p=quarantine, then every message that John sends to the list will fail DMARC when it is relayed back to other receivers. That means all of poor John’s email will end up in the Junk folder of all these destinations (unless the recipient keeps hitting “This is not spam” or adds John to a safe senders list).

When the policy is p=reject, then John’s messages are no longer getting sent to Junk. Instead, they are getting rejected by the receiving email server. There is no chance for any recipient to add John to a safe sender or hit “This is not Junk”, it just bounces back to the mailing list server. And, worse yet, some mailing lists will keep track of which sender email is causing all of these bounces and will unsubscribe John from their mailing list.

The net result is that John can’t send emails to mailing lists.

The admin is trying to control phishing and spoofing, but poor John has been caught in the cross-fire.

A way forward

The official way that the industry is trying to resolve this is with a new protocol called ARC – Authentication Received Chaining. I’m not going to discuss that here. Instead, I’m going to talk about a quick and immediate fix.

If the mailing list server wants to avoid DMARC bounces like this, all it needs to do is rewrite the From: address. Instead of relaying the From: of the original sender, do some creative rewriting and send with the From: belonging to the mailing list:

SMTP MAIL FROM: <lists@iot-security.org>
From: "John Doe via Internet of Things Security mailing list" <lists@iot-security.org>
To: Internet of Things Security
Subject: [Internet of Things Security Discussion] How are we going to deal with this?
Reply-To: john.doe@example.com
DKIM-Signature: d=security-iot.org
DKIM-Signature: d=example.com

In this example, the mailing list now sends from itself as the general From: address, puts the user’s Display Name (and its own name) into the Display Name, and the original sender email address has been retained in the Reply-To address. This works for many people, although some email clients only send to the Reply-To address when you hit “Reply” or “Reply All” which is not what you want, you want to reply to the list and not the original author. That’s an easy enough workaround, just copy/paste the From: address into the To: field when replying. Or, as a list maintainer, drop the Reply-To.

Some list maintainers say that this messes up address books, since you’ll have multiple Display Names associated with a single From: address (lists@security-iot.org) if everyone’s name is inserted into the From: address. The workaround for this is to hash the original email address and include it into the email address:

SMTP MAIL FROM: <joe@example.com>
From: "John Doe via Internet of Things Security mailing list" <am9obi5k+lists@iot-security.org>
To: Internet of Things Security <joe@example.com>
Subject: [Internet of Things Security Discussion] How are we going to deal with this?
Reply-To: john.doe@example.com
DKIM-Signature: d=security-iot.org
DKIM-Signature: d=example.com

I created the above by encoding john.doe@example.com and converting it to Base64, taking the first 8 characters, and putting it in front of a + sign in the localpart of the email address. That gives everyone a unique sending From: address so as not to collide multiple Display Names on a single email address.

This lets senders with strong DMARC policies to sign up to your mailing list. They can still relay to receivers because the DMARC check is done against your domain in the From: address, and you control both the SPF, DKIM, and DMARC policies. Everything is under your control, an administrator of a 3rd party domain doesn’t need to be aware of which of their users are on mailing lists, and a user notices no change (almost no change).

SMTP MAIL FROM: <lists@iot-security.org>
 Authentication-Results: spf=pass (sender IP is yy.yy.yy.yy)
 smtp.mailfrom=security-iot.org;
 dkim=pass header.d=security-iot.org;
 dmarc=pass action=none header.from=security-iot.org
From: John Doe <joe@example.com>
To: Internet of Things Security <lists@iot-security.org>
Subject: [Internet of Things Security Discussion] How are we going to deal with this?
DKIM-Signature: d=security-iot.org
DKIM-Signature: d=example.com

What's the latest on the next big vulnerability?

----------------------
To unsubscribe from this list, click here: http://unsubscribe.example.com

You can see it all passes from a security perspective. The user is happy, email receivers are happy, and the mailing lists are… a little less happy than they were before because they had to do some extra work… but are happy to get things working.

Conclusion

This is how I would run a mailing list server if it were up to me because it allows senders with p=reject DMARC records to sign up, and is relatively quick to deploy.

The DMARC.org maintainers have a DMARC FAQ and this is covered in more detail with specific implementations. It’s available here: I operate a mailing list and I want to interoperate with DMARC, what should I do?

[1] If sending to Office 365, it’ll get marked as spam with a red safety tip. So, Office 365 treats email “from” yourself “to” yourself as if you have a DMARC p=quarantine record regardless of if you have one published or not. It has the same issues with mailing lists, see https://blogs.msdn.microsoft.com/tzink/2016/11/02/troubleshooting-the-red-suspicious-safety-tip-for-fraud-detection-checks/

Recently in Outlook.com, I’ve seen a spurt of user complaints that they are adding senders to the blocked senders list, but keep getting spam from the same sender day after day.

I did some investigation.

First, adding spammers to Blocked Senders isn’t the best way to stop spammers from sending you unwanted email. Spammers randomize the sending addresses and so adding them to the blocked senders list stops yesterday’s spam, but it doesn’t stop tomorrow’s spam from a different sender with the same content. The best way to stop spam is to report it as Junk (see here: The difference between adding safe and blocked senders in outlook vs outlook-com).

However, in some circumstances it makes sense to add to Blocked Senders, and that’s when the From: address is consistent and doesn’t change.

So why is it that sometimes adding a sender to Blocked Sender doesn’t get stopped in the future from the same one?

We recently made a change to the user interface for managing blocked senders. To get there from Outlook.com’s web interface, select the Gear icon > Options > Mail > Junk email > Blocked senders. We added a line of text that you can add a maximum of 1024 blocked senders and 1024 blocked domains:

What happens is that when a user populates their blocked senders or domains list to full, when they try to add more, the UX fails silently. That is, the blocked sender doesn’t get added, and the user is not notified. Thus, the user thinks they are adding more blocked senders, when in fact they are not. Scrolling through the blocked senders list would confirm this.

We are fixing this behavior such that when the blocked senders list is full, when you try to add more (either through the management page shown above, or from the Junk Email folder), you’ll get a notification indicating that the list is full and you’ll need to remove some before you can add more.

I don’t have an ETA on the fix, but it has our attention.

Some technical stuff

One reason why the behavior is like this is because it’s rare for users to fill up their blocked senders list. Like I said, the right way to stop spam is report is as Junk. For the most part, a user adds and adds and adds to their blocked senders list, but it doesn’t matter because the spammers randomize their sending addresses. It’s only when a spammer sends with the same sender does a user with a full blocked senders list matter.

Adding to the blocked senders list is an asynchronous operation. That is, when a user clicks “Block”, it is not instantaneously added. Instead, the front end makes a request to the backend, but doesn’t wait for it to complete. If it did, the user would click “Block” and then have to wait for the update to complete before being allowed to proceed. We don’t want to do that, we want the “Block” operation, from the user perspective, to be seamless.

But because it’s asynchronous, we didn’t have a good way to communicate back to the user that the operation failed. We’re not going to make it blocking, but instead will do a hybrid approach where we can communicate instantaneously back to the user when their blocked senders list is full, and also do it without the user having to wait and wait and wait while the transaction completes.

Hopefully that will help.

One of the problems that some of our users have been experiencing in Outlook.com is using the “You can unsubscribe” widget:

The widget above shows up when we think the message is bulk, and the message contains a List-Unsubscribe header, and that header contains a mailto. We parse out the mailto and send a message to the address, unsubscribing you from the list. If the List-Unsubscribe header only has a http link, we do not show the widget. If it has both a mailto and a http link, we still only parse out the mailto.

One problem users experienced around this widget was when the List-Unsubscribe header was malformatted:

List-Unsubscribe: < mailto : bulk@example.com >

In the above, it’s intuitive to you and me what the email address is, but there are spaces in the middle of the mailto link. This was causing parsing issues and leading to users getting weird bounces in their inbox.

We’re fixing this problem. We’re making the email address parser more robust so that it more intelligently extracts the email address and is less prone to failure. Just like how spammers were malformatting the From: address, bulk senders (not spammers in this case) were malformatting the List-Unsubscribe. In each case we had to make our parsers smarter, so that the widget does what users expect it to.

This change should be released in the next couple of weeks.

A few of you may be curious why we don’t support the http part of the List-Unsubscribe header. There are two reasons:

Not all List-Unsubscribes are single click. Some of them go to a page and then force you to click another box, or click several boxes to “manage your subscription”, and so following that http link may not actually unsubscribe you from the newsletter since we don’t click around on the page after we would follow the link. Thus, you’d be unsubscribing but not actually having anything result from it.
.
The geeky second answer is that it would be a synchronous operation. That means that you’d click the link, we’d spin up another web window in the background and block you from doing an action until the click succeeded before we could message back to you whether or not it succeeded. That can happen in web pages that resolve slowly, or not at all. That’s an unacceptable user delay, we’d take all the heat for the UX responding slowly, even though it’s the newsletter’s back end that is not responsive.The fix for this is to make it asynchronous, that is, not blocking. You’d click and then in the background we follow the link and the “session” would be closed.
.
Then, we’d have to find a way to notify you that the operation succeeded or failed. That sort of thing is possible, but it requires some design to get it working.

That’s the rationale.

It turns out that for #1, there is a new Internet standard, RFC 8058 – Signaling One-Click Functionality for List Email Headers. It became a standard just this past year, in January 2017. This solves the problem in #1 by adding an additional header to signal to the web UX that following the http link in the List-Unsubscribe header is a single click action, so web UX widgets can safely use that and the action will be what the user expects.

For #2, that still requires some engineering effort. I’ve asked our team to look into it, but I don’t have a timeline on it just yet.

In Outlook.com, occasionally we get a complaint from a user saying that a message is in their Junk Email folder even though the message’s sender is on their Safe Senders list. After all, if it’s on the Safe Senders list, shouldn’t the message go to the Inbox?While this can happen with any user, it usually occurs most often for people who have Exclusive Mode turned on in Outlook.com (Options > Mail > Junk Email > Filters and reporting > Choose a junk email filter [Standard/Exclusive]), which sends all messages to the Junk folder unless it’s on your Safe Senders list. This keeps your mailbox clear of all senders whom you are not already familiar with.

While on the one hand this keeps it free from spam, it also means that you may have false positives. To reduce false positives, it means managing a reasonably large contacts list.

Normally, senders on your Safe Senders list do go to your Inbox. However, there are some domains that are managed by Outlook.com that are frequently targeted for spoofing. If a message comes from that domain and it fails authentication, the safe sender is not respected. This is to prevent a spammer from spoofing one of your contacts and getting a free pass to the Inbox. Since the message is not authenticated, it goes to your Junk folder even though the sender is on your Safe Senders list. But since we can’t trust the sender, and this domain is frequently spoofed, we treat it as if they aren’t on your Safe Senders list.

That’s why it goes to Junk.

The reason why there is confusion is because normally when a message in Outlook.com fails authentication, you’ll see the red Safety Tip that the sender failed the fraud detection checks:

However, in Exclusive mode, you see the yellow safety tip about only accepting email from your Safe Senders list. There is no explanation that it failed authentication and therefore Safe Senders were not respected.

So that’s why sometimes a message on your Safe Senders list still goes to the Junk folder. And, while it occurs most frequently for users with Exclusive mode, it can also occur to users in Standard mode for a safe sender if the message fails authentication.

* * * * * * * * * *

Now, I realize that this safety tip in Exclusive mode could give more information. So, I’m pushing internally to change the yellow safety tip about “Safe Senders only” to the red safety tip about the sender failing fraud detection checks. That should hopefully give more clarity about why the message is in the Junk Email folder.

Over here in Outlook.com (and Office 365), we hate spam (and phishing, and malware). We’re doing everything we can, every single day, to keep it out of your Inbox.But we know that there are many of you out there as well that also hate spam as much as we do, and that’s where the Spam Fighters program comes in.

Most of you reading this will have no idea what this “Spam Fighters” program is. So, for those of you who don’t know what it is, and the few of you who do, here’s a rundown.

You may already be familiar with Smartscreen, the spam filter that powers Outlook.com but also is used in other Microsoft products like Edge (the new web browser in Windows 10). Smartscreen works by machine learning, and it’s been machine-learning before the term “machine learning” was a buzzword in the industry.

In order for Smartscreen to be both predictive and effective, it has to learn on a corpus of good and bad email. While we can always find sources of spam (through honeypots and user feedback reports), it can be difficult to acquire a corpus of good email. That’s where the Spam Fighters program comes in.

The Spam Fighters program asks a random sample of users in Outlook.com if they’d like to volunteer to help fighting spam. These invitations are sent periodically, and they are randomly sampled in order to get a good cross-section of users. If you agree, then each day at most we’ll send you a copy of an email that was meant for you and ask you to grade it – Is it spam? Or non-spam?

This is all down-sampled from your own email stream, you aren’t looking at anyone else’s email. You take a look at it, and vote on what you think it is. There is a little wrapper at the top of the message that contains a banner letting you know what the message is, the voting buttons, and then the Not junk and Junk buttons.

Below is an example:

These are all messages that were already sent to you, they are not held up waiting for you to vote.

When you do vote:

First, your choice of spam or non-spam is record for that particular message
.
Your choice is then compared to what the spam filter said for that message when it was scanned through the filter:
.
a) Did you say it was spam and the filter agreed? Then everything is good
b) Did you say it was non-spam and the filter agreed? Then everything is good
c) Did you say it was spam but the filter said it was non-spam? Then we have a false negative (missed spam)
d) Did you say it was non-spam but the filter said it was spam? Then we have a false positive (good email classified as spam)
.
Your vote is then compared against the votes of all other users receiving similar email. Does everyone overwhelmingly agree with you? Or disagree with you? Or are the votes split up?

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.

So, by participating in the Spam Fighters program and voting on a regular basis, you really are helping to fight spam, and your vote counts!

Your email is downsampled and the Spam Fighter vote only happens at most once per day, but it also depends on your email stream so it may not happen every day. But the key point to remember is that machine-learning depends on random sampling.

This means that even though your email is downsampled, Spam Fighter voting does not keep a history of the previous message that was sent to you. Thus:

It is entirely possible that you may get two similar, or even identical messages, in a row. Or more.
..
We’re not asking for you to vote on messages because we don’t know whether or not it’s spam. Sometimes we do know, sometimes we don’t. Rather, we’re building a cross-section of email that is representative of the entire user base, and using that to train on a corpus of labeled messages..
.
Similarly, it’s entirely possible that legitimate messages will end up in the Spam Fighters program, asking you to vote on it. “Don’t you know that’s my Amazon newsletter?” Or “This is a message from Microsoft! How can you not know whether or not your own email is spam or not?!” But here again, we’re looking to learn from a representative section of all email, legitimate or not, bulk or not, newsletter or not, transactional or not, or whether it’s from Microsoft or not. It’s important that even newsletters get into the training system.
.
Remember that machine learning is based upon random sampling, and by artificially bumping up or down certain types of messages, that changes the way the filter operates and makes it less accurate in the future..That’s also why you can’t volunteer for the program. Users in it are selected at random, and participation is entirely voluntary. You can opt-out at any time by clicking the “stop participating” link in the email (although you can also just ignore the email from time to time if you’re busy but still want to participate in the fight against spam). You really are helping.
.
When you vote Spam or Not spam, this is not directly tied to the equivalent message in your Inbox. That is, if a spam is in your Inbox and you get a Spam Fighter email that sampled that exact spam, clicking “Spam” in the Spam Fighter email doesn’t report the message as spam back to us, nor does it add to Blocked Senders, nor does it move the original message out of your Inbox and into Junk Email if you hadn’t yet moved or deleted it (the reverse is also true for clicking “Not spam” if the message was originally detected as spam).
.
Instead, your vote is recorded and used as an input for future messages. In order for you to rescue a message (for false positives) or remove it from your Inbox (for missed spam), you’ll need to use the regular UX tools.

That’s an overview of the Spam Fighters program in Outlook.com. For those of you involved in it, we thank you for your participation.

There’s a lot of ambiguity about the term “sender” when talking about the sender of an email. What do we mean?

The term is overloaded because there are so many possible “senders” of a message. Here’s the most commonly used terms and how they show up in various email clients:

1. The From: address in the message headers
.
This is the email address you see in your email client, and it’s the one that DMARC protects. It’s also the one that Office 365’s antispoofing works on, too (see http://aka.ms/AntispoofingInOffice365). When you hit “Reply” in your email client, this is who the recipient will be with the exception described in #4.
..

2. The SMTP MAIL FROM
.
This is the Return-Path, and it’s where SMTP bounces are sent when the recipient mail server cannot deliver the email (e.g., mailbox is full, mailbox does not exist, etc.). This is is the email address that SPF protects. You won’t see this email address anywhere in the email client, it only appears in the headers, typically in the Return-Path and in the Authentication-Results header in the smtp.mailfrom=<…>.The one exception where this does show up in the email client is in Gmail, where they sometimes show you the SMTP MAIL FROM in the via tag..
.3.

3. The Sender: address in the message headers
.
Some emails have a “Sender” header. RFC 5322 gives some guidance about this header, but I don’t think it’s clear:

The “Sender:” field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the “Sender:” field and the mailbox of the actual author would appear in the “From:” field.
.
The Sender: field is the one that has the least consistent implementation.

Where is it typically used?
.
(a) When someone sends on behalf of another within an organization
.
The place where I see it the most is internally here at work where an admin sends on behalf of an executive, usually when sending a a meeting invitation, or calendar invitation. Because it shows up so often when an admin sends on behalf of an executive, Outlook and Outlook Web Access (not sure about the mobile client or Outlook for Mac) renders the message differently in the mail client:.

<Sender> on behalf of <From>.

So, something like this:

admin@example.com on behalf of executive@example.com

That’s useful to me, because I can see it’s not the executive who is communicating with me, but their admin who is forwarding a message to me.

That rendering only shows up in the message view in Outlook and OWA. The list view displays only the From: address.

(b) On mailing lists

The place where I personally see this the most for my own email (as opposed to everyone else’s as in point [a]) is on mailing lists. Some mailing lists will put the mailing list’s email address into the Sender: and the original poster into the From:, like this:

Birdwatcher’s List <birdwatchers@example.org> on behalf of Terry Zink <someone@noreply.com>

This is helpful when viewing which mailing list sent the message, but I think that there are better workarounds (e.g., A tip for mailing list operators to interoperate with DMARC to avoid failures). As far as I can tell, mailing lists doing this doesn’t help the original poster pass DMARC without the mailing list implementing some workaround.

(c) In bulk email

Some bulk emailers add a Sender: header into their messages. I’m not sure why they do this, but it may be because they want the message to render differently in Outlook (but as far as I know, only Microsoft email clients render it differently; larger receivers like Gmail and Yahoo do not). Or, it may be because they want the message to pass SenderID which sometimes uses the domain in the Sender: header instead of From: upon which to do an SPF check.

Personally, I don’t think adding the Sender: header to bulk email is necessary.

There isn’t a standard authentication technique that protects the Sender: header (other than SenderID, which isn’t used by any major email receiving organization, it’s only used by some on-prem Exchange servers). I suspect that’s because most email clients don’t render it, and therefore any phisher or spammer trying to spoof it doesn’t gain much because the average user won’t even see it.

4. The Reply-To
.
The Reply-To header is added when the originator of the message wants any replies to the message to go to that particular email address rather than the one in the From: address. This usually shows up as a separate field in the email client. There is no technique (SPF, DKIM, DMARC, or any other technology) that protects the Reply-To header.

Some email filters try to compare the Reply-To with the From: address and do something when they are different, but in my experience this generates a lot of false positives.

For the most part, when people say “sender” they are referring to the From: address. Most of the message traces in Office 365 and Outlook.com are referring to that. It’s also the one that email clients are most concerned about protecting. But sometimes we are also referring to the SMTP MAIL FROM.

Hopefully this clears things up a bit.

Well over a year ago, I wrote the following blog post: Why does my email from Facebook, that I forward from my outlook.com account, get rejected?

It’s a very popular blog post, it gets more comment than almost any other post that I have written. The overwhelming majority of comments asks the question: “When will this be fixed?”

Now, I can’t comment on these types of things for two reasons:

We have hit problems many times when deploying this fix, so any time I would have announced something on this blog would have required a subsequent update
.
I am not allowed to make public comments re: timelines for features and fixes that haven’t been announced publicly on a feature roadmap that Microsoft has officially announced

We have had an internal timeline, however, and I’ve been tracking it closely.

But now, I have an update:

In Office 365, we’ve deployed a fix such that if you use Exchange Transport Rules (ETRs) to forward or redirect a message to another destination mailbox, the original message format will be retained. This means that a forwarded or redirected message will retain its original DKIM signature and pass DKIM at the forwarded-to destination.I have personally tested this and can confirm that it works.
.
The more geeky explanation is that as long as the message has not yet undergone MIME-to-MAPI conversion, it will not have the message format modified such that DKIM breaks. So, there are other code paths that this works such as distribution lists (I’ve tested that, too). But I haven’t tested everything, so I can’t say what all works and what doesn’t. I just know that ETRs that forward and redirect are the most common features where this breaks, and those seem to work okay at least when I try it.
.
.
However, mailbox forwarding does not work – neither in Office 365 nor in Outlook.com. This means that if you have a mailbox rule that forwards or redirects to another mailbox, the original DKIM signature will be broken.
.
Per the geeky explanation above, what’s happening here is that the message hits the mailbox and therefore has undergone MIME-to-MAPI conversion, and then when forwarded it does MAPI-to-MIME. But this reconstructed message is not the same as the original.We still have to fix this part.

That’s all for now.

Over the past week, I’ve noticed an increase in user escalations asking to disable unauthorized forwarding. That is, they have a setting in their mailbox where their email is being forwarded to another account.

Users can resolve this themselves: select Options > Mail > Automatic processing > Inbox and sweep rules. Then, look for any mailbox rules that forward to an email address you don’t recognize; you can view the description of the forwarding rule when you select it as the description contains the forward-to mailbox.

If you find a forwarding rule that that you didn’t set up, delete the rule.

If there are multiple rules, you will want to review them individually to make sure there isn’t more than one.

Next, reset your password by going to https://account.live.com/password/reset. Select “I think someone else is using my Microsoft account.” Even though you still have access to your account and you can sign in, there is a likelihood someone else is also using your account.

Go through the steps to reset your password. I recommend saving your new password in a password manager because:

(a) While you can save it in your browser via the “Remember me” feature, sometimes you’ll clear your cache and need to re-enter it. You’ll also need to manually type it in if you check your email on your tablet or phone.

(b) You may be tempted to re-use your password across multiple sites. Don’t do this. Let your password manager generate a random one for you, and save it. That way, if your account ever gets compromised, your password can’t be used to login to multiple sites elsewhere.

And that’s how you disable unauthorized forwarding.

I’ve been asked a few times what I think about organizations that add warnings to messages that their users receive when the message is sent to them from outside the organization. That is, some organizations create Exchange Transport Rules (ETRs) when the message is received outside the organization. This might look something like this:

This is an external message

Or, sometimes it’s bolded:

This message came from outside the organization

Or, sometimes it’s bold and red:

This message came from outside. Please exercise caution when opening attachments.

Or, sometimes it’s bold, red, and contains asterisks:

*** This message came from outside. Please be careful when replying to it ***

I was on a call recently, and a customer asked me what I think about this. I’ve also been on internal email threads where it similarly comes up. And also, would we ever consider adding this to Safety Tips?

My view on warnings of this type is one of mixed feelings.

The advantages of warning on external messages

On the one hand, I get why a company would do this. The majority (but not 100%) of phishing attempts come from outside the organization. Phishers are trying to get users to click on links; open attachments; or reply back with sensitive information such as HR personnel files, or making wire transfers. So, by adding these disclaimers, they are trying to get users to be more vigilant and pay attention to the fact that the message comes from the outside, and therefore might be suspicious.

The drawbacks of warning on external messages

On the other hand, I’m not sure how effective this is for actually changing user behavior.

The majority of external messages that land in your inbox are legitimate. I get plenty of spam but nearly all of it goes to Junk, or is rejected at the network edge and I never see it. Almost everything I see in my own inbox is fine, and it’s like this for the majority of people.

By adding disclaimers to messages when they are external, the user learns to associate the warning at the top with something that is not malicious. By seeing so many benign messages with a warning, the user has been trained to ignore them since they were providing no value (that is, being careful on external messages yielded the same results as not being careful on internal messages). And then, when a malicious message actually does arrive from the outside, because they’ve been conditioned to seeing warnings on messages without any malicious content, the average user still goes ahead and clicks on the link or opens the attachment. And therefore, the external warning has added no value.

It’s kind of like Syndrome from the movie The Incredibles. His evil plan was to give everyone super powers, because when everyone was super, no one would be.

My own experience

Speaking for myself, I recently noticed (!) in Outlook that when I sent emails to external people, it warns me:

And here’s what it looks like in Outlook Web Access:

Even for me, I wasn’t really paying attention to those warnings because (a) they look similar to other notifications that I get in the email client (e.g., Out-of-Office replies), and (b) virtually all external messages that I send are legitimate.

When it comes to Safety Tips, we are hyper-aware that we don’t want to overtip because of exactly this problem. People complain regularly when a message arrives with the red fraud detection tip – even when the message truly is fraudulent! On the other hand, there is a lot of spoofing email out there that contains this tip and the message content is “legitimate”, so we do have evidence that people don’t want noisy notifications.

We’ve also experimented by adding a safety tip to a few more scenarios, and tested it internally. It was a gray safety tip and examined communications between people and added a tip when it deviated from an established pattern.

The feedback from that experiment was not positive. Even though it was only a gray tip, people didn’t like it. It was unclear to them that the the tip was adding any value in the case when a message was not suspicious, and that turned out to be the majority of the cases.

So, the moral of the story is: Warn users when you have something to warn. The criteria has to be specific.

But maybe there’s a place for warning on external messages?

I guess the answer to the question of what I think about external warnings on all messages is: Your mileage may vary.

Perhaps it works for some users who get so few external messages that it’ll work for them since they don’t normally need to differentiate between external and internal
.
Perhaps it works for to add warnings but suppress them when it comes from a trusted source (that is, adding an exclusion to the ETR). But then this forces you into maintaining allow lists, and this list will become long and hard to maintain
.
Perhaps users really do pay attention to it and alter their behavior internally. That may be, but I’ve seen more evidence that it works when you use it sporadically rather than regularly

But having said all that, you may still find it useful to add these external warnings.

<shrug>

If that’s what you want to do, it’s up to you.

If you are a subscriber to the good folks at Eco over in Germany, you might have noticed in their regular newsletter that Outlook.com and Office 365 is now a new ISP partner.

What does that mean?

Over here at Outlook.com and Office 365, we have a complicated relationships with good IP reputation lists. Outlook.com currently uses the ReturnPath IP reputation list to reduce filtering, while Office 365 does not yet do it. Office 365 uses the DKIM-domain reputation list to make filtering decisions, yet Outlook.com does not. The reasons for the discrepancy has to do with infrastructure differences between the two services, as the backends are not yet aligned.

Then there’s also the IP reputation lists that are manually maintained when senders escalate to support.

Then there’s also some legacy reputation lists (not necessarily IP-based) that have done more harm than good in Outlook.com. We have IP+domain reputation lists in Office 365 that work pretty well, except when we get a bunch of spam complaints from one or two particular senders on the list out of a total of several hundred or a few thousand good entries.

In my experience, a good sender reputation list usually contains 80% good senders, 19% mostly okay senders, and 1% sketchy senders (that is, generate more than their fair share of spam complaints despite doing the proper opt-in procedures). And that 1% affects the other 99% because that 1% makes us skeptical of the other 99%.

So, in terms of the CSA reputation list, the way we use it (or at least the way I use it) is in response to escalations:

a) I regularly see spam complaints from bulk senders that are on the CSA list, and so I contact the folks at Eco asking them to look into that particular sender. Visibility for reputation list providers is important.

b) I also take the CSA reputation list into consideration when a sender has delivery trouble at Outlook.com; if they are on the list, it means they’ve gone through the steps of trying to be a good sender.

c) And finally, I recommend that one path senders can take if they want to improve their deliverability in general is to join the CSA because it will help with sending email to various places around the Internet, not just Outlook.com, because if you follow those steps then it reduces the chances that you will display behavior that is considered abusive. I’ve referred to various whitelist providers here: A quick overview of Outlook.com (Hotmail) sender support, which include more than CSA.

This doesn’t mean you have pre-emptive accommodation.

But it does mean we understand the importance of good sending behavior; of working with partners to ensure good senders who are trying to do the right thing get a better experience than they otherwise might have had; and providing senders with a path to get into a good state.

That’s not the full scope of how we use good sender reputation lists, but hopefully it gives you a rough overview of our relationship with them.

The good thing about DMARC

One of the great things about DMARC is that subdomains can inherit the policy of its organizational domain. For example, here's the DMARC record of microsoft.com (I've removed the reporting addresses):

microsoft.com | "v=DMARC1; p=reject; pct=100"

There's no subdomain policy, which means that the following domain which has no DMARC record:

foo.microsoft.com | No DMARC record

... inherits the organizational domain policy, which in this case is p=reject. This is great because suppose I wasn't entirely sure if microsoft.com could be protected and had to set p=none. I could still protect the subdomains by specifying its policy:

microsoft.com | "v=DMARC1; p=none; pct=100; sp=reject"

So, a phisher could spoof microsoft.com, but not foo.microsoft.com, bar.microsoft.com, and so forth. It's one of the best things about DMARC. I can't possibly set up DNS records for every possible combination of *.microsoft.com but I don't have to because they all inherit from the organizational domain by default. Or, I can specify the subdomain policy and make it different than the organizational domain's policy. Or, for certain subdomains, I can explicitly specify the policy by publishing a DMARC record.

The drawback of SPF

But whereas DMARC has inheritance, SPF does not. Suppose that this is the SPF record for microsoft.com:

microsoft.com | "v=spf1 ip4:10.0.0.0/24 -all"

(Let's pretend, for now, that the IP range is not an internal range). Anyone who spoofs microsoft.com from an IP outside that range will hard fail SPF and will experience problems delivering.

But what if a spammer sends from @foo.microsoft.com?

There's no SPF record for that domain, and I can't possibly set them all up. Rather than getting an SPF hard fail, it will get SPF None. That's usually not nearly enough to give a domain delivery trouble.

You may ask "Why does this matter?" After all, microsoft.com already has a DMARC record, so you're all set.

Except that's not true. Many times phishers spoof microsoft.com in the header.from address, or a subdomain in the header.from address; those are protected by DMARC. But often times, they spoof *.microsoft.com in the SMTP Mail From domain, and then have a completely different header.From domain (a domain we do not control).

This is problematic because we don't want spammers or phishers squatting on our domains or subdomains in any capacity, neither the SMTP Mail From, nor the From: domain (nor the Sender: header, but that's another problem). When the SMTP Mail From and From: domains are different, DMARC doesn't help if it's not our brand since we can't publish a DMARC record. And also, SPF isn't helping either because the SPF record does not exist and therefore can't help in refudiating [1] the message.

And that leads to "cosmetic" problems. Many of us understand the complexities of different sender addresses, the limits of SPF and DMARC, and the challenge of authentication. But even more of us (i.e., not me, of course) don't. And when someone gets an email and starts going through the headers and doesn't have that background and then they see *.microsoft.com being spoofed, it leads to all sorts of noise. "Why are you sending spam?" "Why haven't you locked down your domain?" And on it goes.

Email authentication is hard to explain.

Extending SPF to include inheritance

It'd be great to cut down on that noise.

And that's why I think SPF needs an update. It needs a mechanism to specify that a subdomain inherits from its organizational domain, or not. That way, I can sleep easy knowing that the entire domain is protected since I can't possibly publish SPF records for everything.

I think the default should be just like DMARC - if the SPF record doesn't exist, fallback to the organizational domain. We'd have to define a new syntax to say that the subdomain should not inherit from the organizational domain; and that syntax should also be able to specify a default fallback (hard fail, soft fail, neutral) for subdomains. I don't know for certain that's necessary because it's rare that unpublished subdomains should have a different fallback policy than the organizational domain. If it's that big a concern, explicitly set one up.

So, this SPF record:

foo.microsoft.com | None

... would be treated as this:

microsoft.com | "v=spf1 ip4:10.0.0.0/24 -all"

The correct way to do this would be to propose an extension to RFC 7208, get sign-off from the industry and publish an updated RFC. I think that's the long-term path.

The short-term path would be to start doing it, and then in the Authentication-Results header, add some comment that says that's what you're doing, e.g.,

Authentication-Results: spf=fail (sending IP is 192.168.1.2)
  smtp.mailfrom=foo.microsoft.com (using SPF record for microsoft.com)

That makes it clear to anyone who asks what is being done. There's probably a better way to specify this (e.g., with a new result, like spf=inheritFail). In parallel, work on updating the standard.

And that's my idea about how we can make SPF great again.

[1] "Refudiate" is a word. Look it up.

Some background

As I've said before, one of the things I like about DMARC is how I don't have to specify a policy for every single domain that I own. To recap what I said in my other post, here's the DMARC record of microsoft.com (I've removed the reporting addresses):

microsoft.com | "v=DMARC1; p=reject; pct=100"

There's no subdomain policy, which means that the following domain which has no DMARC record:

foo.microsoft.com | No DMARC record

... inherits the organizational domain policy, which in this case is p=reject. This is great because I can't possibly set up DNS records for every possible combination of *.microsoft.com but I don't have to because they all inherit from the organizational domain by default. I set it and forget it on the organizational domain, and I'm done unless I specifically publish a policy for a subdomain.

The tricky part of DMARC is where branded domains come in (which from this point forward I will sometimes refer to as .brand). If you're not aware, a branded domain is something that a company (or any organization willing to pay for it) can specify that customizes their own Top Level Domain. That is, outside of traditional TLDs like .com, .net, .io, you can specify .microsoft. For example, https://home.microsoft is a real domain, it redirects to https://www.microsoft.com. The URL https://surface.microsoft redirects to https://www.microsoft.com/en-ca/surface. Branded TLDs are neat because you can put your entire brand into the URL, and it looks reasonably authoritative.

Indeed, I think if we were to start the Internet all over again, we'd put a greater emphasis on branded domains.

So what's the problem?

The problem with .brand comes with DMARC.

How do you specify a DMARC policy that covers your entire .brand? That is, how would I publish a policy that covers all @surface.microsoft, @home.microsoft, @xbox.microsoft, and so forth? Obviously, I can set something up for each of those domains but I can't possibly specify a permutation for all of them.

DMARC says that if a domain doesn't have a DMARC record, look up the DMARC record of its organizational domain. The algorithm for this is to look up the Public Suffix List and then go to the string just in front of it. For example, if looking up home.live.microsoft.com's organizational domain, you would say "Find a TLD in that domain -> which is .com. Next, prepend the next substring, which is microsoft. That means the organizational domain for home.live.microsoft.com is microsoft.com."

And, in order for links to resolve someplace such that Internet browsers can make use of a .brand URL, Microsoft had to register .microsoft and publish it in the public suffix list.

For a .brand, the organizational domain for foo.microsoft (which doesn't exist) is... foo.microsoft. That's because the TLD is microsoft, and prepending foo gives us foo.microsft. There's no way I can publish a DMARC entry for everything. You might say "Well, just publish a DMARC record for... er... the microsoft TLD." Well, do we publish DMARC records for com (as in, *.com)? No, we don't.

And that means DMARC needs an update for branded TLDs.

Some options for fixing this

I've thought about this for about 15 minutes, and propose one of the following options:

1. Use home.brand as the default organizational domain

Any new TLD registered after a certain date (has to be something in the past) can be reasonably implied to be a branded TLD. And if the domain with a branded TLD doesn't have a DMARC record, the organizational domain should fallback to home.brand. For example, if the DMARC record for foo.microsoft does not exist, and since .microsoft was registered in December 2014, then check the DMARC record for home.microsoft and use that instead.

The advantage of this is that home.brand is a "natural" place to look a .brand's DMARC policy. If 127.0.0.1 is home, then home.brand can really be home.

2. Assume any non-existent *.brand defaults back to brand.com

Once again, you need to assume that any .brand domain is something created after a certain date so you can know whether or not it is a branded domain (to differentiate it from .com, .net, etc.). If foo.microsoft has no DMARC policy, then check microsoft.com's DMARC policy and use that.

Similarly, bar.foo.microsoft would have no DMARC. Next, check foo.microsoft which has no DMARC. Then, check microsoft.com which does have a DMARC record. This method adds another DNS check, but helps logically connect the .brand to the .com TLD.

The advantage of this is that it ties the most well-known TLD - .com - with the .brand. The drawback is that the .brand may not actually be related to the .com.

3. Assume any .brand is DMARC reject

Let's be honest. If we were doing email over again, we probably wouldn't make it as insecure as it is. We'd start with a strong policy from the ground up. So, if something is a .brand domain then assume it is DMARC p=reject (the .bank TLD is like this). If someone wants to specify something else not as strongly protected, then they have to set it up explicitly. For example, if foo.microsoft has no DMARC policy, then assume it is

p=reject

If foo.microsoft should not behave that way, then the domain administrator would have to explicitly publish a DMARC record for foo.microsoft.

Once again, we need an algorithm to figure out what's .brand and what isn't (e.g., using a date), but this simplifies the management of the .brand domain when it comes to email.

Some email folks don't like default policies that aren't explicit. I'm not one of them.

4. Actually publish a DMARC policy for .brand

I said above that we don't publish DMARC policies for TLDs. But, maybe we should.

On the other hand, how would you do a DNS query for com? That seems a little weird, and it would require modifying the DMARC algorithm to check the TLD's DMARC record after checking the organizational domain. The advantage in this case is that it doesn't require figuring out whether or not a TLD is a .brand, as any .brand could choose to publish or not publish a DMARC policy. The disadvantage is that it requires an upgrade to all existing DMARC implementations.

5. Don't bother with any of this DMARC business and just reject email from domains that don't resolve

Getting email from foo.microsoft which has no DMARC record? Not a problem. If it's spoofed, it's probably coming from something that's completely spoofed. It will probably have no A-record, and no MX-record. Since those are always spam, reject them unconditionally.

Except that they aren't always spam. Microsoft may have a lot of domains in the .brand that we want to use for marketing purposes and set up A-records for. Those will resolve; we just might forget to publish DMARC records but we would still want that email rejected. To which you might respond "Well, that's your problem if you can't manage your DNS."

To which I reply "If you work in a big organization, DNS updates are hard to do. This process as not as simple as you think it is." Relying upon the domain owner to keep their DNS records up-to-date is not going to work. As a large receiver, I don't want to take a dependency someone else. I work on a team that is responsible for keeping spam and phish out of the inbox, and if someone is spoofing your .brand but you haven't locked it down with DMARC, I'm not going to say "Oh, well, I'd like to reject it but since it resolves in DNS, I can't take action on it." I have to say "What was the domain owner's intent?" Options 1-4 above try to guess a domain owner's intent irrespective of whether or not they have good management processes. Option 5 does not.

There you have it. That's what I see on the horizon for an update to DMARC. We don't see a lot of .brand in email yet, but I do see it sometimes when it comes to links. It's only a matter of time before email catches on, and DMARC had better be prepared.

You can see I lean heavily towards figuring out what's a .brand and what isn't, and propose using the date registered in the public suffix list as a potential cutoff. That may not work, but if anyone else has a better suggestion I am open to it.

In order to help stop phishing messages, Office 365 and Outlook.com already filter messages using authentication methods including SPF,

DKIM, DMARC, and antispoofing. These techniques verify that the sender is who they say they are, and they are used to mark the message either as Junk Email, or deliver it to your Inbox. They sometimes also add Safety Tips.In the next few weeks, Outlook Web Access (OWA) and Outlook.com will be rolling out indicators to show indicators when the sender of the message either cannot be identified (authenticated).

Unauthenticated messages show a '?' in the sender photo

When Outlook.com or Office 365 cannot verify the identity of the sender using SPF, DKIM, or any other technique, it will display a '?' in the sender photo:

Not every message that fails to authenticate is malicious. However, you should be careful before interacting with messages that do not authenticate if you do not recognize the sender. Or, if you recognize the sender and they normally don't have a '?' in the sender photo and you suddenly start seeing it, that could be a sign the sender is being spoofed.

Frequently Asked Questions

What criteria does Outlook.com and Office 365 use to stamp the '?' in the sender photo?

Both Outlook.com and Office 365 require the message to pass either SPF or DKIM. Office 365 also has some other internal logic for identifying senders.

Why not simply block the email?

The modern problem of spam, and especially phishing, is that we don't live in a world where the question of "Is it phish?" is so clear-cut. Filters have trouble making decisions sometimes, and this helps to surface an extra little bit of information to the user.

Also, there is a lot of unauthenticated email in the world that is not spam nor phish. This is usually legacy software that hasn't been updated in ages, or comes from servers that never bothered to authenticate their email. Showing a '?' can hopefully act as a nudge to do the right thing - if you want the '?' to go away, authenticate your email.

Can customers of Office 365 or Outlook.com override this with IP Allows, Exchange Transport Rule Allows, or safe senders?

No.

This is a good thing, because if a spammer spoofs that sender, you have no way of differentiating between it and a "legitimate" message that failed authentication. But, if you do allow rules on a sender that does authenticate, then that is a safe allow rule and the '?' will not be displayed.

This doesn't prevent allow rules from executing, they still go to the inbox. They won't remove the '?', however.

I'm a big sender. How do I make these properties disappear?

As a sender, you should authenticate your message with either SPF or DKIM.

I'm a medium sender. How do I make these properties disappear?

See above.

I'm a small sender. How do I make this '?' disappear?

Same as a medium sender.

Does Outlook.com and Office 365 show this for every message that doesn't pass authentication?

Not necessarily. In addition to SPF and DKIM, Office 365 has additional logic to authenticate a message.

In addition, Office 365 only shows these properties in the event that the receiving domain's MX record points to Office 365, and has not undergone routing into and out of the environment.

Isn't this kind of similar to the way Gmail shows a '?' for an unauthenticated sender?

Gmail shows the following for messages that don't pass authentication:

So yes, it is similar. Because there is a lot of user overlap between Gmail, Outlook.com, and Office 365, we decided it was best to unify the experiences across multiple email platforms. We don't want to retrain users.

They aren't identical, however. Office 365 has additional criteria that Gmail does not have.

The official version of this documentation lives here: Identify suspicious messages in Outlook.com or Outlook on the web

I recently signed up for a new credit card.

I don't normally do that on a whim, but instead do it for the big sign-up bonuses they offer. I get the card for one year, and then cancel it before I have to pay the annual fee. The big sign-up bonus points are typically worth between 40,000 - 50,000 points which are good towards the cost of a flight somewhere, or you get more bang-for-your-(points)-buck by applying it towards hotel.

To me, credit cards are mostly interchangeable [1]. Unless I get a nice sign-up bonus, it's all the same (just like it is to the many-faced god on Game of Thrones). This particular card wasn't all that impressive. All I got was rental card insurance (which I already have for a different credit card), and 2x bonus points on certain purchases. The 2x bonus points isn't all that enticing, you have to spend a lot of money over a long period of time to get anywhere close to the sign-up bonus on a good card. Without that, the card doesn't have anything to make me get excited over it.

I don't even know why I got it other than my wife made me do it.

But anyway, I'm not writing a blog post to discuss the rather mediocre offers that credit cards make to me.

Instead, I'm writing a blog post to discuss my existential nihilism when I called up the credit card company.

For you see, I did get a new credit card issued by the same bank as another one I had. But it wasn't showing up on my online account. Not only that, but I couldn't figure out how to link it to my bank account. I had to call them up and get them to sort it out for me to link it.

You may be saying "That doesn't sound so bad." But it gets worse.

Earlier this evening, I was doing some stretching and self-massage (I have a bad neck and back due to years of bad posture caused by sitting in a computer chair for hours on end). When I do, I like to listen to podcasts. This time, I listened to Money for the Rest of Us which is a podcast about personal advance. I like it because it's not for beginners, but also not too super advanced. I'd say on a scale of 1-10 for sophistication, it's intended for a 7 or 8.

The episode I listened to was entitled "Equifax Aftermath - Should you freeze your credit to protect against identity theft?" In case you've been living in a cave the past two weeks, the credit reporting company Equifax revealed that tons of sensitive data was leaked after they were breached by an attacker. The host, David Stein, was discussing possible steps you can take to limit the damage to yourself. A few days ago I checked to see if my data was leaked. I suspected what the answer was, and my fears were confirmed - it was.

Not only that, Stein recounted leak after leak after leak that has occurred over the past 10 years. I know that other bits of my data were leaked in those breaches, too. I had to change credit cards a few times already.

The Equifax breach is especially egregious because it's Social Security numbers, credit card numbers, birth dates, and a bunch of other personally identifiable information, and it's all floating around the black markets by now. It's there for anyone whose willing to pay for it, and there's nothing I can do to change that information other than maybe issue a credit freeze. It's very disempowering. What am I supposed to do? Sure, my credit can be frozen, but that's not all that can be done with that information.

Which brings me back to calling up my credit card company.

I'm on the phone, trying to link up my account to my new credit card. This is 30 minutes after listened to that podcast. The agent on the other end of the phone was helpful, but before she could link up my account, she asked me to verify some personal information.

And a big knot formed in the pit of my stomach.

She asked me for the last 4 digits of my Social Security number and I almost said "What's the point of asking me this? Hackers out there have it and could be using it to impersonate me."

She then gave me an address and asked me what county (in the state where I live) the address referred to, giving me three options plus none of the above. Finally, she asked me what address I had previously resided at, giving me three options plus none of the above. I answered the questions and she linked my account.

And all I could think of was "This information that I'm using to identify myself is probably leaked. A hacker could get that data and use it to impersonate me. It's probably no security at all, the very thing I'm doing now could be done by somebody else. What's the point of it all?"

And that thought was depressing.

[1] The one exception is the Chase Sapphire Reserve card which I got earlier this year. This is the one credit card that is totally worth it. Not only did I get rental car insurance (which is good when I rent cars, which isn't often), I also got a 100,000 point sign-up bonus. That's double what almost any other card gets you. But the coup-de-grace is that it came with a Priority Pass which gets you access to airport lounges around the world. It's awesome! I don't know how I ever flew before this year.

The card was so popular that Chase stopped issuing it after three months.

The thing about this card is that the annual fee, including the Priority Pass, is $450 but only $150 in the first year. But because the Priority Pass is so great, I am considering renewing the card. Not sure I want to pay $450 for zero bonus other than the meh-tacular rental car insurance, but the lounge pass benefit sure is tempting.

A couple of weeks ago, we made an announcement in Office 365 that we would be implementing stricter checks of the From: address, starting Nov 9, 2017. You can find that at How Office 365 validates the From: address to prevent phishing. I won't repeat everything in that article as you can click and read for yourself.

Instead, I'm going to describe the background of that decision. For you see, we've been doing a lot of work on phishing this past year, and one of the tricks that spammers use is to send email with malformed From: addresses:

From: Sender

From: Example Sender <example>

From: Another Example <someone@>

And so forth.

As you may know, earlier this year we tightened up Outlook.com to prevent anyone from sending email with a malformed From: address. We are now aligning the behavior in Office 365 as well.

After deploying the behavior in Outlook.com, I was concerned that we would get complaints from senders that we were marking these messages as spam. I knew from analysis that there appeared to be "legitimate" messages sending in that fashion. We went ahead and deployed anyway, and the total number of complaints was... zero.

Not one.

That caught me off-guard.

That was Consumer email, but what about Enterprise? The problem with Enterprise email is that there is a ton of legacy email servers out there that send malformatted email. I wasn't sure whether we could get away with marking these types of messages as spam.

But the reality is that we can't protect users from phishing attacks if we let these types of messages through. It gives spammers far too much room to maneuver if they can put random garbage into the From: header as our parsers cannot possibly detect every possible combination of usually-bad-but-not-always. And therefore we took the decision to enforce the RFCs that define how to send email with a properly formatted From: address. It's the only way to prevent phishers from living in that space.

You may recall I wrote a blog post last year about some other type of From: address enforcement here - Sending mail with invalid From: addresses to Office 365. This new behavior will take precedence over that one.

I am aware that this will probably affect some small subset of "legitimate" email, that is, email software that is misconfigured. Those types of messages will start getting marked as spam unconditionally unless an administrator creates an override for them. I've gotten the follow-up question "Can we still get these types of messages scanned for spam, and just have the From: validation enforced?"

The answer is no. Either accept the email unconditionally using an IP Allow entry or Exchange Transport Rule, or let the message go to Junk. There is no hybrid approach.

Hopefully this cuts down on unwanted email, while minimizing any "legitimate" messages that are sending non-RFC compliant messages.

Oh, one last thing.

This is called out in the linked article at the top of this blog post, but I want to say it again. One thing that some senders do is try to suppress replies to automated mailers. Thus, they send email this way:

SMTP MAIL FROM: <>

From: <>

This is a clever attempt to trick a mail server into not replying to a message. Those types of messages will be marked as spam, and messages without a From: header at all may even be rejected in the future.

If you want to suppress autoreplies, either:

Send from a domain that is set up for it, e.g., noreply.contoso.com, and set up a rule in your email filter to delete all messages going to that domain. OR
.
Send from a domain that has a null MX record, e.g.,
```
noreply.contoso.com IN MX .
```
That lets mail servers know that the domain does not receive email.

Use one of those two methods. But don't send non-RFC compliant email. We are getting pickier and pickier about it.

I couldn't believe it. I had been blind for ages. Why had I not seen it before?

The month was August 2017, and none of Microsoft's largest consumer email brands - msn.com, live.com, hotmail.com, and outlook.com - had DMARC reject records in place. Not one. As a result, we were still seeing lots and lots of spoofing.

I had a rough plan in my head to close these down, although it required us to roll out a fix that stopped up entirely from modifying messages once they passed through the Exchange pipeline, thus breaking DKIM signatures. We got that partially fixed this past year, but not entirely. Getting it entirely fixed is something I just didn't have time to drive, I'm far too consumed with antiphishing work, random antispam escalations, and running the service.

It always irked me that even though we managed to lock down @microsoft.com, the biggest brands were still open.

And that's when I had a revelation. I felt ridiculous; why had I never used this technique before?

The big reason why I couldn't move any of our consumer domains to DMARC reject or quarantine is because of false positives. While Microsoft Corporate IT might be willing to take the hit when it comes to mailing lists (lots of our employees are on mailing lists, and going to p=reject resulted in major disruption for them unfortunately [although we do have some mailing lists on our "do not enforce DMARC" list to avoid false positives when sending to Office 365]), it's not something I felt I could expect consumer users to understand. They'd have their mailflow working one day, and the next day experience disruption. We work hard to ensure a good email experience even for our free users, and I was unwilling to push the envelope on that side. So we (I) had to live with the fact that it was prone to spoofing [1].

I consoled myself with the fact that even though @yahoo.com and @aol.com had gone to p=reject three years earlier, at least @gmail.com hadn't. So worst case, we were even with Gmail.

And then one day I said to myself "Self, why are you trying so hard to block spoofing of all of our consumer domains? Can you not clamp down on the subdomains?"

I then said "Self... that's a great idea!" [2]

I had gotten into the rut of thinking that @hotmail.com was like @microsoft.com. @microsoft.com has many dozens of subdomains from which it sends email, so my goal was to prevent spoofing of @microsoft.com and @*.microsoft.com. But for our Consumer domains, there isn't that much legitimate email on our subdomains. That would be a much easier piece of the elephant to consume.

I hadn't previously considered separating out the DMARC enforcement policy before. I knew that DMARC let you specify a different subdomain policy from organizational domain policy, but I had never intentionally tried to decouple them before. It turned out to not be that difficult.

I decided to start with msn.com. I had set up DKIM-signing for it a year ago, along with outlook.com and hotmail.com. Out of all of our consumer domains, for some reason msn.com was the least-spoofed one. I headed over to the Agari portal which is where we point our DMARC reports to and looked at the trend for the organizational domain:

[Disclaimer: The y-axis on the left hand side is not necessarily the actual values; I may have modified them to prevent information disclosure. Not sure that matters... but I did it anyway. The point is to show the trend]

You can see that even though msn.com has SPF and DKIM set up, the majority of email from @msn.com fails DMARC. That means that there's a lot of spoofing of it.

But the organizational domain is not what I was targeting. Instead, I focused on subdomains. I knew that msn.com definitely was used to send email, and I knew that we never opened up any subdomains to allow users to sign up to receive email. But was there any other team at Microsoft using *.msn.com to send email? I checked out the subdomains:

Those all look super spammy to me except maybe web.store.msn.com. Indeed, there were a handful of legitimate-sounding domains like spaces.msn.com or server4.msn.com. I wasn't sure that they were legitimate, but none of them were sending from IPs that looked legitimate.

The puzzle was not yet complete, I didn't have all the data I wanted. And, I wanted to move fast.

The Agari portal was one thing, but I wasn't sure I was getting the full data set of what I needed. Not every email receiver sends DMARC reports reliably, and some don't send them at all. So I decided to go straight to the source I have the best access to - our own logs we store internally for email scanned by Office 365 and Outlook.com.

We store all of our email logs in a big database that can require several hours to parse and run, depending on what you want to do. Some of it is optimized, some of it... not so much.

I discovered the logs optimized by From: addresses could be queried fairly quickly, but did not have that much metadata on it (such as sending IP, or DMARC status). I decided to use those, as they could be good enough.

I did a query on all traffic over the past 30 days sending to Outlook.com (all of our consumer domains that I wanted to enforce) and Office 365, looking only for subdomains. I then added a column for whether or not it was sent to a consumer domain or enterprise customer, and I also added a column for whether or not it was sent by a bulk email provider (we wrap all these up into a BCL value in Enterprise, or NCL value in Consumer). The idea was that any subdomain with a BCL was probably legitimate.

I ran the query and got pretty much the same data I saw in the Agari portal, except I saw a lot more of what was clear phishing attempts - a bunch of phishers sending from variations of accountprotection.msn.com. For months we've been battling phishers impersonating our Microsoft password/notification alias, and they were using msn.com to do it. I was surprised by how much was in there.

But I also found a handful of domains that kind of looked legitimate like email.msn.com, mail.msn.com, and so forth. I went through the list of domains, eyeballing the ones that looked legitimate. I stopped going down the list when the volume became too small. Any legitimate subdomain of msn.com was going to have a lot of traffic. I got it down to a list of 6 subdomains, and I created SPF records for them. If they were legitimate, then they were not passing SPF before but would be now. If they weren't legitimate, then they were not passing before and now would be failing.

I could live with that. Furthermore, every single team that tries to send from a subdomain of *.microsoft.com can't deliver unless they set up proper authentication. The teams that are motivated to have actual delivery come and find me, so I wasn't too worried about breaking anyone's legitimate email flow on a long-term basis. I know the infrastructure (more or less) of how most of Microsoft sends email, and I was pretty sure the default SPF records I set up would work.

I took the plunge and on Aug 31, 2017, updated the subdomain policy of msn.com to p=quarantine. The subdomain was now protected everywhere (that enforced DMARC).

I repeated the process for hotmail.com on Sept 5, 2017 (hotmail.com, believe it or not, was the easiest and had the least amount of subdomain spoofing). This was followed by live.com (which had by far the most subdomain phishing on it... a fact I never would have guessed), and enforced subdomain protection on Sept 7, 2017.

And did spammers give up?

[The following chart may or may not obfuscate the actual numbers on the y-axis]

The answer on msn.com (gray line) is yes, they did. Sort of. They seem to come and go in little waves.

For hotmail.com, it had no impact on their behavior.

For live.com, it went away almost overnight.

For outlook.com, which just went live (Oct 21, 2017), I will have to pull some updated data. You can see the overall trend was downward for months, so perhaps this just firms up the protection.

So at this point, all four large consumer brands of Microsoft's - Outlook, MSN, Hotmail, and Live - have their subdomains protected by DMARC quarantine. And it's also a process I recommend to others: instead of trying to protect your organization all at once, consider splitting up the org domain policy from its subdomain policy and tackling that.

The next stop, of course, is going to enforcement even for the organizational domains. But that's a story for another blog post.

[1] We have other techniques beside DMARC to detect spoofs of our consumer domains. So it's not actually that vulnerable to spoofing.

[2] In this blog post, I frequently refer to myself in the first person "I", as if I did all this work by myself. That's a major oversimplification. There are many people behind-the-scenes who contribute to DMARC enforcement of subdomains and by no means did I do it all myself. In this blog post, I refer to myself in the first person pronoun for storytelling purposes.

18 months ago, I wrote the following blog post: Why does my email from Facebook, that I forward from my outlook.com account, get rejected.

6 (ish) months ago, I provided an update at An update on the forwarding email problem in Office 365 where I said that we made a change such that Exchange Transport Rules (ETRs) will work with forwarding, that is, the original message content is retained so that a message signed with DKIM will pass at the forwarded-to destination. However, mailbox forwarding does not work.

Today, I am announcing another update - Office 365 mailbox forwarding now works! That is, if you go into your Office 365 web portal and navigate to Settings > Mail > Accounts > Forwarding and start forwarding your email, then a message that passes DKIM/DMARC at Office 365 will also pass at the forwarded-to destination.

I tested it out myself, I sent a message from my Gmail account to my Office 365 account, forwarding to my Hotmail account. It passed DKIM/DMARC whereas a year ago it would have failed. I then sent from my corporate Microsoft account through my personal Office 365 account, forwarding to Gmail. It passed DKIM/DMARC again!

So that part is now working with respect to forwarding.

However, mailbox forwarding does not work. That is, Settings > Mail > Automatic processing > Inbox and sweep rules will not pass DKIM/DMARC when forwarding:

So, if you want to forward your email out of Office 365, my recommendation is to use mailbox forwarding, and not inbox rules. You could always forward the message as an attachment, but that makes it look like a manual forward and usually that's not what you want to do.

Oh, one more thing.

You may have noticed that I've said "Office 365" in this blog post when I've talked about forwarding, but not Outlook.com. That's because Outlook.com's mailbox forwarding does not yet work. We still have to work on that.

But this is a good step forward and should help relieve a chunk of issues our users have been experiencing.

The difference between adding Safe and Blocked senders in Outlook, vs. Outlook.com

If you want to send to Outlook.com, send with a valid From: address

A quick overview of Outlook.com (Hotmail) sender support

A tip for mailing list operators to interoperate with DMARC to avoid failures

Why adding to Blocked Senders sometimes doesn’t block the sender

Fixing a problem with “Unsubscribe” in Outlook.com

Why messages sometimes end up in the Junk folder in Outlook.com even when the sender is on your Safe Senders list

How the Outlook.com Spam Fighters program works

What do we mean when we refer to the ‘sender’ of an email?

An update on the forwarding email problem in Office 365

Disabling unauthorized forwarding in Outlook.com

Should you warn users when they receive an external message?

How we use the Certified Senders Alliance IP reputation list

Does SPF need an update so subdomains can inherit the policy of its organizational domain? I say yes

Does DMARC need an update to handled branded TLDs? I say yes

Showing a question mark ‘?’ in the sender photo when a message is not authenticated

I called my credit card company, and when they verified my identity I got super depressed

Blocking invalid From: addresses in Office 365

How we got to enforce DMARC for sub-domains of Microsoft’s largest consumer email brands

A second update to the problem of email forwarding in Office 365