Implemented for Ingo 1.2.

Yes, it does.

It looks to me like we simply do a break, aborting all further rules, 
if a stop-script rule matches in the imap driver. Since we're 
processing multiple messages at once, this makes no sense.



I think what we should do instead is store a cache of the imap uids 
that have matched stop rules, and exclude them from all future rules. 
Does that make sense?

If the filters are executed on login and refresh, he has to be using imap.

No. Sieve? IMAP filters? Procmail? Maildrop?

I'm not entirely sure what you mean. Like what version of PHP? Should 
be PHP 5.2.3

Which script backend are you using?

I have rules A, B, and C.

I have unseen messages #1 through #9.



#1 - Matches rule A.

#2 - A

#3 - A

#4 - B

#5 - A

#6 - B

#7 - C

#8 - C

#9 - B



My options are set up to only filter unseen messages and to apply the 
filter rules whenever the Inbox is displayed.



Upon first login, messages matching filter rule A (#1, #2, #3, #5) 
will get filtered. No other messages get filtered.



Refreshing the Inbox immediately results in messages matching filter 
rule B (#4, #6, and #9) being filtered.



Refreshing the Inbox again results in the remaining messages getting 
filtered by rule C.



All rules have the "Stop checking if this rule applies" checkbox 
marked, but that should not prevent the other rules from running in 
the same session. Expected behavior should be that messages #1 through 
#9 get filtered by the 3 different rules.



Just an assumption that maybe a "stop checking other rules" flag is 
being set on larger variable scope instead of just the current message 
being filtered?