Aracılığıyla paylaş


Recipient Notifications

The ability to send a notification to the recipient when a transport rule triggers. This is a request that we have received from a lot of customers, and I’m happy to let you know that it is now rolling out in the form of an action in EOP transport rules. Sweet!

Recipient Notifications

Let’s say you have a transport rule that quarantines all inbound messages with an executable attachment. In the past there was no way to automatically notify your users that a message destined to them had been redirected to the quarantine because of your transport rule. Now, with Recipient Notifications, your transport rules can send a notification to the recipient when they trigger.

Configuration

When creating a transport rule, you will notice a new action called “Notify the recipient with a message…”


 
As an example, if we want to quarantine messages destined to our users that contain executable content, and want to notify them when this happens, our transport rule could look like this.


 
In this rule contoso.com is our own domain. Here’s what the notification text looks like in the above rule.

A company policy blocked an inbound message to you - Executable content not permitted.<br><br>

Date: %%MessageDate%% UTC<br>
From: %%From%%<br>
To: %%To%%<br>
CC: %%Cc%%<br>
Subject: %%Subject%%

And here is what the notification looks like that the recipient will receive when this rule triggers.


 
You’ll notice that I was able to insert information from the original message into the notification using variables. Let’s look next at what customization is possible.

Notification customization

Variables can be added into the notification text to include information from the original message. The following variables are supported for recipient notifications.

Type of Information

Configuration
The sender of the message for which the notification is being generated. %%From%%
The recipients listed on the "To" line. %%To%%
The recipients listed on the "Cc" line. %%Cc%%
The subject of the message for which the notification is being generated. %%Subject%%
The headers from the original message. %%Headers%%
The sent date of the original message. Time is in UTC. %%MessageDate%%

Summary

If you don’t see the recipient notification action yet in your transport rules don’t panic. This feature only just lit up in my test tenant this past week and will still be rolling out. Enjoy this new capability!

Resources

TechNet documentation has not been updated yet, but once it has I will post links here.

Comments

  • Anonymous
    January 01, 2003
    Hi Andrew,

    The sender was outside my organisation..

    A workaround from your support team is to run this command on my on-premise server: "set-SenderFilterConfig -BlankSenderBlockingEnabled $false", This then allows it to receive messages with blank senders.

    Now i get notifications and the headers just say this:
    To:
    Sender: Microsoft Outlook
    Message-ID:

    This solution seems odd to me though, it just looks wrong having no sender address to me.
    • Anonymous
      May 25, 2017
      Why would Microsoft code this to send as a blank sender when recognising that email with a blank sender is an issue !!? They've essentially broken a level of protection. Do I disable the filtering on my Edge servers so that we can receive the notifications or not ...... what a pain.
  • Anonymous
    January 01, 2003
    Hi John, this can be accomplished with a transport rule. If you want to specifically target internal senders, you could create a transport rule that looks as follows. I'm assuming your own domain is contoso.com.

    IF THE MESSAGE...
    If sender domain is contoso.com
    AND
    Has an attachment with a file extension that matches one of these values: 'exe'

    DO THE FOLLOWING...
    Reject the message and include the explanation 'Unsupported attachment detected' with status code 5.7.1.

    The above rule would reject message coming from your own domain (contoso.com) and reject them. The sender will receive an NDR with the explanation that you specify in the transport rule.
  • Anonymous
    January 01, 2003
    Hey Mark, that's very interesting, I haven't been able to replicate that behavior with my testing. In your testing, is the sender from inside or outside your organization?
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    Hi there Erlend, I just replicated your rule in my test tenant and did not see what you experienced. In my test, the sender received the rejection and the recipient in my tenant received the notification that I had configured in the rule. Are you still having problems with your rule?
  • Anonymous
    January 01, 2003
    Useful article. Thank you.
  • Anonymous
    January 21, 2015
    Sweet! :)
  • Anonymous
    January 22, 2015
    Hello. I've enabled this in our "block zip/rar attachments" rule, but the notification is never sent.

    The actions in our rule is 1) reject the mail with the following message "blah blah", 2) Notify recipient .
    The mail is rejected, and the sender gets a message from postmaster explaining this, but action #2 never fires... What could be wrong?
  • Anonymous
    April 02, 2015
    I too find the recipient never receives the notification.. looking at the logs it is failing as the sender address for the notification is missing.. logs state sender is "<>" !!
  • Anonymous
    April 09, 2015
    This is frustratingly close to what we need. If one of our users is attempting to send blocked attachment types we would much prefer to notify the SENDER with a message, rather than the recipient. Is there a way to achieve that? I only see Policy Tips which does not allow enough characters for a proper message.
  • Anonymous
    July 12, 2015
    When will we get this same functionality in Exchange on premises? It's just what I'm looking for at the moment.
  • Anonymous
    September 09, 2015
    The comment has been removed
  • Anonymous
    June 03, 2016
    can we also include what kind of attachement extension was blocked by rule?
  • Anonymous
    May 18, 2017
    This works well for inbound messages. But what about outbound? I realised today I had not scoped this rule for inbound only; an internal user sent a message which ended in quarantine and the external recipients received notifications from the postmaster that their message was blocked.In this case, I want to "Notify the sender with a message..."Is there anything like this?[I tried with Policy Tips and got this error: "The NotifySender action isn't compatible with 'AttachmentHasExecutableContent' predicate." And I'm not sure it would have worked on mobile clients either.
  • Anonymous
    November 23, 2017
    Thank you for your article, Andrew. I configured our notification to our needs and it works good. But I miss one thing: We block i. e. old Office file formats like DOC or XLS. But the recipients don´t know the exact reason for the blocked email, so that they can decide to communicate with the sender before they contact the local IT.When I look at the quarantined email in EOP interface, I can see the attachments. Do you know, if there is also a variable for the attachment which I can use in the recipient notification to inform the users, which files are the reason for blocking the particular email?
    • Anonymous
      November 24, 2017
      I don't believe there is a variable which links to the attachment name unfortunately. I'look into this though and post back here if I find one.
  • Anonymous
    December 31, 2018
    Thx for the article, Andrew. The content is still interesting, three years on. I'm replying to agree with John Willoughby's comment below; MSFT could give us the best of both worlds if a sender-notification action were available. This would be great to notify internal senders that their content contained (e.g.,) PCI data and was acted upon in whatever way. Security & Compliance Center allows the admin to create lengthy notice messages to the sender, but doesn't allow dynamic content of the sort available here -- the %%parameter%% attributes. I'll post this over at User Voice as well, as an alternate means to get some traction for this requirement.