6.0.0-beta1
7/12/25

[#1378] change in whitelist sieve behavior?
Summary change in whitelist sieve behavior?
Queue Ingo
Queue Version 1.0.1
Type Bug
State Resolved
Priority 1. Low
Owners
Requester liamr (at) umich (dot) edu
Created 02/15/2005 (7452 days ago)
Due
Updated 03/06/2005 (7433 days ago)
Assigned
Resolved 03/06/2005 (7433 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
03/06/2005 01:29:27 PM Jan Schneider Comment #2
State ⇒ Resolved
Reply to this comment
Makes sense to me. Changed in CVS and 1.0.2.
02/15/2005 12:07:26 AM liamr (at) umich (dot) edu Comment #1
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ change in whitelist sieve behavior?
Queue ⇒ Ingo
Reply to this comment
The description for Ingo's whitelist is...



"The whitelist is a list of (legitimate) email addresses that you 
always wish to see in your INBOX. Each address should be entered on a 
separate line."



In it's current condition, when generating rule using the sieve 
backend, it generates rules that look like..



     if address :all :comparator "i;ascii-casemap"

         :is ["From", "Sender", "Resent-From"] ["user@example.com"]  {

         keep;

     }



whitelist is the first rule be default, all "keep" does is mean "keep 
it in the inbox".  Subsequent rules can still act upon these messages 
should they match the critera set forth in those rules.



To accurately produce the behavior described in the help text, 
shouldn't there be a "stop" in the rule?



     if address :all :comparator "i;ascii-casemap"

         :is ["From", "Sender", "Resent-From"] ["user@example.com"]  {

         keep;

         stop;

     }



Or... line ~300 in lib/Script/sieve.php..



                 $action = array();

                 $action[] = &new Sieve_Action_Keep();

                 $action[] = &new Sieve_Action_Stop();


Saved Queries