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: testuser@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 "ldap@mailResponderText"; }

# traditional "vacation" mode, say reply once every 30d if ldap "mailResponderMode" "vacation" { vacation :days 30 "ldap@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 "ldap@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_foster@pacific.net.au martin.foster@pacnet.com