Any way to add message filters from command line?

[jbwiv]

Guys,

I have a rather large procmail config and I'd like to convert it to Zimbra filters. Is there any way to add a filter (message filter) to an account from the command line?

Thanks!
Jbwiv

[phoenix]

Yes, search the forums for 'sieve'.

[jbwiv]

Ok, got it working, thanks. For anyone else trying to do this, here's a quick and dirty perl script that'll convert your procmail ^TO rules to sieve rules. Mind you, I hacked this quickly and it assumes some things about your .procmailrc AND the paths to your folders (for example, it assumes you have .folder style courier folders), so PLEASE check your results before running. I make not guarantees it'll work at all for you.

You essentially run it passing the path of your procmailrc as the first arg, zimbra account name as second arg, and then direct it's output to a file. Then, run this file as a shell script...

Hope it helps:

#!/usr/bin/perl

$file = $ARGV[0];
$acct = $ARGV[1];

sub output {
$list = shift;
$folder = shift;
print <<EOL
# $list
if anyof (header :contains "to" "$list" ,
 header :contains "cc" "$list" )
{
    fileinto "/$folder";
    stop;
}
EOL
}

print "#!/bin/bash\nzmprov ma $acct zimbraMailSieveScript '\n";
print 'require ["fileinto", "reject", "tag", "flag"];' . "\n";
open(FH, $file) or die "Can't open $file\n";
$to = "";
$fo = "";
while (<FH>) {
        $line = $_;
        if ($line=~/\^TO_(.*)/) {
                $to = $1;
                $line = <FH>;
                $fo = $1 if ($line=~/\.(.*)\/new/);
        }

        if ($fo && $to) {
                output($to, $fo);
                $to = "";
                $fo = "";
        }
}
print "'\n";

[dkarp]

Pretty cool ! Any chance you could post this to the Migration wiki for posterity at some point?

[jbwiv]

Sure...when things slow down this week I'll do just that...

[phoenix]

Yes, that's a neat solution.

[dlbewley]

My rules didn't comply for that conversion script, but once you have your rules converted, below is a way to stick them into Zimbra.

Create a file like the following and pipe it to zmprov. Note that the newlines inside the value for zimbraMailSieveScript must be escaped:

ma jdoe zimbraMailSieveScript '\
require ["fileinto", "reject", "tag", "flag"];\
# Helpdesk Tickets\
if anyof (header :contains "subject" "[Lib Help #" )\
{\
    tag "Tickets";\
    flag "flagged";\
    stop;\
}\
'

Maybe you have a filter you want to pre-populate for a set of workstation support people. Create a file with your filters in it, like this call it filters.tmpl:

require ["fileinto", "reject", "tag", "flag"];\
# Helpdesk Tickets\
if anyof (header :contains "subject" "[Lib Help #" )\
{\
    tag "Tickets";\
    flag "flagged";\
    stop;\
}\

Then you can pre-populate users' filters like this:

 cat users.txt | while read user; do
     echo "ma $user zimbraMailSieveScript '\\" >> filters.zmp
     cat filters.tmpl >> filters.zmp
     echo "'" >> filters.zmp
 done

Now pipe filters.zmp to zmprov.

If you have tags in your filters like my example, you'll need to pre-create those. Put them in a file called tags.tmpl (one per line) and do this.

 cat users.txt | while read user; do
    echo "sm $user" >> tags.zmp
    cat tags.tmpl | while read tag; do
         echo "createTag '$tag'" >> tags.zmp
     done
     echo "exit" >> tags.zmp 
done

Now pipe tags.zmp to zmprov. Note, you should create the tags before the filters.

[Daimyo]

This thread looked like a good place to get some advice on a similar problem we're having. We're migrating users from Cyrus IMAP to Zimbra, and one of the things we want to do is preserve their message filters. The cyrus filters we have in place use Sieve-style syntax, so we don't have to convert one kind of filter syntax to another; I'm just having trouble getting the procedure outlined above to work properly.

I have a script that parses the server-side filter script for a particular user and appends the filters to a file intended to be piped to zmprov. The format of this file is as follows (for an example user jdoe):

ma jdoe zimbraMailSieveScript '\
require ["imapflags", "fileinto"];\
# backups no news is good news\
if allof ( header :comparator "i;ascii-casemap" :contains "List-Id" "backup-reports.lists.example.domain",
 header :comparator "i;octet" :matches "Subject" "*SUCCEEDED", address :all :comparator "i;ascii-casemap
" :contains "From" "root@example.domain", header :comparator "i;ascii-casemap" :matches "Subject" "[backup
-reports]*" ) { \
    discard;\
} \
# Test Filter\
if allof ( header :comparator "i;ascii-casemap" :contains "Subject" "testing", address :all :comparator 
"i;ascii-casemap" :contains "From" "jdoe" ) { \
    addflag "\\Flagged";\
    fileinto "testing";\
    removeflag "\\Flagged";\
    stop;\
} \
'

When I pipe this into zmprov, I get no errors, but the zimbraMailSieveScript attribute looks wrong, and the filters for the user I populated do not appear in the web interface as expected. Here's what 'zmprov ga jdoe' shows for the zimbraMailSieveScript attribute:

zimbraMailSieveScript: require ["imapflags", "fileinto"];# backups no news is good newsif allof ( header :comparator "i;ascii-casemap" :contains "List-Id" "backup-reports.lists.example.domain", header :comparator "i;octet" :matches "Subject" "*SUCCEEDED", address :all :comparator "i;ascii-casemap" :contains "From" "root@example.domain", header :comparator "i;ascii-casemap" :matches "Subject" "[backup-reports]*" ) {     discard;} # Test Filterif allof ( header :comparator "i;ascii-casemap" :contains "Subject" "testing", address :all :comparator "i;ascii-casemap" :contains "From" "jdoe" ) {     addflag "\Flagged";    fileinto "testing";    removeflag "\Flagged";    stop;}

It looks like newlines aren't being preserved, but I'm not sure what's wrong with the format of the file I'm piping to zmprov. Can anyone help me out?

Thanks,

~Dave Flynn

[dlbewley]

What ver of Zimbra? I did all the above on 4.5.3 or maybe 4.5.4.

Your output from zmprov ga should definitely have newlines in the zimbraMailSieveScript attribute. You sure you don't have spaces at the end of those lines? Have DOS line endings perhaps?

Try making a simple test filter like mine above and see if that works.

[Daimyo]

Thanks for the quick reply. I created a new file and copied exactly your example filter above. This file looks like the following:

ma dflynn zimbraMailSieveScript '\
require ["fileinto", "reject", "tag", "flag"];\
# Helpdesk Tickets\
if anyof (header :contains "subject" "[Lib Help #" )\
{\
    tag "Tickets";\
    flag "flagged";\
    stop;\
}\
'

I then run the following command as user Zimbra:

cat zmprov.script | zmprov

And then

zmprov ga dflynn

Which gives me the following:

zimbraMailSieveScript: require ["fileinto", "reject", "tag", "flag"];# Helpdesk Ticketsif anyof (header :contains "subject" "[Lib Help #" ){    tag "Tickets";    flag "flagged";    stop;}

Somewhere, the newlines are getting truncated. They've gotta be present in the original file, but they aren't showing up in the LDAP attribute, and it's not clear why. To make things more fun, I'm now getting errors from the web interface for this account when I attempt to create a filter manually:

There was a problem parsing your filter rules: invalid request: missing required attribute: name

(of course, I did put in a name for the filter I was trying to create)

tail -f /opt/zimbra/log/mailbox.log shows the following information:

2007-07-10 13:48:30,529 INFO [http-443-Processor99] [name=dflynn@example.domain;ip=*.*.*.*;ua=ZimbraWeb Client - FF2.0 (Win)/4.5.6_GA_1023.RHEL4_64;] SoapEngine - handler exception
com.zimbra.common.service.ServiceException: invalid request: missing required attribute: name
at com.zimbra.common.service.ServiceException.INVALID _REQUEST(ServiceException.java:182)
at com.zimbra.soap.Element.checkNull(Element.java:179 )
at com.zimbra.soap.Element.getAttribute(Element.java: 158)
at com.zimbra.cs.filter.RuleRewriter.condition(RuleRe writer.java:306)
at com.zimbra.cs.filter.RuleRewriter.condition(RuleRe writer.java:297)
at com.zimbra.cs.filter.RuleRewriter.traverse(RuleRew riter.java:273)
at com.zimbra.cs.filter.RuleRewriter.getScript(RuleRe writer.java:252)
at com.zimbra.cs.filter.RuleManager.setXMLRules(RuleM anager.java:145)
at com.zimbra.cs.service.mail.SaveRules.handle(SaveRu les.java:55)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEng ine.java:270)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:168)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:90)
at com.zimbra.soap.SoapServlet.doPost(SoapServlet.jav a:223)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:709)
at com.zimbra.cs.servlet.ZimbraServlet.service(Zimbra Servlet.java:162)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:802)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:107)
at org.apache.catalina.valves.AccessLogValve.invoke(A ccessLogValve.java:541)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11 ConnectionHandler.processConnection(Http11BaseProt ocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.process Socket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThr ead.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlR unnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

So what it comes down to is that there's something wacky going on in the 'zmprov ma zimbraMailSieveScript' command, and it's managed to mess up something about the account associated with the operations. The server version is 4.5.6 - any ideas?