bounce verification and receipt notification

Unanswered Question

Hi all,
I'm planning to enable bounce verification on my C300 (AsyncOS 5.1.2) and I'm trying to figure out how to keep everything running.
My problem is that the advanced user guide states that "AsyncOS consider bounces as mail with a null Mail From Address [...]" and I found out that receipt notifications are sent with a null mail from address and the same happens for out-of-office messages, so I think I would lose those messages.
Setting sender groups is not an option to preserve them, since they can originate from any mail server.
Has anyone had these kind of issues with bounce verification ? is there any workaround ?

TIA

Andrea Murari

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
staylor_ironport Tue, 04/15/2008 - 13:26

Hi There,
You don't have to reject the messages immediately at the rcpt-to stage, what you can choose to do is insert an X-Header and then use that within content filtering in the work queue.
For example if X-Header and Subject contains: out of office then deliver otherwise drop.

Hope that helps

Pat_ironport Tue, 04/15/2008 - 16:26

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...

Bart_ironport Wed, 05/07/2008 - 21:05

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.

Pat_ironport Thu, 05/08/2008 - 08:06

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?

meyd45_ironport Thu, 05/08/2008 - 10:51

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).

Donald Nash Thu, 05/08/2008 - 21:21

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

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.

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

This sort of thing really ticks me off. How do vendors get away with such inept excuses for antispam software?
Pat_ironport Fri, 05/09/2008 - 07:12

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).
Do we have a general thread for such announcements (that I have missed)?

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.

I guess that this could be handled by tagging "Content-Disposition-To" headers as well as the sender in the SMTP command.
IMO Ironport engineers did as much as they could to stop spam bounces and their approach is smart as it is designed to be proactive; unfortunately those SMTP extensions seem not to be consistent with respect to senders and recipients: some use the SMTP level ones, while others use eh SMTP body headers. I am not an SMTP guru and I didn't dig too deep into RFCs and therefore there may be underlying reasons for these behaviours that I am completely missing.

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

It might be also an aggressive configuration that matches smtp commands and headers and treats a mismatch as spam; I neither condemn nor justify them, i was just reporting what happened since BV activation so that other citizens could get benefit from it.
Donald Nash Fri, 05/09/2008 - 17:16

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

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.

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

Ugh, that would mean digging into the message contents rather than just dealing with the envelope. It could be done, but it would mean doing a lot more work. BATV as currently specified doesn't have to parse the message contents, since it deals only with the envelope.

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.

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

There is no requirement that the addresses in the envelope match those in the headers. And in fact, they quite often do not match (forwarded mail is the most common case).

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.

thanks for the link; (obviously enough) I was unaware that there were those kinds of efforts.

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.

At first I was not interested in using BV because of many concerns about the way our legacy systems (try to) use smtp, but suddendly we were flooded with invalid bounces (i've been reported of more than 200 messages a day for a single user); at that point it was the only choice I could think of (I was lucky enough that a feature like that was available).

Actions

This Discussion