Server disconnect is not handled

[532910]

Prerequisites

• Tried the most recent nightly build
• Checked if your issue is already reported.

Steps

1. Open seive tool and press connect, server it will show server files:
   

2. Wait for disconnect, server files still be shown

3. Trying to edit a file will show it as empty:
   

4. Pressing Tools -> Sieve Message Filters again (step 1) will switch you to the tab from the first screenshot without offering to connect again.

Expected solution:

Completely remove connect button. The connection should happen automatically, on demand.

Version

0.4.0

[thsmi]

Neither keep alive messages nor reconnects are implemented in the webextension.
As stated it is a pre-alpha release and is far await form parity with the old addon. In case you want something more stable you should use the app.

This is currently the expected behavior. Just click in the account's burger menu and select reconnect here.

[rhclayto]

Neither keep alive messages nor reconnects are implemented in the webextension. As stated it is a pre-alpha release and is far await form parity with the old addon. In case you want something more stable you should use the app.

This is currently the expected behavior. Just click in the account's burger menu and select reconnect here.

Hi. It seems the Windows app has the same behavior as the Thunderbird Webextension, lacking keepalives or reconnects. The server I connect to is behind a Haproxy reverse proxy, with a client timeout of one minute. When I connect to the sieve server, it disconnects every time after a minute.

[thsmi]

Well, when your proxy disconnects after one minute, then it clearly violates the manage sieve protocol. The ManageSieve RFC (https://datatracker.ietf.org/doc/html/rfc5804) requires the server side that the timeout is no less than 30 minutes:

The BYE response SHOULD be used if the server wishes to close the
connection. A server may wish to do this because the client was idle
for too long or there were too many failed authentication attempts.
This response can be issued at any time and should be immediately
followed by a server hang-up of the connection. If a server has an
inactivity timeout resulting in client autologout, it MUST be no less
than 30 minutes after successful authentication. The inactivity
timeout MAY be less before authentication.

The timeout in the manage sieve specification is to my knowledge aligned with the TCP/IP specification. This is the reason also why almost TCP based protocol I am aware of have similar timeout and keep alive requirement. They all expect and require that a TCP channel can stay open for at least something in the 30 minutes range.

The only exception is HTTP/1 and HTTP/2 they use a separate channel for each request. Thus they technically do not really support keep alive at all. For those protocols it is quite common to have a really short timeout. But WebSockets and HTTP/3 connections corrected this we are back to the initial 30 minutes.

The HAProxy documentation suggest "A common value for this timeout is five minutes." which is perfectly fine for HTTP/1 and HTTP/2 but is also on the very very low side for common non HTTP protocols and far away from a minute.

The webextension as well as the app uses a 5 minute timeout by default. To be on the safe side and so fulfill the Nyquist-Shannon theorem we need to send a package at least every 15 minutes for a 30 minutes timeout. This guarantees that in worst case the keep alive package never misses. For additional error margins I added a factor three thus the 5 minutes.

Let's speculate a little. In case the RFC would allow a one minute timeout. Then you need a keep alive of well below 30 seconds to work reliably. With error margins you would end-up at something in the 10-20 seconds range which is a tremendous load for an idling client, compared to one request every 30 Minutes. The absolute minimal timeout in the app is one minute, which is way too far away from the 10-20 seconds theoretically needed in your case. And honestly makes no sense at all especially, when running lots of client. You would just jam up your proxy with completely useless idle messages.

This gets even worse when you have an application which implements an auto reconnect. Every time the connection is closed due to the timeout, the client reconnects silently in the background. Which means it needs to renegotiate the secure channel, capabilities as well as the authentication which is very costly and creates unnecessary round trip times, traffic as well as load on the server. It technically means that each request ends up being a completely separated channel without any reuse. Which cannot and does not scale at all. Especially true thinking about protocols like IMAP, which has a very costly and heavy weight connection phase but keeping the connection open/alive is designed to be very light weight.

As you can see having such a small timeout on a proxy works out perfectly fine for HTTP/1 and HTTP/2 and may give you some performance benefits. But it does not work at all with most non HTTP protocol, in this use case it does exactly the opposite you expect and just burns performance for nothing.

To sum it up:

• Your proxy configuration dramatically violates the absolute minimal requirement of 30 minutes as specified in the Manage Sieve RFC (which derives the timeout from the TCP/IP specs).
• A theoretical one minute timeout needs a keep alive send every 10-20 seconds. The default in the app and webextension is 5 minutes. The absolute minimum the app supports is one minute. So no way this can ever work.
• Neither the app nor the webextension implement an automatic reconnect. You need to manually reconnect. And due to the mandatory 30 minutes timeout there is no real need for that and thus has a very low priority.

The "correct" fix is to reconfigure your HAProxy to have a 30 minute timeout for all clients connecting on the sieve port, better would be all port not using HTTP. At least for IMAP and Exchange I know that they also specify a timeout of not less than 30 minutes. Violating this requirement results in serious performance penalties due to constant and very expensive reconnects.

The bare minimum would be increasing the timeout to the five minutes suggested by the HAPoxy documentation. But you would manually need to reduce the keep alive interval in the app to 2 minutes. But it just cures the symptoms not the root cause.