Community Discussions and Support
PMail 4.91 fails to download mails from POP3

In pmail.ini, if the paths to the mailbox locations are to C:, then...
... you have a conflict between those paths and pmail.cfg pointing to the server.
... I suspect the option to download after filtering is being written to the .PND file on C:. I'm am not certain about that though, so I suggest looking at the .PND file in both locations.


In pmail.ini, if the paths to the mailbox locations are to C:, then... ... you have a conflict between those paths and pmail.cfg pointing to the server. ... I suspect the option to download after filtering is being written to the .PND file on C:. I'm am not certain about that though, so I suggest looking at the .PND file in both locations.

Yes, but both locations have their own pmail.ini file but two entries:
Working home mailbox location = C:\PMAIL\MAIL\tj
New mailbox location = C:\PMAIL\MAIL\tj
gets updated when you launch the program.
Other than that, there are no paths present in the ini file.


And you are right, the download after filtering is the entry
Def_action : 0
in the pnd file.


Cheers


Torben


Yes, but both locations have their own pmail.ini file but two entries: Working home mailbox location = C:\PMAIL\MAIL\tj New mailbox location = C:\PMAIL\MAIL\tj gets updated when you launch the program. Other than that, there are no paths present in the ini file. And you are right, the download after filtering is the entry Def_action : 0 in the pnd file. Cheers Torben

And you are right, the download after filtering is the entry
Def_action : 0
in the pnd file.


What I was curious about is whether the content of the .PND file in the mailbox on the server is the same as the one in the mailbox on C:.


[quote="pid:59084, uid:38340"]And you are right, the download after filtering is the entry Def_action : 0 in the pnd file.[/quote] What I was curious about is whether the content of the .PND file in the mailbox on the server is the same as the one in the mailbox on C:.

I am out of ideas.


I truly appreciate your responses to my inquiries and am glad that you can tolerate the issue.


I am out of ideas. I truly appreciate your responses to my inquiries and am glad that you can tolerate the issue.

Don't know if it might get more info on connection running connection thru stunnel.


Stunnel uses openssl and I use a higher log level that show more info.
Can't say it would provide more info, but might.


My configuration for my local ISP


[guampop]
client=yes
accept = 127.0.0.1:20996
connect = mail.guam.net:995
debug = 7
verifyChain = yes
CApath = /etc/ssl/certs
checkHost = mail.guam.net
OCSPaia = yes


[guamsmtp]
client=yes
accept = 127.0.0.1:20466
connect = smtp1.guam.net:465
debug = 7
verifyChain = yes
CApath = /etc/ssl/certs
checkHost = smtp1.guam.net
OCSPaia = yes


Lines after the Debug = 7 are protection for man in middle attacks so not required.
I also run on Linux so might have different paths for windows.


Set Pegasus up to connect to the local host 127.0.0.1 using local port
connect is the final host and port.
Pegasus is set to direct connect, since it doesn't do the SSL connection at all.
The Stunnel (tunnels) setting up the SSL and handling connection.


Used it for many many years. Just put a new version out 5.80 is latest.
https://www.stunnel.org/


So might give something.


Just did a connection, and these are lines from the message log.


Aug 5 09:14:00 setzcodell stunnel[1454]: LOG5[6]: Service [guampop] accepted connection from 127.0.0.1:47024
Aug 5 09:14:00 setzcodell stunnel[1454]: LOG6[6]: s_connect: connecting 202.128.81.33:995
Aug 5 09:14:00 setzcodell stunnel[1454]: LOG5[6]: s_connect: connected 202.128.81.33:995
Aug 5 09:14:00 setzcodell stunnel[1454]: LOG5[6]: Service [guampop] connected remote server from 192.168.1.16:35450
Aug 5 09:14:00 setzcodell stunnel[1454]: LOG6[6]: SNI: sending servername: mail.guam.net
Aug 5 09:14:00 setzcodell stunnel[1454]: LOG6[6]: Attempting to resume: 0F0801E6F928947A212333D9CD82E7F2B709E0D965D4F25E50CD66866F74201B
Aug 5 09:14:00 setzcodell stunnel[1454]: LOG6[6]: Peer certificate required
Aug 5 09:14:01 setzcodell stunnel[1454]: LOG6[6]: Certificate accepted at depth=2: C=US, ST=Arizona, L=Scottsdale, O="GoDaddy.com, Inc.", CN=Go Daddy Root Certificate Authority - G2
Aug 5 09:14:01 setzcodell stunnel[1454]: LOG5[6]: OCSP: Connecting the AIA responder "http://ocsp.godaddy.com/"
Aug 5 09:14:01 setzcodell stunnel[1454]: LOG6[6]: s_connect: connecting 192.124.249.117:80
Aug 5 09:14:01 setzcodell stunnel[1454]: LOG5[6]: s_connect: connected 192.124.249.117:80
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: Status: good
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: This update: 2026.08.05 04:21:08
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: Next update: 2026.08.09 04:20:08
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: OCSP: Certificate accepted
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: OCSP: Accepted (good)
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: Certificate accepted at depth=1: C=US, ST=Arizona, L=Scottsdale, O="GoDaddy.com, Inc.", OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: CERT: Host name "mail.guam.net" matched with ".guam.net"
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: Certificate accepted at depth=0: CN=
.guam.net
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: No OCSP stapling response received
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: OCSP: Connecting the AIA responder "http://ocsp.godaddy.com/"
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: s_connect: connecting 192.124.249.127:80
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: s_connect: connected 192.124.249.127:80
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: Status: good
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: This update: 2026.08.05 07:06:04
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: Next update: 2026.08.09 07:05:04
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: OCSP: Certificate accepted
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: OCSP: Accepted (good)
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: TLS connected: new session negotiated
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption)
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: Peer temporary key: X25519, 253 bits
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: Session id: 4A287993F443B5D6DBFB496A10C8E83FBD9E8C30DA72D1A79A97CB1FC1E1008D
Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: Session id: 84AFCA94F2A90B9285FC713492FC0FDC66B03B1D976D39806A1188CDC99F6D0B
Aug 5 09:14:09 setzcodell stunnel[1454]: LOG6[6]: TLS closed (SSL_read)
Aug 5 09:14:09 setzcodell stunnel[1454]: LOG6[6]: Read socket closed (readsocket)
Aug 5 09:14:09 setzcodell stunnel[1454]: LOG6[6]: SSL_shutdown successfully sent close_notify alert
Aug 5 09:14:09 setzcodell stunnel[1454]: LOG5[6]: Connection closed: 149 byte(s) sent to TLS, 385990 byte(s) sent to socket


On linux using openssl-3.5.7-2.fc43.x86_64
Uses the 64 bit version with Pegasus includes an older 32 bit version.


Don't know if it might get more info on connection running connection thru stunnel. Stunnel uses openssl and I use a higher log level that show more info. Can't say it would provide more info, but might. My configuration for my local ISP [guampop] client=yes accept = 127.0.0.1:20996 connect = mail.guam.net:995 debug = 7 verifyChain = yes CApath = /etc/ssl/certs checkHost = mail.guam.net OCSPaia = yes [guamsmtp] client=yes accept = 127.0.0.1:20466 connect = smtp1.guam.net:465 debug = 7 verifyChain = yes CApath = /etc/ssl/certs checkHost = smtp1.guam.net OCSPaia = yes Lines after the Debug = 7 are protection for man in middle attacks so not required. I also run on Linux so might have different paths for windows. Set Pegasus up to connect to the local host 127.0.0.1 using local port connect is the final host and port. Pegasus is set to direct connect, since it doesn't do the SSL connection at all. The Stunnel (tunnels) setting up the SSL and handling connection. Used it for many many years. Just put a new version out 5.80 is latest. https://www.stunnel.org/ So might give something. Just did a connection, and these are lines from the message log. Aug 5 09:14:00 setzcodell stunnel[1454]: LOG5[6]: Service [guampop] accepted connection from 127.0.0.1:47024 Aug 5 09:14:00 setzcodell stunnel[1454]: LOG6[6]: s_connect: connecting 202.128.81.33:995 Aug 5 09:14:00 setzcodell stunnel[1454]: LOG5[6]: s_connect: connected 202.128.81.33:995 Aug 5 09:14:00 setzcodell stunnel[1454]: LOG5[6]: Service [guampop] connected remote server from 192.168.1.16:35450 Aug 5 09:14:00 setzcodell stunnel[1454]: LOG6[6]: SNI: sending servername: mail.guam.net Aug 5 09:14:00 setzcodell stunnel[1454]: LOG6[6]: Attempting to resume: 0F0801E6F928947A212333D9CD82E7F2B709E0D965D4F25E50CD66866F74201B Aug 5 09:14:00 setzcodell stunnel[1454]: LOG6[6]: Peer certificate required Aug 5 09:14:01 setzcodell stunnel[1454]: LOG6[6]: Certificate accepted at depth=2: C=US, ST=Arizona, L=Scottsdale, O="GoDaddy.com, Inc.", CN=Go Daddy Root Certificate Authority - G2 Aug 5 09:14:01 setzcodell stunnel[1454]: LOG5[6]: OCSP: Connecting the AIA responder "http://ocsp.godaddy.com/" Aug 5 09:14:01 setzcodell stunnel[1454]: LOG6[6]: s_connect: connecting 192.124.249.117:80 Aug 5 09:14:01 setzcodell stunnel[1454]: LOG5[6]: s_connect: connected 192.124.249.117:80 Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: Status: good Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: This update: 2026.08.05 04:21:08 Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: Next update: 2026.08.09 04:20:08 Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: OCSP: Certificate accepted Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: OCSP: Accepted (good) Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: Certificate accepted at depth=1: C=US, ST=Arizona, L=Scottsdale, O="GoDaddy.com, Inc.", OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2 Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: CERT: Host name "mail.guam.net" matched with "*.guam.net" Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: Certificate accepted at depth=0: CN=*.guam.net Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: No OCSP stapling response received Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: OCSP: Connecting the AIA responder "http://ocsp.godaddy.com/" Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: s_connect: connecting 192.124.249.127:80 Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: s_connect: connected 192.124.249.127:80 Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: Status: good Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: This update: 2026.08.05 07:06:04 Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: OCSP: Next update: 2026.08.09 07:05:04 Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: OCSP: Certificate accepted Aug 5 09:14:04 setzcodell stunnel[1454]: LOG5[6]: OCSP: Accepted (good) Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: TLS connected: new session negotiated Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption) Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: Peer temporary key: X25519, 253 bits Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: Session id: 4A287993F443B5D6DBFB496A10C8E83FBD9E8C30DA72D1A79A97CB1FC1E1008D Aug 5 09:14:04 setzcodell stunnel[1454]: LOG6[6]: Session id: 84AFCA94F2A90B9285FC713492FC0FDC66B03B1D976D39806A1188CDC99F6D0B Aug 5 09:14:09 setzcodell stunnel[1454]: LOG6[6]: TLS closed (SSL_read) Aug 5 09:14:09 setzcodell stunnel[1454]: LOG6[6]: Read socket closed (readsocket) Aug 5 09:14:09 setzcodell stunnel[1454]: LOG6[6]: SSL_shutdown successfully sent close_notify alert Aug 5 09:14:09 setzcodell stunnel[1454]: LOG5[6]: Connection closed: 149 byte(s) sent to TLS, 385990 byte(s) sent to socket On linux using openssl-3.5.7-2.fc43.x86_64 Uses the 64 bit version with Pegasus includes an older 32 bit version.

mikes@guam.net

I do not think it is worth the trouble. The TLS communication is done in the exact same fashion. Only difference is where the mails are placed: Either on the local harddrive, or on a linux box running samba, exposing the drive to windows.


I do appreciate the suggestion though!


Cheers,


Torben


I do not think it is worth the trouble. The TLS communication is done in the exact same fashion. Only difference is where the mails are placed: Either on the local harddrive, or on a linux box running samba, exposing the drive to windows. I do appreciate the suggestion though! Cheers, Torben

Thought one of the message stated connection was unexpectedly closed by server, so though finding out why would help.


Pegasus use to use the ssl dll files separately, so installing newer ones would update it.
But now it is compiled into the program. It is currently at 1.1.1k as far as I know. There were updates within that version, but don't recall what last was.


They did a jump from 1 to 3, so my linux is currently using
openssl-3.5.7-2.fc43.x86_64


So, not sure what all has changed between 1.1.1k and 3.5.7-2?


Google AI comes up with this.


The jump from OpenSSL 1.1.1k to OpenSSL 3.5.7-2 marks a massive architectural, performance, and feature transformation. It bypasses version 2.0 entirely, as the OpenSSL project jumped straight to 3.0 to signal major breaking API updates.
Here are the key differences broken down by category:
Architecture & API Changes


The Provider Model: OpenSSL 3.x introduced a "Provider" architecture. Algorithms are now treated as modules (e.g., Default, Legacy, FIPS) rather than being hardcoded into the core library. 
API Deprecation: All legacy, low-level cryptographic functions (like AES_encrypt or SHA256_Update) are completely deprecated. Developers are forced to use the high-level EVP API.
Opaque Structures: Many public data structures have been made internal/opaque to increase safety. You can no longer stack-allocate them
; they must be heap-allocated via setter and getter functions.
Version Scheme: OpenSSL moved to a standard MAJOR.MINOR.PATCH system. API and ABI compatibility are now explicitly guaranteed across the same Major version (all 3.x releases).

Protocol & Algorithm Upgrades


QUIC Protocol: OpenSSL 3.x introduces native client-side support for the QUIC transport protocol (RFC 9000). Version 1.1.1 only supported TLS and DTLS.
FIPS 140-3 Compliance: Version 1.1.1 utilized an outdated FIPS module. The 3.x series introduces a natively validated FIPS provider meeting modern cryptographic standards.
Modern Cryptography: Massive additions include support for Post-Quantum Cryptography (like ML-KEM/ML-DSA), Encrypted Client Hello (ECH), and Certificate Management Protocol (CMP).

Performance & Stability


Handshake Latency: Interestingly, because of the extra software abstraction layer introduced by the provider framework, OpenSSL 3.x can experience slightly higher TLS handshake latency compared to 1.1.1 when using Elliptic Curve (EC) algorithms.
Threading: Multi-threading capabilities are cleaner and inherently safer due to modern RNG upgrades and decoupled providers.

Support Status


OpenSSL 1.1.1k: This version is fully End-of-Life (EOL). It does not receive public security patches or bug fixes, making it a high security risk.
OpenSSL 3.5.7-2: This is the current, actively supported Long-Term Support (LTS) branch, fully patched against modern vulnerabilities.

So, it is what it is. Also, with linux it is using the 64bit version. So for info.


Thought one of the message stated connection was unexpectedly closed by server, so though finding out why would help. Pegasus use to use the ssl dll files separately, so installing newer ones would update it. But now it is compiled into the program. It is currently at 1.1.1k as far as I know. There were updates within that version, but don't recall what last was. They did a jump from 1 to 3, so my linux is currently using openssl-3.5.7-2.fc43.x86_64 So, not sure what all has changed between 1.1.1k and 3.5.7-2? Google AI comes up with this. The jump from OpenSSL 1.1.1k to OpenSSL 3.5.7-2 marks a massive architectural, performance, and feature transformation. It bypasses version 2.0 entirely, as the OpenSSL project jumped straight to 3.0 to signal major breaking API updates. Here are the key differences broken down by category: Architecture & API Changes The Provider Model: OpenSSL 3.x introduced a "Provider" architecture. Algorithms are now treated as modules (e.g., Default, Legacy, FIPS) rather than being hardcoded into the core library. API Deprecation: All legacy, low-level cryptographic functions (like AES_encrypt or SHA256_Update) are completely deprecated. Developers are forced to use the high-level EVP API. Opaque Structures: Many public data structures have been made internal/opaque to increase safety. You can no longer stack-allocate them; they must be heap-allocated via setter and getter functions. Version Scheme: OpenSSL moved to a standard MAJOR.MINOR.PATCH system. API and ABI compatibility are now explicitly guaranteed across the same Major version (all 3.x releases). Protocol & Algorithm Upgrades QUIC Protocol: OpenSSL 3.x introduces native client-side support for the QUIC transport protocol (RFC 9000). Version 1.1.1 only supported TLS and DTLS. FIPS 140-3 Compliance: Version 1.1.1 utilized an outdated FIPS module. The 3.x series introduces a natively validated FIPS provider meeting modern cryptographic standards. Modern Cryptography: Massive additions include support for Post-Quantum Cryptography (like ML-KEM/ML-DSA), Encrypted Client Hello (ECH), and Certificate Management Protocol (CMP). Performance & Stability Handshake Latency: Interestingly, because of the extra software abstraction layer introduced by the provider framework, OpenSSL 3.x can experience slightly higher TLS handshake latency compared to 1.1.1 when using Elliptic Curve (EC) algorithms. Threading: Multi-threading capabilities are cleaner and inherently safer due to modern RNG upgrades and decoupled providers. Support Status OpenSSL 1.1.1k: This version is fully End-of-Life (EOL). It does not receive public security patches or bug fixes, making it a high security risk. OpenSSL 3.5.7-2: This is the current, actively supported Long-Term Support (LTS) branch, fully patched against modern vulnerabilities. So, it is what it is. Also, with linux it is using the 64bit version. So for info.

mikes@guam.net

12
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft