At first: Thanks for new parameter!!!
Pop3 seems to be a very "non-standard" protocol.
Month ago I tried to write my own pop3-retrival code but it did not work correctly.
It seems that so many diffrent formats are in use, that nobody can write a real good analyse routine to catch the mail from the mail-server.
Here is a little sample code from Eudora (sender) and my local mercury mail server:
Code:
Received: from spooler by loassis.de (Mercury/32 v4.01a); 29 Oct 2005 15:10:25 +0200
X-Envelope-To: <rom>
Return-path: <fl>
Received: from fl (192.168.132.60) by loassis.de (Mercury/32 v4.01a) with ESMTP ID MG00000A;
29 Oct 2005 15:10:20 +0200
Message-Id: <6.1.2.0.0.20051029150955.021df2e8@pop3.loassis.de>
X-Sender: fl@192.168.132.60
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Sat, 29 Oct 2005 15:10:20 +0200
To: rom
From: Lars <fl>
Subject: Test
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
134567890
This mail returns no Body-Text... With
PurePOP3_GetMessageTextInMemory() but 134567890 should be correct.
In some cases the last two caracters are missing...
I do not have any suggestions for that pop3-behavior (I think this is not a library problem!!!). I bet: if you write the same mail with outlook or use another mail-server you get the correct result.
With the new (optional) parameter I can try to parse the mail with a separate routine. And the lib is now -the- replacement for getmail.exe.
Hope to see more releases!
If you need more example codes let me know.
Lars