Dear Remy,
Thank you for your reply.
I did say which versions of Indy that I was using. Initially I was using
the version supplied with Delphi 7, which I think was 9.00.18. 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 application hadn't been changed at all - indeed I hadn't recompiled it
for 12 months prior to the problem.
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:
"Content-Transfer-Encoding : base64 "
the space is read by Indy, and when used to check the encoding scheme, it
doesn't match 'base64 ' with 'base64'. This happens at around line 383 of
idMesageCoderMime, a snippet of which is attached below.
Adding the line:
LContentTransferEncoding := Trim(LContentTransferEncoding);
in the place indicated resolves the problem. Obviously the 'Clever'
components feature this problem too. I am assuming that this is a bug in
the receiving code, I haven't checked the RFCs to see if a space is
permitted on the end of the line, but white space is normally allowed in
Internet documents and other readers cope.
I would like to have theis fault reported to the Indy developers, but they
have closed their bug reporting page. If you or anyone else reading this
message has access to the page, could you please report it?
Many thanks
Mike
The code snippet:
if FBodyEncoded then begin
LContentTransferEncoding := TIdMessage(Owner).ContentTransferEncoding;
end else begin
LContentTransferEncoding :=
FHeaders.Values['Content-Transfer-Encoding']; {Do not Localize}
if LContentTransferEncoding = '' then begin
LContentTransferEncoding := FHeaders.Values['Content-Type']; {Do not
Localize}
if TextStartsWith(LContentTransferEncoding,
'application/mac-binhex40') then begin {Do not Localize}
LContentTransferEncoding := 'binhex40'; {do not localize}
end;
end;
end;
// Add this line to resolve the problem LContentTransferEncoding :=
Trim(LContentTransferEncoding);
if TextIsSame(LContentTransferEncoding, 'base64') then begin {Do not
Localize}
LDecoder := TIdDecoderMIMELineByLine.Create(nil);
end else if TextIsSame(LContentTransferEncoding, 'quoted-printable') then
begin {Do not Localize}
LDecoder := TIdDecoderQuotedPrintable.Create(nil);
end else if TextIsSame(LContentTransferEncoding, 'binhex40') then begin
{Do not Localize}
LDecoder := TIdDecoderBinHex4.Create(nil);
end else begin
LDecoder := nil;
end;
try
if LDecoder <> nil then begin
LDecoder.DecodeBegin(ADestStream);
end;
Kind regards
Mike.
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:444d2b68$1@newsgroups.borland.com...
>
> "Mike Hall" <Mike.Hall@NOSPAMPLEASEMachine-IT.Com.invalid> wrote in
> message
> news:444b6963@newsgroups.borland.com...
>
>> I have an application, which has been running sucessfullt for
>> around 18 months, which accepts files by e-mail and uploads
>> an XML attachment to a DB.
>
> You did not say which version of Indy you are using.
>
>> Suddenly, the application has stopped working, and this is due
>> to the attachment not being decoded by Indy, but saved to disk
>> in MIME format; just the attachment that is, not the whole file.
>
> Did you change anything in your code lately? Did you upgrade Indy
> recently?
> If not, then the only explanation is that messages have started arriving
> to
> your application in a different format that your version of Indy can't
> handle.
>
>> the sending client's format has changed a little and I presume that this
>> has caused the problem.
>
> Very likely, yes. What EXACTLY has changed? Which portions of the
> message
> are not being parsed correctly?
>
>> I have upgraded it to the latest version 9 and the latest 10 (not the
>> development one).
>
> Why not the latest snapshot of Indy 10?
>
>> Return-Path: *****@*****.com
>
> The "Return-Path" header appears twice in the message. Although that has
> no
> effect on Indy's parsing, it is an indication of a malformed message from
> the client's end. That header should appear only once.
>
>
> Gmbit
