GNOME Bugzilla – Bug 763670
[IMAPx] Silently ignore G_TLS_ERROR_EOF
Last modified: 2016-12-13 09:30:57 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1317700 Description of problem: Evolution consistently displays a variety of error messages when an outlook.com IMAP account is check for new mail. These messages include: Failed to refresh folder "#######@outlook.com : INBOX". The reported error was "Error running STATUS: TLS connection closed unexpectedly". Error while performing operation. Error fetching folders: TLS connection closed unexpectedly Failed to refresh folder "#######@outlook.com : INBOX". The reported error was "Error performing NOOP: TLS connection closed unexpectedly". The account was created via Evolution's setup wizard and is correctly configured. Version-Release number of selected component (if applicable): Fedora 23, Gnome 3,18,2, Evolution 3.18.5.1 How reproducible: Rare for it *not* to happen. Steps to Reproduce: 1. Create outlook.com IMAP accout 2. Tell Evolution to check for new mail or wait for regular refresh Actual results: Error messages Expected results: No errors Additional info: This is not new behavior.
The "TLS connection closed unexpectedly" means that the server disconnected when it was not expected by the glib's gio library (respectively gnutls). Why it is so with the outlook.com server I do not know. The reason why this error isn't silently ignored and the operation which failed restarted is that the documentation for this error [1] says: G_TLS_ERROR_EOF - The TLS connection was closed without proper notice, which may indicate an attack. That the error can also mean it's an attack, thus I decided to not hide it. Weird that it's mainly shown with the outlook.com site, which I guess is an indication that the server does something oddly. I can add this error to the set of errors being ignored, for 3.20.1 of the evolution-data-server. [1] https://developer.gnome.org/gio/2.46/gio-TLS-Overview.html#G-TLS-ERROR-EOF:CAPS
Created attachment 323966 [details] [review] eds patch for evolution-data-server; This adds the G_TLS_ERROR_EOF into the set of errors which can be silently ignored and the connection reconnected to the server, followed by a re-try of the operation on the new connection to the server.
Created commit d85e809 in eds master (3.21.1+) Created commit f03f0e9 in eds gnome-3-20 (3.20.1+)
Hi, I ran into the same issue (also outlook.com). setting evolution to check for email every 2 minutes worked as a workaround (setting 3 minutes I saw connections close unexpectedly). Perhaps a more aggressive(or configurable) keepalive configuration would also work, without hiding the error. Jan
I'm afraid most regular users won't understand such option. Also, that the outlook.com doesn't respect IMAP IDLE [RFC2177] is a pita, but mostly their fault, from my point of view. Also see the Autologout Timer section of [RFC3501]. [RFC2177] https://tools.ietf.org/html/rfc2177 [RFC3501] https://tools.ietf.org/html/rfc3501.html#section-5.4
It can affect more users than just outlook.com. I occasionally see the message with gmail (google apps for education) too. (set to 5mins, I haven't investigated other settings). You can also have an aggressive ISP that cuts connections, in fact that was my original suspicion when I saw the message. It can be hidden in advanced options, or even just a dconf entry, but I think it'd be useful to handle couple of non-standard situations.
(In reply to Milan Crha from comment #5) > I'm afraid most regular users won't understand such option. Also, that the > outlook.com doesn't respect IMAP IDLE [RFC2177] is a pita, but mostly their > fault, from my point of view. Also see the Autologout Timer section of > [RFC3501]. > > [RFC2177] https://tools.ietf.org/html/rfc2177 > [RFC3501] https://tools.ietf.org/html/rfc3501.html#section-5.4 I would have to disagree and say that you are underestimating the intelligence of your users. In fact since the application automatically resolves the issue itself then why even display the error? Or am I misunderstanding something? I for one believe that it would be advantageous for power users to have the ability to hide the error or like Jan Vesely said "Perhaps a more aggressive or configurable keepalive configuration. On developer to developer note I almost feel like you are dismissing a bug and claiming it to be a feature on the assumption of your user bases intelligence level. The program is made for Linux after all, so the statement "I'm afraid most regular users won't understand such options." doesn't really work here. Because the last time I checked Linux user stats, we have more intermediate to advanced users than novice users in the overall Linux ecosystem. Overall I must say it is my favorite email client I have used in all my years as a geek so kudos to the overall great app. It would just be really nice to get rid of the error from view.
(In reply to George from comment #7) > I would have to disagree and say that you are underestimating the > intelligence of your users. In fact since the application automatically > resolves the issue itself then why even display the error? Or am I > misunderstanding something? Since changes mentioned in comment #3 the error is completely hidden from the UI, speaking of IMAPx. That's also the reason why this bug report is named "[IMAPx] Silently ignore G_TLS_ERROR_EOF". What I wrote in comment #5 was just my observation. I can be wrong with that, no doubt.
Don't know if it's gonna help anyone, but I fixed this error by changing the SMTP authentication type to "Login" rather than "PLAIN" in Evolution account preferences
Dan, do you really mean SMTP? Or it made it that your IMAPx connection to a server had been closed after sending a message, but only until you made that change in the authentication type for the SMTP connection?