Subject: Re: Storing filters in LDAP

From: Randall Gellens <[email-masked]>
Date: Fri, 2 Jul 1999 17:33:16 -0700

I think we'll see UIs that expose a subset of Sieve functionality to 
users, very much like today's mail client filter UIs.  The UI itself 
will generate and interpret Sieve syntax (and will probably punt on 
interpreting complex Sieve scripts and present an edit box).

How the UI accesses the Sieve script is n interesting question.  My 
Email Accounts draft (draft-ietf-acap-email-02.txt) suggests using an 
ACAP dataset for email account information.

We have prototype code that includes an NT GUI for Sieve creation and 
editing, a mini-ACAP server for accessing the Sieve script, and a 
Sieve execution engine.  The actual Sieve script is stored in a file, 
but this is invisible except to the mini-ACAP server and the Sieve 
execution engine.

I can also see people implementing various other access methods 
including email and HTTP.

I think ACAP is attractive because it allows the client to get 
extension information and syntax errors and the syntax is very easy 
on both the client and the server, and there is no need for a full 
ACAP server -- the mini-server (just for Sieve) works well.

---

From: Lawrence Greenfield <[email-masked]>
Date: 2 Jul 1999 21:26:21 -0400

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 could probably produce a draft of such functionality (and perhaps a
prototype server) if people desire.

Larry

---

From: Randall Gellens <[email-masked]>
Date: Tue, 6 Jul 1999 17:25:46 -0700

>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.

>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.