About 3 weeks ago I downloaded Pegasus Mail v4.91.1746 and updated my previous installation of v4.81-pb3 that I'd been running successfully and accessing my various GMail mailboxes using OAUTH2 without any significant issues since v4.81-pb3 was first released in approx Feb 2023.

Although I can't be absolutely certain about the timing, it seems to me that since I installed v4.91 I've regularly been getting POP3 errors when accessing my various GMail mailboxes; the following is the error message that typically appears:

15:00:38.088: --- 3 Oct 2025, 15:00:38.088 ---
15:00:38.088: Connect to 'pop.gmail.com', timeout 300 seconds, flags 16842753.
15:00:39.102: [] Setting SNI hostname to 'pop.gmail.com'
15:00:39.117: [] SSL/TLS session established
15:00:39.117: [] TLS_AES_256_GCM_SHA384, TLSv1.3, Kx=any, Au=any, Enc=AESGCM(256), Mac=AEAD
15:00:39.117: [] Peer's certificate name is '/CN=pop.gmail.com'.
15:00:39.133: >> +OK Gpop ready for requests from 90.155.35.170 e09e53db590de-858ac63b879mb108247354d85
15:00:39.133: << AUTH XOAUTH2 dXNlcj1tYXJ0aW5nMGhkYkBnbWFpbC5jb20BYXV0aD1CZWFyZXIgeWEyOS5hMEFRUV9CRFNESnY3YnRZc3gyclFab3A2OXVpVGN2ZV9NX3B2SUpqWjhRcWJVNlBOOUNheDhlNXd3YmlFX281TWZFU0prWXBLZE5RVmVqVmJOU0NNbXZfZnk4cHpELTNUZUJwb29HZEQ2UnVHZUc2b1JHbzVZZkFWbzBHck5CWDhOV1NqUUZ3NEl0cUdndnlTRFVQWWFUYnR5cXlVUFROQmxfWV9XMUlEUXZMUDZaME4zTEFzQmNXRm1Mckp4MFlWUnh1VmtLOVhJckFhQ2dZS0FaQVNBUlVTRlFIR1gyTWlwOWdzY2lDMmNPWUllRUFaTG1GV1VnMDIwOQEB
15:00:39.972: >> +OK Welcome.
15:00:39.973: << STAT
15:00:40.101: >> +OK 19 1639062
15:00:40.101: << LIST
15:00:40.230: >> +OK 19 messages (1639062 bytes)
15:00:40.246: << RETR 1
15:00:40.375: >> +OK message follows
15:00:40.401: << DELE 1
15:00:40.520: >> +OK marked for deletion
15:00:40.520: << RETR 2
15:00:40.659: >> +OK message follows

The consequence of the POP3 errors is that the downloads of the 19 messages that are waiting on GMail never seem to complete successfully so the same messages appear again during the next download attempt.

My GMail mailboxes are all configured to archive the messages on GMail after they've been successfully downloaded by PMail; this always seemed to work perfectly well when I was running v4.81-pb3.

Has anyone else encountered any issues of this sort when accessing GMail mailboxes using PMail v4.91?

Thanks in advance,

--
Martin Davies

I don't use the Delete mail on server setting. Perhaps I should since I have Gmail configured to archive after download but messaged don't get moved to the Archive category. This is probably worthy of its own discussion since it does not affect POP3 retrieval of new message, at least not for me.

The subject line of this post indicates there are POP3 errors but the log snippet provided did not show an error. What are you seeing that indicates an error?

Is the problem specifically that the same messages are repeatedly being downloaded?

Also, there is mention of upgrading to 4.91 three weeks ago. Details about what has been happening during the past three weeks might be helpful.

Hello Euler and Brian, thanks for your replies to my posting.

I wasn't sure if the reference to 'Delete mail on server...' applied to the PMail config or to the POP3 settings in the Gmail mailboxes; I currently have (and believe I have always had) the 'Delete mail on server once it has been successfully retrieved' option checked in the Internet Mail Options > Receiving (POP3) settings in PMail and this always seemed to work fine when I was running v4.81-pb3.

In the settings for the Gmail mailboxes, the 'When messages are accessed with POP' option is set to 'archive Gmail's copy' as selected from the dropdown list.

The log snippet that I posted originally was all that appeared; the download process seemed to stop after the '+OK message follows' line at 15:00:40.659 - there were no further transactions which is presumably why the usual POP3 error window popped up. I'll try to get a screengrab of it when it next appears but I'm going to be away for a few days so it might be a while before I can do that.

The POP3 error seems to occur most often when there's more than 2 or 3 emails waiting in a Gmail mailbox - these will usually but not always download without the error occurring but on occasions I've had the POP3 error window pop up when attempting to download a single message. The log snippet I posted was for a Gmail mailbox in which there were 19 messages waiting.

As I said originally, I can't be absolutely certain but the POP3 errors only seemed to have started occurring since I installed v4.91 - I don't ever recall having encountered this particular POP3 error when I was running earlier versions.

Thanks again for your assistance,

--
Martin Davies

I'm clueless at this point.

The log content in your original post contains a "DELE 1" entry followed by "+OK marked for deletion". That entry does not exist in the log file I captured earlier. Do you use a POP3 filter that does deletions?

Just a note: As I understand the POP3 Process, the Delete request only actually happen if the session ends successfully.
So, the deleted messages in a session are not deleted if there is a failure later in the connection.

Sorry it's taken a while to follow up but I just got back from hols today and have tried to download a bunch of emails from one of my Gmail accounts; here's a screengrab of the error message that popped up after a few of the messages had been downloaded. None of them appear to have been deleted from the Gmail account yet.

I believe the rest of the information in the trace, after the << LIST command, was very similar or identical to the details in the original trace that I posted, ie. the session terminated abruptly after a few messages had been downloaded and flagged for deletion but the session didn't complete successfully.

To answer Brian's question, I've never knowingly set a POP3 filter and, as I've said previously, I don't recall this particular problem ever occurring while I was running v4.81-pb3 (or earlier versions) - it seems to have only become apparent since I upgraded to v4.91.

Is there an easy way I can revert to v4.81-pb3...??!!

--
Martin

Have you tried it again. As I understand the POP3 transaction at server side. If the complete transaction doesn't finish completely, the process is reset. Any messages flagged for delete are restored.

The failure could be a lot of issues.

1. Issue with Client Program.
2. Issue with Server Program
3. Break in the actual network connection that causes connection failure.

Show would recomment you check the create log files, and then check the log files for a specific failure message.
Note: If you post make sure to remove any userid and password lines. Since they may be included.

As far as I know, you can simple install 4.81pb3 on top of 4.91 and it will downgrade the Pegasus. Don't need to do anything fancy.

But more likely, the TCP Pop3 log would have more info on the issue.

Good Luck.

@msetzerii is correct in that an internet session log may provide details that will identify the point of failure. You can enable that logging in the General tab of Internet options. The log will be created in a subdirectory named TCPlogs which will be in your mailbox directory. The log file will contain a .pop extension but is a plain text file so can be viewed with a text editor.

@msetzerii is also correct that installing 4.81 pb3 as an 'upgrade' to 4.91 will revert it back to 4.81 pb3.

When a failure happens, does the subsequent POP3 download attempt normally work?

Thanks again to especially Brian and @msetzerii for their input.

I tried enabling the Internet session logging and captured a couple of session logs for one of my Gmail mailboxes; the first attempt to download the 18 waiting messages resulted in the session bombing out before even the first message was downloaded, Here's the session log for that attempt:

22:54:06.649: --- 9 Oct 2025, 22:54:06.649 ---
22:54:06.649: Connect to 'pop.gmail.com', timeout 90 seconds, flags 16842753.
22:54:07.659: [] Setting SNI hostname to 'pop.gmail.com'
22:54:07.681: [] SSL/TLS session established
22:54:07.681: [] TLS_AES_256_GCM_SHA384, TLSv1.3, Kx=any, Au=any, Enc=AESGCM(256), Mac=AEAD<lf>
22:54:07.683: [] Peer's certificate name is '/CN=pop.gmail.com'.
22:54:07.691: >> +OK Gpop ready for requests from 90.155.35.170 cdcc0902adbc2-3b00cc95ab5mb56332354d76<cr><lf>
22:54:07.691: << AUTH XOAUTH2 dXNlcj1vdGhlcmFtZEBnbWFpbC5jb20BYXV0aD1CZWFyZXIgeWEyOS5hMEFRUV9CRFJoaE1iM3l5bVJJd0RyRXBmRXVQZ0k5YUNGaUlJVWFLeWNfa1RDalFvZ2pfYkNyRjBtd0t6ZUk0RGxBYTBsNE5CM1ZFOGVtWW03WnhiZlpHN3M0T1JTS1ctOUNULVVqcHhSQ2RseE5pdklieVdtbnUyaXpGclRZdGFvZkFUbEJrVVluN25pdWtuSlV1RDBBckVTaXRiNzc0bTN0MktaOU9TM1Z3eGJJWmFRdXdadzgweHphd3VpZTZGMFh3My1MZHlHalFhQ2dZS0FUY1NBUllTRlFIR1gyTWlval9GZS1HUndZUHpxOWkybUo3NHZBMDIwOQEB<cr><lf>
22:54:08.113: >> +OK Welcome.<cr><lf>
22:54:08.119: << STAT<cr><lf>
22:54:08.236: >> +OK 18 1426684<cr><lf>
22:54:08.236: << LIST<cr><lf>
22:54:08.349: >> +OK 18 messages (1426684 bytes)<cr><lf>
22:54:08.349: >> 1 4806<cr><lf>
22:54:08.349: >> 2 4806<cr><lf>
22:54:08.349: >> 3 15665<cr><lf>
22:54:08.349: >> 4 69597<cr><lf>
22:54:08.349: >> 5 723992<cr><lf>
22:54:08.349: >> 6 59832<cr><lf>
22:54:08.349: >> 7 100855<cr><lf>
22:54:08.349: >> 8 83208<cr><lf>
22:54:08.349: >> 9 5367<cr><lf>
22:54:08.349: >> 10 5382<cr><lf>
22:54:08.349: >> 11 77454<cr><lf>
22:54:08.349: >> 12 56641<cr><lf>
22:54:08.349: >> 13 5372<cr><lf>
22:54:08.349: >> 14 5377<cr><lf>
22:54:08.349: >> 15 51430<cr><lf>
22:54:08.349: >> 16 51430<cr><lf>
22:54:08.349: >> 17 89791<cr><lf>
22:54:08.349: >> 18 15679<cr><lf>
22:54:08.349: >> .<cr><lf>
22:54:08.362: << RETR 1<cr><lf>
22:54:08.483: >> +OK message follows<cr><lf>
22:54:08.492: 26: SSL_read returned zero (socket was closed)
22:54:08.492: >>
22:54:15.457: << QUIT<cr><lf>
22:54:15.470: 26: SSL_read returned zero (socket was closed)
22:54:15.470: >>
22:54:15.470: 28: Error 6:0 shutting down OpenSSL session.
22:54:15.470: [!] OpenSSL reported a shutdown error - diagnostics follow:
22:54:15.470: [!] -------------------------------------------------------------------------
22:54:15.470: [!] OpenSSL supplied no extended diagnostic information.
22:54:15.470: [!] This usually indicates one of the following:
22:54:15.470: [!] - The connection was improperly closed by the peer.
22:54:15.470: [!] - A Network error external to this system occurred.
22:54:15.470: [!] -------------------------------------------------------------------------
22:54:15.470: --- Connection closed at 9 Oct 2025, 22:54:15.470. ---
22:54:15.470:

As the log shows, there seems to be something odd happening with SSL that's causing the connection to be closed by the peer, which is presumably pop.gmail.com.

A (very) short time later a second attempt to download the 18 messages waiting in the mailbox resulted in a few messages being downloaded; here's the final part of the session log for that attempt:

22:54:30.919: >> +OK marked for deletion<cr><lf>
22:54:30.919: << RETR 6<cr><lf>
22:54:31.059: >> +OK message follows<cr><lf>
22:54:31.061: 26: SSL_read returned zero (socket was closed)
22:54:31.064: >>
22:54:35.983: << QUIT<cr><lf>
22:54:35.995: 26: SSL_read returned zero (socket was closed)
22:54:35.995: >>
22:54:35.995: 28: Error 6:0 shutting down OpenSSL session.
22:54:35.995: [!] OpenSSL reported a shutdown error - diagnostics follow:
22:54:35.995: [!] -------------------------------------------------------------------------
22:54:35.995: [!] OpenSSL supplied no extended diagnostic information.
22:54:35.995: [!] This usually indicates one of the following:
22:54:35.995: [!] - The connection was improperly closed by the peer.
22:54:35.995: [!] - A Network error external to this system occurred.
22:54:35.995: [!] -------------------------------------------------------------------------
22:54:35.995: --- Connection closed at 9 Oct 2025, 22:54:35.995. ---
22:54:35.995:

Again this seems to show that the session was closed because of an SSL issue, so the question is what to do to overcome the problem.

I'll try reverting to v4.81-pb3 and see if the SSL issues persist...!

To answer Brian's question, a subsequent POP3 download attempt after the error has occurred usually doesn't work although sometimes the download gets a bit further through the list of waiting messages before the POP3 session bombs out (again).

--
Martin

Just a quick update - I just tried reverting to PMail v4.81-pb3 and found that when I tried to download the messages (which have grown from 18 to 22) waiting in one of my Gmail mailboxes the session bombed out in exactly the same way as it was doing when running v4.91.

I've updated to v4.91 again and have re-enabled Internet session logging; I'll wait to see what the logs show but I'm beginning to wonder if Google have reconfigured something on their POP3 server(s) that's causing the apparent SSL issues...

--
Martin

To me, it would seem you have some bogus email in your gmail mailbox?
I would probable recommend connecting to it via the web interface, and look at what it shows.
Perhaps there is a bad email in the group. Probable some spam message that didn't get caught.
Would probable delete any messages that might be spam. Other thing might be if something has either 0 bytes or a very large size.

Don't use the web interface much, but might try moving the messages to some other folder, and redo download. Then move them back to the inbox one by one. See which ones download and when it breaks again, would identify which message(s) it is.

Might also try the selective download option under the File menu, and see what it shows.

Might be able to selected just a few messages at a time to download, or might at least show the headers.

The log files lead me to believe that the Gmail server just stops responding. In both logs you can see where the Gmail server responds with "+OK message follows" and then nothing is transmitted resulting in the "SSL_read returned zero (socket was closed)" entry. From then on there are no responses from the Gmail server. I don't know what to make of that.

A couple of years ago I was having a problem with a gmx.com server. Fortunately I was receiving email from another gmx.com account holder so looked at those message headers to identify the IP address of the gmx server he was hitting and started using it. The problem was resolved. I wonder if that would work with gmail. I would suggest trying it if you were using an app password but I'm concerned that trying to test it with OAUTH2 would break your OAUTH2.

At this time I don't have any suggestions beyond those already made. FWIW, I have two gmail accounts. One I authenticate with an app password, the other via OAUTH2. Both are working fine. I don't delete on server.

Thanks yet again to Brian and @msetzerii for your suggestions; here are my further thoughts:

I don't believe the cause of the apparent SSL issues could be a bogus or rogue email because the POP3 error occurs when I access any of my 4 active Gmail mailboxes, and there are no messages that are common to all the mailboxes.

I have tried accessing the mailboxes using the web interface - I do it fairly regularly for various reasons - and I haven't noticed anything untoward in any of the mailboxes. I have cleaned out a few emails that have successfully been downloaded by PMail but then didn't get archived in Gmail because the download sessions didn't complete successfully.

As Brian has indicated it does appear that the Gmail server just stops responding in the middle of a session; I don't know how feasible it will be to draw the issue to the attention of the Gmail support team...

I'll try unchecking the option in PMail to delete messages on the server after they've been retrieved to see if that makes any difference.

--
Martin

Sorry for joining this thread so late, but I'm under the impression that the 18 messages listed on your session log have already been downloaded.
Gmail handles this differently than other servers. For example, a message read through the web interface on Yahoo won't be available for download via POP3 (already read). Gmail, however, is different, and messages read via the web will continue to be available for download via POP3, and in this case, they can be archived, deleted, or ignored. This leads me to wonder if the recent: option is being used. Is it? Below is a screenshot from the Gmail help page https://support.google.com/mail/answer/7104828?hl=en#zippy=%2Cemails-arent-downloading-correctly

Have you tried that? It's a long shot in the dark, but...

Quite a time ago I had a problem with one of my Gmail accounts. I don't remember exactly what happened BUT apparently all of my archived email were made available for POP3 download AGAIN. At that time there was no recent: workaround. I would have to re-archive ALL already downloaded messages to regain control of my email account.
While using Selective POP3 mail download with Gmail I learned that Mark for deletion was sufficient to make Gmail archive the message without the need to a new download, and so did I. You may be suffering for some sort extraneous Gmail glitch.

Good thought Euler. I had forgotten about the recent: option. That is worth a try to see if it changes things although the unanswered questions remains why it had worked fine until recently. The recent: option has been around for years.