Email monitor attachment error


I'm seeing an error in an email monitor that I'm not sure how to decipher.  The attachment is a 1M, 500+ page PDF.  Other attachments seem to be processing fine.  This issue has only been happening the past couple of weeks.  Would this be related to disabling legacy email services?  We do have a security scanner in place for attachments, and I suspect the monitor may be trying to process the email before the scan completes.  Most attachments are significantly smaller in size and may finish scanning in time.

Error message in the log:

Unable to upload attachment [Device_change_Audit_20211022_083256_878.pdf] for email [143227004.2157.1634909579687.JavaMail.root@prime1-prd], but email processing will continue.: Response status code does not indicate success: 400 (FileContents must not be empty.
Parameter name: FileContents).: at Tdx.RestProxy.Core.Proxy.RestProxyBase.EnsureSuccessfulResponseAsync(HttpResponseMessage responseMessage)
at Tdx.RestProxy.Core.Proxy.RestProxyBase.<>c__DisplayClass10_1`2.<<ExecutePostAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at Tdx.Core.Threading.MultiThreadObject`1.LockAsync(Func`2 lockedFunc)
at Tdx.RestProxy.Core.Proxy.RestProxyBase.ExecutePostAsync[TContent,TResponse](String uri, TContent content, Func`2 onRetryFunc)
at Tdx.Email.Monitor.Core.ApiProxy.TeamDynamixInternalWebApiProxy.UploadAttachmentAsync(UploadAttachmentRequest request)
at Tdx.Email.Monitor.Microservice.EmailProcessor.Utility.AttachmentUploader.UploadAttachmentsAsync(Int32 partitionId, Int32 billableEntityId, Guid userId, Nullable`1 parentItemId, Nullable`1 itemId, Int32 componentId, String emailId, List`1 attachments, ITeamDynamixInternalWebApiProxy proxy, IEmailMonitorComponentLogger componentLogger, CancellationToken token) in /app/Tdx.Email.Monitor.Microservice.EmailProcessor/Utility/AttachmentUploader.cs:line 109

Thank you,


Tags attachments email-monitor
Asked by Pamela Jordan on Fri 10/22/21 10:38 AM
Sign In to leave feedback or contribute an answer

Answer (1)

This answer has been marked as the accepted answer
Mark Sayers Fri 10/22/21 11:21 AM

Hello Pamela,

When I've seen this error in the past and the client has attachment scanning active, that scanner is the most common culprit for why the attachment isn't able to be uploaded at the time the message is processed.

If it is that large perhaps the user ought to instead be directed to upload the file after their ticket generates so it doesn't have to go through the attachment scanning process of your mail system.

TDX does have our own security around attachments so we would not allow them to upload anything malicious in nature.

Let me know if that would work.

Mark Sayers
Sr Support Consultant, CS

2 of 2 users found this helpful.
Thanks, Mark.

The message in question is a daily report auto-generated by one of our system monitors, so we're looking into what other options we have. It's certainly likely that other attachments will get caught up over time, so we need to think about those as well.

- Pamela Jordan Fri 10/22/21 12:27 PM
Does your attachment scanning system perhaps have a way to flag certain senders as "always allowed/safe" so their attachments aren't caught in the scanner? - Mark Sayers Fri 10/22/21 12:29 PM
Looks like we're disabling scanning on the email monitor accounts. TDX scanning is automatic, correct? Thanks for your quick responses and helpful information today! -Pam - Pamela Jordan Fri 10/22/21 1:38 PM
Yes it is. - Mark Sayers Fri 10/22/21 2:00 PM
Hi Mark. Just a quick question: When you wrote "TDX does have our own security around attachments" is this for all solutions (cloud-based and on-prem)? - Eugene McGeehan Wed 1/18/23 8:57 AM
This is for only the cloud-based solutions. On-prem clients would have to have their own file scanning products on your TDX web and/or file servers to prevent malicious or malformed files from being uploaded to them. - Mark Sayers Wed 1/18/23 9:22 AM