I am looking at porting and generalizing an old in-house patch that I'm
using for the CMU Sieve plugin. It allows sieve script to test & lookup
arguments from LDAP.
Before getting too involved in this, I'd like to discuss my goals here
in the hopes that someone else also thinks this would be useful. Many
heads may make better design?
Goal:
------
Allows scripts which are still stored on the filesystem to lookup
parameters stored in an LDAP directory.
Useful if you provide a global sieve script to implement functions such
as "vacation", forwarding to small groups (not a MLM), wish to toggle
whether a message is kept in the mailbox after being forwarded, etc.
<example>
# determine if we always auto-respond, or if we respond with a more
vacation-ish setting of every 30d
#
# sample LDAP entry:
# uid: testu...@domain.com
# mailResponderMode: vacation
# mailResponderText: "I'm on vacation, far far from the Internet"
(base64 encoded string...)
# "always" reply mode, sanitized to once a day
if ldap "mailResponderMode" "reply" {
vacation :days 1 "l...@mailrespondertext";
}
# traditional "vacation" mode, say reply once every 30d
if ldap "mailResponderMode" "vacation" {
vacation :days 30 "l...@mailrespondertext";
}
</example>
This introduces:
1. a new command "ldap", to lookup attributes and their values in an
LDAP directory using the user's context
2. an extention to the vacation command that looks up the vacation
reply text that is triggered by supplying "l...@ldapattribute" as
the text.
3. other actions not shown above which extends redirect and a few
other commands to lookup data from LDAP
Related work:
1. Pigeonhole low priority TODO would like to implement alternate
script storage, eg: LDAP & SQL. I'm not immediately interested in
alternate types of script storage, but for what I want to acheive,
I need to sanely access at least an LDAP directory.
2. draft-ietf-sieve-external-lists
(http://tools.ietf.org/html/draft-ietf-sieve-external-lists-01)
proposes a mechanism to pull mailing list addresses from external
storage mechanisms such as LDAP, ACAP or relational databases.
I'm interested in this, but would like to extend this
functionality beyond just lists as the example above demonstrates.
3. there are security and resource consumption issues with doing
this, suggesting that limits should be set, or the use may have to
be restricted to global scripts eg: sieve_before or sieve_after
The question:
- do others on this list see value in the functionality described above?
If there's some consensus that this would be useful, I'll flesh out howI
think a generalized version of this old patch may behave, then (!) work
on an implementation as a plugin to dovecot's sieve.
cheers,
-Martin Foster
martin_fos...@pacific.net.au
martin.fos...@pacnet.com
