(03-07-2023, 03:16 AM)BartKindt Wrote: I have no access to the AUsesDotTransparency.
Add the IdMessageHelper unit to your uses clause. Right now, a class helper is being used to overload the TIdMessage.LoadFrom...() and TIdMessage.SaveTo...() methods with an additional AUsesDotTransparency parameter:
Code:
type
TIdMessageHelper = class helper for TIdMessage
public
procedure LoadFromFile(const AFileName: string; const AHeadersOnly: Boolean; const AUsesDotTransparency: Boolean); overload;
procedure LoadFromStream(AStream: TStream; const AHeadersOnly: Boolean; const AUsesDotTransparency: Boolean); overload;
procedure SaveToFile(const AFileName: string; const AHeadersOnly: Boolean; const AUseDotTransparency: Boolean); overload;
procedure SaveToStream(AStream: TStream; const AHeadersOnly: Boolean; const AUseDotTransparency: Boolean); overload;
end;(03-07-2023, 03:16 AM)BartKindt Wrote: I also don't know what it means.
The way that the POP3 and SMTP protocols are structured (but not the IMAP protocol), email data needs to be escaped when transmitted over the socket connection. Specifically, that escaping involves adding an extra period ('.') character in front of any line of text that already begins with a period, because the email data is terminated by sending a period ('.') character on a line by itself. The TIdMessage.SaveTo...() methods save only escaped emails, and the TIdMessage.LoadFrom...() methods load only escaped emails, regardless of whether the emails are being used with POP3/SMTP or not (see https://github.com/IndySockets/Indy/issues/135). The TIdMessageHelper class helper was added to workaround that issue without completely redesigning TIdMessage's internals.
When AUsesDotTransparency is True, the escaping is saved/parsed as before.
When AUsesDotTransparency is False, the escaping is not saved/parsed.
(03-07-2023, 03:16 AM)BartKindt Wrote: I load the TIdIMAP4.UIDRetrieveNoDecodeToStream, then save the resulting TIdMessage.SaveToFile();
Since TIdIMAP4.UIDRetrieveNoDecodeToStream() uses TIdMessage.SaveToStream(), the stream data will be dot-escaped. If you are simply calling TIdMessage.LoadFromStream() and then TIdMessage.SaveToFile(), the stream will be loaded with dot-escaping parsed, and then the file will be saved with dot-escaping applied.
(03-07-2023, 03:16 AM)BartKindt Wrote: I create a *new* TIdMessage, and reload from File.
If you are simply calling TIdMessage.LoadFromFile(), then it will expect a dot-escaped file (which you have), and so the TIdMessage would end up holding the original un-escaped data.
(03-07-2023, 03:16 AM)BartKindt Wrote: There is no valid data in any of the fields.
It should be. I would need to see the raw stream/file data.
(03-07-2023, 03:16 AM)BartKindt Wrote: What do I have to do in the TIdMessage itself, to actually populate all the fields?
Given everything you have described, you should NOT have to do anything extra.
However, I would suggest that you call TIdMessage.SaveToFile() and TIdMessage.LoadFromFile() with the AUseDotTransparency parameter set to False for both, since .EML files don't need to be escaped.
(03-07-2023, 03:16 AM)BartKindt Wrote: Even if I use 'IdMessage.LoadFromFile(xxx,true) // Headers only
then there are NO headers. The Count is 0.
The ONLY way that should happen is if either:
- the file is completely empty to begin with.
- the file is (treated as) dot-escaped, and there is a sole '.' line before the headers.

