thank you for your suggestion; it could be the easiest way not to lose incoming messages. I'm using message filters only to manage specific exceptions to mail flow policies, such as blacklists or whitelists, but I see no drawbacks in coupling bounce verification with a filter for being more effective.

Are you sure, that you will loose Out-Of-Office-Messages?
I can't follow this. If I write a mail to an external mail-recipient the IronPort with activated Bounce Verification add the self choosen "address tagging key" to the outgoing message.

If the recipient send a OOO-message back, the appliance should recognize this as a valid and "expected" message.

Am I wrong?

You should not be wrong, at least for out of office: RFC 3834 (not aware of it when I posted first, sorry) says that automatic responses should be sent to the "Return-path" field which is set by the receiving MTA based on the SMTP FROM command and therefore is "bounce tagged".
When it comes down to return receipts however RFC 3798 requires that a "Disposition-Notification-To" message header be placed to receive a "return receipt", and it also says that the return receipt "MUST be addressed (in both the message header and the transport envelope) to the address(es) from the Disposition-Notification-To header from the original message"; moreover it says that "The envelope sender address of the MDN MUST be null". This means that a return receipt is handled by the ESA as a bounce because of the null MAIL FROM, but unfortunately the "Disposition-Notification-To" header is not "bounce tagged" and that leads to an invalid bounce.
And then, after RFCs, there is the real world...

FYI. Some observations after running bounce verification for a little while:

- most out of office messages (at least exchange) are sent to the "From" address from the headers, not the BATV-tagged address. However, most don't have a null sender address either, so they don't trigger BATV and are allowed through.
- there was an exception and I haven't quite figured out why yet. One user does send out of office messages with a blank sender - which are blocked by BATV. But it only happens to one person. Maybe its an exchange 2003/2007 difference.

Just set BATV to insert an X-header and create a content filter that quarantines the bounces for testing so you don't really loose any messages. If required you can still create exceptions in that filter if you detect problems.

Thank your for that information.

BTW: Do you have any news about the important problem "IronPort has identified an issue with Bounce Verification that affects all versions of AsyncOS for Email Security Appliances and Security Management Appliances." from last saturday?

Customer Support is expecting an updated build to be made available during (Californian) Thursday.

I enabled bounce verification about two weeks ago, inserting a custom header and then using message filters to check the e-mail that failed BV.
here are my findings, for those that might be interested:
- I had to build a filter to allow return receipt to pass through, otherwise they would be dropped; I asked for an enhancement to tech support in order to automatically handle disposition notifications;
- I found out many incoming "automatic forwards" (don't know how to define them; suppose an external account where you setup a "send incoming messages to" rule pointing to your internal accounts) that cannot be saved because they come from too many sources;
- some autoresponders seem to fail bounce verification; I didn't investigated it in detail but it seems to be related to webmail sistems;
- many bounces aren't correctly handled by BV because of BV-tagged addresses whose case is modified by the remote server; this has already been reported to tech support and should be fixed in release 6.3;
I got a strange behaviour from an antispam software that marked all BV-tagged addresses as spam and therefore forced me to enable destination controls without address tagging for a couple of domains and I found also some service providers that check the sender address of their customers (who are also my users..).
Many of these issues were known before BV activation so they caused no troubles; after all I think of BV as an effective solution, though not perfect (I'm not sure it could be perfect anyway).

I asked for an enhancement to tech support in order to automatically handle disposition notifications;

I got a strange behaviour from an antispam software that marked all BV-tagged addresses as spam

JFYI:

IronPort Systems announces a hot patch release of AsyncOS 6.1.0-306 for all Email Security Appliances (C-Series and X-Series) and Security Management Appliances (M-Series).

I'm curious about how this could be handled in a way that wouldn't allow spammers to subvert the process to get around BV entirely.

This sort of thing really ticks me off. How do vendors get away with such inept excuses for antispam software?

IMO Ironport engineers did as much as they could to stop spam bounces and their approach is smart

I guess that this could be handled by tagging "Content-Disposition-To" headers as well as the sender in the SMTP command.

It might be also an aggressive configuration that matches smtp commands and headers and treats a mismatch as spam;

Actually, all they did was implement an existing specification called Bounce Address Tag Validation (BATV). Any changes to handle read receipts would need to be done there.

It's edge conditions like this that have deterred me from turning on BV. It still has some rough edges that need to be cleaned up.