Re: Problem/Bug with IdPOP3

Giganews Newsgroups
Subject: Re: Problem/Bug with IdPOP3
Posted by:  Remy Lebeau \(Indy Team\) (no.spam@no.spam.com)
Date: Tue, 27 Nov 2007

"HHenk" <nospam@nospam.com> wrote in message
news:04AF34ECB43EE340nospam@nospam.com...

> I was experimenting a bit with Indy 10 as supplied with
> Codegear RAD Studio 2007, latest version.

The version of Indy 10 that shipped with RAD2007 is not the latest Indy 10
version that is available.  It is the same (now outdated) version that
shipped with BDS2006.  Indy was not able to finish a new version in time for
RAD2007's release, so CodeGear used the version they already had on hand.

>  catch(Exception &e) {return;}

You should always catch exceptions by 'const' reference instead:

    catch(const Exception &e)

>  int cnt = IdPOP31->CheckMessages();
>  if (!cnt) return;

>  TIdMessage *msg = new TIdMessage(NULL);
>  if (IdPOP31->Retrieve(1, msg)) msg->SaveToFile("mail.eml");

Since you are not doing anything with the TIdMessage, you could use a
TStringList or a TStream for better performance, as well as preserving the
original email data as-is without TIdMessage parsing and regenerating it.

>  IdPOP31->Disconnect();

That should be inside a try..catch or try..finally block to ensure the
connection is always closed even if an error occurs.

> In the received file mail.eml I, see this (6 lines, line 1, 3 and 5 end
> with =):

As it should be.  You are not taking into account that the email data you
are saving to file is being encoded by TIdMessage.  Email lines are limited
to a certain length.  Lines longer than that have to be broken into multiple
lines, and that is where the extra '=' comes into play.  That is a "soft"
break, as defined by the "quoted-printable" algorithm that MIME uses.

> Note that there is an extra dot (0..000 instead of 0.000)!

Any encoded line that begins with a '.' character must be escaped as '..'
for proper handling by email systems.  TIdMessage.SaveToFile() encodes the
file in the same format as if the email were being transmitted over a
connection.  Indy does not modify '.' characters otherwise.  The only way
that '..' could ever be appearing is if the lines were previously broken at
that position during parsing, causing '.' to appear at the beginning of a
new line.  Since the resulting '..' does not actually appear at the
beginning of a line, that can only suggest that there is a descrepency
between the various encoders that TIdMessage uses internally.  I have no
clue at this moment how that could be happening.  Please provide the
original raw email data that was downloaded from the POP3 server (not the
data that TIdMessage saved to file).

> When opening mail.eml with outlook, and saving the attachment, the
> resulting file also has the 0..000.

Because the '..' is not at the very beginning on the line, so it is treated
as-is when read back, rather than being unescapsed.

> When I drag the send email from the outlook-express 'send-items'
> folder to the desktop, the email is saved as an .eml file. In this (send)
> eml file I see this (6 lines, line 1, 3 and 5 end with =):

OE does not save .eml files in the exact same format that TIdMessage does.
This is a known design issue with TIdMessage's SaveTo/LoadFromFile() methods
that has not been addressed yet.

> To me, it looks like IdPOP3 is inserting an extra dot before the =
> character.

It is, but it is doing so intentionally.  LoadFromFile() will remove the
extra dots when reading the file back, but only if they appear at the
beginning of a line (which they are supposed to be).

Gambit

Replies

In response to

Problem/Bug with IdPOP3 posted by HHenk on Tue, 27 Nov 2007