Managesieve plugin reporting server error; though seems OK at TCP level.

[Kazinator]

Hi All,

I just set up a managesieve plugin. This is a migration scenario.

Everything I'm using is from Debian 11: roundcube and roundcube-plugin packages.

I pointed it at the existing pysieved instance: different server from where RC is running.

When I try to select Filters, I see the pane with "roundcube" filter category, but everything is empty. There is an error dialog box saying "Unknown server error".

I captured the TCP traffic with Wireshark and decoded the conversation. It looks fine???

Below is the capture. It's redacted to remove some of my filters.

It looks as if managesieve connected to the pysieved server, authenticated, obtained the sieve rules, then issued a LOGOUT command and all was well.

What could be the problem? I don't see any kind of "server error" into this, known or unknown.

Maybe the syntax in the rules is outdated in some detail?

Code: [Select]

"IMPLEMENTATION" "pysieved 0.91+DEV"

"SASL" "PLAIN"

"SIEVE" "envelope fileinto encoded-character enotify subaddress vacation copy comparator-i;ascii-casemap comparator-en;ascii-casemap comparator-i;octet comparator-i;ascii-numeric"

OK

AUTHENTICATE "PLAIN" "AGthegBuYWdhcmV5YW1hdHN1ZG8="

OK

CAPABILITY

"IMPLEMENTATION" "pysieved 0.91+DEV"

"SASL" "PLAIN"

"SIEVE" "envelope fileinto encoded-character enotify subaddress vacation copy comparator-i;ascii-casemap comparator-en;ascii-casemap comparator-i;octet comparator-i;ascii-numeric"

OK

LISTSCRIPTS

"roundcube" ACTIVE

OK

GETSCRIPT "roundcube"

{4436+}

# Sieve filter

 

require ["fileinto","copy"];

# rule:[roundcube]

if anyof (header :contains "Subject" "[RCU]", header :contains "Subject" "[Roundcube Webmail]")

{

fileinto "INBOX.Projects.Roundcube";

stop;

}

# rule:[gcc-build-farm]

if anyof (header :contains "To" "cfarm-users@lists.tetaneutral.net", header :contains "Cc" "cfarm-users@lists.tetaneutral.net")

{

fileinto "INBOX.Projects.GCC Build Farm";

stop;

}

# rule:[clozure]

if anyof (header :contains "To" "openmcl-devel@clozure.com", header :contains "Cc" "openmcl-devel@clozure.com")

{

fileinto "INBOX.Projects.Clozure";

stop;

}

 

# rule:[bison]

if anyof (header :contains "Cc" "bug-bison@gnu.org", header :contains "To" "bug-bison@gnu.org")

{

fileinto "INBOX.Projects.Bison";

}

# rule:[gnu-misc-discuss]

if anyof (header :contains "To" "936-846-2769@kylheku.com", header :contains "Cc" "936-846-2769@kylheku.com", header :contains "Cc" "gnu-misc-discuss@gnu.org", header :contains "List-id" "gnu-misc-discuss.gnu.org", header :contains "To" "gnu-misc-discuss@gnu.org")

{

fileinto "INBOX.Projects.GNU";

}

# rule:[bison-patches]

if anyof (header :contains "To" "bison-patches@gnu.org", header :contains "Cc" "bison-patches@gnu.org")

{

fileinto "INBOX.Projects.Bison";

}

 

OK

LOGOUT

OK

[Kazinator]

More info: in RC's

Code: [Select]

errors.log I have numerous entries like:

Code: [Select]

[29-Nov-2023 15:06:25 -0800]: <n8lte8a2> PHP Error: Failed to read from socket (GET /?_task=settings&_action=plugin.managesieve)
[29-Nov-2023 15:06:25 -0800]: <n8lte8a2> PHP Error: Failed to read from socket (GET /?_task=settings&_action=plugin.managesieve)
[29-Nov-2023 15:06:28 -0800]: <n8lte8a2> PHP Error: Failed to read from socket (POST /?_task=settings&_action=plugin.managesieve-action)
[29-Nov-2023 15:06:28 -0800]: <n8lte8a2> PHP Error: Failed to read from socket (POST /?_task=settings&_action=plugin.managesieve-action)
At the end of the TCP conversation there is an abrupt termination in the connection connection: a RST (reset) segment is seen:

Code: [Select]

71 3.486112 192.168.1.206 192.168.1.88 TCP 66 41790 → 4190 [RST, ACK] Seq=110 Ack=4962 Win=64128 Len=0 TSval=3235803071 TSecr=401306205
This RST is from the RoundCube machine (.206) to the one running pysieved (.88).

Basically the last three packets seen are: LOGOUT (RC to pysieved). The OK (pysieved to RC), then RC abruptly closes the connection, such that it is reset.

[Kazinator]

I turned on managesieve debugging. There is a possible clue here.

It looks like the client (RC side connection to the sieve daemon) is not waiting for the sieve data. It issues:

Code: [Select]

GETSCRIPT "roundcube"
and then

Code: [Select]

LOGOUT
without waiting for the data from the server to complete. Or so it appears.

Code: [Select]

[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: "IMPLEMENTATION" "pysieved 0.91+DEV"
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: "SASL" "PLAIN"
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: "SIEVE" "envelope fileinto encoded-character enotify subaddress vacation
copy comparator-i;ascii-casemap comparator-en;ascii-casemap comparator-i;octet comparator-i;ascii-numeric"
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: OK
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> C: AUTHENTICATE "PLAIN" "AGthegBuYWdhcmV5YW1hdHN1ZG8="
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: OK
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> C: CAPABILITY
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: "IMPLEMENTATION" "pysieved 0.91+DEV"
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: "SASL" "PLAIN"
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: "SIEVE" "envelope fileinto encoded-character enotify subaddress vacation
copy comparator-i;ascii-casemap comparator-en;ascii-casemap comparator-i;octet comparator-i;ascii-numeric"
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: OK
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> C: LISTSCRIPTS
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: "roundcube" ACTIVE
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: OK
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> C: GETSCRIPT "roundcube"
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: {4436+}
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: # Sieve filter
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S:
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> C: LOGOUT
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: require ["fileinto","copy"];
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: # rule:[roundcube]
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: if anyof (header :contains "Subject" "[RCU]", header :contains "Subject"
"[Roundcube Webmail]")
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: {
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S:     fileinto "INBOX.Projects.Roundcube";
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S:     stop;
[29-Nov-2023 20:50:55 -0800]: <n8lte8a2> S: }
...
[ rest of the sieve content snipped; no more client C: commands appear ]

[Kazinator]

Okay, this PHP cruft is confused by an empty read from the server!

In the file /usr/share/php/Net/Sieve.php if I comment out the lines below, like so:

Code: [Select]

    function _recvLn()
    {
        $lastline = $this->_sock->gets(8192);
        if (is_a($lastline, 'PEAR_Error')) {
            return $this->_pear->raiseError(
                'Failed to read from socket: ' . $lastline->getMessage()
            );
        }

        $lastline = rtrim($lastline);
        $this->_debug("S: $lastline");

        //if ($lastline === '') {
        //    return $this->_pear->raiseError('Failed to read from socket');
        //}

        return $lastline;
    }

Blam! The UI loads all my filters.

There is no socket read error!

Indeed, in the sieve log there is this:

Code: [Select]

[29-Nov-2023 21:26:01 -0800]: <n8lte8a2> S:
That corresponds to the debug("S: $lastline").

But there is no empty line in the actual file on the server side. This is, I'm guessing, likely a situation whereby the EOF on the socket (zero byte read: not an error!) is turning into an empty string.

[Kazinator]

It gets weirder. With that little change in place, things work: I can see all the filters in the UI, and edit them.

When I save them, though, the sieve file now has CR-LF line endings: ^M characters all over the place.

The previous file saved by an old version of the plugin (RC 0.9.x era) saved it in normal POSIX format.

But that's not the problem; if I take off the PHP patch, it will not load the filters, even though they now have the CR-LF endings. So the patch has to stay.


Why did they change line endings; probably some RFC required it or something.

[Kazinator]

The sieve filter with the spurious carriage returns inserted by the Debian 11 version of managesieve, running on top of the Net_Sieve PHP class from that distro ... isn't working.

Mailing list posts that should go to folders are going into my Inbox.

I can easily reproduce the issue: save the sieve file in CR-LF format, send an e-mail to a certain alias, and it goes into Inbox. Save the file in LF format, send the same e-mail, and it goes to the right folder.

The fucks are tightly clustered here.