How do I identify and break an existing email loop?
Oracle Service Cloud (OSvC), All versions
Most email loops can be identified by either many duplicate incidents or incidents that have many duplicate threads. The type of loop depends on the auto-responder. If the responder sends enough of the original message to contain the tracking string, then incidents are updated with many threads. If the responder does not send the tracking string then duplicate incidents may be created. If a site has one type of loop, the other will usually also exist. For more information on email tracking strings please refer to Answer ID 5331: Incident Update by Email.
1. To search for the current loops you need to create two reports. Refer to the following answers for instructions.
2. Inspect the incidents identified by the 2 reports and decide which are appropriate. Often times there are multiple appropriate incidents with duplicate subjects and/or incidents with many threads due to processes or external integrations (such as forms that create incidents).
3. Gather email addresses from the incidents which appear to be loops.
4. Add these addresses temporarily to the Barracuda Spam filter email blacklist to break the loops. Refer to Answer ID 2345: Barracuda Spam filters on hosted Service mailboxes for information on logging in to the spam filter and configuring the blacklist.
5. Edit or disable the contacts that have invalid email addresses.
6. Wait for a few hours for the all emails created by the loops to be filtered. Remove the active customer addresses from the Barracuda Spam filter blacklist.
7. Evaluate your site for the causes of loops and make changes.
There are multiple causes for email loops. Most unhandled loops include rules and configuration settings and usually all go un-noticed due to agent reports that filter the loop incidents.
- All loops require an automatic response from CX. Evaluate the business case for sending automatic responses carefully. If loops are a problem find some other functionality to satisfy your business case.
- When configuring business rules to send auto-responses, take into consideration the case when a message cannot be delivered to its destination. If the message cannot be delivered and the bounced email message does not invalidate the contact, a loop can occur if the business rule that sends the auto-response is hit every time the bounce message updates the incident. For more details, please see Bounced E-mail message handling.
- Never send more than one autoresponse per incoming email. Add multiple responses through rules and only include one "send response" action. Disable automatic Contact Emails in Configuration -> Interfaces.
- In all rules that send auto-responses, move the "send response" action to a state that is only active once. Ensure that there are catch-all rules so that all incidents follow the path that sends only one response.
- Chose the correct level for the mailbox Discard Automatic Responses setting. Evaluate the common autoresponders and add a REGEX for common response subjects to the EGW_AR_CONS/MODR/AGGR_BODY_FLTR configuration.
- There is an automatic anti-loop filter that filters any messages above 23 per 12 hour period (EGW_MAX_PER_ADDRESS per EGW_MAX_MSG_DURATION) from the same address. Do not disturb these configuration settings. Ensure that external processes that send email to OSvC use the sender's address instead of a single email address. (See Configurations EGW_MAX_PER_ADDRESS and EGW_MAX_MSG_DURATION explained for more information.)