
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ā02-22-2019 06:28 AM
Hello SN Comm,
I am looking for some help to see if anyone has dealt with and/ or changed the instance's email filters.
I have been noticing that many legit incoming emails to our system are being ignored based on filters from the system. The two that are handling the ignoring are 'Ignore header' and 'Ignore sender'. I know that the main intention of this email filter was to make sure any undeliverable type emails sent from mailer daemon or postmaster. But looks like in our case, it is incorrectly ignoring valid emails from users.
Anyone able to shed some light as to how I may be able to adjust these filters? I put in a ticket with SN HI - and they suggested disabling a filter, however, did not state which I should try.
So I am looking to the Community for some help with these!
Thank you in advance!
~Rob
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ā02-25-2019 05:17 AM
Thanks for your reply creative - I was banking on adjusting the filters in a way that would work for me. However, I cannot use your suggestion, as not all users within the system have roles. We have thousands of users that have HR Cases created for them, and they need to be able to email back into their Cases at any given time. Along with that, users that email directly into our Employee Resource Center, should have the system create a Case for them automatically. Of course, we have many inbound email actions to filter out fake/duplicates - our inbound actions for the most part are already pretty robust.
I did however go ahead and look at two filters - 'Ignore Header' and 'Ignore Sender', to see if I could adjust either of those. It was suggested by SN HI, to try and disable one of them within a test instance, and see how certain emails reacted that were already ignored (we cloned over not too long ago so I was able to test some good data).
I disabled 'Ignore Sender' which has two conditions:
Through some heavy research within our emails that come in from our employees, many if not all, have 'postmaster' in the header. True junk emails had 'mailer-daemon'. Therefore as a test, I went ahead and added the 'mailer-daemon' as a condition to the 'Ignore Header' filter, kept 'Ignore Sender' filter disabled, and reprocessed many of the emails that were labeled as junk, but are definitely legit.
Sure enough, those emails were then processed correctly. New one created Cases, and reply ones went to their already in process Cases, and posted the update.
I am going to run with this for now, however have our Employee Resource Center to really pay attention to Cases that are created via emails, just in case.
Thanks again for your suggestion!
-Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ā02-22-2019 08:16 AM
It might be configured somewhere in Inbound email action code for that table.
Example code for ignoring OUT OF OFFICE mails
var skpmsg = false;
var subj = email.subject;
//var k = email.subject.indexOf('Out of Office');
//gs.log('Therefroe the value insideis '+k);
if(subj.indexOf("OUT OF OFFICE") > -1)
{
gs.log(' loop which can prevent incident creation');
skpmsg = true;
}
OR
you can adjust the filters like this
Only emails from senders with the Required roles will trigger this inbound action.
(So under this in When to Run tab in Inbound action ) you can mention the email id from which there will be impact on SNOW
tables or the roles
Mark my ANSWER as CORRECT and HELPFUL if it helepd

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ā02-25-2019 05:17 AM
Thanks for your reply creative - I was banking on adjusting the filters in a way that would work for me. However, I cannot use your suggestion, as not all users within the system have roles. We have thousands of users that have HR Cases created for them, and they need to be able to email back into their Cases at any given time. Along with that, users that email directly into our Employee Resource Center, should have the system create a Case for them automatically. Of course, we have many inbound email actions to filter out fake/duplicates - our inbound actions for the most part are already pretty robust.
I did however go ahead and look at two filters - 'Ignore Header' and 'Ignore Sender', to see if I could adjust either of those. It was suggested by SN HI, to try and disable one of them within a test instance, and see how certain emails reacted that were already ignored (we cloned over not too long ago so I was able to test some good data).
I disabled 'Ignore Sender' which has two conditions:
Through some heavy research within our emails that come in from our employees, many if not all, have 'postmaster' in the header. True junk emails had 'mailer-daemon'. Therefore as a test, I went ahead and added the 'mailer-daemon' as a condition to the 'Ignore Header' filter, kept 'Ignore Sender' filter disabled, and reprocessed many of the emails that were labeled as junk, but are definitely legit.
Sure enough, those emails were then processed correctly. New one created Cases, and reply ones went to their already in process Cases, and posted the update.
I am going to run with this for now, however have our Employee Resource Center to really pay attention to Cases that are created via emails, just in case.
Thanks again for your suggestion!
-Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ā06-26-2019 05:48 AM
This issues is mostly occuring due to SPF helo handshake. Which add postmater in the header if it unable to authenticate the Sender.
https://tools.ietf.org/html/rfc7208
What I fail to understand is why ServiceNow mechanism is not aligned to International SPF RFC standard. HR delivery definitely receives email from outside world and such generic email filter has a drastic effect on the business KPI.
also the HI is not suggesting a good workaround other than disabling this.