filters.php doesn't handle extra untagged responses from search (patch)
|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
 |
filters.php doesn't handle extra untagged responses from search (patch)
by Robert L Mathews
::
Rate this Message:
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: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: filters.php doesn't handle extra untagged responses from search (patch)
by Paul Lesniewski
::
Rate this Message:
On Fri, Jan 2, 2009 at 3:07 PM, Robert L Mathews <lists@...> wrote:
> I'm testing the development snapshot and found a problem in filters.php. Please state what version next time. Looks to me like you're trying out 1.5.x. Thanks very much for helping improve our newest development code! You should also note that if you are using a snapshot, you don't have the newest code - the snapshot generation script seems to have stalled out in December. > 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 Makes sense to me, but I don't have the motivation to test it out. I am inclined to commit the fix, but if others have any opinions, I'd like to hear them first. Feedback? ------------------------------------------------------------------------------ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: filters.php doesn't handle extra untagged responses from search (patch)
by Paul Lesniewski
::
Rate this Message:
On Fri, Jan 2, 2009 at 5:05 PM, Paul Lesniewski <paul@...> wrote:
> On Fri, Jan 2, 2009 at 3:07 PM, Robert L Mathews <lists@...> wrote: >> I'm testing the development snapshot and found a problem in filters.php. > > Please state what version next time. Looks to me like you're trying > out 1.5.x. Thanks very much for helping improve our newest > development code! > > You should also note that if you are using a snapshot, you don't have > the newest code - the snapshot generation script seems to have stalled > out in December. > >> 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 > > Makes sense to me, but I don't have the motivation to test it out. I > am inclined to commit the fix, but if others have any opinions, I'd > like to hear them first. > > Feedback? Any feedback people? Otherwise, I will commit this in the near future. ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
| Free embeddable forum powered by Nabble | Forum Help |
