How to prevent a bounce back loop?
How do we prevent a bounce back loop when automatically sending email notifications? A user emails us or submits a ticket. An automated response is sent to the users email address. Their mail server does not recognize the email address for whatever reason and bounces it back. When the bounced message comes in the system apparently thinks its a new ticket submission and an automated response is sent again. Bounces again. And so on. This actually happened to us and we ended up with 1400 bounced emails in our ticket queue.
Freshdesk has an inbuilt spam prevention mechanism that looks for certain keys in the original email headers to identify a spam (or) bulk message. For any email that follows the standards as per RFC 3834, Freshdesk would automatically detect the presence of Auto-submitted field in the header.
For any email that has the following values in the header, Freshdesk would automatically skip the new ticket notifications to prevent the bounce-back loop.
Some spammers can get intelligent and not let the system identify that it is indeed a bulk message and the system tend to send notifications, thus causing a feedback loop. In such cases, you can setup a Dispatch'r rule and make use of the condition " Skip new ticket notifications " as a reactive measure.
4 people have this question
Sorry for the inconvenience caused.
We checked our system and looks like this was the problem - Mail delivery failed: returning message to sender
We have handled this now and any Email from end user with subject - "Mail delivery failed" will only be created once as Ticket in Freshdesk account.
Mail Loop will be stopped.
thanks for bringing this to our attention.
Could FD Support possibly weigh in again on this subject? The company I just joined says they turned of Email ticketing because of rampant loops and multiple tickets for the same issue. This was less than a year ago and it's been five years since the last comment on this thread. I'd like to turn email ticketing back on, but before I do I need to reassure my team that we can minimize the risk of hundreds of extraneous tickets.
What strategies does FD recommend for avoiding loops?
Are there any other mitigation strategies that FD has implemented like the one Vijay mentioned 6 years ago?
What are other companies doing on their Service Desk to prevent or mitigate duplicate or erroneous email-to-ticket problems?
Any help or guidance would be appreciated!
I understand your concern. However, currently if an email is not sent or delivered to a recipient, there is a feature that updates the information inside the ticket.
In cases of looping, we would also block a contact temporarily if there is a spam suspicion.
However, we would like to understand the exact problem in your scenario. Do you think we could schedule a quick call and look into this further ?
Please provide us with your convenient time slots, so that we could schedule one accordingly.
Thanks Thriyam, I will contact you directly by email.
In general, when a customer raises a ticket with someone in cc and when the cc responds, it will be appended in the existing ticket. Only when someone not in cc responds, it will be created as new tickets. Even when cc'd address receive the notification email and reply to it, it should be appended to the existing ticket.
A new ticket will be created only when the requesters are different, the cc is different or if the message Id (that is present in the email thread) is different.
Thanks for your efforts in providing us with the screenshots.
The dispatcher rule that you have configured looks to be fine. Please make sure that you are using the exact request email address and also the exact subject phrases (even the punctuations).
Thank you for your response.
Yes, we are also working on controlling spam in the future and I believe this will be covered.
Technical Account Manager, Freshdesk
p : +61281884692
e : email@example.com
This isn't a Freshdesk specific comment, having worked with many email ticket/case systems in the past this is an age old problem. You can put defensive rules on the provider side to detect certain subject titles and sender attributes in order to prevent multiple ticket creation, almost like to trying to treat it as a DNS attack.
In my experience though it can still happen even via human error so my approach is to once a loops is spotted deactivate the auto response momentarily to break the loop. In our FD instance we also haven't used the platform wide notification we've built dispatcher rules at group level, so if the loop is in one group, we can turn that one off without affecting all customers.
One way to deal with this is what platforms like Desk.com do ( https://support.desk.com/customer/portal/articles/1167831-preventing-an-email-war-email-loop ), namely, have a configurable minimum time interval between successive automatic 'new ticket created' email notifications sent to the same recipient.( requester/CC ). However, I cannot understand their insistence on suggesting 24 hours as a minimum for this interval - the number seems excessive.
Are there any dispatcher rules that we can create to stop this kind of attacks?
Hello Freshdesk Support,
We had a loop incident a few days ago: someone sent a message to our organization's email address and we use Freshdesk's autoreply to send a basic acknowledgment. The external sender received our auto-reply and their system began generating their own tickets which auto-replied to our auto-replies etc. until ~1400 messages accumulated in our Freshdesk portal and we turned off our Freshdesk autoreplies to break the loop. Attached is a sample of a loop ticket that arrived in our Freshdesk.
I have sent a message to the original sender to notify them of what happened in case they can adjust their settings.
I'm writing to ask: what settings can I change in our Freshdesk configuration, or what new Freshdesk features can you add, in order to avoid future loops?
Hi all, any update on the issue explained above? We occasionally experience the exact problem. Surely there is a way that FD would be able to detect and prevent this?