Bounce Verification and Out of Office notifications

[Tony Kilbarger]

From doing some searching on this forum, I have seen several discussions about Bounce Verification blocking Out Of Office messages specifically when sending to Exchange recipients.  I am currently working with a user who was waiting on a reply from a vendor for some time and when the vendor finally replied she found they had been sending OOO notices telling her who to call in their absence but the notices were blocked as invalid bounces.  Has their been any more developments in this area?  Does Exchange 2010, 2016, ... still use the Mail From address to send the OOO notice to and not the BATV Return Path value?  Is there a work around from my perspective?  I've read ideas like tagging bad bounces with a header then if that header is there and the subject is not Out Of Office then drop.  What other types of messages are we likely dropping as a result of BATV?  We have had this in place many many years, sounds like it's time to re-evaluate what value this is adding or removing.

Thanks for your time.

[suporte2r]

I would first recommend that you search the mail_logs looking for actions that the device took about the OOO.

If you confirm these were rejected as invalid bounces, then you have a start point.

But, in regards to how Exchange works this is something to review in the MS Exchange documentation.

Some references:

RFC 3798 - The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be null (<>), specifying that no Delivery Status Notification messages or
other messages indicating successful or unsuccessful delivery are to be sent in response to an MDN.

RFC 3834 - Section 4 says auto-replies SHOULD be sent to the return path.

RFC 3834 -  section 7 gives an example of a Personal Responder (which is what the Out of Office Assistant is), and it uses a null sender, and the Return-Path of the subject message as the recipient.

RFC 2821 - Section 4.5.5 says non-standards-track autoreplies SHOULD be sent with non-null return paths.

So, to me, this is something to be fixed on MS side of the conversation. But since that is not at your control, you would need an exception at your end. Please refer to:

https://supportforums.cisco.com/t5/email-security/out-of-office-replies-dropped-by-ironport-bounce-verification/m-p/2862247/highlight/true#M12902

As I believe that could be an option for you.

As always, please be diligent in applying any configuration change to your production environment.

Hope that helps.

-Valter