philpennock / sieve-connect

sieve-connect/sieve-connect.pre.pl

Line 953 in 945b561

ssend $sock, "{$sendlen+}";

I'm curious to know why sieve-connect does this, since it causes issues with Stalwart
stalwartlabs/mail-server#187

If it's nonessential, it could be removed or make it optional (e.g. through a flag)

sieve-connect does this because SASL is a step-wise protocol which continues until the server exits, and is deliberately sending an empty message, to be compatible with SASL.

The issue you're seeing is a bug in Stalwart's authentication. The SASL exchange MUST end in an OK line on successful authentication, and this comes before the reissuance of the server capabilities. You can see an example of this in the ManageSieve RFC, 5804, at the end of the text in section 2.1 before entering section 2.1.1

       C: AUTHENTICATE "GSSAPI" {1488+}
       C: YIIE[...1480 octets here ...]dA==
       S: {208}
       S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic
          [...114 octets here ...]
          /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6
       C: {0+}
       C:
       S: {44}
       S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA=
       C: {44+}
       C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE=
       S: OK
       <Further commands/responses are under SASL security layer>
       S: "IMPLEMENTATION" "Example1 ManageSieved v001"
       S: "VERSION" "1.0"
       S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
       S: "SIEVE" "fileinto vacation"
       S: "LANGUAGE" "ru"
       S: "MAXREDIRECTS" "3"
       S: ok

Here you both see the client having to send an empty message, and how the Server (S: lines sends the OK to terminate the authentication flow, before then reissuing the capabilities and ending with ok (or OK) again.

In the linked issue stalwartlabs/mail-server#187 you can see that the server response is missing the OK at the end of the SASL authentication flow and instead proceeds into capabilities immediately. That is a bug. The mail-server might get away with it with naive clients which send one auth string and nothing else, but that's naive clients missing a server bug.

I am confident that the sieve-connect behaviour is correct here.

Why sending data length?