Messaging Gateway

I'm trying to figure out how to strip Disposition-Notification-To: headers (otherwise known as Read Receipt requests) under certain conditions, but I don't see a Delete Header option under compliance. What would be the best way to do this? The goal is to delete the header and then pass the message along normally. Thanks

Hi Doni,

Sounds like an enhancement request to me as currently you can not delete a header using the compliance rules.

However, using the support account, it may be possible to create a sieve script to delete specific heaers.  Support may be able to provide some guidance on it but generally this type of custom work is unsupported.

Or you can create a compliance rule to detect that header and then send a notification to the original recipient with the orignal message attached.  I am not sure if this is going to achieve the end result you are after.

Regards,

Adnan

Adnan, thanks for the quick response! Perhaps if I explain more full there may be another solution...

Running AD/Exchange 2003. Like many organizations, we have quite a few publically-advertised generic addresses (along the lines of: info@, sales@, feedback@, etc) that are Distribution Lists, distributing to several internal individual addresses. Pretty common stuff. The problem is that if the sender requests a read receipt and the internal user allows read receipts to be sent (which is a common internal requirement), a customer emailing a public DL will receive a receipt from that individual. We now have a business requirement to disable this, for obvious reasons. For example, we don't want an email to feedback@ DL to return read receipt from director@, manager@, and president@.

While delivery receipts can be disabled on the Exchange server, the problem is that read receipts are a client-side Outlook control, not Exchange. And we don't want to disable them altogether client-side, because they are useful internally. Therefore stripping the incoming read receipt request, the "Disposition-Notification-To" header, at the gateway seems to be the most elegant solution.

Any other way of achieving this through SBG, or does a sieve script remain my best hope? Thanks again, doni

I have another idea; just an idea; haven't tested it so I don't know what would be the outcome.

How about if you create a compliance policy to detect the presence of "Disposition-Notification-To" header; then add a new "Disposition-Notification-To" header pointing to an internal black hole email address or something that you can monitor during testing phase.  So in essence, you will have more than 1 "Disposition-Notification-To" headers, but probably the top one will be the one added by SBG once mail gets to the end user.  How is Exchange/Outlook going to behave with multiple "Disposition-Notification-To" headers; is it going to act only on the top header or all?

If I get a change I will test it, but probably it's going to take a while before I can setup the environment.

Regards,

Adnan

Interesting concept, thanks. I'll test that out here and respond back with results. I would imagine that the SBG-added header would be added below (as is the X-Brightmail-Tracker header), but maybe not. And as you wrote, maybe that will be enough to confuse Outlook into inaction. Good idea, thanks again!

Hi Doni,

Did you get a chance to try out the suggestion?

Regards,

Adnan