Blog Post

Exchange Team Blog
2 MIN READ

New Reply-all Storm Protection Report, Settings UI, and Alert Policy

The_Exchange_Team's avatar
The_Exchange_Team
Icon for Microsoft rankMicrosoft
Apr 22, 2022

The Reply-all Storm Protection feature in Exchange Online helps protect your organization from unwanted and disruptive reply-all storms. Last year we updated the feature to give admins the ability to customize key settings for reply-all storm detection and block duration, and in that announcement we noted that several additional updates were planned for a future date. We're pleased to announce that we're rolling out three updates:

  1. A Reply-all Storm Protection Report to track reply-all storms and the messages blocked by the feature.
  2. The ability to customize feature settings within the EAC (in addition to Remote PowerShell).
  3. A mail flow system alert policy to notify admins when a reply-all storm hits your organization.

The report includes charts for detected reply-all storms and associated blocked messages, and a pop-out storm details panel available when you click on a storm name at the bottom of each chart with additional details about each storm. It also includes a CSV-exportable table with key details of each storm such as subject, original message, total messages, and message ID. The report is available in the new EAC under the Reports > Mail flow section. Here's a sample report:

Roll-out of the report starts this week and should finish by the end of May for the WW environments (including GCC), with availability in the GCC-High environment expected by the end of July. More information about the report can be found in Reply-all storm protection report in the new EAC in Exchange Online.

It's been possible to customize key settings for the Reply-all storm protection feature using Remote PowerShell for over a year. Today, we're happy to announce that you can now also customize these settings in the new EAC under the Settings > Mail flow panel, available now, as shown below:

To change these settings, you must have permission to change Transport configuration information (e.g., Set-TransportConfig) as part of the Organization Transport Settings role group (and included as part of the Exchange Admin and Global Admin roles).

Lastly, we're currently working on a mail flow system alert policy that will notify admins when a reply-all storm has been detected and at least one reply-all has been blocked. Like all mail flow alerts it will be customizable so you can configure who gets notified and other common alert parameters. When the Reply-all Storm Protection alert policy is released (by the end of July) it will appear in the Mail flow > Alert policies section of the new EAC.

We hope you find these new updates for the Reply-all Storm Protection feature useful, and we look forward to any feedback or suggestions for future updates you might have.

Exchange Transport Team

Updated Apr 23, 2022
Version 2.0
announcements
Exchange Online
transport
  • tonire's avatar
    tonire
    Copper Contributor
    Apr 25, 2022

    This is a bit off-topic but was there an unnotified change made in the way the "Exchange Online Forwarding" from a mailbox is working? Since last Friday, we see a change in how Exchange Online is forwarding mails.

     

    I will use the example of a sender "x.y@gmail.com" to a recipient "x.y@exodomain.com" with a forwarding configured to "x.y@externaldomain.com"

     

    Before Friday the "From (Envelope)" header of the forwarded mail was an automatically generated one from Exchange Online with an internal email domain.

    In our example, this would be x.y+srs=metml=u4=externaldomain.com=x.y@exodomain.com

     

    After Friday the "From (Envelope)" header is the mail address from the sender. The forwarding, therefore, is now getting rejected in many mail systems as the SPF is wrong. 

    In our example, this would be x.y@gmail.com

     

    Can you please confirm that a change was made there and if this is the new expected behavior? A support ticket for that has been opened on Friday but we got no answer to that yet. 

  • tonire's avatar
    tonire
    Copper Contributor
    Apr 26, 2022

    Hello KevinShaughnessy,

     

    thank you for your detailed post on that. Actually, I really wonder how customers should configure their mail flow if they have a central mail flow to a third-party provider for compliance reasons. So the mail flow is as follows 

    Internet -> third party mailgateway -> EXO -> mailbox forwarding -> third party mailgateway -> forwarded target mail system

     

    In my opinion, it is not possible to keep up that scenario after the change as we can not "force" the SRS on a partner connector in EXO. It is only possible to do it over on-premises Exchange connectors. If we forward over the on-Premises connector after changing SenderRewritingEnabled to true, it is working properly.

     

    Is there a chance to set SenderRewritingEnabled on partner connectors in the future?

     

     

     

  • Sean_Stevenson's avatar
    Sean_Stevenson
    Icon for Microsoft rankMicrosoft
    Apr 28, 2022

    tonire The Relay Pool criteria will always govern the decision to apply SRS so SenderRewritingEnabled will not help here even if it applies for Partner Connectors.  


    I will reach out to the Relay Pool team to inform them of this complex routing scenario.

  • KevinShaughnessy's avatar
    KevinShaughnessy
    Icon for Microsoft rankMicrosoft
    Apr 25, 2022

    tonire , MisterKevin is on to something here wrt to SRS and relay pool (#3 in the SRS blog post). At the end of last week the relay pool was fully enabled world wide and the likely reason for not doing the SRS rewrite is due to the message identified as subject to being routed out via the relay pool. As noted here: Outbound delivery pools - Office 365 | Microsoft Docs

     

    The forwarded or relayed message should meet one of the following criteria to avoid using the relay pool:

    • The outbound sender is in an accepted domain.
    • SPF passes when the message comes to Microsoft 365.
    • DKIM on the sender domain passes when the message comes to Microsoft 365.

    The support engineer handling your support ticket should be able to assist you to configure your scenario properly to avoid getting tagged for sending out via the relay pool. 

  • ExchSupport-SA's avatar
    ExchSupport-SA
    Copper Contributor
    Apr 28, 2022

    Thank you for this Microsoft Team.  I have a request :

     

    Please may you allow the admin to change the setting "Minimum number of recipients" value to as low as 250 ?

     

  • KevinShaughnessy's avatar
    KevinShaughnessy
    Icon for Microsoft rankMicrosoft
    Apr 30, 2022
    ExchSupport-SA RE allowing changing minimum recipients threshold to 250: Thanks for your feedback! We'd love to. However, the current possible minimum setting of 1000 was chosen for a number of reasons. The most important of which is that it reduces the risk of erroneously identifying a legitimate conversation as a reply-all storm. Our analysis suggests that most legitimate conversations take place on DLs with 500 or fewer recipients/members. Enabling the feature for threads with 500 or fewer recipients would significantly raise the likelihood of blocking legitimate conversations, so its value in blocking actual reply-all storms would be cancelled out by a preponderance of false positive detections. A lot of customers would probably get annoyed/upset about the false positives, then either disable the feature entirely or raise the threshold to a higher value (like 1000) to reduce those false positives and their impact on legitimate business communications - both of which would make it moot for organizations with fewer than 1000 users anyway. 
     
     
     
    We do understand that organizations with less than 1000 users also suffer from reply-all storms, and we'd like to expand the feature's protection to those customers as well, so long as we can do it in a way that minimizes the chance of false detections. It won't be any time soon, but I believe it's something we'll be able to do in the future. Thanks again for your feedback!
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     

     

  • Arindam_Thokder's avatar
    Arindam_Thokder
    Icon for Microsoft rankMicrosoft
    May 04, 2022

    tonire - You mentioned it was working last week, so I guess it is related to the recent change that Kevin mentioned earlier and SenderRewritingEnabled is not the solution. Your routing is as following -

    Internet -> third party mailgateway -> EXO -> mailbox forwarding -> third party mailgateway -> forwarded target mail system
    In the above routing scenario, inbound SPF on EXO would always fail because the sender is internet but sending IP as far as EXO sees it is the mailgateway. To avoid the SPF failure, there is a feature called "    Enhanced Filtering for Connectors in Exchange Online" which will help EXO to find the IP address of the actual sender and that would solve the Inbound SPF issue as well as SRS rewriting. I suggest you to configure "Enhanced Filtering for Connectors in Exchange Online". If it's already configured and you are still facing the issue, please open a support ticket. 

  • tonire's avatar
    tonire
    Copper Contributor
    May 17, 2022

    Arindam_Thokder Sean_Stevenson KevinShaughnessy 

    Thanks to all of you together. Configuring the "Enhanced Filtering for Connectors in Exchange Online" was fixing the problem. We have now a correct SPF setup and therefore the mails are not sent through the relay pool.

     

    Thanks for pointing me to the right direction!

     

    Regards

    Toni

     

  • johnivey's avatar
    johnivey
    Copper Contributor
    Jul 30, 2024

    Looking in the options for this feature, there is something in notifications that has no explanation:

     

    Threshold - Number of VIP messages is over ------

     

     

    What does this setting mean, and how does it apply?