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 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 delivery.
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
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
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 the
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].
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
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
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
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
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
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
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
14 matches
Mail list logo
