<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>Guess I chose first ;)<br></div>
<div>&nbsp;</div>
<div>Patches (untested in production, but I do have Cassandane tests for them)<br></div>
<div>&nbsp;</div>
<div><a href="https://github.com/brong/cyrus-imapd/commit/6f3e97023c16b1af19926b6ef67b6dc2ddcc844b">https://github.com/brong/cyrus-imapd/commit/6f3e97023c16b1af19926b6ef67b6dc2ddcc844b</a><br></div>
<div><a href="https://github.com/brong/cyrus-imapd/commit/bda966274a8f53497bcf510a43b1bfc81baf4f7f">https://github.com/brong/cyrus-imapd/commit/bda966274a8f53497bcf510a43b1bfc81baf4f7f</a><br></div>
<div>&nbsp;</div>
<div>They'll probably be rebased and tested some more before going upstream.<br></div>
<div>&nbsp;</div>
<div>First one allows delivery to a name starting with a backslash (double-backslashed, and again in the test)<br></div>
<div>and successfully finds the folder with that backslash and delivers there.<br></div>
<div>&nbsp;</div>
<div>Second one rejects renames if they aren't exactly one mailbox level deep in the mbname (aka a top<br></div>
<div>level of altnamespace, or an immediate sub of INBOX in standard namespace)<br></div>
<div>&nbsp;</div>
<div>Bron.<br></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>On Sat, Oct 3, 2015, at 16:38, Bron Gondwana wrote:<br></div>
<blockquote type="cite"><div>It's not impossible yet, though maybe it should be. I'll pick either the first or last depending on implementation ;)<br></div>
<div>&nbsp;</div>
<div>Bron.<br></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>On Sat, Oct 3, 2015, at 09:37, Stephen Ulmer wrote:<br></div>
<blockquote type="cite"><div>Now THAT is a good idea!<br></div>
<div>&nbsp;</div>
<div><div>What are you going to do for delivery if there’s more than one folder with the flag (or is that already impossible some other way)?<br></div>
<div><div>&nbsp;</div>
<div><div>&nbsp;</div>
<div><span style="color:rgb(0, 0, 0)" class="colour"><span style="font-family:Helvetica" class="font">--&nbsp;</span></span><br></div>
<div><span style="color:rgb(0, 0, 0)" class="colour"><span style="font-family:Helvetica" class="font">Stephen</span></span><br></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</div>
<div>&nbsp;</div>
<div><blockquote type="cite"><div>On Oct 2, 2015, at 5:43 PM, Bron Gondwana &lt;<a href="mailto:brong@fastmail.fm">brong@fastmail.fm</a>&gt; wrote:<br></div>
<div>&nbsp;</div>
<div><div><div>I'm planning to create an option to reject delete or move into a sub folder for any folder with a special-use flag. We would allow rename. Of course with this would be a sieve extension to do delivery to a special-use flag instead of folder name...<br></div>
<div>&nbsp;</div>
<div>Bron.<br></div>
<div>&nbsp;</div>
<div>On Sat, Oct 3, 2015, at 05:41, Stephen Ulmer wrote:<br></div>
<blockquote type="cite"><div>A user deleting her spam folder won’t be prevented by a sieve script.<br></div>
<div>&nbsp;</div>
<div>I hope that most of your spam identification rules are run in your MTA (not in sieve) and then sieve is used to sort messages based on a a few simple flags.<br></div>
<div>&nbsp;</div>
<div>There may be a perfectly good use case for confusing users by having something that they can’t see or edit change their mailbox behavior, but I don’t think that spam defense is it. That being said, implementing global identifiers for an “include” directive would be nice… Then the user could include features from a catalog using a name from a registry of includes, rather than a path.<br></div>
<div><div>&nbsp;</div>
<div><div><div>&nbsp;</div>
<div><span style="border-collapse:separate;">--&nbsp;</span><br></div>
<div><span style="border-collapse:separate;">Stephen</span><br></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</div>
<div>&nbsp;</div>
<div><blockquote type="cite"><div>On Oct 2, 2015, at 3:22 PM, Mai Ling &lt;<a href="mailto:mailinglists35@gmail.com">mailinglists35@gmail.com</a>&gt; wrote:<br></div>
<div>&nbsp;</div>
<div><div>Even if you create once &amp; forget, there are still cases where site-enforced rules are useful:<br></div>
<div>On the previous setup I've managed I've encountered lots of cases where people accidentally deleted their spam folders or their spam rules;<br></div>
<div><div>Having an user rule automagically imported/enforced from a site template would always prevent these.<br></div>
<div>&nbsp;</div>
<div><div style=""><div>On Vin, oct. 2, 2015 at 10:13 p.m.,  Stephen Ulmer &lt;<a href="mailto:ulmer@ufl.edu">ulmer@ufl.edu</a>&gt; wrote:<br></div>
<div style="overflow-y:visible;overflow-x:visible;"><blockquote style="color:rgb(48, 59, 64);"><div><div>I would not imagine that you’d need (or want) to change all of the users’ rules to make an update for spam filtering. Just filter on an X- header that’s added by your MTA. Change the way the header gets calculated, but not what it means to the sieve script.<br></div>
<div>&nbsp;</div>
<div>This is presuming that you make the modification just once (to turn it on).<br></div>
<div>&nbsp;</div>
<div><div><div>&nbsp;</div>
<div>--&nbsp;<br></div>
<div>Stephen<br></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</div>
<div>&nbsp;</div>
<div><blockquote><div>On Oct 2, 2015, at 3:08 PM, Mai Ling &lt;<a href="mailto:mailinglists35@gmail.com">mailinglists35@gmail.com</a>&gt; wrote:<br></div>
<div>&nbsp;</div>
<div><div>Oh awesome!<br></div>
<div><div>&nbsp;</div>
<div>I wish they add support for editable site-default sieve rules that override user sieve rules.<br></div>
<div>&nbsp;</div>
<div><div>This way you won't have to update all users rules when you want to make modification to everyones' rules (usecase: spam filtering)<br></div>
<div>&nbsp;</div>
<div><div><div>On Sâm, sept. 26, 2015 at 1:30 a.m.,  Artyom Aleksandrov &lt;<a href="mailto:mailing.list@tem4uk.ru">mailing.list@tem4uk.ru</a>&gt; wrote:<br></div>
<div style="overflow-y:visible;overflow-x:visible;"><blockquote style="color:rgb(48, 59, 64);"><div dir="ltr"><div><div><div>Hello,I want to create default sieve scipt for all my users 
but I stuck with strange problem that looks like the bug. Unfortunately 
I've never wrote on C so it's difficult for me to find it.<br></div>
<div>When Cyrus
 (2.5.3 or 2.5.6) create default sieve script it doesn't put file in 
sieve_dir/?/user folder. It jist creates tmp files in configdirectory 
with names like this<br></div>
</div>
<div style="margin-left:40px;"><div>-rw-------  1 cyrus mail   124 Sep 26 00:41 ?&amp;?P??default.script.bc<br></div>
<div>-rw-------  1 cyrus mail   231 Sep 26 00:41 ?&amp;?P??default.script.script<br></div>
<div>lrwxrwxrwx  1 cyrus mail    17 Sep 26 00:41 ?&amp;?P??defaultbc -&gt; default.script.bc<br></div>
</div>
<div>&nbsp;</div>
</div>
<div>There are not checks in this stage so my syslog is clean of error.<br></div>
<div><div>Everything seems fine.<br></div>
<div>&nbsp;</div>
<div style="margin-left:40px;"><div>Sep
 26 00:41:34 imapsync cyrus/imap[26117]: autocreate_sieve: Problem 
opening compiled script file: default.script.bc. Compiling it<br></div>
<div>Sep 26 00:41:34 imapsync cyrus/imap[26117]: autocreate_sieve: Compiled sieve script was successfully saved in default.script.bc<br></div>
<div>Sep 26 00:41:34 imapsync cyrus/imap[26117]: autocreate_sieve: User XXXX, default sieve script creation succeeded <br></div>
</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</div>
<div><div>My setting:<br></div>
<div style="margin-left:40px;"><div>autocreate_sieve_script: /var/spool/sieve/global/default.script<br></div>
<div>autocreate_sieve_script_compile: yes<br></div>
<div>autocreate_sieve_script_compiled: default.script.bc<br></div>
<div>sievedir: /var/spool/sieve/<br></div>
</div>
<div>Distributive: Ubuntu 14.04.3<br></div>
</div>
<div>&nbsp;</div>
<div>I'll be glad for any help. )<br></div>
<div>&nbsp;</div>
<div>Best regards, Artyom<br></div>
</div>
</blockquote></div>
</div>
</div>
</div>
</div>
<div>----<br></div>
<div>Cyrus Home Page: <a href="http://www.cyrusimap.org/"></a><a href="http://www.cyrusimap.org/">http://www.cyrusimap.org/</a><br></div>
<div>List Archives/Info: <a href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/"></a><a href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a><br></div>
<div>To Unsubscribe:<br></div>
<div><a href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus"></a><a href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a><br></div>
</div>
</blockquote></div>
</div>
</div>
</blockquote></div>
</div>
</div>
</div>
</div>
</blockquote></div>
</div>
</div>
<div>----<br></div>
<div>Cyrus Home Page: <a href="http://www.cyrusimap.org/">http://www.cyrusimap.org/</a><br></div>
<div>List Archives/Info: <a href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a><br></div>
<div>To Unsubscribe:<br></div>
<div><a href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a><br></div>
</blockquote><div>&nbsp;</div>
<div><div>--<br></div>
<div>&nbsp; Bron Gondwana<br></div>
<div><a href="mailto:brong@fastmail.fm">brong@fastmail.fm</a><br></div>
<div>&nbsp;</div>
</div>
<div>&nbsp;</div>
</div>
</div>
</blockquote></div>
</div>
</div>
</blockquote><div>&nbsp;</div>
<div><div>--<br></div>
<div>&nbsp; Bron Gondwana<br></div>
<div>&nbsp; brong@fastmail.fm<br></div>
<div>&nbsp;</div>
</div>
<div>&nbsp;</div>
<div>----<br></div>
<div>Cyrus Home Page: <a href="http://www.cyrusimap.org/">http://www.cyrusimap.org/</a><br></div>
<div>List Archives/Info: <a href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a><br></div>
<div>To Unsubscribe:<br></div>
<div><a href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a><br></div>
</blockquote><div>&nbsp;</div>
<div id="sig567075"><div class="signature">--<br></div>
<div class="signature">&nbsp; Bron Gondwana<br></div>
<div class="signature">&nbsp; brong@fastmail.fm<br></div>
<div class="signature">&nbsp;</div>
</div>
<div>&nbsp;</div>
</body>
</html>