[Dovecot] Sieve > Pigeonhole > external storage with LDAP or other data source available to dovecot

Martin F. Foster martin_foster at pacific.net.au
Tue Jan 5 10:02:56 EET 2010


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 at 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 at mailResponderText";
}

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





More information about the dovecot mailing list