Mail message sent from PI comes with weird characters at Subject

Question

Hi folks,
I've a Scenario where I must send a e-mail with some process data. To do that, I'm using emial Package to build the email Message.
The email Package XML Looks like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<ns:email xmlns:ns="http://sap.com/xi/XI/emial/30">
<Subject>HEY THIS IS JUST A LONG PLACEHOLDER SUBJECT TO HELP ME TO FIND OUT THE ISSUE OF MY MESSAGE</Subject>
<From>sender</From>
<To>rcpt</To>
<Content_Type>multipart/mixed; boundary="--JrSnBoUnDaRy"</Content_Type><Content>----JrSnBoUnDaRy
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Lorem Ipsum Dolor Sit ...
</Content></ns:email>
When the message arrives at my emialbox, the SUBJECT looks like this:
"HEY THIS IS JUST A LONG PLACEHOLDER SUBJECT TO HELP ME TO FIND OUT THE I SSUE OF MY emial MESSAGE"
Instead of:
"HEY THIS IS JUST A LONG PLACEHOLDER SUBJECT TO HELP ME TO FIND OUT THE ISSUE OF MY emial MESSAGE"
As you can see, there`s a "space" between the I and SSUE word. Looking closer at a Hex Editor I can see that I'm dealing with two special characters, first one LF (0xA) and later a TAB(0x9).
Doing some test I've found out that it just happens at the 72th position of the Subject string.
Is there any limitation for email fields while using email Package or Receiver email Adapter?
Thanks in advance,
José Nunes
Edited by: Jose Nunes on Mar 11, 2010 1:39 AM

Answer 1

Hi José,
SMTP has a line length limit and any long header line needs to be split in multiple lines, where each subsequent line must start with a single TAB.
It is strange that your mail client couldn't decode these multiple lines back to the original single line.
It might be that the mail adapter did not split the original line into valid multiple lines.
TCPGateway attached in the SOAP adapter note can capture the SMTP traffic and save it into a binary file.
You can check if the mail adapter correctly did the splitting.
This is not directly related to your issue. But you should avoid using the mail package if you have some format sensitive content. XML parsing inevitably changes the original physical representation (refer to whitespace handling in the XML specification). The issue can be avoided if the base64 encoding option is used within the content encoding. But you should switch to the adapter specific message attributes (ASMA) approach if you are configuring a new scenario.
Best regards, Yza