I thought that 4.81 would be fine. And it has been. Then today I have been getting this smtp error (pop3 is fine) with all identities.

0:04:56.050: --- 21 Dec 2024, 20:04:56.050 ---
20:04:56.050: Connect to 'mail534.pair.com', timeout 9999 seconds, flags 16842753.
20:04:57.056: [] Setting SNI hostname to 'mail534.pair.com'
20:04:57.057: [!] OpenSSL reported error -1/5 during handshake - diagnostics follow:
20:04:57.057: [!] -------------------------------------------------------------------------
20:04:57.057: [!] ** OpenSSL supplied no extended diagnostic information.
20:04:57.057: [!] -------------------------------------------------------------2435

No settings have been changed and Pair says that all the settings check out.

Appreciate any help.
Tariya

Did a check, but not sure it is related.
Pegasus has the ssl built in, but I use stunnel on my linux setup that does have a newer version.
openssl-3.2.2-3
Using stunnel, so Pegasus is configured to connect to local ports that map thru stunnel to ISP.
Example: gmail setting in stunnel.conf
[gmailpop]
client=yes
accept = 127.0.0.1:20995
connect = pop.gmail.com:995
debug = 7
verifyChain = yes
CApath = /etc/ssl/certs
checkHost = pop.gmail.com
OCSPaia = yes

[gmailsmtp]
client=yes
accept = 127.0.0.1:20465
connect = smtp.gmail.com:465
debug = 7
verifyChain = yes
CApath = /etc/ssl/certs
checkHost = smtp.gmail.com
OCSPaia = yes

So, not sure if they might have setup some requirement that might need newer version.
Pegasus has openssl 1.1.1k

openssl s_client mail534.pair.com:995
Connecting to 209.68.5.151
CONNECTED(00000003)
depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
verify return:1
depth=1 C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Organization Validation Secure Server CA
verify return:1
depth=0 C=US, ST=Pennsylvania, O=Pair Networks, Inc., CN=*.pair.com
verify return:1
---
Certificate chain
 0 s:C=US, ST=Pennsylvania, O=Pair Networks, Inc., CN=*.pair.com
   i:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Organization Validation Secure Server CA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan  5 00:00:00 2024 GMT; NotAfter: Feb  4 23:59:59 2025 GMT
 1 s:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Organization Validation Secure Server CA
   i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
   v:NotBefore: Nov  2 00:00:00 2018 GMT; NotAfter: Dec 31 23:59:59 2030 GMT
 2 s:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
   i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 12 00:00:00 2019 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIG0zCCBbugAwIBAgIRAKqdsdR4x0nBQ8S1PwJK9BgwDQYJKoZIhvcNAQELBQAw
gZUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE9MDsGA1UE
AxM0U2VjdGlnbyBSU0EgT3JnYW5pemF0aW9uIFZhbGlkYXRpb24gU2VjdXJlIFNl
cnZlciBDQTAeFw0yNDAxMDUwMDAwMDBaFw0yNTAyMDQyMzU5NTlaMFcxCzAJBgNV
BAYTAlVTMRUwEwYDVQQIEwxQZW5uc3lsdmFuaWExHDAaBgNVBAoTE1BhaXIgTmV0
d29ya3MsIEluYy4xEzARBgNVBAMMCioucGFpci5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCbJ+IjI7IFQPsBhWT9MZG4nH0vz5KR/UpHYC5svXYL
bVdNBgMZ4Mpj36Q/n/ATMH2dBv3x4wxCpEIb6dsBJfgLKt1Z7s+m5j7DPR3vBG00
styi2G4ZTyY7WPnLeJTY68l1X5h7esyR3WsDs4TaAbo3hDI/KaxZ5faJWaUdhL69
MAB2QHt7/pwTGcBp1R2qGap3mnyBHwrDWae/6cNaPpIND80Z+SrNhUQmkC9qSZc8
T+fB3M50qkkcrN22K6BNURRVfOByaDdAHVxC5ZfpdO6KO+3QPnc3z/9/BmxmdzlV
LYgtOYv1r2PZqSaLb/O44Dc2kzDQ6I8WT2oXXolWLCCLAgMBAAGjggNZMIIDVTAf
BgNVHSMEGDAWgBQX2dYlJ2f5McJJQ9kwNkSMbKlP6zAdBgNVHQ4EFgQUPxeU2Naf
eelljJRJfTDL/mkguj8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYD
VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMEoGA1UdIARDMEEwNQYMKwYBBAGy
MQECAQMEMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMAgG
BmeBDAECAjBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsLnNlY3RpZ28uY29t
L1NlY3RpZ29SU0FPcmdhbml6YXRpb25WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0Eu
Y3JsMIGKBggrBgEFBQcBAQR+MHwwVQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuc2Vj
dGlnby5jb20vU2VjdGlnb1JTQU9yZ2FuaXphdGlvblZhbGlkYXRpb25TZWN1cmVT
ZXJ2ZXJDQS5jcnQwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLnNlY3RpZ28uY29t
MB8GA1UdEQQYMBaCCioucGFpci5jb22CCHBhaXIuY29tMIIBfgYKKwYBBAHWeQIE
AgSCAW4EggFqAWgAdgDPEVbu1S58r/OHW9lpLpvpGnFnSrAX7KwB0lt3zsw7CAAA
AYzaihcaAAAEAwBHMEUCIQC3NFsbOzpxdqfAcql61aWBwppLCtPgWW8nESHc/3oX
6QIgTEEx9luDf16ctbXzIu22BmaDWkxyRNnvTEA8XogrzxQAdgCi4wrkRe+9rZt+
OO1HZ3dT14JbhJTXK14bLMS5UKRH5wAAAYzaihayAAAEAwBHMEUCIQDWFs9Vv/K2
x0cr0ALe0xWu5OzraMdzU7iNmnlxlsnAzAIgaLkaaimPSdLiLqdpODHZNF3pYOpu
2eemKcV5Ac6fOnkAdgBOdaMnXJoQwzhbbNTfP1LrHfDgjhuNacCx+mSxYpo53wAA
AYzaiha5AAAEAwBHMEUCIFO8STpPAVVmLjADFoETHzQ7XBHNOPxbH6Q96Vx9q9TT
AiEA/HInXDbjbDV/EZeLE9zST1B49F6E4VxdbxD7dLx+j4QwDQYJKoZIhvcNAQEL
BQADggEBAFq2f7rBxnk5V/PmJEG1JGdjcbfCjn5B6R5c4oMeyxQwTmq1o6XBhcF7
0hFLDSdiMchFSotUV0J6L7GrWagAT/WUKyVhovoOJlhe+UcAKGFFbABBmeNtqx27
tj3zbRSi2Z01VQgNKXvjEtP/2mats4sVDb1w8YG4obB87UYjid1RMmh81KKFkWQi
ofWww2hp5QhG0AiKNkmQsJfO9iYb/l7eGDSN9/q2wBXbtFWelTzu5aUdkBimitaa
OFlwS35K2cI9yQgeFD3PJ+qUTWlR5JwP3Pp5j1RKpTjrHg4hpUIl9UR6YJKgKRDy
drfMoVsVdj2MeMeCp+Z2OYzlMytMBbo=
-----END CERTIFICATE-----
subject=C=US, ST=Pennsylvania, O=Pair Networks, Inc., CN=*.pair.com
issuer=C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Organization Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5299 bytes and written 407 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 30578566C3199144EE6A314D99C9294A3E30B356657FA5624D954A8E7809E973
    Session-ID-ctx: 
    Resumption PSK: 28AFF9ED49E0E3D2B89E3A2F2B8659B152C9C3B797BC6C6F8898B4553CDC50AECE246BB2ACE7763393D51C423BD7A352
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 44 fb 17 f3 65 45 32 d9-b0 2c 97 00 98 e0 4b 57   D...eE2..,....KW
    0010 - ff b6 0d 05 f3 1a 91 47-8e 6e be a2 8d 52 f6 47   .......G.n...R.G
    0020 - 60 c7 7d ae 57 c9 f3 96-27 85 4b 9b 7a 57 e9 c0   `.}.W...'.K.zW..
    0030 - 59 80 c8 1a 0a 43 30 d0-04 eb 97 ad 70 e4 03 1a   Y....C0.....p...
    0040 - 9f 70 59 72 c0 25 9f dd-3d c2 f6 f1 95 bf 0a d9   .pYr.%..=.......
    0050 - 4a 0f 1b 41 50 19 8e ae-d8 a8 ce 94 f0 24 f7 13   J..AP........$..
    0060 - a1 f4 cb 4e c5 a1 44 35-6f 3a 5f 9c 94 23 8c e7   ...N..D5o:_..#..
    0070 - d1 f8 be 7a c0 0b 11 6b-93 c7 39 ed 8a 6a 27 5f   ...z...k..9..j'_
    0080 - d2 6c 4a 9a 70 04 fc a8-a4 0b 79 b9 b9 3d 27 f9   .lJ.p.....y..='.
    0090 - ed ee f8 c8 66 98 20 31-9b 50 15 d2 56 35 a4 b5   ....f. 1.P..V5..
    00a0 - 46 22 5f 84 47 aa 3b 02-c2 77 d1 1a 2d d2 78 c8   F"_.G.;..w..-.x.
    00b0 - e2 66 c5 ad 4e a7 2a b5-b0 e7 cc 07 ff 6b 5d 53   .f..N.*......k]S
    00c0 - 35 7b 36 01 9f 8b 02 9d-a5 30 32 5c 92 95 33 9f   5{6......02\..3.
    00d0 - 13 23 f7 b5 77 fc 79 86-b6 2e 65 4b 57 a3 1e e7   .#..w.y...eKW...

    Start Time: 1734807039
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 28AD3F55EE9C991C9FCBF3C9CB699FB2D59B4C5DA8ACF7DA644B91090D2406AA
    Session-ID-ctx: 
    Resumption PSK: 11386F4414D801EB411DF2586A312B556CF7ABEBCA2640CA9A69E2FEF11C2BE22EA0065FE8656673B92CE96FEE63657E
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 44 fb 17 f3 65 45 32 d9-b0 2c 97 00 98 e0 4b 57   D...eE2..,....KW
    0010 - 7f 75 f4 18 28 11 eb 33-76 3b b6 db 97 8a 5c 8f   .u..(..3v;....\.
    0020 - b4 5c b5 8e 2b b2 fb 04-64 13 2e e5 db 44 cf fd   .\..+...d....D..
    0030 - 93 b0 1c 10 83 8e ef 76-b4 d9 05 d3 50 c2 b5 52   .......v....P..R
    0040 - d1 c3 14 40 ac 61 c0 58-fe 3d 32 c1 fc 08 76 36   ...@.a.X.=2...v6
    0050 - f7 cf 81 8f a2 9f 2c c6-fa 89 78 d7 46 fd 50 6c   ......,...x.F.Pl
    0060 - 5f 15 36 45 79 d7 4e 84-4a dd 22 cb 2b 64 81 5a   _.6Ey.N.J.".+d.Z
    0070 - 23 99 0a 85 44 92 62 f2-c1 c4 dc 4d 25 8d 97 09   #...D.b....M%...
    0080 - e0 21 61 c4 23 f5 26 c6-38 5c 48 c5 1d 83 eb 03   .!a.#.&.8\H.....
    0090 - dd ba 82 4d de 04 2b 6b-39 c4 1a d0 e6 c2 02 42   ...M..+k9......B
    00a0 - b1 9c 8a 9b 9f 58 de 13-30 05 f3 9c e8 95 58 41   .....X..0.....XA
    00b0 - f3 59 6d aa a0 74 51 70-30 c7 f7 5d df 9a 5f 34   .Ym..tQp0..].._4
    00c0 - 80 3e f2 48 38 69 89 b3-4b 69 29 3d 55 6a ba e5   .>.H8i..Ki)=Uj..
    00d0 - 4a ac ec 79 f3 31 48 a0-a5 94 e5 9b b2 bb 50 e4   J..y.1H.......P.

    Start Time: 1734807039
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
+OK Dovecot ready.

I found a Pair support webpage about SMTP that was updated on December 2, 2024. There is no indication of what the changes were but I thought it worth mentioning for review because of its recent update especially considering a separate paragraph specific to SSL. This makes me wonder whether SSL is required. Consider testing without SSL enabled.

https://www.pair.com/support/kb/smtp-service-at-pair-networks/

Thanks Brian. Everything checks out. And SSL is required. As I mentioned, receiving is fine. Sending is erratic. Sometimes it shows the error, sometimes it doesn't and eventualy sends the message. And now, it's sending two copies of the message. What does it mean in the Queue Manager when a message is shown as Final Form? It won't send with this status. Then after a while, sometimes a long while, it changes the status to Ready to Send. Then it sends but it takes unusual time to do so.

In the smtp settings to you have selected starttls or direct ssl?

Did a test with https://mxtoolbox.com/SuperTool.aspx?action=smtp%3amail534.pair.com&run=toolpage

Shows

Connecting to 209.68.5.151

220 mta.marbuta.pair.com ESMTP Postfix [139 ms]
EHLO keeper-us-east-1d.mxtoolbox.com
250-mta.marbuta.pair.com
250-PIPELINING
250-SIZE 104857600
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING [194 ms]
MAIL FROM:supertool@mxtoolboxsmtpdiag.com
250 2.1.0 Ok [136 ms]
RCPT TO:test@mxtoolboxsmtpdiag.com
554 5.7.1 test@mxtoolboxsmtpdiag.com: Relay access denied [112 ms]

LookupServer 940ms

Direct SSL

Pair requires ssl/tls protocol. Pegasus shows three options in internet security for ssl/tls: Never, via starttls, and via direct ssl connect. We've always selected the direct ssl connect. Pair's support can't tell me whether that is correct. Something seems to have changed on their side. They think that direct connect may only activate ssl. This has slipped beyond a state of aggravation. As I mentioned before, the pop3 receive works fine and smoothly as usual. It's the smtp. It keeps throwing up an error. One remedy we've found is that after the error, if we login with pop3 receive and then back to smtp it will send, but it takes a long time. The smtp security is "not" set to use the pop3 login for authentication. It uses email address and password. We need some quick help with this!

When a newly created message is sent to the queue it sits there in Ready to Send status which is an editable form. Once a Send is attempted, those messages are processed into Final Form and then transmitted. If the transmission fails, they will remain in the queue in Final Form until the next transmission attempt. Regarding two copies being sent, I suspect that the first one is being caused by the first send attempt being successful but the confirmation from the Pair SMTP server is never received by Pegasus Mail so it leaves it in the queue which leads to it being transmitted again. That is just a guess though.

Look at the timeout setting in your SMTP host configuration. I suggest setting it to at least 120. I once had one of mine set at 300. High is not harmful.

I would test with the "Via STARTTLS: option enabled instead.
It also wouldn't hurt to enable the "Do prior POP3 login to authenticate..." option. Below is what the Help file says about it, which seems appropriate in your case.

Do a prior POP3 login to authenticate before sending mail If your ISP supports it, this is the simplest way of authenticating who you are. Some ISPs will log POP3 mail checks, and provided you have done such a check in the last x minutes, will permit you to send mail from the same address. When you enable this control, Pegasus Mail will login to your POP3 server and immediately logout without actually retrieving mail, prior to opening the SMTP connection to send mail. It is harmless to enable this option, even if your ISP does not require it. When you enable this option, you must select one of your POP3 mail definitions by clicking the Select button.

Switched via STARTTLS and now it's working fine. Why, after all these years set for via direct SSK connect... it's changed. Pair doesn't know and Pegasus doesn't know. But it doesn't matter as long our email is operating normally.
Thanks for all the help.