This does seem to have fixed the issue.

Funny, this is exactly the same like bug 3313 which you reported a 
year ago, only with leading commas instead of trailing commas. Fixed 
in CVS and 1.1.4.

Our help desk has expressed dismay that the "is" match is described as



    IS:  Will be considered to be true if the specified string matches the line

      exactly. Example: user@example.com is user@example.com



but, in reality, it's not an exact string match.  We have users that 
want to match strings that contain commas.   E.g.,  spam that has 
subjects like...



    Cats eat mice, stop them!



or more specfically...



    , stop them!



We're using Horde 3.0.12 and Ingo 1.0.2 in production, and using...



  [ Subject ] [ is ] [ , stop them! ]



in the rules screen, generates a sieve rule that looks like...



     if header :comparator "i;ascii-casemap" :is "Subject" ["", "stop 
them!"]  {

          discard;

          stop;

     }



which matches all sorts of stuff it shouldn't.



In Horde 3.2-cvs and Ingo 1.2-cvs, we don't even get that much.



  [ Subject ] [ is ] [ , stop them! ]



generates...



    if header :comparator "i;ascii-casemap" :is "Subject" ""  {

         discard;

         stop;

    }



curiously, in both Ingo 1.0.2 and 1.2-cvs, the little pop-up that 
describes the rule when you hover over it in the rules management 
screen does describe the rule as the user intended..



    Subject is ", stop them!"

    Delete message completely

    [stop]



Mind you, I probably wouldn't create rules like this.. but users want 
what users want,  and the the rules like..



     is "Subject" ""



match everything.



We'd like to see "is" match generate exact string matches for the 
sieve backend w/o having to escape anything.