Re: [Dovecot] Sieve > Pigeonhole > external storage with LDAP or other data source available to dovecot
Le 09-Jan-10 20:29, Stephan Bosch a écrit :
I thought this would be an excellent opportunity to test the new Pigeonhole plugin support and also to do something interesting with the namespace functionality of the variables extension. That is why I gave this a short look, which promptly resulted in a preliminary implementation.
If you want to play around with it, you can download it from:
http://hg.rename-it.nl/pigeonhole-sieve-extdata/
It will compile and run with both Pigeonhole for Dovecot v1.2 and Pigeonhole for Dovecot v2.0, but only with the tip Mercurial revisions (since only those have plugin support).
Thanks Stephan,
I have the extdata plugin compiled, and am now trying to make a global sieve script to test it. I'm running into problems when using sievec to compile the script - I'm not getting the plugin's variables that are provided in dovecot.conf's plugin {}. I added a few sieve_sys_warning messages to track the calls to sieve_setting_get()
<output> /usr/local/bin/sievec -d -P sieve_extdata /usr/local/etc/dovecot/sieve/before.sv Warning: sieve: sieve_setting_get: req: 'sieve_max_script_size' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_max_actions' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_max_redirects' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_subaddress_sep' res: '(null)' Warning: sieve: sieve_setting_get: req: 'recipient_delimiter' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_plugin_dir' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_plugins' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_extdata_dict_uri' res: '(null)' Warning: sieve: extdata: no dict uri specified, extension is unconfigured (sieve_extdata_dict_uri is not set).
Required extensions:
0: vacation (9) 1: variables (17) 2: vnd.dovecot.extdata (29)
Main program (block: 1):
00000000: EXTENSIONS [3]: 00000001: vacation 00000002: variables 00000003: SCOPE [0] (end: 00000008) 00000008: vnd.dovecot.extdata 00000009: VACATION 0000000a: (source line: 3) 0000000d: subject: VAR ${extdata.vacation_subject} 00000023: reason: VAR ${extdata.vacation_message} 00000038: handle: STR[77] "${extdata.vacation_message}${extdata.vacation_subject}<default-from><NO-MIME>" 00000088: [End of code] </output>
I'm new to dovecot's internals, it looks like it just needs some environment variables provided, but I'm puzzled as to how this is to be done. I've traced it through sievec.c -> sieve_tool_sieve_env -> sieve_tool_get_setting -> getenv() call.
More info:
- I've traced the process, there's no attempt to open or stat any dovecot.conf
- using tip dovecot-1.2, dovecot-1.2-sieve, pigeonhole-sieve-extdata.
I pulled+updated & rebuilt and confirmed the above behaviour just prior to sending this message. - The test scripts run because the test framework uses the test_config mechanism to provide sieve_extdata_dict_uri.
Any hints on how to get the dovecot.conf data to sievec?
Thanks,
-Martin Foster
Martin F. Foster wrote:
I'm new to dovecot's internals, it looks like it just needs some environment variables provided, but I'm puzzled as to how this is to be done. I've traced it through sievec.c -> sieve_tool_sieve_env -> sieve_tool_get_setting -> getenv() call.
Hmm, yeah, this is still somewhat stupid. Sievec does not use the global Dovecot config directly, which is something that can be solved for v2.0. Thus far this was no problem as the Sieve engine had no interesting settings to configure for command line use, but now apparently it does :)
More info:
- I've traced the process, there's no attempt to open or stat any dovecot.conf
- using tip dovecot-1.2, dovecot-1.2-sieve, pigeonhole-sieve-extdata.
I pulled+updated & rebuilt and confirmed the above behaviour just prior to sending this message.- The test scripts run because the test framework uses the test_config mechanism to provide sieve_extdata_dict_uri.
Any hints on how to get the dovecot.conf data to sievec?
Manual:
bash$ export SIEVE_EXTDATA_DICT_URI=file:/etc/dovecot/frop.dict bash$ /usr/local/bin/sievec -d -P sieve_extdata frop.sieve
Using dovecot.conf:
/usr/sbin/dovecot --exec-mail ext /usr/bin/sievec frop.sieve
Regards,
Stephan
oh wow - ignore my last message about sievec & environment. As the output says, it's just a warning... it is not blocking the compilation of the sieve script as I originally thought.
moving on: The compiled script is now being used as a sieve_before entry. The LDA is erroring on the result, something that I'll continue to investigate. The "failed to open" message below isn't correct - a trace shows the compiled .sieve being opened and read by the process; but I get that there is an error in interpreting & using the compiled script. The extdata .dict file is not opened by the deliver process.
I'm going to continue investigating. some info below if anyone's interested:
<script> require ["vacation", "variables", "vnd.dovecot.extdata"]; vacation :subject "${extdata.vacation_subject}" "${extdata.vacation_message}"; </script>
<compile script> # /usr/local/bin/sievec -P sieve_extdata /usr/local/etc/dovecot/sieve/before.sv /usr/local/etc/dovecot/sieve/before.sieve Warning: sieve: extdata: no dict uri specified, extension is unconfigured (sieve_extdata_dict_uri is not set).
# echo $? 0
<logs> 2010-01-12T08:41:08.005962+00:00 node001 dovecot: auth(default): ldap(test@domain1.test): user search: base=o=services scope=subtree filter=(uid=test@domain1.test) fields=homeDirectory,mailStoreDirectory,mailQuota 2010-01-12T08:41:08.006457+00:00 node001 dovecot: auth(default): ldap(test@domain1.test): result: homeDirectory(home)=/services/vmail/home/1000000 mailQuota(quota_rule)=maildir:storage=5M mailStoreDirectory(mail)=maildir:/services/vmail/mail/1000000/ 2010-01-12T08:41:08.006477+00:00 node001 dovecot: auth(default): master out: USER#0111#011test@domain1.test#011home=/services/vmail/home/1000000#011quota_rule=maildir:storage=5M#011mail=maildir:/services/vmail/mail/1000000/ 2010-01-12T08:41:08.012161+00:00 node001 dovecot: deliver(test@domain1.test): sieve: before: line 1: unexpected character(s) starting with 0xbe 2010-01-12T08:41:08.012556+00:00 node001 dovecot: deliver(test@domain1.test): sieve: before: line 1: unexpected unknown characters found at (the presumed) end of file 2010-01-12T08:41:08.012987+00:00 node001 dovecot: deliver(test@domain1.test): sieve: before: parse failed 2010-01-12T08:41:08.013380+00:00 node001 dovecot: deliver(test@domain1.test): sieve: failed to open script /usr/local/etc/dovecot/sieve/before.sieve 2010-01-12T08:41:08.860595+00:00 node001 dovecot: deliver(test@domain1.test): msgid=<20100112084107.2E72A27713@node001.netlog.net>: saved mail to INBOX </logs>
<dovecot config> plugin: sieve_plugin_dir: /usr/local/lib/dovecot/sieve sieve_plugins: sieve_extdata sieve_extdata_dict_uri: file:/usr/local/etc/dovecot/extdata.dict sieve_before: /usr/local/etc/dovecot/sieve/before.sieve quota: maildir sieve: ~/.dovecot.sieve sieve_dir: ~/sieve
$ cat /usr/local/etc/dovecot/extdata.dict priv/vacation_subject I am the subject. priv/vacation_message I ame the message. </config>
Cheers,
-Martin Foster
Le 12-Jan-10 16:25, Martin F. Foster a écrit :
I have the extdata plugin compiled, and am now trying to make a global sieve script to test it. I'm running into problems when using sievec to compile the script - I'm not getting the plugin's variables that are provided in dovecot.conf's plugin {}. I added a few sieve_sys_warning messages to track the calls to sieve_setting_get()
<output> /usr/local/bin/sievec -d -P sieve_extdata /usr/local/etc/dovecot/sieve/before.sv Warning: sieve: sieve_setting_get: req: 'sieve_max_script_size' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_max_actions' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_max_redirects' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_subaddress_sep' res: '(null)' Warning: sieve: sieve_setting_get: req: 'recipient_delimiter' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_plugin_dir' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_plugins' res: '(null)' Warning: sieve: sieve_setting_get: req: 'sieve_extdata_dict_uri' res: '(null)' Warning: sieve: extdata: no dict uri specified, extension is unconfigured (sieve_extdata_dict_uri is not set).
Required extensions:
0: vacation (9) 1: variables (17) 2: vnd.dovecot.extdata (29)
Main program (block: 1):
00000000: EXTENSIONS [3]: 00000001: vacation 00000002: variables 00000003: SCOPE [0] (end: 00000008) 00000008: vnd.dovecot.extdata 00000009: VACATION 0000000a: (source line: 3) 0000000d: subject: VAR ${extdata.vacation_subject} 00000023: reason: VAR ${extdata.vacation_message} 00000038: handle: STR[77] "${extdata.vacation_message}${extdata.vacation_subject}<default-from><NO-MIME>"
00000088: [End of code] </output>
I'm new to dovecot's internals, it looks like it just needs some environment variables provided, but I'm puzzled as to how this is to be done. I've traced it through sievec.c -> sieve_tool_sieve_env -> sieve_tool_get_setting -> getenv() call.
More info: pigeonhole-sieve-extdata. I pulled+updated & rebuilt and confirmed
- I've traced the process, there's no attempt to open or stat any dovecot.conf
- using tip dovecot-1.2, dovecot-1.2-sieve,
the above behaviour just prior to sending this message. 3. The test scripts run because the test framework uses the test_config mechanism to provide sieve_extdata_dict_uri.
Any hints on how to get the dovecot.conf data to sievec?
Thanks,
-Martin Foster
Martin F. Foster wrote:
oh wow - ignore my last message about sievec & environment. As the output says, it's just a warning... it is not blocking the compilation of the sieve script as I originally thought.
<compile script> # /usr/local/bin/sievec -P sieve_extdata /usr/local/etc/dovecot/sieve/before.sv /usr/local/etc/dovecot/sieve/before.sieve Warning: sieve: extdata: no dict uri specified, extension is unconfigured (sieve_extdata_dict_uri is not set).
# echo $? 0
This will compile the before.sv into a binary before.sieve, which is wrong. First of all, Pigeonhole expects scripts to have the .sieve extension. Second, binaries are expected to have the .svbin extension. The errors you get are caused by the deliver plugin's attempts at compiling a binary (since the .sieve is the binary and a .svbin file does not exist) :)
Regards,
Stephan.
participants (2)
-
Martin F. Foster
-
Stephan Bosch