Exchange Transport News from Microsoft Ignite 2019

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

With the number of emails delivered daily worldwide forecast to grow 18% by 2023, the criticality of email for businesses remains as strong as ever! And the Microsoft Exchange Online Transport team loves nothing better than to continue to improve our email service and introduce new and useful email features that help make your organization safe, smart, and secure. In fact, that's what our session at Microsoft Ignite 2019 is all about!

At Microsoft Ignite 2019 the Transport team showcased how the cloud improves the email experience for end-users and email admins. In our session BRK3312 - Office 365 email enhancements that makes your organization smart, safe, and secure we announced the following features, most of which will be coming your way in the first half of 2020.

Exchange Online Email Enhancements for End Users

  • Support for Plus Addressing
  • Send from proxy address (alias)
  • Message Recall in Exchange Online
  • Reply-All Storm Protection

Email Enhancements for Admins

  • Modern Exchange Admin Center (EAC) Portal
  • Customizable Recipient Limits
  • Securing SMTP Auth Submissions

Let's take a look at the awesomeness that each of these brings to the email party.

Support for Plus Addressing in Exchange Online

We love hearing from our customers about what features or improvements they'd like to see in Exchange Online. And boy, did we ever hear from you about this one! Over 5,000 votes for this feature on our User Voice feedback site! (you see, we really do look at that stuff, so make sure you get involved)

Plus address support allows you to add a suffix to the local-part of your email address to create a child address or disposable address which you can use as your email address. For example:

Standard address: kimakers@contoso.com

Plus Address: kimakers+MotherBones@contoso.com

Now, when Kim signs up for the MotherBones.com newsletter, she can use the special  address, kimakers+MotherBones@contoso.com to sign up, instead of her standard email address. She can then create an Inbox rule to route all messages sent to this + address (kimakerts+MotherBones@contoso.com) to a folder of her choice. It's a great way to more easily manage your Inbox, track marketing or sales campaigns, and even help you identify when a Web site or service account sold (or accidentally leaked) your email address to a spammer. . .er. . .uh. . .a legitimate third-party marketer who is now sending you endless emails about loan offers and other items you're most surely interested in. ;)

Plus addressing support is already available for Outlook.com, but it's a bit trickier for Exchange Online. You see, the RFC (the collection of rules for all things interweb) says that having the "+" character in an email address is a perfectly valid character to use in email addresses as part of a standard email address. But plus addressing treats the "+" sign as a special indicator where the standard email address used for routing is to the left of the "+" while everything to the right is ignored for routing purposes. And it turns out there are quite a few Exchange Online customers who have email addresses in their organizations that have "+" signs in them. So, as we roll out plus addressing support in Exchange Online, we'll be working with these customers to make sure we don't inadvertently break any of their mail flow.

Word of advice: If you don't have any email addresses in your organization that have a "+" sign in them already, great! Don't start now! Keep your email addresses free of "+" signs, so that when support for plus addressing rolls out in 2020 you and your organization's end users will be able to take full advantage of the coolness plus addresses offer without anyone's mail flow breaking.

Send from SMTP Proxy Address (alias)

OK, we admit it – sometimes we get a bit embarrassed about some less-than-critical-but-still-annoying issues that have been out there for a while that we haven't addressed yet. Actually, we get a lot embarrassed about it and sometimes would rather slink back to our shared workspace desk (offices are so 20th century) and immerse ourselves in the depths of code so as to not face the torches and pitchforks of real customers. But face it we must, and at Microsoft Ignite 2019 we've got a bunch of email enhancements that we're finally doing something about! Supporting the ability to send from an SMTP proxy address (alias) and having the that address be preserved in the recipient's FROM and REPLY TO is one of those enhancements!

Sending from an SMTP proxy address or alias is useful for multiple scenarios. The first is to send from a team alias rather than your own. Let's say instead of sending from her standard alias kimakers@contoso.com, part of Kim's job is to send out emails that appear to come from her team, the Communications Team. So instead of sending from kimakers@contoso.com, she wants to send an email from CommsTeams@contoso.com. Another common scenario for sending email using an alias is mergers and acquisitions, where one company acquires another company and some employees from each company need to be able to send email from both of the companies' domain names. For example, Contoso acquires Northwind, and Kim now needs the ability to send as both kimakers@contoso.com and kimakers@northwind.

While you can set up an SMTP proxy address for Kim, she wouldn't be able to send from it using the native capabilities of Outlook, Outlook on the web, or Outlook Mobile. And even if she used a spiffy Outlook plug-in to send the mail from an alias, in some circumstances the recipient would see her primary address in the FROM and REPLY TO fields, kimakers@contoso.com, instead of the intended kimakers@northwind.com.

Addressing this (no pun intended) is a journey – we're going to start with Outlook on the web (OWA – yes, we know the acronym doesn’t make sense, but we all know it as OWA don’t we?), where coming in the first half of 2020, OWA will natively support the ability to select an alias from a drop-down list in the compose panel in OWA, and when the recipient receives it, the FROM and REPLY TO fields will show that alias instead of the primary SMTP address. It'll look something like this:

transport1.png

Message Recall in Exchange Online

Outlook introduced Message Recall around 20 years ago, and despite the fact we all seem to think it doesn’t work, we’d like to think it's still better than doing nothing at all when you really goof up. In Office 365 we once tracked over 800,000 recall attempts in one day! So yeah, people are still goofing up and to say it's still a popular feature is an understatement! But wouldn't it be great if the recall worked better for more recipients, and was easier to understand for whom it failed and for whom it succeeded? Well. . .here's another of those long-standing issues that we're addressing, thanks to the power of the cloud!

The current Message Recall feature is actually client-based, and only Outlook for Windows supports it today. The sender needs to use Outlook to recall a message, and the recipient needs to use Outlook in order for the recall to work (there are some other conditions that must be met as well, discussed in this article). Not great, we know.

But thanks to the cloud we now host millions of end user mailboxes in Office 365 and are able to implement a cloud-based message recall in the Office 365 datacenters that will recall the message directly from Office 365 mailboxes. It won't matter which email client the recipient uses to sync with their Office 365 mailbox (whether Outlook, OWA, Outlook Mobile, or some other email client)! Our initial testing of this feature with Microsoft employees shows nearly double the number of successful recalls compared to the Outlook client-based version of Message Recall. Yep, Microsoft employees goof just as much as anyone else, and also need this feature to work better than ever! I like to say with Message Recall in Office 365 "It actually now works. . .better.TM" :) It's not 100% - for example, we'll still honor the condition that if the message has been read by the recipient we won't recall it - let's just say a few hours in a windowless room with representatives from our legal team ultimately convinced us of that. ;) But it's a lot better than before, and we plan to continue honing the feature in the future to make it even better and more usable in additional scenarios.

In addition to better recall success, we're also introducing an aggregate recall status report to make it easier to find out for whom it succeeded and for whom it failed. The Outlook feature today sends sindividual email messages for each success or failure it registers – pretty unwieldy if the recall is for more than a dozen recipients. The new aggregate Message Recall status report will look something like this:

transport2.png

Reply-All Storm Protection

Anyone here remember BedlamDL3? Me too! Ha, ha! OK, not everyone was around in 1997 to either experience it or hear about it, but BedlamDL3 was probably the first recorded Reply All storm that hit the news in a big way. A brief history follows.

In 1997 an employee at Microsoft noticed that he was on a distribution list (DL) called BedlamDL3. He couldn't see any members in the list nor the owner, so assuming it was just a random empty DL he sent an email to the DL asking why he was on it and could he be removed from it. The belief was that only the owner would get the mail and then remove him from it. What he didn't know is that the DL included one-quarter of all Microsoft employees, around 13,000 members at that time. So all 13,000 members got a copy of his request to be removed from the DL, and others started to use Reply All to also ask to be removed - the now iconic "Me, too!" requests. Other "heroes" chimed in (using Reply All) to say how bad it was to Reply All to the thread and to please stop, and so on, ad nauseum. Within an hour 15 million messages were generated, 195 GB of data, and it brought Microsoft's Exchange servers to a slow crawl. It took two days to clean it all up.

After the BedlamDL3 incident, the Exchange team introduced a number of features to help reduce the chance of such an occurrence from ever happening again, for Microsoft and for all Exchange customers. Hidden Distribution Lists, Recipient Limits, and DL sender restrictions were just a few of the measures introduced. And since then, the number of Reply-All storms and their severity have been greatly curtailed. Yet, human beings are. . .well, human. So people still get caught up in Reply-All storms, asking to be removed from a DL or to be removed from the thread that's going on and on, etc.

So, the Exchange Online Transport team decided we'd help us poor human beings out, and again thanks to the cloud and the vast scale and telemetry in Office 365 that we're able to evaluate and work with, we're introducing yet another feature to better help thwart, or at least reduce the impact of, Reply-All Mail Storms. We call it: Reply-All Storm Protection.

Reply-All Storm Protection in some ways sounds pretty simple (and cool), but there's some pretty intelligent stuff going on in the background, in the cloud, that makes it possible:

  • For an organization in Office 365, we'll identify what looks like might be a Reply-All storm conversation
  • We'll then temporarily block anyone from replying to all members of the conversation, sending a bounce message (NDR) back to anyone who tries

So when we detect what looks like it might be (or become) a Reply-All storm, anyone who subsequently attempts to reply to everyone will get an NDR back instead, basically telling them to stop trying to Reply All to the thread. Here's an example of what that NDR might look like once we ship the feature in the first half of 2020.

transport3.png

We'll maintain the temporary block (and sending of NDRs) active for a number of hours, a "cool-down" period, to let the storm pass so people can get back to their regular work. Because while the scale and reliability of Exchange Online servers now ensure the service isn't impacted by a Reply-All storm, your business might be – whether because your employees become overly distracted with it, or because the excess mail volumes generated kick in mail throttling specific to your organization. But with Reply-All Storm Protection, the chance of either of these happening in the future will be significantly reduced if not eliminated.

Modern Exchange Admin Center (EAC) Portal

When we introduced the Mail Flow Dashboard, Insights, and Reports a few years ago, there was a compelling argument to place the features inside of the Security and Compliance Center (SCC). A lot of the day-to-day concerns for mail flow management are about email security, fighting spam and viruses, checking for hacked accounts, etc. And we heard from plenty of customers, usually those more focused on security, that they appreciated having the Mail Flow Dashboard and new Message Trace in the SCC, where they spent a lot of their time. Yet, we also heard loud and clear from a lot of email admins that these features should really be in the Exchange Admin Center (EAC), not the SCC.

As you likely know (and saw earlier in the week), the EAC team has been engaged in a modernization of the EAC – to adopt a similar look and feel as the rest of the Office 365 admin centers, make it better organized and improve feature discoverability, and enhance its overall design and user experience. The Transport team decided that now was a good time to address the concerns we'd been hearing from email admins in this area, and we have decided to move all the Mail Flow assets into the new, Modern Exchange Admin Center (EAC) portal. It won't happen overnight, but over the course of the first half of 2020 you'll find more and more of the Mail Flow features (like the Dashboard with some insights and reports, and Message Trace) will appear in the Modern EAC as it moves through Preview and eventually into general availability later in 2020. To see a preview demo of this, check out our Microsoft Ignite 2019 session video here (starts about 25 minutes in).

Customizable Recipient Limits

As mentioned earlier, after the BedlamDL3 Reply-All storm incident in 1997, one of the features Exchange introduced was the Recipient Limits setting. This limits the number of recipients someone can send a message to. In the Office 365 multi-tenant service this is set to 500 for all mailboxes.

Over the last few years, hundreds of customers have opened support tickets asking us to change this limit for some or all of their mailboxes. On the User Voice site, it's also one of the most requested Transport related feature. While some want to increase the limit for a handful of mailboxes (to better support regularly occurring mailings, like end-of-the-month billing statements and such), the majority actually want to reduce the number, to, say, 50 or 20, as a way to better protect against potential spam-like abuse from rogue employees or hacked accounts.

We're excited to announce that we'll be opening this up to customers so they can customize this setting for all mailboxes in their organization! The setting can be found in EAC > Recipients > Mailboxes > Mailbox Features > Mail Flow, and once made available in the first part of 2020, admins will be able to customize the Recipient Limit from 1 to 1000 for individual mailboxes. Bulk editing of multiple mailboxes will become available in the Modern EAC later in 2020. And of course the option to edit this for individual mailboxes, bulk edit for multiple mailboxes, and to set the default for new mailboxes, will all be available via Remote PowerShell. Examples of each are shown below:

Update a single mailbox

 

Set-Mailbox kimakers@contoso.com -RecipientLimits 20

 

Update multiple mailboxes

 

(Get-Mailbox | where {$_.RecipientTypeDetails -ne "DiscoveryMailbox"}) | % {Set-Mailbox $_.Identity -RecipientLimits 10}

 

Update the default for new mailboxes created in the future (all plans)

 

Get-MailboxPlan | Set-MailboxPlan -RecipientLimits 50

 

While the Exchange Online Protection service already includes features to help detect abuse by a rogue employee or a hacked email account, making recipient limits customizable for the email admin is another way we're helping to make your organization's email safer.

Securing SMTP Auth Submissions

Something else we're doing to help secure your email in Exchange Online is a taking a multi-phased approach to better secure SMTP authenticated submission. SMTP authenticated submission is most commonly used by applications or devices (printers, scanners, etc.) to submit email into the Office 365 service. It only requires login credentials, and doesn't support modern authentication (e.g. Multi-factor Auth (MFA), certificate-based auth (CBA), etc., enabled in Exchange Online via ADAL and OAuth 2.0). So this leaves any account that's using SMTP authenticated submission more vulnerable to abuse and hacking than accounts that exclusively use the other protocols that do support modern authentication.

To help reduce the potential for exploiting the less secure SMTP authenticated submission protocol, last year we introduced the ability to disable SMTP authenticated submission for both your organization and for individual mailboxes via Remote PowerShell cmdlets:

Disable SMTP authenticated submission at the organization level

 

Set-TransportConfig -SmtpClientAuthenticationDisabled $true

 

Disable SMTP authenticated submission per mailbox

 

Set-CASMailbox <mailboxname> -SmtpClientAuthenticationDisabled $true

 

While the mailbox level setting has been exposed in the EAC UI for a few months now, we discussed this in more detail during our presentation at Microsoft Ignite 2019. Go listen to the recording to hear about the plan and schedule for how we're going to better secure this protocol (disable it) by default, first for new organizations onboarding onto Office 365, then later for tenants with no SMTP authenticated submission usage. We also expect in the future to deliver more tools, reports, and optics to help email admins gain better insight into SMTP authenticated submission usage in their organizations. This will help better plan for possible future disablement of the protocol for those accounts using it, plan for future upgrades to devices that support modern authentication, or more readily monitor any potential abuse or hacks of those accounts.

So we think both admins and end users will find something to like in our roster of enhancements that we announced at Microsoft Ignite! And we're not done yet! It really is a journey, and we plan on doing even more work in the future for both admins and end-users, building on the work we announced this year at Microsoft Ignite, as well as coming up with new enhancements – all of which we believe will continue to help make your organization safe, smart, and secure.

Kevin Shaughnessy

The Exchange Transport Team

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.