filters.php doesn't handle extra untagged responses from search (patch)
Robert L Mathews <[email protected]>
| Newsgroups | gmane.mail.squirrelmail.devel |
|---|---|
| Message-ID | <[email protected]> |
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/postingguidelines List address: [email protected] List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel