Thank you for these variables. The event didn't list these variables as options but I have added them and will wait for the next occurance to verify it is working.

Thank you.

This didn't work. Here is a copy of what the reply email looks like and the event configuration.

EMAIL

EVENT BODY:

Thanks for the details, Patrick! Which ticket event Type did you use for this? And what conditions did you use in the event?

Event type: SMTP Delivery Failed

No extra conditions enabled.

Single action of Send Email

Action body was listed in previous message and I have it set to "HTML + Plain Text"

Is this what you were looking for?

Patrick,

I did some testing with the events, unfortunately, I couldn't find a different event that you could use for this. However, I did find an alternate solution. While there's no setting for max message or attachment size limit in the management interface, you can change the maxRequestLength in the web.config, which will change the attachment size limit. Because of some conversions we do on the back end you would need to set the limit to less than 35MB. The maxRequestLength is in kilobytes so use less than 35000. For example, the original limit is maxRequestLength="102400". If you set it to maxRequestLength="30000" agents would get an error when they try to upload any files larger than 30MB, thus forcing them to stay under the message size limit set on your mail server.

To make this change you will first need to stop the SmarterTrack IIS site. Do NOT save any changes in the web.config before you stop the IIS site. By default the web.config file is located in C:\Program Files (x86)\SmarterTools\SmarterTrack\MRS. After you make and save the change start the IIS site again.

Something to notate:
Any time you upgrade SmarterTrack, any changes you've made in the web.config will revert back to the defaults. So you would have to go back in and make the change again after every update. Or, you can make a copy of web.config after you've made and saved the changes, and keep it in a separate folder. Then just restore that copy of the web.config after every upgrade. That said, we don't usually make changes to the web.config in our releases, but it can happen. So you would need to keep your eye on the release notes before doing any upgrades to ensure there were no changes to the web.config. You would need to make the changes again and save a new backup of the web.config after upgrading. In that case, you should not restore from the backup.

Not ideal and not a fix but it will reduce a good percentage of these instances. What I think I am going to do is not ideal but the only solution I can come up with.

It would be nice if an email limit (not just single file limit) could be put into the software for companies like ours that limit attachment size. In short we use a lot of large art files so we implemented a file sharing tool for the large items so we don't bog down everyone's email accounts with attachments.