TIdMessage - html content being damaged..

[rlebeau]

When the IdSMTPServer1MsgReceive event is triggered, I'm creating a TIdMessage and loading the AMsg stream into it.

Let's stop right there for a moment.

Know that the TStream provided in the OnMsgReceive event is the raw email data sent by the client - MINUS any transparency escaping used to transmit the data over SMTP.  This is important to note, because the TIdMessage.LoadFrom...() methods require that escaping by default, as they are expecting to load emails that were saved by the TIdMessage.SaveTo...() methods, which apply escaping by default.

So, before looking at anything else, an extra step is needed to ensure that escaping is not an issue here.  In modern Indy, there is a class helper in the IdMessageHelper unit which adds an additional AUsesDotTransparency parameter to the TIdMessage.LoadFrom...() and TIdMessage.SaveTo...() methods to control the escaping behavior.

In this case, since the TStream data is not escaped, you need to call LoadFromStream() with this extra parameter set to False, eg:

Code:

uses
  ..., IdMessageHelper;

Msg := TIdMessage.Create;
Msg.LoadFromStream(AMsg, False, False);

If your version of Delphi does not support class helpers, there is a standalone TIdMessageHelper_LoadFromStream() function available, eg:

Code:

uses
  ..., IdMessageHelper;

Msg := TIdMessage.Create;
TIdMessageHelper_LoadFromStream(Msg, AMsg, False, False);

And if your version of Indy does not have the IdMessageHelper unit, well then you need to upgrade.

OK, now with that being said...

The problem is that the html content is then heavily damaged.

I am not able to reproduce that issue with the current version of Indy.  The HTML is preserved, as expected.

This is the original email from AMsg:
...
This is how TIdMessage leaves it after it is loaded in from AMsg
...

Aside from your HTML issue, and the usual expected dynamic header regenerations (Date, MIME boundary, etc), the only other changes I see in your example are:

• the X-Priority header being dropped (because 3 means Normal, and TIdMessage.SaveTo...() does not output X-Priority for Normal)
  
• the In-Reply-To header being added.  It should not be doing that, and the current version does not do that.
  

If i use NoDecode := True; then it does make a little difference..

For relaying purposes, I would recommend using both NoDecode=True and NoEncode=True. That way, the parsed email will preserve the original headers and message body as-is between load and save.  The downside is you would not be able to use the TIdMessage.MessageParts anymore, the raw content will be in the TIdMessage.Body only.

Now, I do have a confession to make, as in the opening post of my other thread i mentioned that I'm using an older version of V10. Was this a known bug back then or am I doing something wrong?

Looks like a bug, yes.

Is this still an issue in the latest version?

No.  I tested it using your example, and the HTML was preserved.

Alternatively, is there a way to send the AMsg stream itself so that IdMessage is only used internally to get addresses etc but SMTP sends the original version? - That would work for me.

TIdSMTP only natively supports sending a TMessage, not a TStream, which would be ideal in a relaying scenario. I'll consider adding it, I've opened a ticket for it:

#539 Update TIdSMTP and TIdSMTPRelay to support sending a TStream instead of a TIdMessage

If you want to send the TStream as-is, you will have to forgo using the TIdSMTP.Send() method and instead use the TIdSMTP.SendCmd() method to issue the SMTP MAIL FROM, RCPT TO, and DATA commands manually.

Otherwise, setting both TIdMessage.NoDecode and TIdMessage.NoEncode to True is the next best option.