Exchange Mail Flow Rule "Any Recipient" Options

[safarijosh]

I'm just another admin and have a few ideas, although I don't understand the use case.

You said:
You want to redirect (to a mailbox, connector, etc) an entire email if any of the recipients are "outside of the organization". Said inversely, you want to redirect an email if all of the recipients are not "inside the organization".You want to redirect (to a mailbox, connector, etc) an entire email if any of the recipients are "outside of the organization". Said inversely, you want to redirect an email if all of the recipients are not "inside the organization".

But those two things are not the same. Do you mean to say for the second version to redirect an email if ANY of the recipients are not "inside the organization"?

Regardless, I would recommend setting up this type of logic with mailbox-level rules. Additionally, I would strongly recommend forwarding instead of redirecting email that arrives externally and is sent externally.

[CraigG1]

Good catch on the all/any typo. I've fixed that important distinction.

Quote:

"Regardless, I would recommend setting up this type of logic with mailbox-level rules. Additionally, I would strongly recommend forwarding instead of redirecting email that arrives externally and is sent externally."

This is specifically for logic that would need to exist in a global transport/mail flow rule, such as redirecting a message to a connector, special purpose mailbox, approval system, etc. These tasks are either impossible or unmanageable via mailbox rules.

[safarijosh]

I'm probably still not understanding the use case, so I really don't know if this would work or how difficult it would be, but...

One potential workaround/approach (ideally tested in a demo EXO tenant) would be to create a mail transport rule that BCCes a mailbox that runs mailbox rules. Or potentially BCC multiple mailboxes each with their own set of rules.  There may be some limitations to this approach depending on the specific mailbox rules in EXO, such as message moderation actions.

Or BCC an entirely different application for all emails that handles business logic for all emails in cases where the mailbox approach wouldn't work (https://docs.microsoft.com/en-us/azure/logic-apps/tutorial-process-email-attachments-workflow).

There's also a way to use Power Automate to take action on an inbound email:
https://docs.microsoft.com/en-us/power-automate/email-triggers

That said, I completely agree with the original suggestion of adding additional functionality directly to mail transport rules. Doing things outside of transport rules lead to kludgy solutions and often more complicated when running on EXO instead of on-prem.

[CraigG1]

Sure, I understand that this is not a requirement that everyone will have, but when you do need it, the behavior is not what you expect or likely need. I'm happy to share some more detail since you're interested. If you look at the below screenshot, you can see some of the options that are really only possible in a transport rule:

You can get very creative with some of these use cases, but just take message approval for example. Let's say you have an overly zealous owner of a startup that want's to approve every message sent that includes an external (outside of the organization) recipient. An employee sends out a message that is addressed to both internal and external recipients. In the current rule options you would say "require approval for any email to a recipient outside of the organization".  The problem is that all internal recipients will still get this message even if the owner decides to reject the message for external recipients. So now you have a situation where the internal recipients received the message, but the external recipients did not. There is no way to say "It's ok if the message is only sent to internal recipients, but as soon as an external recipient(s) is added along with internal recipient(s), I want to approve or reject the entire message". That might be a terrible example, but I think it helps explain what we are missing here.

Our specific example is that we use a product called MailApprove (mailapprove.com) which requires users to self-approve emails that match certain criteria. The product works great, but the flow logic requires some internal/external recipient messages to be processed (and bypassed) unnecessarily.

[safarijosh]

That makes a lot more sense now.

It seems that since this falls into the DLP category, the vendor could probably use the reinjection technique. At least that's what Postini used to call it (when there was Postini). Another more modern example would be the signature manager Exclaimer that can work in a server-side fashion modifying all outbound emails. They have a wizard that configured the appropriate connectors, so the centralized mailflow doc (below) has more relevant screenshots. The normal outbound default send connector in EXO routes mail to the DLP/signature vendor which then sends the mail back to EXO after it is transformed/approved. And because this is on the default send connector, this

https://support.exclaimer.com/hc/en-gb/articles/360028963991-How-to-setup-an-Office-365-subscription...
https://support.exclaimer.com/hc/en-gb/articles/360028964351-How-to-set-up-Exclaimer-Cloud-in-a-hybr...

And here's another example I just found that might also be FAR MORE useful to you depending on how MailApprove works. This vendor suggests creating a rule to determine if the recipient is outside of the organization. I included a screenshot below for a test connector.

https://www.codetwo.com/userguide/email-signatures-for-office-365/connectors-configuration.htm