PureBasic Forum

See your PM. Thanks.

Interesting. My app was also having issues and it uses this command, so I will be watching this fix with interest, in case it's the problem I've been having.

I have updated the library (PB 4.50 version).

The problem was that the boundary definition in your mail was missing quotes. I have updated the library internal functions to handle this case. Hopefully, it will not break anything else.

Thank you gnozal, I can confirm it works correctly now.

I just noticed today that if I call PurePOP3_OpenPOP3Connection() with an invalid username or invalid password, then my app freezes at that command and uses 50% CPU while the command tries to authenticate during its timeout period. So, is it possible this command can be modified to not use such high CPU during authentication? Because my PC slowed down noticeably today and I didn't realise why at first, and then discovered it was due to my app trying to authenticate with an invalid username.

- PurePOP3 uses Delay() in the loop waiting for the POP server answer.
- you could try to change the time out using PurePOP3_SetTimeOut()

Anyway, I have updated the PurePOP3 library with a slightly greater delay. Maybe it helps.

Yep, my app now shows 0% CPU in the Task Manager when trying to connect with an invalid login, instead of 50%. Thank you!

Hi gnozal.

I'm wondering whether it is possible or not to implement the TOP function provided by POP? The reason behind this is that I would like to get just the header part ( subject, address, .... ) without actually downloading the whole message before.

Thanks!

Update (PB4.5x version)

Changes :
- New function PurePOP3_RetrieveInfo(MessageNumber.l) [see help file]
  Retrieve message headers from POP3 server.
  . This function only retrieves the headers (not the message, nor the attachments) : use only PurePOP3_GetMessageInfo() after it.
  . Not all mail servers support the POP3 TOP command but if they do it is useful for only retrieving part of the message.

Thanks again gnozal. Works like a charm

Found an issue with the way PurePOP3 parses a HTML email. Here's a snippet of the email's raw source:


The PurePOP3_IsMessageHTML() command returns 1 for the above. But then when I use PurePOP3_GetMessageTextInMemory(1) with it, the URL of "www.bluesnews.com" is returned in the body as "www.bluesnews..com" by mistake. Note the double-periods. I assume this is because in the raw source above, there is a "=" before the ".com" in the email, and the URL is also broken over two lines at that exact part of text. Hope this can be fixed easily.

I use a decode routine which should handle the '=' stuff.
Basically, it does this :
  =CRLF => nothing
  ..CRLF => .CRLF
  =XX => CHR(DEC(XX)) < if XX is a valid HEX number >
Using your snippet above and assuming that there is a CRLF after each line, my decode routine outputs this :Which looks fine to me.
I can't test more without the complete traces.

I did some checking. The source I posted above is what my ISP shows as the raw message source. But when I used PurePOP3_Trace(1), the debug files actually show it like this:


So, it seems your library is adding a second dot for some reason? Is there any point me sending you the traces if they don't match the raw source in the first place? If so, I will do it. Let me know.

Now that's odd : the dumps are the exact copy of the data received with ReceiveNetworkData().

PurePOP3-DEBUG-COM.txt shows all the communication, PurePOP3-DEBUG-RETR-XX.txt only the final complete message.

Do you also find the duplicated dot in PurePOP3-DEBUG-COM.txt ? If yes, that's what ReceiveNetworkData() gets...

Yes, both "PurePOP3-DEBUG-COM.txt" and "PurePOP3-DEBUG-RETR-000.txt" have the double dot, but the message source in my ISP's webmail has only one. It's like the message source you get in Gmail when you click "Show original" when viewing an email. As a side-note, the "text/plain" part of these emails are correct, with only one dot ("weburl http://www.bluesnews.com--").

Maybe my ISP is fixing the double-dot when showing me the source? This might be a false alarm...?