My file system was corrupted and I had to start over. When trying to set up my mail accounts in Evolution I can get some of them to work but two in particular will no longer work. I have a charter.net and sbcglobal.net email I am trying to add. For both I get the same message - “Peer failed to perform TLS handshake: Error receiving data: Connection reset by peer”. I have confirmed the correct username, mail server, and password but nothing seems to work. I have tried using the GNOME online accounts and adding an account to Evolution directly. My work EWS account as well as gmail and hotmail accounts work flawlessly. Does anyone know what is happening here and how to fix it?
CAMEL_DEBUG=imapx:io evolution >& logfile
The relevant contents of the log file
(org.gnome.Evolution:2317671): e-mail-engine-WARNING **: 13:48:27.257: mail_folder_cache_note_store_thread: Failed to run initial setup for ‘myusername@charter.net’: Peer failed to perform TLS handshake: Error receiving data: Connection reset by peer
This output isn’t really any different than the error message I listed in my original post.
Anyone else have any suggestions. It is frustrating that this used to work and now it doesn’t but I can’t figure out how to debug it when the suggested link points me to something that returns the same information I was getting in Evolution.
Hi,
it’s failing too early, the GnuTLS (used by glib-networking) fails to
connect to the server, before it sends anything log-able by the IMAPx
code. I guess when you try:
gnutls-cli imap.googlemail.com:993
replacing the server address and the port with those you have used in
the Evolution Receiving Email tab of the account Properties.
If it’ll not show a better explanation for the error, then I do not
know. Maybe the crypto policies stepped in, try to switch them from
DEFAULT to LEGACY, if it applies to your distro. Note such change has
implications, it allows weaker security for the connections (apart of
other things), thus use it with caution. A command is:
sudo update-crypto-policies --set LEGACY
You can use:
update-crypto-policies --show
to see what you’ve set. These changes require app restarts, because the
settings are loaded on start only.
Bye,
Milan
For the sbcglobal email it fails pretty fast.
$ gnutls-cli imap.mail.att.net:993
Processed 388 CA certificate(s).
Resolving ‘imap.mail.att.net:993’…
Connecting to ‘98.137.156.39:993’…
*** Fatal error: Error in the pull function.
But for charter it provides slightly more information but but fails at the same spot.
Processed 388 CA certificate(s).
Resolving ‘mobile.charter.net:993’…
Connecting to ‘47.43.18.12:993’…
Certificate type: X.509
Got a certificate list of 4 certificates.
Certificate[0] info:
subject
CN=mail.charter.net,O=Charter Communications Operating\, LLC,L=St. Louis,ST=Missouri,C=US', issuerCN=GlobalSign RSA OV SSL CA 2018,O=GlobalSign nv-sa,C=BE’, serial 0x53152d44a309e314ea819c34, RSA key 2048 bits, signed using RSA-SHA256, activated2025-05-16 03:31:48 UTC', expires2026-06-17 03:31:47 UTC’, pin-sha256=“zQ4r7dhYqcW7Ys9QdGo47M75yrSuo/06b2rrYAByqxE=”
Public Key ID:
sha1:a7ad61d58324a443f05f8b382e38e64a07fa8c55
sha256:cd0e2bedd858a9c5bb62cf50746a38eccef9cab4aea3fd3a6f6aeb600072ab11
Public Key PIN:
pin-sha256:zQ4r7dhYqcW7Ys9QdGo47M75yrSuo/06b2rrYAByqxE=Certificate[1] info:
subject
CN=GlobalSign RSA OV SSL CA 2018,O=GlobalSign nv-sa,C=BE', issuerCN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3’, serial 0x01ee5f221dfc623bd4333a8557, RSA key 2048 bits, signed using RSA-SHA256, activated2018-11-21 00:00:00 UTC', expires2028-11-21 00:00:00 UTC’, pin-sha256=“hETpgVvaLC0bvcGG3t0cuqiHvr4XyP2MTwCiqhgRWwU=”Certificate[2] info:
subject
CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3', issuerCN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3’, serial 0x04000000000121585308a2, RSA key 2048 bits, signed using RSA-SHA256, activated2009-03-18 10:00:00 UTC', expires2029-03-18 10:00:00 UTC’, pin-sha256=“cGuxAXyFXFkWm61cF4HPWX8S0srS9j0aSqN0k4AP+4A=”Certificate[3] info:
subject
CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3', issuerCN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3’, serial 0x04000000000121585308a2, RSA key 2048 bits, signed using RSA-SHA256, activated2009-03-18 10:00:00 UTC', expires2029-03-18 10:00:00 UTC’, pin-sha256=“cGuxAXyFXFkWm61cF4HPWX8S0srS9j0aSqN0k4AP+4A=”StatuProcessed 388 CA certificate(s).
Resolving ‘mobile. charter. net:993’…
Connecting to ‘47.43.18.12:993’…
Certificate type: X.509
Got a certificate list of 4 certificates.
Certificate[0] info:
subject
CN=mail.charter.net,O=Charter Communications Operating\, LLC,L=St. Louis,ST=Missouri,C=US', issuerCN=GlobalSign RSA OV SSL CA 2018,O=GlobalSign nv-sa,C=BE’, serial 0x53152d44a309e314ea819c34, RSA key 2048 bits, signed using RSA-SHA256, activated2025-05-16 03:31:48 UTC', expires2026-06-17 03:31:47 UTC’, pin-sha256=“zQ4r7dhYqcW7Ys9QdGo47M75yrSuo/06b2rrYAByqxE=”
Public Key ID:
sha1:a7ad61d58324a443f05f8b382e38e64a07fa8c55
sha256:cd0e2bedd858a9c5bb62cf50746a38eccef9cab4aea3fd3a6f6aeb600072ab11
Public Key PIN:
pin-sha256:zQ4r7dhYqcW7Ys9QdGo47M75yrSuo/06b2rrYAByqxE=Certificate[1] info:
subject
CN=GlobalSign RSA OV SSL CA 2018,O=GlobalSign nv-sa,C=BE', issuerCN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3’, serial 0x01ee5f221dfc623bd4333a8557, RSA key 2048 bits, signed using RSA-SHA256, activated2018-11-21 00:00:00 UTC', expires2028-11-21 00:00:00 UTC’, pin-sha256=“hETpgVvaLC0bvcGG3t0cuqiHvr4XyP2MTwCiqhgRWwU=”Certificate[2] info:
subject
CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3', issuerCN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3’, serial 0x04000000000121585308a2, RSA key 2048 bits, signed using RSA-SHA256, activated2009-03-18 10:00:00 UTC', expires2029-03-18 10:00:00 UTC’, pin-sha256=“cGuxAXyFXFkWm61cF4HPWX8S0srS9j0aSqN0k4AP+4A=”Certificate[3] info:
subject
CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3', issuerCN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3’, serial 0x04000000000121585308a2, RSA key 2048 bits, signed using RSA-SHA256, activated2009-03-18 10:00:00 UTC', expires2029-03-18 10:00:00 UTC’, pin-sha256=“cGuxAXyFXFkWm61cF4HPWX8S0srS9j0aSqN0k4AP+4A=”Status: The certificate is trusted.
*** Fatal error: Error in the pull function.
I tried the LEGACY vs DEFAULT suggestion and had the exact same results.
I had to tweak one url since I am limited to only 3. Ignore the spaces in the last charter address.
But for charter it provides slightly more information but but fails
at the same spot.
Hi,
I tried it here, with GnuTLS 3.8.10, and both servers can connect fine
names resolve to a different IP, but even when I use the IP as shown in
your snippet (and add --insecure argument to the command), they can
connect to the server just fine.
The gnutls-cli has --verbose and --debug=9999 options for more
chatty output, but I’m not used to these things, I do not know what it
should show and what means which output. Maybe it’ll help you to get a
clue, but I won’t help much with it, I’m sorry. The gnutls-cli is good
for testing where the connection problem is - your current test proves
it’s in the GnuTLS, not in the libraries used in the Evolution. You
might probably ask on the GnuTLS forum/mailing list for some guidance,
they are more experience with these low-level things.
I tried the LEGACY vs DEFAULT suggestion and had the exact same
results.
Ah, right, it was a blind shot. I could connect with the DEFAULT too,
on a Fedora 43 machine, thus quite recent bits.
What is your GnuTLS version, please? Maybe they fixed something in
version I have, or “broke” something if you’ve a newer version than I
do.
Bye,
Milan
My GnuTLS version is the same as yours - 3.8.10. I am running Fedora 42 so we have a similar but not identical OS underneath all of this.
The –verbose option just adds a bunch of certificate information and signatures. When the error occurs there is no additional detail. Using the –insecure argument I still get the same “Fatal error: Error in the pull function” at the end.
I will try and see if I can find out anything more in the GnuTLS forum. Thanks for the suggestion.