Here is the 21.K patch.
Apologies if this makes for an unacceptably large email.
- It adds a new command folder which takes a folder as a parameter to
timsieved which allows a script to be associated with any folder or
heirarchy of folders in the imap store.
- It alters lmtpd to pick the
From: Lawrence Greenfield [mailto:[EMAIL PROTECTED]]
I think that you addressed my concerns in your second proposal. I'm
not sure I love the idea of the folder command in timsieved, but
I'll have to contemplate.
I think there's also a question about whether at most one sieve script
--On Friday, November 09, 2001 08:10:35 + Ian Castle
[EMAIL PROTECTED] wrote:
So rather than thinking that this script applies to this user I am
suggesting that we think this script applies to this folder. Obviously,
if the folder is user.fred then the statements are synonymous. However,
On Fri, 9 Nov 2001 08:10:35 -,
Ian Castle [EMAIL PROTECTED] (ic) writes:
ic Well, the mechanism/interface is there. Allow activate to apply to more
ic than one script.
ic One way would be to have a subdirectory called default with symlinks to
ic all the active scripts in the directory.
OK, here is the code I knocked up yesterday which implements the
scripts use the same namespace as folders concept. i.e. allows a
script to be set on a per folder basis, rather then a per user basis.
Note that there is a bit of functionality missing from what I described
yesterday - esp. in
On 09 Nov 2001 16:48:43 +,
Ian Castle [EMAIL PROTECTED] (ic) writes:
ic ... An alternative approach might be to implement the redirect feature
ic in sieve. So that 'fileinto some.folder' wouldn't do any extra
It's already there. See RFC3028:
4.3. Action redirect
Syntax:
It seems to me that this could be far more easily done by creating a pseudo-
user. Have this user be the target of the alias and his sieve script will
be run. That sieve script can have nothing but fileinto directives to
populate the public folders. This pseudo-user does not even have to have an
On Fri, 9 Nov 2001 09:35:29 -0800 (PST),
Nick Sayer [EMAIL PROTECTED] (ns) writes:
ns It seems to me that this could be far more easily done by creating a pseudo-
ns user. Have this user be the target of the alias and his sieve script will
ns be run. That sieve script can have nothing but
That was how my inital implementation worked. In this case the pseudo
user was anyone.
It is working quite nicely for me.
The big problem is that you can only have one script for the entire set
of public folders.
On Fri, 2001-11-09 at 17:35, Nick Sayer wrote:
It seems to me that this could
I *was* referring to the action redirect in sieve... for some reason I
thought it was an extension that hadn't been implemented in cyrus
But sure enough it exists in CVS and 2.0.16. Strange. I must have made a
mistake somewhere in one of my scripts...
This is what I got after trying to use
I think trying to patch in little solutions to how sieve currently works
are going to meet with problems that the current model wasn't designed with
this kind of broad functionality in mind. Going to a slightly different
model would not only solve this problem, but others as well.
Here's
On Thu, 2001-11-08 at 06:44, Ian Castle wrote:
And I have a question - why is the existing name space magic cluttered
up with the hash on the user name? Not saying it is unneeded - but if it
is needed, then why isn't a similar hash needed in the folder directory?
Sorry, I was being
From: Ian Castle [EMAIL PROTECTED]
Date: 08 Nov 2001 06:44:20 +
On Wed, 2001-11-07 at 22:22, Lawrence Greenfield wrote:
The other thing to consider is how to keep the Cyrus black-box
approach. Non-administrators should be able to modify these Sieve
scripts and name them
Introduction
The following is an implementation of the facility to allow mail
delivered directly to a shared/public folder to be filtered with sieve.
For example, you might have a shared folder public.interestingmessages
and deliver mail to it using an address of
[EMAIL PROTECTED].
The other thing to consider is how to keep the Cyrus black-box
approach. Non-administrators should be able to modify these Sieve
scripts and name them appropriately.
Magic directories just don't cut it.
Larry
On Wed, 7 Nov 2001 17:22:08 -0500,
Lawrence Greenfield [EMAIL PROTECTED] (lg) writes:
lg The other thing to consider is how to keep the Cyrus black-box
lg approach. Non-administrators should be able to modify these Sieve
lg scripts and name them appropriately.
lg Magic directories just don't
On Wed, 2001-11-07 at 22:22, Lawrence Greenfield wrote:
The other thing to consider is how to keep the Cyrus black-box
approach. Non-administrators should be able to modify these Sieve
scripts and name them appropriately.
I'm not sure I understand what you mean. By non-administrators do
17 matches
Mail list logo