[bug]: Sieve filtering not working properly

[Megver83]

What happened?

I uploaded a sieve script using sieve-connect but it did not take any effect. The rules tell that certain mails should be moved to some INBOX subfolders, but does not happen.

How can we reproduce the problem?

I can reproduce the problem by doing the following steps:

1. Upload and activate a sieve script with sieve-connect with rules for moving some emails to INBOX subfolders
2. Get some email
3. The emails are not moved

Also, not sure if related to this, there's something wrong with sieve-connect when trying to download or edit the sieve script. Here's the example of what happens to me:

<<< "IMPLEMENTATION" "Stalwart ManageSieve"\r\n
<<< "VERSION" "1.0"\r\n
<<< "STARTTLS"\r\n
<<< "SASL" "OAUTHBEARER"\r\n
<<< "SIEVE" "body comparator-elbonia comparator-i;ascii-casemap comparator-i;ascii-numeric comparator-i;octet convert copy date duplicate editheader enclose encoded-character enotify envelope envelope-deliverby envelope-dsn environment ereject extlists extracttext fcc fileinto foreverypart ihave imap4flags imapsieve include index mailbox mailboxid mboxmetadata mime redirect-deliverby redirect-dsn regex reject relational replace servermetadata spamtest spamtestplus special-use subaddress vacation vacation-seconds variables virustest"\r\n
<<< "NOTIFY" "mailto"\r\n
<<< "MAXREDIRECTS" "1"\r\n
<<< OK "Stalwart ManageSieve at your service."
-T- will use TLS certs from directory "/etc/ssl/certs"
-T- using hostname 'mail.pizarro.info', verification verify-peer cert-required
>>> STARTTLS\r\n
<<< OK Begin TLS negotiation now\r\n
-T- TLS activated here [256 bits]
>>> NOOP "STARTTLS-RESYNC-CAPA"\r\n
... literal string response, length 20
<<< OK (TAG {20}STARTTLS-RESYNC-CAPA) "Done"\r\n
>>> CAPABILITY\r\n
<<< "IMPLEMENTATION" "Stalwart ManageSieve"\r\n
<<< "VERSION" "1.0"\r\n
<<< "SASL" "PLAIN OAUTHBEARER"\r\n
<<< "SIEVE" "body comparator-elbonia comparator-i;ascii-casemap comparator-i;ascii-numeric comparator-i;octet convert copy date duplicate editheader enclose encoded-character enotify envelope envelope-deliverby envelope-dsn environment ereject extlists extracttext fcc fileinto foreverypart ihave imap4flags imapsieve include index mailbox mailboxid mboxmetadata mime redirect-deliverby redirect-dsn regex reject relational replace servermetadata spamtest spamtestplus special-use subaddress vacation vacation-seconds variables virustest"\r\n
<<< "NOTIFY" "mailto"\r\n
<<< "MAXREDIRECTS" "1"\r\n
<<< OK
>>> AUTHENTICATE "PLAIN" {24+}\r\n
>>> 
<<< "IMPLEMENTATION" "Stalwart ManageSieve"\r\n
>>> \r\n
<<< "VERSION" "1.0"\r\n
>>> \r\n
<<< "SASL" "PLAIN OAUTHBEARER"\r\n
>>> \r\n
<<< "SIEVE" "body comparator-elbonia comparator-i;ascii-casemap comparator-i;ascii-numeric comparator-i;octet convert copy date duplicate editheader enclose encoded-character enotify envelope envelope-deliverby envelope-dsn environment ereject extlists extracttext fcc fileinto foreverypart ihave imap4flags imapsieve include index mailbox mailboxid mboxmetadata mime redirect-deliverby redirect-dsn regex reject relational replace servermetadata spamtest spamtestplus special-use subaddress vacation vacation-seconds variables virustest"\r\n
>>> \r\n
<<< "NOTIFY" "mailto"\r\n
>>> \r\n
<<< "MAXREDIRECTS" "1"\r\n
>>> \r\n
<<< OK "Authentication successful"\r\n
>>> GETSCRIPT "kupos"\r\n
... literal string response, length 132
... after literal, did not get final CRLF but "OK
"
<<< {132}\r\nrequire ["fileinto"];\n\n# rule:[kupos]\nif allof (header :contains "to" "kupos@daveepark.anonaddy.com")\n{\n\tfileinto "INBOX.kupos";\n}\n\n

IDK if this has to do with ManageSieve but the problem (or symptom) is after literal, did not get final CRLF but "OK

I didn't have this problem with Dovecot, fyi.

Version

v0.8.x

What database are you using?

RocksDB

What blob storage are you using?

RocksDB

Where is your directory located?

Internal

What operating system are you using?

Docker

Relevant log output

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[Megver83]

This was already observed in #396

[mdecimus]

This issue has been fixed and will be included in the next release.