Dear Remy,
In don't think that the message is malformed - the RFC 822 permits white
space around any symbol except in a few defined instances. RFC 2045, which
defines the MIME message warns that transport protocols may add or delete
white space to or from a message. If this is the case, then the sender may
be correct when they say that they haven't changed anything!
That said, I am glad that this particular problem has been resolved by the
Indy developers, but I find the idea of using a pre-release version a bit
unattractive. Do you know when the next release is scheduled for?
Kind regards
Mike
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:444e61af$1@newsgroups.borland.com...
>
> "Mike Hall" <Mike.Hall@NOSPAMPLEASEMachine-IT.Com.invalid> wrote in
> message
> news:444de291$1@newsgroups.borland.com...
>
>> I have tried the latest verion 9 and also the latest release of version
> 10,
>> but not the develpoment snapshot. This is because I don't want to
>> introduce further complications with untested code.
>
> The snapshot is over a year newer then the release. It has been tested,
> and
> plenty of people use it in production projects.
>
>> I have, however trace the decoding through the Indy source code,
>> and have found that the problem is a space on the end of the line:
>
> Told you the message was likely malformed ;-)
>
>> Adding the line:
>>
>> LContentTransferEncoding := Trim(LContentTransferEncoding);
>>
>> in the place indicated resolves the problem.
>
> All the more result that you should be using the latest snapshot, because
> TIdHeaderList already trims the header values that is returns.
>
>> I am assuming that this is a bug in the receiving code
>
> It is a bug in the sender's code. It should not be putting extra spaces
> in
> its headers to begin with.
>
>> I would like to have theis fault reported to the Indy developers
>
> It has already been addressed. You need to use a newer version that
> already
> has it implemented.
>
>
> Gambit
