- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2016 06:18 PM
Hi folks,
I have previous raised a question about inbound action script that prevents excessive attachment from attaching. After attempting to implement the script, I realised ServiceNow seems to stop the email from processing if an attachment is over-sized ( Email.attachment.size >= glide.email.inbound.max_total_attachment_size_bytes : default 16m)
Therefore the script would never seem to be reached if the size condition is met, but following would be a plan to achieve this
1) Change the value of glide.email.inbound.max_total_attachment_size_bytes to 10485760 (100m)
2) Create a new sys_properties of test.email.inbound.max_total_attachment_size_bytes and set value to (16m)
3) Create Inbound Action Script including the code below
If attachment is over 16 mb and less than 100m, it will fires off 'systems_email_oversize.bounce', notifying the sender that the attachments are not attached.
Any advice would be appreciated.
Kind regards,
var max_attach_bytes = gs.getProperty('test.email.inbound.max_total_attachment_size_bytes'); | |||
//total attachments size | |||
var total_size=0; | |||
var att = new GlideAggregate('sys_attachment'); | |||
att.addEncodedQuery('table_sys_id=' + eml.sys_id); | |||
att.addAggregate('SUM', 'size_bytes'); | |||
att.query(); | |||
if (att.next()) | |||
total_size = att.getAggregate('SUM', 'size_bytes'); | |||
// if total size exceeds the maximum limit, fires off the bounce event | |||
if (total_size >= max_attach_bytes) | |||
gs.eventQueue('systems_email_oversize.bounce', null, email.origemail, email.subject); |
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2016 08:22 PM
Are you using the ServiceNow email infrastructure?
If so, an email sent to your instance, containing 100mb of attachments would never even see your instance. There is a total limit on an email of 25mb through the email infrastructure (that includes the ~1.3-1.4x increase in size on attachments as transmitted due to Base64 MIME encoding typically seen on atttachments. See Email Size Restrictions.
Even if using private email infrastructure, you will likely face some size limits. Check with the email service administrator or documentation.
If the email does make through the infrastructure and to your instance, attachments are dropped prior to the inbound email actions running. The attachment has already been excluded and will not be in the table for you to locate.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-21-2017 10:32 PM
Thank you soo very much George! This was really helpful.
Highly appreciate you taking your time out and providing such detailed documentation on the matter.
Considering the performance issue, i have decided to go with the Scheduled script approach. Hope it works fine.
Many thanks once again
Regards,
Shahid Kalaniya
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-11-2018 05:50 AM
OK, the may be old and hopefully someone will reply.
Given the above information, my question is will the Sender be notified that the email was rejected / bounced?
If so, what to the emails look like? As my customers are claiming they aren't getting anything back.
If not, then what is the reason users aren't being notified.
Thank You.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2019 07:03 PM
As of New York, any inbound email having attachments discarded due to exceeding attachment size or count limits will get an event logged 'inbound_email_attachments.discarded', with the email record as the target record of the event.
That means anyone wanting to notify a user can do so by responding to this event and deriving the email address of the sender from the email record.
Warning: You should ensure the emails you are auto-responding to (for this reason or any others) are for situations that make sense for your use case. For example if a spammer sent an email to your instance email address, having an unintelligent auto-response on this kind of error may auto-respond to the spammer, which is quite likely not something you want to do.
So, when handling this event, an example check might be that the sending email address is an allowed sender Another check could be that the ServiceNow spam/virus headers are not present.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2019 07:14 PM
As of New York, any inbound email having attachments discarded due to exceeding attachment size or count limits will get an event logged 'inbound_email_attachments.discarded', with the email record as the target record of the event.
That means anyone wanting to notify a user can do so by responding to this event and deriving the email address of the sender from the email record.
See documentation.
Warning: You should ensure the emails you are auto-responding to (for this reason or any others) are for situations that make sense for your use case. For example if a spammer sent an email to your instance email address, having an unintelligent auto-response on this kind of error may auto-respond to the spammer, which is quite likely not something you want to do.
So, when handling this event, an example check might be that the sending email address is an allowed sender. Another check could be that the ServiceNow spam/virus headers are not present in the email.