- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi, we’re seeing inbound emails from an external vendor being ignored by our inbound email processing. The emails are marked as received-ignored by the Ignore header filter.
The messages include the header:
X-ServiceNow-Generated: true
They also contain a SN watermark in the body, which suggests the emails are being generated by the vendor’s SN instance. Because of this, they’re being treated as system-generated and skipped to prevent mail loops.
I understand this is expected OOB behaviour, but I’m interested to know if anyone else has encountered this and, if so, what you’ve put in place to handle it so that these emails are processed. I’d prefer not to add any conditions to the Ignore header filter.
Many thanks
Max
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi Max,
This is a classic "Instance-to-Instance" loop protection scenario. Since the Ignore header filter acts as a hard "gatekeeper" (if it matches, execution stops and the email is ignored), you generally cannot "bypass" it with a previous filter unless that previous filter moves the email to a different state effectively skipping the remaining filters.
Here are the three ways to handle this, ranging from "Best Practice" to "Advanced Workaround":
1. The "Source" Fix (Cleanest) If you have a contact at the vendor, the absolute best solution is for them to prevent this header from being sent to you.
They can use a Business Rule or Email Header configuration on their instance to remove X-ServiceNow-Generated specifically when the recipient is your instance email address.
This solves the problem without you having to lower your defenses.
2. The Filter Exception (Standard) Although you prefer not to add conditions, adding an exception to the existing filter is the standard way to handle this on the receiving side.
Update the "Ignore header" filter condition:
Headers contains X-ServiceNow-Generated: true
AND From is not [Vendor Email Address]
Risk Mitigation: Ensure your Inbound Action for this vendor has strict checks (like requiring a Watermark or a specific Subject pattern) so you don't actually trigger a loop if they generate a new automated email that isn't a reply.
3. The "Header Stripper" (Advanced - Preserves OOB Filter) If you absolutely do not want to touch the OOB Filter conditions (to avoid skipped updates during upgrades), you can intercept the email before the filters run using a Business Rule.
Table: sys_email
When: Before (Insert)
Condition: headers contains X-ServiceNow-Generated AND user (or from) is [Vendor].
Script: Remove the specific string from the headers field.
JavaScriptcurrent.headers = current.headers.replace("X-ServiceNow-Generated: true", "");
Result: When the email reaches the Filter processing stage, the header is gone, so the OOB filter ignores it and lets it pass through to your Inbound Actions.
Hope this helps!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi Max,
This is a classic "Instance-to-Instance" loop protection scenario. Since the Ignore header filter acts as a hard "gatekeeper" (if it matches, execution stops and the email is ignored), you generally cannot "bypass" it with a previous filter unless that previous filter moves the email to a different state effectively skipping the remaining filters.
Here are the three ways to handle this, ranging from "Best Practice" to "Advanced Workaround":
1. The "Source" Fix (Cleanest) If you have a contact at the vendor, the absolute best solution is for them to prevent this header from being sent to you.
They can use a Business Rule or Email Header configuration on their instance to remove X-ServiceNow-Generated specifically when the recipient is your instance email address.
This solves the problem without you having to lower your defenses.
2. The Filter Exception (Standard) Although you prefer not to add conditions, adding an exception to the existing filter is the standard way to handle this on the receiving side.
Update the "Ignore header" filter condition:
Headers contains X-ServiceNow-Generated: true
AND From is not [Vendor Email Address]
Risk Mitigation: Ensure your Inbound Action for this vendor has strict checks (like requiring a Watermark or a specific Subject pattern) so you don't actually trigger a loop if they generate a new automated email that isn't a reply.
3. The "Header Stripper" (Advanced - Preserves OOB Filter) If you absolutely do not want to touch the OOB Filter conditions (to avoid skipped updates during upgrades), you can intercept the email before the filters run using a Business Rule.
Table: sys_email
When: Before (Insert)
Condition: headers contains X-ServiceNow-Generated AND user (or from) is [Vendor].
Script: Remove the specific string from the headers field.
JavaScriptcurrent.headers = current.headers.replace("X-ServiceNow-Generated: true", "");
Result: When the email reaches the Filter processing stage, the header is gone, so the OOB filter ignores it and lets it pass through to your Inbound Actions.
Hope this helps!
