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 ap
On Sat, 2001-11-10 at 00:36, Nick Sayer wrote:
>
> > The big problem is that you can only have one script for the entire set
> > of public folders.
> >
>
> Unless you create multiple such users.
>
>
>
I'm sure that will work... but I think a more natural fit is "scripts go
with folders" - be
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 what
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
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
> 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 no
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
I
> 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
Ian Castle wrote:
>
> On Fri, 2001-11-09 at 14:52, Dave McCracken wrote:
> >
> > I have a question, though. If a sieve script does a 'fileinto' to redirect
> > mail to another folder, does the sieve script for that folder get run?
> > Intuitively I think it should, but what are the implication
On Fri, 2001-11-09 at 14:52, Dave McCracken wrote:
>
> I have a question, though. If a sieve script does a 'fileinto' to redirect
> mail to another folder, does the sieve script for that folder get run?
> Intuitively I think it should, but what are the implications?
Interesting. That would prob
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 tim
> 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 i
--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
> 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 scri
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
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 ig
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"
> 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 directo
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 21:12:48 -,
> Ian Castle <[EMAIL PROTECTED]> (ic) writes:
ic> Oh dear. I can see a whole new imap function coming on - ". SIEVE folder
ic> script"...
Actually, in one of my more perverse moments I actually wondered
about storing the sieve scripts in the same dire
> So maybe for a post to "[EMAIL PROTECTED]",
> the script would be in /var/lib/sieve/system/public/interestingmessages/ ?
> Or would this be tooo bizarre?
>
> I'd love to have the ability of running Sieve for some of our shared
> folders, but must admit to being a tad concerned about running *al
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]
22 matches
Mail list logo
