Bob,

I have heard back from David Harris. His comment and suggest is below. It is relevant to v4.80 and leads me to think that 4.81 may solve the problem.

In older versions of the program SNI was turned off by default; these days,
it's turned on by default.

Suggest the user create a file called TCPIP.OPT in the directory where
TCPIP.DLL is located containing the following lines:

-------------------------- Cut here ----------------------------
EnableSNI : 1
ModernTLS : 1
-------------------------- Cut here ----------------------------

If the file already exists, add these lines to it (replacing any existing versions
of the same lines).

I set up the file just as directed with the values copied from David's post. I exited Pegasus and restarted. I wish I could say it fixed the problem, but unfortunately it did not. One silly question though. The file name for the TCPIP.OPT file I created was in upper case. The tcpip.dll filename is in lower case. Would that make any difference?

I got the predictable results I expected when I restarted Pegasus. The connection to pop.mail.yahoo.com failed with "OpenSSL supplied no extended diagnostic information". That usually happens after a restart. After the error is acknowledged, the rest of POP mail is collected successfully, even Gmail. If I don't shut down Pegasus and collect mail the next morning using the "Check your POP3 host" icon, the connection to Gmail fails. This scenario is pretty consistent.

Enclosed is the System Messages window after startup.
Protocol Error 022625 System Messages Window.pdf

I hate to keep piling on the problems, but I have the General option to "Preserve deleted messages until Pegasus closes" set on (box is checked). Whenever I restart Pegasus, the Deleted Messages folder is not emptied. Is there a time limit associated with that?

I will report to David that his suggestion did not help.

Since the problem is associated SSL, I would go into you POP3 host configuration files for Gmail & Yahoo and switch the SSL setting to see if that makes a difference (eg: if STLS, switch to direct SSL connect). Grasping at straws here, again.

When a Deleted Messages folder exists at the time the "Preserve deleted messages until Pegasus closes" option is set, it will not be deleted on close. That is likely what has happened to you. You will need to manually delete it. It will be recreated on next delete, and then should be removed during future shutdowns.

Just another idea - altough it's very unlikely: What is your Winsock setting on Tools > Options > Advanced settings > Load Windows Internet Services (): It's recommended to enable Always.

Thanks for these suggestions.

Michael,
The "Load Windows Internet Services" option is already set to Always.

Brian,
Just for fun I tried to set the "via STLS command" option on both Gmail and Yahoo (doing so changed the port # to 110). I did each host individually. I then tried the File/Selective Mail Download and received a 10060 error for each host.
POP3 error: -ERR Cannot connect to POP server 74.125.137.109 (74.125.137.109:110), connect error 10060
POP3 error: -ERR Cannot connect to POP server 66.163.170.35 (66.163.170.35:110), connect error 10060
I switched both back to Direct SSL (port 995) and they connect successfully using the File/Selective Mail Download .

As for the Deleted Message Folder, - my bad! I have the Advanced setting "Deleted messages folder persists between sessions" option marked which I believe overrides the "Preserve deleted messages until Pegasus closes" option. Sorry for wasting your time on that.

Just to follow up on the above. After I successfully connected to the Yahoo and Gmail servers as described above, I used the "Check your POP3 host for new mail" icon which checks Yahoo, Gmail, Spectrum and Yahoo again in that order. The first Yahoo connection was successful, Gmail failed with the messages below. Spectrum and 2nd Yahoo connections also succeeded.

08:24:02.244: --- 27 Feb 2025, 8:24:02.244 ---
08:24:02.260: Connect to 'pop.gmail.com', timeout 30 seconds.
08:24:55.450: [!] OpenSSL reported error -1/5 during handshake - diagnostics follow:
08:24:55.450: [!] -------------------------------------------------------------------------
08:24:55.450: [!] * OpenSSL supplied no extended diagnostic information.
08:24:55.450: [!] -------------------------------------------------------------------------

Changing the port would definitely cause it to fail.

I should have tested STLS with Gmail before suggesting it. I have since done so and it doesn't work. I have asked David about the OpenSSL error, wondering if it is separate from the peer connection issue. I'll let you know of any response.

Sorry for jumping into the thread so lately.

The SMTP 10060 error indicates that the sending server did not receive a response from the recipient server within the timeout interval. The more common causes are:

• Invalid SMTP host or port.
  • 587 TLS
  • 465 SSL
• Invalid SMTP authentication.
• Network connectivity issues on the sending server.

POP3 uses port 995 (SSL or TLS)

IIRC, setting Pmail to work with OAUTH2 takes care of everything.

I have been hesitant to state that because my v4.81 POPs Gmail account using an app password without issue. I don't know anything about SSL so am clueless whether OAUTH2 authentication would make a difference.

David commented on the last posted log content with the following:
"Error 5 is the error OpenSSL reports when it has no idea
what happened (I'm not kidding about that, either). There's something really
off happening in the protocol negotiation, though."

That was all so I think he is as clueless as the rest of us. We know that 4.80 normally works fine for accessing Gmail with an app password. We just don't know what is causing the problem for Bob.

I'm confident the problem is on Gmail's side. What I'm assuming is that the reported "Invalid SMTP authentication" could be "Invalid OAUTH2 authentication." As we know, OAUTH2 is not a standardized protocol, but a private authentication method. As the mail server doesn't know that, throws the default message.

Maybe I'm overshooting this but a fair test to know if OP's app password is still valid would be retrieving messages via POP3. If it is working to get must work to send.

I agree except for the fact that it has happened with yahoo. Something is off with the "protocol negotiation" (David's words). IDK whether this is solely a Pegasus Mail thing or whether anything in the OS is involved.

OP is running v4.80 so no OAUTH2 involved. I don't have much confidence that v4.81 with OAUTH2 will fix the problem. David has not mentioned upgrading in my correspondence with him. That said, I still recommend the 4.81 beta, not only for Gmail OAUTH2, but also for the bug fixes and new copyself format options.

OK, I decided to take the plunge this morning. I backed up the complete PMAIL folder, insured that IERenderer (whatever that is?) was current at 2.7.2.2 and installed V4.81. It was a quick and easy install. Below is the "About" info on the new release.
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.81.1154, Jan 10 2023, build ID 1154
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.DLL

Commandline: -roam -A -ID All_Mail
Active -Z options: 32800
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

Good news so far. When I started Pegasus the first time after the new install - no timeouts on any of the servers. With 4.80 I would have expected a connection timeout on the first server - Yahoo, but it connected right away. All connections seemed quick, just following the status line at the bottom. Maybe it's because it's early Sunday morning and server traffic is low but I suspect the new release is a better explanation. I then tried the "Check POP3 host" icon and same thing - no connection failures, not even Gmail. The only thing I see so far is the Connection message in the TCPlog still says 30 seconds but there are no 30 second timeout values set in any of my network definitions.

I'll continue to watch the performance of 4.81 to see if the OpenSSL gremlin comes back, but for now life is good.

Sincere thanks for all your help on this. Will keep you posted.

When will we know when 4.81 become official?

Yea!

I would love to know where this is coming from but I know you have spent on lot of time resolving the connection issue so perhaps start a new discussion if and when you want to pursue it.

For the record, I've been observing consistent SSL handshake failures for about two days now, when sending = on an SMTP service. I'm using a local indigenous freemail service, pretty popular, but I don't want to name them in this context :-) I'm in touch with their helpdesk, who have made quite some effort to help me, considering that this is a free service.

For a few months, I've been running the 4.81 beta: namely 4.81.1154, dated Jan 10 2023.
Among intelligible strings inside its tcpip.dll, I've noticed OpenSSL v1.1.1q . That's relatively fresh, but at the same time it belongs to the classic OpenSSL code strain/pedigree that's been frowned upon a lot during the last decades and has recently stopped getting patches. (At times like these, it would be nice to have the SSL library pedigree and version mentioned in the About dialogue...)

I'm referring to the schism around OpenSSL many years ago, when LibreTLS got forked, and then OpenSSL forked the 3.x family as its own "inside job of a codebase overhaul", initially bringing some wrinkles of its own, which later got rectified... And then there's also the GnuTLS...

The day before yesterday, the failures used to contain the error code "-1/5" (my assumption: SSL_do_handshake() = -1, SSL_get_error() = 5). I assume this points to the error known in ssl.h as SSL_ERROR_SYSCALL . As has been mentioned in this thread already, this error is not very specific in the way of pointing a finger at the culprit, yet it does have a reasonably clear local meaning: the underlying layer of communication (aka "BIO", namely probably the TCP session) has disconnected. Something just closed the socket without much explanation - possibly the opposite party, i.e. the server. BTW when an SSL_ERROR_SYSCALL occurs, another additional error code could immediately be obtained from the standard libc "errno" (not reported by PMail). Yet it would probably not reveal much further information (I'd hazard my guess at EPIPE or some such).

Interestingly, today I can see PMail report a different error: "SSL_read returned zero (socket was closed)" . Which sounds fairly similar to the previous error and analysis.

I have tried watching the session using a locally running instance of Wireshark at the client machine. I have some captures... essentially the server does "answer the call" (accept and handle the socket), the initial SSL greetings are exchanged, then the server says "change cipher" (plus some encrypted payload), obtains a plain TCP ACK from the client, then the client says "change cipher" (plus some encrypted payload), in response to which the server hangs up the TCP session (FIN, FIN+ACK, actually nailed by an RST).

As Wireshark cannot see into even the early encrypted stages of the SSL session, I've tried a locally running mitmproxy - namely in its "local mode", pointed to a particular binary (winpm-32.exe) where it just hooks any TCP sessions originated by the requested binary.
This didn't show any payload passed through the SSL session - and yes the session handshake still failed. Mitmproxy did report the TCP session getting established, and then a failed SSL handshake, with no payload making it through. Read: probably no SMTP welcome exchange, no auth. Which matches what my freemail provider's helpdesk would say: no authentication attempt in their logs, on those sessions.

I then tried "openssl.exe s_client -connect smtp.freemail.censored:465", which connected just fine, and I got a welcome message from the SMTP service (and it responded to my "quit". I've also observed the respective few rows of cleartext SMTP in the mitmproxy output. That was using openssl.exe from OpenSSL 3.5.0 = a current version, as installed in Windows by Chocolatey. Still on the same Windows machine running PMail.

So, to sum up, the attempt to start SSL to port 465 fails from Pegasus (OpenSSL 1.1.1q), but succeeds from OpenSSL 3.5.0. If I compare wireshark traces, there is not much difference, until in the case of Pegasus, the server does a graceful shutdown of the TCP session, without a word of SMTP explanation.

Interestingly, an SMTP session on port 587, from Pegasus using STARTTLS, towards the same server machine with the same credentials, works just fine :-)
I wonder what flavours and versions of the SSL library are used on those two "SMTP submission" ports - but I have not learned those details (which makes good sense).

Thanks for your attention everyone...
and thanks David & Co. for Pegasus :-)

Frank

Interesting indeed. This prompted me to look at my configurations. I have one Gmail SMTP host configured to use an app password and another configured by for OAUTH2. The app password one uses port 465 and direct SSL connect. The OAUTH2 one uses port 587 and STARTTLS. I have the OAUTH2 one disabled. I have not experienced any connection issues with the app password one but out of curiosity, I tested it with 587 and STARTTTLS. It worked. I then switched back to 465 and direct SSL connect and tested again, sending the same message and watching for any noticeable difference and connection and transmission time. I didn't notice any. I don't know what this means beyond providing an option to anyone having issues with 465 and direct SSL connect. I do however wonder whether it makes a difference which Gmail server gets contacted.

Brian,

I know I started this as a connectivity/time out issue, but this problem seems to have manifested itself into something else. It seems to be related to a filtering problem. I'm going to open a new discussion with some detail there.

Bob