Re: Storing filters in LDAP

[Randall Gellens <[e-mail]>]

At 9:26 PM -0400 7/2/99, Lawrence Greenfield wrote:

>I agree with Randy that ACAP is the best place to store sieve
>scripts.  We could define a small subset that an ACAP server must
>support to handle Sieve scripts which should be straightforward to
>implement and place no large resource requirements on servers.
>
>Locating the ACAP server would be interesting.  I would suggest
>connecting to the ACAP port on the same host as the IMAP server, but
>paying attention to referral.  (This complicates the client
>implementation somewhat, but is probably worth it.)

I suggest we use a different port, since the server may support a 
subset of ACAP.

We probably need a new email accounts dataset attribute, 
email.sieve.script.url, and should probably rename the 
email.sieve.script to email.sieve.script.text.  Then, if there is a 
general ACAP server available, the client can connect to it and 
examine the email.sieve.script.url attribute of the email accounts 
dataset.

If both are null and the client wants to store a Sieve script, the 
capabilities dataset should be queried to determine if this server 
supports Sieve.  If not, I suppose the client should try the ACAP 
Sieve profile port on the mail server.  It should then store into 
either email.sieve.script.text or into email.sieve.script.url on the 
ACAP server and into email.sieve.script.text on the mail server.

If there is no general ACAP server available, then the ACAP Sieve 
profile port of the mail server should be tried.

>I could probably produce a draft of such functionality (and perhaps a
>prototype server) if people desire.

I was going to write a draft for the ACAP Sieve profile, I'd be happy 
to either let you do it or to coauthor it with you.

I think a prototype server would be useful.  We do have some code 
we've been playing with which we were considering for inclusion in 
qpopper 3.1, if it gets finished in time.  The more the merrier.