<?xml version="1.0" encoding="UTF-8"?> 
<?xml-stylesheet href="https://dev.horde.org/themes/horde//default/feed-rss.xsl" type="text/xsl"?> 
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> 
 <channel> 
  <title>patch to resolve sieve forward/keep ambiguity</title> 
  <pubDate>Fri, 10 Apr 2026 16:31:11 +0000</pubDate> 
  <link>https://bugs.horde.org/ticket/5746</link> 
  <atom:link rel="self" type="application/rss+xml" title="patch to resolve sieve forward/keep ambiguity" href="https://bugs.horde.org/ticket/5746/rss" /> 
  <description>patch to resolve sieve forward/keep ambiguity</description> 
 
   
   
  <item> 
   <title>The attached patch fixes a problem in the keep behavior for </title> 
   <description>The attached patch fixes a problem in the keep behavior for the Forward script by 

creating two Sieve rules to handle &#039;redirect&#039; and &#039;keep&#039; as separate actions.



Currently using Forward with Keep looks like this:

# Forwards

if true {

    redirect &quot;username@server&quot;;

    keep;

}



and without Keep:

# Forwards

if true {

    redirect &quot;username@server&quot;;

}



The behavior of the first script is to redirect mail as expected and then immediately 

drop a copy into the Inbox followed by parsing of any additional filters.



The second script will redirect the mail and then continue to parse via additional rules 

until a stop is encountered.  Mail is not delivered into the Inbox at the end of the 

script.



The reason why mail does not go to the inbox during a Forward request is that the 

redirect action disables the implicit keep within Sieve.



The keep action declares an _explicit_ keep action which is the same as declaring: 

fileinto &quot;Inbox&quot;.



This patch results one of the following:



Without Keep:



# Forwards

if true {

    redirect &quot;username@server&quot;;

    stop;

}



With Keep:



# Forwards

if true {

    redirect &quot;username@server&quot;;

}



... any other rules that exist with the last rule being ...



# Forward Keep Action

if true {

    keep;

    stop;

}



A user can still move the position of the Forwards script within Ingo.

The Forward Keep Action script is always placed at the end.  This script replicated the 

implicit keep function.



- Tobias Drewry</description> 
   <pubDate>Wed, 26 Sep 2007 14:26:17 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5746#t37081</link> 
  </item> 
   
  <item> 
   <title>Just to make sure I understand what you are trying to achiev</title> 
   <description>Just to make sure I understand what you are trying to achieve with this change:

With keep, your patch enables all other filter rules to be applied while this didn&#039;t happen without your patch?

Without keep, what does the extra &quot;stop&quot; change, if &quot;redirect&quot; already doesn&#039;t keep the message?</description> 
   <pubDate>Fri, 05 Oct 2007 15:20:39 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5746#t37465</link> 
  </item> 
   
  <item> 
   <title>&gt; Just to make sure I understand what you are trying to achi</title> 
   <description>&gt; Just to make sure I understand what you are trying to achieve with 

&gt; this change:

&gt; With keep, your patch enables all other filter rules to be applied 

&gt; while this didn&#039;t happen without your patch?



Yes and no.  With the current implementation the behavior with keep was to immediately copy the message to the users INBOX and then pass the message to any remaining filters.  This would result in duplicates of the messages being saved to folders as well as to the INBOX.



By moving the keep action to a separate rule at the end of the sieve list, you are able to move the forward rule around so as to allow some or all of your filters to be used (and possible stop the filtering) before the keep action is executed.



The &#039;stop&#039; action in the Forward Keep Action is just there for completeness.  It  makes the sieve script behave reliably no matter what version of the RFC is in use (i.e. it is slightly redundant).



&gt; Without keep, what does the extra &quot;stop&quot; change, if &quot;redirect&quot; 

&gt; already doesn&#039;t keep the message?



A redirect without stop redirects the mail and passes the message on to any other filters until a stop action is found.  



The redirect directive disable the implicit keep in Sieve.  With the implicit keep disabled, when a message reaches the end of the filter list it is not &quot;kept&quot;.  

However, if the message matched any filters after the redirect, then the message is also delivered according to the rules of that message.  



The stop prevents further processing of the mail message after the forward, thus preventing messages from collecting in folders when a user is thinking that all of their mail is being redirected.



Let me know if you need examples or more explanation.  I can also site the RFC if needed.



- Tobias

</description> 
   <pubDate>Fri, 05 Oct 2007 15:43:33 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5746#t37469</link> 
  </item> 
   
  <item> 
   <title>Thanks for your detailed explanation. It helped to understan</title> 
   <description>Thanks for your detailed explanation. It helped to understand what your patch was supposed to, because it didn&#039;t work at all. :) You were referring to variables that didn&#039;t exist, the &quot;stop&quot; rule was not added after the redirect call, etc.

Please see if what I committed to CVS now is what you wanted to achieve.</description> 
   <pubDate>Sun, 07 Oct 2007 11:08:14 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5746#t37495</link> 
  </item> 
   
  <item> 
   <title>&gt; Thanks for your detailed explanation. It helped to underst</title> 
   <description>&gt; Thanks for your detailed explanation. It helped to understand what 

&gt; your patch was supposed to, because it didn&#039;t work at all. :) You 

&gt; were referring to variables that didn&#039;t exist, the &quot;stop&quot; rule was 

&gt; not added after the redirect call, etc.

&gt; Please see if what I committed to CVS now is what you wanted to achieve.



That works great :), I&#039;m not sure why the patch didn&#039;t work for you though.  However, I&#039;m not complaining, your code is much cleaner then what I generated.



Thanks again,

Tobias</description> 
   <pubDate>Tue, 09 Oct 2007 14:20:20 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/5746#t37575</link> 
  </item> 
   
   
 
 </channel> 
</rss> 
