"Marcelo" <mcgal-N-O-S-P-A-M-ig.com.br> wrote in message
news:45eeb8b7@newsgroups.borland.com...
> RawData.Write(#10#13'.'#10#13, 5);
> RawData.Seek(0, soFromBeginning);
You do not need to do that. TIdMessage already does that internally.
For that matter, you could just call TIdMessage.LoadFromFile() and not
deal with a stream at all.
But in any case, loading an .eml file into TIdMessage is buggy,
because eml files do not escape periods at the beginning of lines,
which TIdMessage expects. All of TIdMessage's processing is based on
the assumption that the data is coming from a socket instead of a
file. As long as there are no leading periods in the file, then all
is well, but if there are then they end up getting stripped out.
There have been some very lengthy discussion on that topic before, and
the issue has not been addressed in Indy yet:
> idmessage.ExtraHeaders.add('Cc: "' + edfrom.text + '" <' +
edReplyTo.text+ '>')
Why are you using the ExtraHeaders property for the Cc? TIdMessage
has a CcList property for that purpose.
> i check the "messaparts" and i see all ok , the boundary values are
> matching. but after send the message i receive the message and the
> "first" boundary is wrong
Which specific version and build of Indy are you actually using? It
would seem that you are using a version that is not preserving the
existing boundary from the Content-Type header. It is generating a
new boundary when sending the message, but the body text is preserved
so the old boundaries are not touched. Looking at the code for Indy
10, I do see how that could be happening. When sending a MIME-encoded
message with no text in the TIdMessage.Body property, a new boundary
is generated and put into the top-level Content-Type header. Why Indy
is doing that, I have no clue.
Gambit
