Receiving attachment over an email up to 1000 characters

, ,
1

Product/components used and version/fix level:

wM 10.15 Integration server

Detailed explanation of the problem:

We observed that when we receiving the attachment report over an SMPT service we got upto 1000 characters in report heading.

Http data after 1000 characters in a line it is not including in the report heading.

It cloud be the reason that Line lengths in SMPT are not allowed to exceed 998 characters.

Could you please help to suggest to get the complete heading in the report.

Error messages / full error message screenshot / log file:

Question related to a free trial, or to a production (customer) instance?

2

This is an SMTP server-side limit - check if your SMTP server administrator can increase the limit.

When you say “Header”, do you mean the email subject, or the body?
For the body, you can form an HTML report instead and it will be rendered on the sent email.

KM

3

Hi Kasi,

Thanks for looking into this.
This is the body of the attachment.
It is resolved after set encoding :base64 in smtp

Thank you

4

Unrelated to this specific issue, but I would encourage avoiding the use of email for transport. It is mostly reliable but if something doesn’t make it you have no way to track it. And no way to prove non-receipt. And without additional protections added to the email (signing, certificate, etc.) there is no way to prevent a bad actor from sending you emails that are not genuine – which could be a big problem depending upon what is done with them.

I suspect the existing SMTP usage you have in place is something implemented some time ago. But either new or old, I would strongly encourage to find another way to transport the data.

2 Likes
5

@reamon There are several things which are still with emails. Bank statements that are sent to customers, invoices, order confirmations, receipts, advices etc., In an org there will be different systems that generated such emails (call it system generated emails, not user generated) and these systems will have to connect to a smtp server to relay the message to end users. All systems could connect to smtp or having IS (middleware) that exposes service to all internal systems to connect to and smtp conversion and integration with smtp server will be done by it.

Cheers
Senthil

6

@Senthilkumar_G Sure, but that should be minimized/avoided whenever possible when the communication is between 2 systems. Emails to users makes sense if there is no application they can use to view data that is sent to the app (not directly to the user).

Putting IS in between an email sender and SMTP is something to avoid too, IMO.

I understand that many still use SMTP for transport for app to app, system to system. My advice is to not do so if at all possible.

7

These are business requirements which determines such as interface is needed or not. Yes in my example, I am stating about there will be operations who will have UI that checks cases logged by customers and communication from customers could be by various means and one such is that email.

8

We agree – interaction with people often needs to be via email. I hope my main point that system-to-system interaction should avoid email was clear.

1 Like