Tickets :: [#3313] putting commas in text to match generates bad rules

6.0.0-beta1

7/7/25

Summary	putting commas in text to match generates bad rules
Queue	Ingo
Queue Version	HEAD
Type	Bug
State	Resolved
Priority	1. Low
Owners	jan (at) horde (dot) org
Requester	liamr (at) umich (dot) edu
Created	01/20/2006 (7108 days ago)
Due
Updated	04/26/2006 (7012 days ago)
Assigned	02/01/2006 (7096 days ago)
Resolved	04/24/2006 (7014 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

04/26/2006 07:10:19 PM	Matt Selsky	Comment #6	Reply to this comment
Looks good.

04/26/2006 05:26:00 PM	Jan Schneider	Comment #5	Reply to this comment
Try now?

04/25/2006 03:16:21 AM	Matt Selsky	Comment #4	Reply to this comment
The sieve script now says: header :comparator "i;ascii-casemap" :contains "Subject" "Amazing" The trailing comma is missing.

04/24/2006 12:41:06 PM	Jan Schneider	Comment #3 State ⇒ Resolved	Reply to this comment
A check has been added to make sure that no empty headers or addresses can be added to the test accidentally.

02/01/2006 06:10:13 PM	Jan Schneider	Assigned to Jan Schneider State ⇒ Assigned

01/21/2006 12:33:33 AM	Jan Schneider	Comment #2 State ⇒ Feedback	Reply to this comment
This is the intended behaviour, see ~~ticket 1105~~. But maybe we should check if one of the values is empty.

01/20/2006 09:28:39 PM	liamr (at) umich (dot) edu	Comment #1 Priority ⇒ 1. Low Type ⇒ Bug Summary ⇒ putting commas in text to match generates bad rules Queue ⇒ Ingo State ⇒ Unconfirmed	Reply to this comment
Another report from our help desk.. basically, if you create a sieve rule that tries to match a subject string with a comma in it ( eg... "Amazing," ), the comma gets mistranslated when the sieve script is generated. SQL sez.. [field] => Subject [type] => 1 [match] => contains [value] => Amazing, but, the sieve script sez... header :comparator "i;ascii-casemap" :contains "Subject" ["Amazing", ""] and the "" ends up matching ALL rules. I've tried this with CVS HEAD from this PM (1/20/06) and w/ Ingo 1.0.2.