I am using POP3 to collect mail on 3 different servers, TWC, Google and Yahoo (for 2 different mail addresses). Connection to the first server (Google (OAUTH2)) collects mail and starts the new mail filtering process. I can watch the progress window go through the "Getting mail headers" and "Applying mail filtering steps", then the second server (Yahoo) gets a timeout error:

Setting SNI hostname to 'pop.mail.yahoo.com'
OpenSSL reported error during handshake - 1/5 ...
* OpenSSL supplied no extended dialog information

After that timeout, server number 3 (TWC) retrieves mail and goes through the filtering process. Then Yahoo is opened again for the second email address but get the timeout error described above.

When I go back and use the "Check your POP3 host for mail" icon, mail is retrieved successfully for the first timed out server 2 but fails again on the next server. I have to go back and select mail a third time to retrieve all my mail.

This pattern is consistent and the timeout seems to follow the filtering process of new mail.

Any ideas?

Does this happen every time you retrieve messages or just on one triggered when you open the new mail message? If the later, do you have a large number of unread messages in your new mail folder? What I am getting at is wondering whether the filtering activity you are seeing is the filtering of unread messages as the new mail folder open which in turn is affecting the POP3 process.

I'm not sure how to interpret the process. I generally leave Pegasus open all the time. Each morning (or sometimes more often) I use the "Check your POP3 host for new mail" icon which goes through the list of POP3 servers I have defined in the "Receiving (POP3)" Internet options. Usually the first server retrieves several (15-20) items and goes through the "Downloading Headers" and "Applying Filters" process successfully. The second server then times out with the "SNI" error listed above. After I acknowledge the error, the third server retrieves several more messages successfully and goes through the filtering process. Often I see a "Not Responding)" message at the top of the window and then the timeout occurs. I wish I had a tracing facility for a better description of the process.

To answer your question better, yes, it appears that when the new mail folder is opened with multiple messages (usually 15-20) and the filtering process starts, it affects communication with the next server.

What version of Pegasus Mail are you running?

I installed Version 4.8.1.1154 Jan 10, 2023 build 1154 about a month ago. I think it was in beta at the time.

That's good. The 4.8x versions have a newer SSL which is what I wanted to make sure you had.

The "Not responding" message is a system message that indicates that Pegasus Mail is busy and, being single threaded, is not responding to inquiries from the system checking to make sure it is functioning. Are you running an older, low ram PC?

My other random thoughts:

• Make sure Load Winsock is enabled in the Various tab of IER configuration and set to Always in the Pegasus Mail Tools > Options > General settings > Advanced settings.
• Confirm the system default printer is available.
• In the POP3 host configurations for those Yahoo accounts, increase the timeout values and check the security tab to see if they are using via direct SSL connect.
• Does a restart of Pegasus Mail will temporarily solve the problem?

I am using an older laptop - Toshiba Satellite L855 about 10-12 years with 16GB Ram, Intel i3-3110M CPU (2.40 Ghz) 466 GB of solid state storage, x64 Windows 10 OS.

The Load WinSock setting is ALWAYS. Printer is available. You may not remember, but in the other timeout issue we worked on a few weeks ago, the timeout values in all the POP3 server definitions are set to 0 so the default General setting would be used. That doesn't work either because every timeout message says 30 seconds regardless of the settings in either the General or individual settings. Lastly, a restart of Pegasus does not solve the problem.

I genuinely believe that it does work and that the timeout you see is associated with a legacy entry in pmail.ini that has been replaced with the timeout value stored in the host .PND file, or if zero, the default timeout which, IIRC, has its own entry in pmail.ini. I don't have time to dig into this now to be certain. For testing, I suggest setting the default timeout to 120 if it isn't. I have not seen a high timeout value cause any issues. Beyond that, I am at a loss.

I am wrong about this! I apologize Bob. Please go back to assigning a timeout value in the host configuration files. I have just found that placing a zero in the host configuration results in a default of 30 seconds and not to the number specified on the General tab as the support documents claim.

In the earlier discussion I may incorrectly be recalling that you had assigned different timeout values in each host but still saw the 30 seconds in the logs. I just tested it with my four POP3 hosts and the resulting log files reflected the value as assigned.

This morning I experienced the same connection failure reported by the OP in the original post except mine was a connection attempt to a zoho.com account. The failure occurred at second 16 in the connection. I was playing with timeout values at the time but I do not believe this error was a timeout error for two reasons. First, a timeout event was not logged. Second, I do not believe my the timeout value was that low when the error occurred.

I have logged numerous POP3 connections to my zoho account since then and all have completed in about 3 seconds. Like the OP, my zoho account is much like his yahoo account in that it is being POP3 polled as part of a sequence of multiple other accounts. Unlike the OP, my email volume is very low. There is no correlation between filtering and that zoho POP3 error. I have not been able to duplicate it.

The SSL related communication in a successful connection looks like this:

13:06:17.772: --- 15 May 2025, 13:06:17.772 ---
13:06:17.772: Connect to 'pop.zoho.com', timeout 30 seconds, flags 16842753.
13:06:18.828: [] Setting SNI hostname to 'pop.zoho.com'
13:06:18.891: [] SSL/TLS session established
13:06:18.891: [] TLS_AES_256_GCM_SHA384, TLSv1.3, Kx=any, Au=any, Enc=AESGCM(256), Mac=AEAD<lf>
13:06:18.891: [] Peer's certificate name is '/CN=*.zoho.com'.
13:06:18.938: >> +OK POP3 mx.zohomail.com v1.0 server ready

Whereas the failed connection looks like this:

07:36:09.321: --- 15 May 2025, 7:36:09.321 ---
07:36:09.321: Connect to 'pop.zoho.com', timeout 30 seconds, flags 16842753.
07:36:25.311: [] Setting SNI hostname to 'pop.zoho.com'
07:36:25.311: [!] OpenSSL reported error -1/5 during handshake - diagnostics follow:
07:36:25.311: [!] -------------------------------------------------------------------------
07:36:25.311: [!] ** OpenSSL supplied no extended diagnostic information.
07:36:25.311: [!] -------------------------------------------------------------------------

You can see the 16 second period of no communication before the OpenSSL error. I do not know whether it is Pegasus Mail or zoho that is waiting for a response during this time.

I tracked two days of mail retrieval on the three servers I use. Like the example above, there was a significant amount of time between the Connection attempt and the "Setting SNI ..." for the servers that failed. On both days, and throughout the past weeks, I observed that the next server in sequence fails after retrieving and filtering multiple messages from the prior server. I don't know the relationship, but that seems to be the pattern. I set the TCP/IP trace on and collected the data for the two days. I've enclosed a summary of the data from those traces. If needed, I can supply the actual trace files for closer inspection.

I may have uploaded the summary documents twice. I don't see them here so I hope they made it.

I just thought of a test that I would do if I was experiencing this issue. That test would be of the POP3 connections while the new mail filtering is disabled. I don't know whether identifying filtering as the cause will help in finding a solution but at least we'll know.

My test would be:

• Insert an "Always exit" rule as the first rule in the new mail filters.
• Test a POP3 cycle and note yahoo.com connection behavior.
• Disable that "Always exit" rule then close/open the new mail folder to process all new mail through the filters.
• Enable the "Always exit" rule to test again.
• Do the disable to process new mail.

Repeat until there is some sense of behavior change, if any.

I'll try that, but first a couple questions.
By disabling the filtering rules (Always Exit), does that leave all collected mail in the New Mail Folder?
How do I close/open the new mail folder to process the new mail after removing the "Always Exit"?

BTW, did you see the trace summary documents I included?

You don't need to remove the "Always Exit" rule, just disable it. To toggle enable/disable right-click on the rule then select Enable/disable rule. Each time the New Mail folder is opened, all unread messages get processed through the new mail filtering rules so you need to go through an open process once the rule is disabled. Doing the open process depends on whether you work in List mode or Preview mode. If in Preview mode, double click on the New Mail folder entry to open it in its own window. That will process the unreads through the filter. If in List mode, close New Mail folder and then open it again (it's the toolbar icon that looks like a green tray containing envelopes).

I don't see it.

Here are results from the "Always Exit" test.

The very first rule in New Mail Filtering rule set is "Always ... Exit this rule set"

First Pass of the servers:
TWC - 9 new messages - 5 stored in New Mail Folder, 4 stored in Junk Folder
GMail - CONNECTION FAILED
Yahoo - 9 new messages - 6 stored in New Mail Folder, 3 stored in Junk Folder
Second Pass:
TWC - No new messages
GMail - 19 new messages - 12 stored in New Mail Folder, 7 stored in Junk Folder
Yahoo - CONNECTION FAILED

All of the above results were with the "Always Exit" rule in effect. That would indicate to me that filtering doesn't cause the connection failure.

After Exit rule was disabled and New Mail Folder was re-opened (Preview Mode), all mail was filtered to it's appropriate folders.

As for the document upload, I still can't seem to get them to upload. They are Word documents. I use the "Upload file or image" button and get a new window to search my files. I select the document (14+ Kb), click Upload, the window goes away, but nothing is loaded to this discussion.

That rules out filtering as cause.

Frustratingly, the connection failures are not associated with a specific account.

Do you check all accounts from one identity or do use the "When checking for mail, perform checks for all identities" configuration option?

This is unfortunate. It's the forum. I recall needing help from forum admin so that I could upload a .pdf to the Add-ons category. First I needed permission, then .pdf files needed to be set as an allowed file type. David Harris is hosting this site on his server so perhaps there is a need to control space, or maybe just a tight control over who can do what.

Update for today (5/20/25):
I used the File>Selective Mail Download method to retrieve mail today.

First was GMail - 3 separate TCP log files
595 - connected successfully - listed 22 messages
596 - connected successfully - all 22 messages retrieved and deleted from server
597 - connected successfully - no messages left on the server

Next was TWC - 2 TCP log files
598 - connected successfully - listed 8 messages
599 - connected successfully - 1 message retrieved & deleted, 7 messages deleted

Next was Yahoo - 2 TCP log files
600 - connected successfully - listed 20 messages - received warning error at closing "Warning [Benign]: SSL connection improperly closed by remote host."
601 - connected successfully - 5 messages retrieved & deleted, all others deleted - received same warning error as above.

Conclusion:
When contacted separately, all servers connect successfully via SSL. When contacted in succession from an identity, connections fail. We've already determined it's not the filtering that causes the failure. What else could be causing the failures? I'd be happy to provide detailed TCP logs if allowed to upload them.

N.B. It would be great if you could elaborate on the method you are using to check your multiple email accounts. It would also be great if you could post screenshots of the POP/SMTP settings of your Pegasus accounts. Feel free to mask email addresses but keep the rest of the information clear.