I posted a patch a few weeks ago that allows you to do this Search
the archives...
It is fast enough for my very low volume server ;-).
On Tue, 2001-12-11 at 01:09, Jeremy Howard wrote:
> I'd love to set some site-wide policies using a Sieve script. Is it possible
> to create a Sieve script
I'm probably not the most qualified person to talk about this ... but...
Duplicate elimnation is not a runtime or build option. It is only
disabled in the event of some strange failure in the initialisation of
the database (no permissions on the /var/imap/deliverdb directory or
similar).
If you
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 *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, 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, 2001-11-09 at 06:15, Amos Gouaux wrote:
> What about all the stats looking for the script? Could that be a
> problem? If so, could a db be used as a Sieve script index, like
> the mailboxes.db?
>
That would be a possible optimisation. Currently, the is one fopen call
for every deliver
> 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
This follows on from my previous email, where I presented a method of
enabling sieving on mail delivered directly to shared/public folders.
While that does all the I need it to do, my implementation only allowed
a single active script for all public folders. This is a serious
limitation if you wa
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?
>
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"
> 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]
Hurray! I've now got sieving on my public folders... It was a little bit
trickier than I thought - but not too bad. I want to test things a bit
more thoroughly and think about the issues a bit first...
Basically, I using a 'security context' of "anyone" for the filtering...
I'm also working on th
On Mon, 2001-11-05 at 16:02, Ken Murchison wrote:
>
>
>
> I don't really remember where we left off. I *think* that Ian's idea is
> what we were talking about -- checking sieveusehomedir==false and if
> postuser!="" using postuser as the owner of the script.
>
Or maybe having a "sievesharedf
I have quite a large number of shared/public folders to which mail is
sent/posted directly using the [EMAIL PROTECTED] convention.
I want to sieve mail sent to these folders (to remove spam and other
nasties).
Currently (2.0.16 and CVS HEAD) only mail sent to a user's folders is
sieved.
The re
18 matches
Mail list logo
