This is a strange one, at least to me. I'm using Pegasus to collect POP mail from 3 different servers, Yahoo, Gmail and Spectrum, set up in that order in "Internet Mail Options / Receiving (POP3)". The General default timeout is set at 45 seconds, and Settings for Receiving Mail is set to 15 seconds on each server definition. I have several "New mail filtering rules" set up and they seem to work properly. I also have some server side filtering rules set up that also seem to work properly.

The first time I check mail each morning I receive a "Not Responding" message in the New Mail folder while "Applying Filtering Rules" shows in the status line. Then a "POP3 Network or Protocol Error" on pop.gmail.com comes up (see attachment). After I acknowledge that error the remaining mail is collected from the other servers. I can then go back and select the "Check your POP3 host for new mail" icon and all connections work just fine. Mail is then collected from Gmail correctly. This error only happens once, the first time I retrieve mail in the morning. Throughout the day I don't get the protocol error. I don't know if this is a connection error or a filtering error but it is frustrating to deal with each day. Your help or suggestions would be appreciated.

Bob

P.S. Having trouble attaching Protocol Error image. Any suggestions?

The timeout setting in the definitions takes precedence over the timeout set in the General tab which means you have a 15 second timeout for each server. IMO and experience, that is not enough time for Gmail. I don't know why you are only experiencing a problem on first access of the day though. Then again, I am assuming that the problem is due to the connection timing out. A session log would confirm that, or perhaps identify another issue. Regardless, consider setting the timeout in the definitions to zero. They will then all use the timeout defined in the General tab.

Regarding attaching an image, I would not be surprised if only certain filetypes are accepted. What was your image filetype? The image below is a .jpg file.

Thanks, Brian. I'll try setting all the timeout values to 0 so the General definition is used. If that doesn't work, how do I capture a session log?

I changed the image format to .jpg format and was able to attach it below. The image shows some log information but ultimately says there was no extended diagnostic information. Is there a more comprehensive log I can capture?

I think I figured out the logging question. If I set "System Message Reporting Level" to 5 in Tools/Options/User Interface/Reporting/Logging that should give a complete log of activity. Is that correct?

New test:
I set all individual server timeout values to 0 and General timeout is set to 45 seconds. I set system messages to level 5 before I collected mail. Bottom line - that showed nothing about the Gmail connection error. I have included attachments showing the error alert from the Gmail connection and the system log with my notes about the process. Again today, the first time I tried to collect mail, the Gmail connection timed out but all other servers processed correctly. The second time through, using the "Check your POP3 host for mail" icon, the connection to Gmail was successful and mail was collected correctly. This is frustrating. Help is appreciated.

Protocol Error 021825.pdf

Protocol Error 021825 SysLog with Comments.pdf

The log you need is an Internet Session log. That logging is enabled by a tick box at the bottom of the General tab in Internet Options. These log files are created in a mailbox subdirectory named TCPLogs. Their extension identities the type of transaction that created the log. They are plain text files so you can append .txt to the filename and then double-click to open in your default text editor. Do not post an entire log file because they contain authentication credentials, sometimes in plain text but sometime encoded in an easily decodable form. If you feel the need to post the content of a log, locate the "Auth login" entry and obfuscate the four entries below it. Two will start with "334". These entries will only exist when using an app password. They do not exist when using OAUTH2 to authenticate.

FWIW, connection to my Gmail account has been very slow for awhile, as compared to how fast other accounts connect. My timeout for it is 120. That is likely overkill but the only drawback to a high timeout is a longer wait in the event of failure, which have not been occurring for me.

Today's run: (Internet Session Log turned on)

First connection was successful to pop.mail.yahoo.com - 11 messages processed.
This message was received when the connection closed:
" [!] Warning [Benign]: SSL connection improperly closed by remote host."

The second connection was to pop.gmail.com with the following results.

06:56:31.956: --- 19 Feb 2025, 6:56:31.956 ---
06:56:31.956: Connect to 'pop.gmail.com', timeout 30 seconds.
06:57:54.024: [!] OpenSSL reported error -1/5 during handshake - diagnostics follow:
06:57:54.024: [!] -------------------------------------------------------------------------
06:57:54.024: [!] * OpenSSL supplied no extended diagnostic information.
06:57:54.024: [!] -------------------------------------------------------------------------

(that's all that was in the log file)
According to my rough calculations, from start time to end time there's a span of about 83 seconds, yet timeout value says 30 seconds and General timeout in Pegasus is set to 45 seconds. Something is very strange here.

The next 3 connections to servers were made successfully although each received the "SSL connection improperly closed by remote host" error.

When I requested mail again from pop.gmail.com the connection was successful in a little over 1 second. The session log looks like this with the notes about fixing the client.

06:59:15.734: Connect to 'pop.gmail.com', timeout 30 seconds.
06:59:16.876: [] SSL/TLS session established
06:59:16.876: [] TLS_AES_256_GCM_SHA384, TLSv1.3, Kx=any, Au=any, Enc=AESGCM(256), Mac=AEAD<lf>
06:59:16.884: [*] Peer's certificate name is '/OU=No SNI provided; please fix your client./CN=invalid2.invalid'.

This information is way beyond my pay grade so help is appreciated.

It's over my head too. The "Peer's certificate..." entry indicates that something is wrong but I don't know what. Below is from a log I just made:

13:00:00.041: --- 19 Feb 2025, 13:00:00.041 ---
13:00:00.044: Connect to 'pop.gmail.com', timeout 90 seconds, flags 16842753.
13:00:01.049: [] Setting SNI hostname to 'pop.gmail.com'
13:00:01.080: [] SSL/TLS session established
13:00:01.080: [] TLS_AES_256_GCM_SHA384, TLSv1.3, Kx=any, Au=any, Enc=AESGCM(256), Mac=AEAD<lf>
13:00:01.080: [] Peer's certificate name is '/CN=pop.gmail.com'.

In the log of the failed attempt, it appears that no response is received from the gmail server. I don't know where the 30 second timeout is coming from or why the connection attempt lasted 81 seconds. You can see my timeout is 90 which I what I set it to in the host configuration before running the test.

What version of Pegasus Mail are you running?

In the POP3 host configuration Security tab, if you have the 'STLS' option ticked, try the 'direct SSL' option.

How do you have Pegasus Mail configured to check the multiple email accounts? Multiple hosts selected in one identity? Multiple identities being checked?

In the screenshot you posted, I noticed that IER was not current. I don't think that would have anything to do with the gmail issue but wanted to make sure you were aware of it.

Ok, can we break this down into smaller pieces?

First:
I have 4 identities defined <Default> (which was created at install years ago), Bob, Paula and All_Mail. The All_Mail is the one I use all the time. I hardly ever use the others. Just to do a test, I changed the "Default timeout for network connections" value to different values - not 30 seconds on all the identities. No matter which identity I use, when I collect mail and look at the TCPLogs, the connection entry shows 30 seconds.
Example - "15:38:38.451: Connect to 'pop.gmail.com', timeout 30 seconds.".

I don't know where the 30 second timeout comes from but it is NOT from any of the network configuration definitions from any of the identities I have defined.

Second:
I stopped (File/Exit) Pegasus and restarted it. This time, the first connection to pop.mail.yahoo.com failed with the same error that Gmail was getting.
"OpenSSL Reported Error 1/5 during handshake ..."
"* OpenSSL supplied no extended diagnostic information ..."
The Gmail connection on that attempt was successful the first time!

Brian, I think you may have something when you suggest there's a Peer Certificate problem, but I know very little about the protocol and don't know where to start. I can provide any information needed to help solve this if I know what to supply.

I don't think it has anything to do with Pegasus Mail. The way I interpret the failure, Pegasus Mail is sending a greeting to the a server, whether yahoo, or gmail, but does not receive a response.

Regarding the 30 second timeout, keep in mind that the timeout values are identity specific. I had this in mind when I asked how you had Pegasus Mail configured to check multiple host, by identity, or does one identity check all POP3 hosts. Put simpler, when you are in the All_Mail identity, are multiple POP3 hosts are enabled in the Receiving tab of Internet Options?
or
Do you have just one host enabled and the "When checking for mail, perform checks for all identities" option enabled?

Also, are you consistently waking or booting your PC and then immediately trying to check mail? If so, try this. Wake or boot the PC, once the desktop is rendered, wait 30 seconds, open a browser, visit a webpage, then start Pegasus Mail and see what happens. I have a Lenovo Thinkbook that is absurdly slow to wake the LAN card and to make contact with my printer. Both will affect Pegasus Mail. My old HP Pavilion came fully to life in just seconds so I could wake it and then immediately fire-up and use Pegasus Mail. Not so with my Lenovo. I wake it, have a sip of coffee or two, start a browser, and then start Pegasus Mail.

I realize the timeout values are identity specific. That's why I set each identity to a different timeout value, none of them to 30 seconds. To answer your question , yes, I only use 1 identity to retrieve mail. That identity (All_Mail) checks 3 servers. First Yahoo, next Gmail, next Spectrum and last, Yahoo again for a different email address. All the connection log entries whether they are successful or not specify a timeout value of 30 seconds.
Example - "15:40:59.760: Connect to 'pop.mail.yahoo.com', timeout 30 seconds."
As for waking or booting the PC, I rarely shut it down but when I do, I can guarantee the connection to Gmail or one of the other servers will fail the first time I open Pegasus. When I wake up the PC each day (not after a reboot), I have sort of a daily routine of tasks I go through but checking mail is not the first thing on the list. I do several other things before checking mail so there's a significant amount of time to wake up the LAN card. The strange thing is that the first connection to Yahoo is 99% successful while the second connection to Gmail fails. If the LAN card was still sleeping wouldn't the first connection fail?

Timeout values are stored in PMAIL.INI so it would be interesting to do a search of it for "timeout" and see if it reveals any "30" values, and if so, in what section(s). Do this with Pegasus Mail closed, or make a copy of the .INI and search it (safer).

Yes, I would expect so. I admit to grasping at straws though.

I checked the timeout values in the PMAIL.INI file. They are:
[General]
Default TCP/IP timeout value = 31

[WinPMail Identity - Bob]
Default TCP/IP timeout value = 90
TCP/IP timeout value (seconds) = 30

[WinPMail Identity - Paula]
Default TCP/IP timeout value = 91
TCP/IP timeout value (seconds) = 30

[WinPMail Identity - All_Mail]
Default TCP/IP timeout value = 45
TCP/IP timeout value (seconds) = 30

The "Default TCP/IP" timeout values are the ones I set in the Network Configuration/General panel for each Identity. The Receiving(POP3) timeout is set to zero for each host in all those Identities. The second timeout value in each identity is the value that is displayed in all the connection error messages.
My conclusion is that the 30 second timeout value is being used from the second "timeout value" entry in the Identity section but the first entry is what is being listed in the Network Configuration panels. Is the .INI file corrupted?

Checking further, I looked at the SMTP definitions. I have two definitions for outgoing mail, one for NY and one for AZ where I am now. I found the timeout value in both definitions to be 30. I changed those values to be different than all the other timeout values, so now all values are unique for both POP3 and SMTP definitions. I shut down Pegasus (File/Exit) and restarted. Got the same connection errors with 30 second timeouts shown. I checked the PMAIL.INI after the startup and the POP3 timeout values had not changed. When I looked at the .PND files listed in PMAIL.INI for the each Identity, I saw that the timeout values were changed correctly. Now here's the rest of the story! Even though I only show two SMTP definitions in the Network configuration panels for all Identities, there are nine SMTxxxxx.PND files in the ADMIN directory. Is my ADMIN folder messed up or is it OK to have old .PND files hanging around?

I'll be glad to share any of this information if it would help.

I'm seeing what you are seeing in that timeout changes made to host configuration are not written to PMAIL.IN. This leads me to think that the "TCP/IP timeout value (seconds) = 30" are legacy entries that are no longer used, which makes sense considering you can have several hosts enabled in an identity. It also indicates that the timeout values set in a host configuration are stored in its .PND file. This is all conjecture at this point. It is just logical based on both of our observations. Unfortunately, I don't have a clear enough picture to know whether this reveals where that logged 30 second timeout is coming from. Setting the default in each identity to 90 and every host configuration to 0 should force all POP3 activity to be at 90 but I think you have already tried this so I'm at a loss.

Regarding .PND files, they normally reside in the Home mailbox directory. If you are running the v4.81 public beta, and Home and New are in different directories, then you will likely have them in both locations as a workaround to a bug in v4.81. Copies in both is applicable only to v4.81 with different Home and New directories.

The number of uniquely named POP?????.PND files should correspond to the number of them listed when you click the "Add" button when the Receiving tab of Internet options.

The same goes for SMT?????.PND files when in the Sending tab.

.PND files are plain text files. You can open them with a text editor which will reveal which host the belong to. Do not manually delete .PND files as this will orphan their associated .PM3 file. Deletions should be done from within Pegasus Mail, which may be worthwhile if you have some that are obsolete.

Bob,
Please post the content produced by the Info button in Help > About Pegasus Mail. This will provide information about your installation that might be helpful. That content does not contain any personal information.

Brian,
Here's the installation info.

Pegasus Mail for Microsoft Windows
Copyright (C) 1992-2022, David Harris, all rights reserved
Electronic mail to support@pmail.gen.nz.

WinPMail version: Version 4.80.1028, Jan 16 2022, build ID 1028
Language resources: Standard UK English resources (EN,0,LL)
Extension Manager version: 1.14
Operating mode: Standalone
User name and ID: Admin, 0
Windows version: 6.2
Windows flag word: 0
WINPMAIL.EXE directory: C:\PMAIL\Programs
Home mailbox location: C:\PMAIL\MAIL\Admin
New mailbox location: C:\PMAIL\MAIL\Admin
TMP environment variable: C:\Users\Bob\AppData\Local\Temp
TEMP environment variable: C:\Users\Bob\AppData\Local\Temp
LAN-based SMTP support: N, N, N
NetWare MHS support: N, N, N
Built-in TCP/IP support: Enabled

• WINSOCK version: WinSock 2.0
• WINSOCK path: WSOCK32.DLLCommandline: -roam -A -ID All_MailActive -Z options: 32768PMR variable: (None)PML variable: (None)MAI variable: (None)NB variable: (None)Autofiltering folders: 0 (0 active, 0 inactive)Last new mail count: 0Message size soft limit: 0 bytesMessage size hard limit: 0 bytesAttachment size soft limit: 0 bytesAttachment size hard limit: 0 bytes

The last few parameters got a bit garbled. Here they are again.

• WINSOCK version: WinSock 2.0
• WINSOCK path: WSOCK32.DLL

Commandline: -roam -A -ID All_Mail
Active -Z options: 32768
PMR variable: (None)
PML variable: (None)
MAI variable: (None)
NB variable: (None)
Autofiltering folders: 0 (0 active, 0 inactive)
Last new mail count: 0
Message size soft limit: 0 bytes
Message size hard limit: 0 bytes
Attachment size soft limit: 0 bytes
Attachment size hard limit: 0 bytes

This info tells me that you running a standard installation of v4.80. Based on that I now know that you are authenticating to Gmail using an app password. The latest and greatest is v4.81 authenticating to Gmail using OAUTH2 but your setup should be working. I have asked for some feedback from the beta test team about the peer connection issue.

Brian,

Thanks so much for your support. Is 4.81 out of Beta yet? I would move to that if that would solve the connection problem.

BTW, I reconciled all the POP3 and SMTP definitions so I'm now down to only the ones that I use.

Keep me posted.

Bob

It is surprisingly not out of beta. The issues it has are minor, the worst of which only affects a small number of non-standard installation. They would not be an issue for you. I recommend it over 4.80 but I do not know whether it would solve your problem. The Gmail OAUTH2 authentication method is different from the username/password that we know but in your problem, the connection is not reaching the authentication stage so I would not think it would make a difference. However, this is my recommendation:

• Upgrade to the 4.81 public beta. Backup your entire \PMAIL directory first.
• Upgrade IE Renderer to the current version (2.7.2.2).
• Don't immediately set up GMail OAUTH2 authentication. Test 4.81 with your current app password authentication for awhile to see whether the problem remains.

BTW, 4.81 fixes the spell checker issue that was in 4.80. If you implemented the workaround of marking the USRDICT5.PMD file as read-only, you can remove that read-only setting.