Preventing possible loop when using notify.

[Tony Kilbarger]

I have a request to create a content filter that will forward email sent to one address to a different address and to notify the sender that we received it.  I have always shyed away from an auto response type filter because of the potential to create a loop.  Are there any best practices to prevent something like that? 

[Libin Varghese]

Hi Tony,

It would be difficult to detect all types of mail loops, however I was able to locate the below article.

http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118522-qa-esa-00.html

If the notification email generated by the ESA gets bounced by the destination server which again gets bounced by the ESA then that could end up in a loop as well.

As there can be multiple scenarios, I would recommend implementing the filter for a few users to start out and monitoring if it works as expected.

Thanks!

Libin Varghese

[exMSW4319]

My ESAs are somewhat behind the current release, but it would appear that both filters and rules aimed at a specific recipient trigger when the addressee is only one of a number of recipients.

If this is not a problem for your scenario, I'm wondering about a filter where you tag the subject line then act accordingly if it finds its way back in again. The following is completely untested, and there's a couple of bits that are probably wrong but it does sketch the concept:

#
No-Loop:
if (rcpt-to == 'your@recipient')) {
    if header(Subject == 'ORG FWD') {
         quarantine('bit bucket')
    }
    else {
        strip-header('Subject');
        insert-header('Subject', '[ORG FWD] $Subject');
        notify($EnvelopeFrom)
        alt-rcpt-to('your@alternate')
    }
}

Where your@recipient is the recipient to be diverted, ORG FWD is a tag you're happy to apply to subject lines that won't crop up by chance, bit bucket is a test quarantine area because we don't try new filters with a drop() and your@alternate is the address the mail is to be shunted on to. The Notify can of course be a lot more sophisticated. 

I'd be more concerned about backscatter rather than a loop. If you're depending on filters or rules further down the pipeline to deal with unwanted mail, a further possibility is to replace the notify and alt-rcpt actions in the second branch with an insert-header that is picked up by a later rule.