Fri, 10 Apr 2026 18:48:35 +0000 https://bugs.horde.org/ticket/5392 "is" matches for sieve aren't exact string matches 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. Wed, 23 May 2007 02:41:34 +0000 https://bugs.horde.org/ticket/5392#t33391 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. Sun, 17 Jun 2007 22:42:18 +0000 https://bugs.horde.org/ticket/5392#t34333 This does seem to have fixed the issue. Fri, 22 Jun 2007 11:29:43 +0000 https://bugs.horde.org/ticket/5392#t34573