OOF messages gets droppend with 250 2.1.5 RESOLVER.OOF.ExtToInt; handled external OOF addressed to internal recipient}

Joachim Vadseth 10

We have a hybrid setup where the the on-prem AllowedOOFType is set to External on all domains and IsInternal is set to $true.

In ExO the AllowedOOFType is also set to External and IsInternal is set to $false. Also AutoReplyEnable is $true.

However all external OOF messages is dropped with the message "250 2.1.5 RESOLVER.OOF.ExtToInt; handled external OOF addressed to internal recipient}"

I do not recall having any transport rules to drop these messages. We however have a rule that forces all mail from our domain to be routed back down to our internal mx relay (Proxmox).

Any ideas?

3 answers

Joachim Vadseth 10 Reputation points

2024-09-13T10:39:35.8333333+00:00

New-TransportRule -Name "Exclude OOF Messages" -MessageTypeMatches "OOF" -ExceptIfMessageTypeMatches "OOF" -RedirectMessage '365 til mx04'

New-TransportRule: Ex94914C|Microsoft.Exchange.Configuration.Tasks.ManagementObjectNotFoundException|Couldn't find object "365 til mx04".

Please make sure that it was spelled correctly or specify a different object.

If i read correctly at the new-transportrule cmdlet and the -redirectmessage parameter, it can only be a emailaddress and not a connector name?
Please sign in to rate this answer.

1 person found this answer helpful.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Joachim Vadseth 10 Reputation points

2024-09-26T09:26:04.4766667+00:00

Solved this by adding exception on messages with the header "X-Auto-Response-Suppress" with the value "OOF" and "All" on the existing transport rule.
Please sign in to rate this answer.

1 person found this answer helpful.
Fink, Carl-Christian 0 Reputation points

2025-02-19T08:07:27.64+00:00

Thanks, that did it for me :)
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Jake Zhang-MSFT 9,090 Reputation points Microsoft Vendor

2024-08-29T08:04:14.9533333+00:00
Hi @Joachim Vadseth ,

Welcome to the Microsoft Q&A platform!

According to your description, it sounds like you’re encountering an issue with the handling of Out of Office (OOF) messages in your hybrid Exchange setup. Here are a few things to consider:

In a hybrid environment, the setting can impact how OOF messages are processed. Since you have set to on both on-premises and Exchange Online (ExO), ensure that this configuration is consistent across all domains.

The setting being on-premises and in ExO might be causing a mismatch. This setting determines whether the recipient is considered internal or external. You might want to align these settings to avoid conflicts.

Even though you don’t recall having transport rules to drop these messages, it’s worth double-checking all your transport rules, especially those that might affect OOF messages. The rule that routes all mail from your domain back to your internal MX relay could be influencing the behavior.

Verify the mail flow and connectors between your on-premises environment and ExO. Ensure that the connectors are correctly configured to handle OOF messages. Sometimes, issues in the mail routing can cause OOF messages to be dropped.

As a troubleshooting step, you can create a new remote domain for an external ISP (like gmail.com) and allow external OOF messages. This can help you determine if the issue is specific to your current configuration.

By reviewing these areas, you should be able to identify and resolve the issue with external OOF messages being dropped.

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang
Please sign in to rate this answer.
Joachim Vadseth 10 Reputation points

2024-08-29T10:35:48.49+00:00

I belive these settings are 'aligned'. We dont have any on-prem mailboxes so all mail is sent to the cloud. We have a custom remote domain entry for gmail with the same settings and there is still the same issue. I belive that if there was a transprot rule causing the issue the message trace events would say that it is due to a transport rule? Ive seen that before on other cases, but might be different for OOF.

I can remove my self from the rule that delivers outbound mail back down to us and see if that changes anything.

Thanks.

Joachim Vadseth 10 Reputation points

2024-08-29T11:26:44.9266667+00:00

Seems like the transport rule is the problem, yes. It work flaslessly when I remove my self from it. I cannot however trace a rejected OOF message on our Proxmox relay, so it must be the rule.

The rule description:

Apply the rule if the recipient is external/internal > notInOrganization and the sender domain is contosoc.com or contoso.onmicrosoft.com, redirect the mesage to the following connector <connector name>.

This is based on a Microsoft article I belive from a time back.

Jake Zhang-MSFT 9,090 Reputation points Microsoft Vendor

2024-08-30T08:26:39.8033333+00:00

Hi @Joachim Vadseth ,

Thanks for your response!

Since the transport rule is the problem, you can try to modify the condition of the rule to ensure that it does not affect OOF messages. For example, add an exception condition to explicitly exclude OOF messages. You can use the condition MessageTypeMatches to exclude OOF messages.

The following is an example of a command to create or modify a rule in the Exchange Online Management Shell:

# New-TransportRule -Name "Exclude OOF Messages" -Conditions @( @{Name="MessageTypeMatches"; Value="AutoReply"} ) -Exceptions @( @{Name="MessageTypeMatches"; Value="AutoReply"} ) -Action @( @{Name="RedirectMessage"; Value="ConnectorName"} )

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang

Joachim Vadseth 10 Reputation points

2024-08-30T10:06:41.5233333+00:00

New rule or modify the current one? Since you type 'new-transportrule'..

The current Conditions are :

Conditions : {Microsoft.Exchange.MessagingPolicies.Rules.Tasks.SentToScopePredicate, Microsoft.Exchange.MessagingPolicies.Rules.Tasks.SenderDomainIsPredicate}

Joachim Vadseth 10 Reputation points

2024-08-30T12:07:37.6466667+00:00

Our rule has this conditions:

Conditions : {Microsoft.Exchange.MessagingPolicies.Rules.Tasks.SentToScopePredicate, Microsoft.Exchange.MessagingPolicies.Rules.Tasks.SenderDomainIsPredicate}

Do we just add your conditions in addition to this or?

Jake Zhang-MSFT 9,090 Reputation points Microsoft Vendor

2024-09-02T01:28:51.75+00:00

Hi @Joachim Vadseth ,

Thanks for your response!

I gave you a complete command. You can delete the previous rules and use this command directly, or add the conditions I mentioned to the previous old command.

Best,

Jake Zhang

Jake Zhang-MSFT 9,090 Reputation points Microsoft Vendor

2024-09-04T02:56:31.76+00:00

Hi @Joachim Vadseth ,

Is there any update on this thread? If the issue has been resolved, please mark the helpful replies as answers, this will make answer searching in the forum easier and be beneficial to other community members as well. Thanks for your understanding.

Best,

Jake Zhang

Joachim Vadseth 10 Reputation points

2024-09-04T10:57:58.91+00:00

"A parameter cannot be found that matches parameter name 'Conditions'."

Jake Zhang-MSFT 9,090 Reputation points Microsoft Vendor

2024-09-05T02:20:57.0133333+00:00

Hi @Joachim Vadseth ,

Thanks for your response!

You can try this command again to recreate this rule:

New-TransportRule -Name "Exclude OOF Messages" -MessageTypeMatches "AutoReply" -ExceptIfMessageTypeMatches "AutoReply" -RedirectMessage "ConnectorName"

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang

Joachim Vadseth 10 Reputation points

2024-09-05T11:03:33.1233333+00:00

The "ConnectorName" beeing the connector that we use to send mail back down to us or regular internet connector?

Jake Zhang-MSFT 9,090 Reputation points Microsoft Vendor

2024-09-06T01:27:10.8466667+00:00

Hi @Joachim Vadseth ,

Thanks for your response!

"ConnectorName" should refer to the specific connector used to send the message back to you, not the regular Internet connector.

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang

Jake Zhang-MSFT 9,090 Reputation points Microsoft Vendor

2024-09-09T01:19:12.8+00:00

Hi @Joachim Vadseth ,

Since you haven't replied for a long time, I would like to ask if your problem has been solved. If it has been solved, I hope you can click the "Accept Answer" button on the answer to the useful reply. This will help other users with similar problems in the forum to find solutions to their problems under this answer. Thank you very much for your understanding and improvement of the forum environment! Have a nice day!

Best regards,

Jake Zhang

Joachim Vadseth 10 Reputation points

2024-09-11T11:12:41.5533333+00:00

New-TransportRule: Cannot process argument transformation on parameter 'ExceptIfMessageTypeMatches'. Cannot convert value "AutoReply" to

type "Microsoft.Exchange.MessagingPolicies.Rules.Tasks.MessageType". Error: "Unable to match the identifier name

AutoReply to a valid enumerator name. Specify one of the following enumerator names and try again: OOF, AutoForward,

Encrypted, Calendaring, PermissionControlled, Voicemail, Signed, ApprovalRequest, ReadReceipt"

Jake Zhang-MSFT 9,090 Reputation points Microsoft Vendor

2024-09-13T06:39:27.37+00:00

Hi @Joachim Vadseth,

You need to modify the specific command according to your actual situation. For the automatic reply email type, you should use "OOF", which stands for "out of office".
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

OOF messages gets droppend with 250 2.1.5 RESOLVER.OOF.ExtToInt; handled external OOF addressed to internal recipient}

3 answers

Your answer