I wanted to share a solution I’ve implemented for us to help deal with 2 common scenarios. 1) Users who have an out of office reply and 2) Non-deliverable email.
To deal with the auto responder, we have to look at the email headers (original discussion @ Access to Email Headers - #5 by DBachen).
You cannot look at just the subject, because not every email system handles it the same way. While Microsoft always adds the text “Automatic reply:” to the beginning, systems like Google allow you to set an arbitrary subject. This solution looks at common email headers that get set for autoresponders across Microsoft and Google and will be updated in the future if I find a different header from a different system. My earlier versions were based on subject and Google’s kept squeaking through.
For the NDR, we can determine it based on the sender in Autotask along with the subject. We check both to ensure there are no false positives.
Check for Out of Office Reply
We’re going to set a global flag if the conditions prove that one of our email headers is valid.
We use the OR construct so that only one of the 5 needs to be true
Here’s the JSON for that expression to make it easy to copy and paste
{
"statements": [
{
"statements": [
{
"expression": "email.headers[\"auto-submitted\"] == \"auto-generated\"",
"type": "legacy"
},
{
"expression": "email.headers[\"auto-submitted\"] == \"auto-replied\"",
"type": "legacy"
},
{
"expression": "email.headers[\"precedence\"] == \"auto_reply\"",
"type": "legacy"
},
{
"expression": "email.headers[\"x-auto-response-suppress\"] == \"All\"",
"type": "legacy"
},
{
"expression": "email.headers[\"x-autoreply\"] == \"yes\"",
"type": "legacy"
}
],
"operator": "||",
"type": "group",
"expression": null
}
],
"operator": "&&",
"type": "group",
"expression": null
}
Update Ticket
Next we duplicate our original Update Ticket step, so that we have 2. The original will run as along as our global flag isn’t set, and the new version will run only if the flag is set. This way we can make sure the auto response becomes an internal note and not a public one.
**Update Ticket - Not Automatic Reply **
This is your original, renamed, with a condition check of global.IsAutoReply == null. FYI: I’m checking for the NDR here, but this is just a sanity check… NDRs are usually their own email, so they would normally flow into the “create” rule.
Update Ticket - Automatic Reply
This is your new rule which only runs if it’s an autoreply
Modify the actions so that the note is made internal (preventing any of your workflows which notify external people, and change your ticket status to do nothing (so that an autoreply doesn’t reopen the ticket)
Check for NDR
This checks for both the sender being the mailer-daemon AND the subject (in case the daemon sends us something other than an actual NDR)
Here’s the JSON:
{
"statements": [
{
"term": "email.from.address",
"operator": "equals",
"subject": "[email protected]",
"isSubjectLocked": false,
"type": "statement",
"expression": null
},
{
"term": "email.subject",
"operator": "equals",
"subject": "Undelivered Mail Returned to Sender",
"isSubjectLocked": false,
"type": "statement",
"expression": null
}
],
"operator": "&&",
"type": "group",
"expression": null
}
Add Note if NDR
So now that we know it’s an NDR, we can add a new rule to our Create Ticket which gives our techs additional information on how to deal with it.
We’re creating an internal note that tells them go open the EML and investigate it, and not just close the ticket.
Normally, when using a flag, I just check ==null or != null, effectively determine if the value is TRUE or FALSE.
In this particular case, I check for the actual value stored inside the flag with a regex global.IsNDR matches "/^TRUE$/i", but only because I was playing around with the ability to match against different string values in testing and just hadn’t reverted it back. The null check is easier and quicker in most cases.
You would probably just stick with that, unless you have another reason to do a regex match.
For example:
Oh, something else that was learned in testing against personal my personal Gmail that had a forward from my personal domain on it. When the vacation email was sent out, it sent it back to Autotask with an additional email address added that began with SRS0 (which then caused that address to get added to the ticket and created an email loop). I hadn’t seen that before and asked Copilot for some help.
Ultimately, the solution was to add a check into both the iterate over each to-address and the iterate over each cc-address to look for that SRS0 email and skip adding it to the ticket.
{
"term": "custom.address.address",
"operator": "!contains",
"subject": "SRS0",
"isSubjectLocked": false,
"type": "statement",
"expression": null
}
Hope you find this solution helpful!
@KeithTessler @travis
