Out Of Office replies dropped by Ironport Bounce Verification

[anthony.livingstone]

A customer has 2 x C170's clustered.

Bounce Verification is enabled with a Tag / Key entered.

Normal email flow and replies to emails work fine.

Inbound Out Of Office replies to the customer are being blocked by the Ironport with the following error:

(Screen shot of message tracking details attached.)

Message 15577043 on incoming connection (ICID 50870809) encountered invalid bounce. Recipient address <ABTTest@xxxxxxx.com> rejected by bounce verification.

Receiving aborted by sender 01 Apr 2016 10:48:21 (GMT +01:00)

Incoming connection (ICID 50870809) lost.

We have tried creating a new Bounce Verification key but this made no difference.

What should we be looking at???

Cheers!

[Mathew Huynh]

Hello Anthony,

Are the Bounce verification tagging keys defined at the cluster level?

And also is bounce verification properly tagging your emails on the destination controls.

Regards,

Matthew

[martin.eppler]

Hello Anthony,

I'd suspect that this observed behavior has nothing to do with the Bounce Verification keys, but more how Microsoft has implemented their out-of-office-replies and calendar invites in Exchange server starting Exchange 2010.

Microsoft has decided to use an empty envelope sender address when sending out out-of-office replies and calendar invites. But these messages do not contain the Bounce Verification tag which would be expected by the Email Security Appliance. So these messages are then declared as invalid bounces.

There is no real solution for this unless Microsoft changes the implementation on their end (e.g. by using a non-empty envelope sender address). Until then the workaround would be to disable Bounce Verification for this particular destination by for instance setting up a new Sender Group containing the IP address(es) of the domain in question in which Bounce Verification is disabled.

Best regards,

Martin

[anthony.livingstone]

Thanks Martin,

That's really bad news as this is a quasi govt.organisation with offices worldwide - there would be no way of identifying all other organisations and companies using 2010 or above and write rules for them and manage this going forward as more destinations are identified.

So now it seems they have a choice - keep bounce verification on and not get OoO for most destinations or turn it off and risk Backscatter.

Regards,

Anthony.

[martin.eppler]

Hello Anthony,

well, the story is two-folded. Microsoft has changed the way how these messages are sent in Exchange 2010 in order to comply with RFC3798 (http://www.ietf.org/rfc/rfc3798.txt). This step caused (and still causes) issues when messages leave the Exchange environment and are sent across the internet. Most SMTP products assume that an empty envelope sender correspond to a non-delivery report ("bounce"). But this is only half of the truth, as both delivery status notifications (DSN, e.g. the non-delivery report) and message disposition notifications  (MDN) - as outlined in RFC5321, section 4.5.5 (https://tools.ietf.org/html/rfc5321) - use an empty envelope sender. So in fact Microsoft is right here when reading the RFCs. 

Both RFCs state that the DSN and MDN are returned as a reply to an previous message. This denoted previous message contains a Bounce Verification tag in case an Email Security Appliance had this feature enabled.

Now we have to deal with two different issues:

1. when an out-of-office reply is sent by Exchange, it contains an empty envelope sender but lacks the Bounce Verification tag from the previous messages. In case Microsoft would decide to include this Bounce Verification tag when sending out DSNs or MDNs (as they do for non-delivery reports), the Email security Appliance could accept the message instead of marking it as an invalid bounce.

2. calendar invites are not sent out as a reply to a previous message, so they do not qualify as DSN or MDN. Instead of sending them with an empty envelope sender address, they should therefore contain a valid sender address here. 

Best regards,

Martin

[exMSW4319]

I parked the issue by changing the feature to just add a header with the intention of incorporating that into some quorum logic at a later date.

It's good to see an explanation of exactly how the feature came to break - thanks for the information, Martin.

[hakan.topcu]

I found this conversation, that has been written some years ago, and the issue with the OOO-Messages and the Bounce Verification feature has also been reported to me recently. Is there a solution or workaround available meanwhile?

Thanks in advance / Best regards, Hakan