I'm testing the development snapshot and found a problem in filters.php.
When using Courier IMAP as the IMAP server, the response from a search
that matched a message looks like:
* SEARCH 50
A006 OK SEARCH done.
But if the only message in the mailbox is then copied by the first
filtering rule, leaving nothing but deleted (but not yet expunged)
messages in the mailbox, the response from the next search that doesn't
match anything has an extra line:
* SEARCH
* 1 FETCH (FLAGS (\Deleted))
A006 OK SEARCH done.
This is odd, but appears to be permitted by the IMAP spec, which says
"For your convenience, untagged responses can appear at random,
anywhere!" (I'm paraphrasing).
Unfortunately, the SquirrelMail code is assuming the search response
always contains exactly two lines, and looks for the final response in
the second. This causes strange problems (in particular, it doesn't read
the last line of the response, causing the next IMAP command to read the
result of this previous one, and so on).
The following patch against the latest development snapshot makes it
read as many untagged lines as necessary, remembering the "* SEARCH" one
and ignoring any others, until we see the final response.
http://www.tigertech.net/patches/squirrelmail-filters.patch--
Robert L Mathews, Tiger Technologies
------------------------------------------------------------------------------
-----
squirrelmail-devel mailing list
Posting guidelines:
http://squirrelmail.org/postingguidelinesList address:
squirrelmail-devel@...
List archives:
http://news.gmane.org/gmane.mail.squirrelmail.develList info (subscribe/unsubscribe/change options):
https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
