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 2.0.16 source base - rather than the CVS head - so it was fairly easy to spot the hardcoded references to "INBOX". I've gone off the idea of using "postuser" as a kind of pseudo user - I think using "anyone" makes more sense from the security point of view - I don't really want to have to set up ACLs for the pseudo user. So, I'm think of having a config variable of something like "sievesystemscripts" to point to the directory containing the public folder scripts. Anyway, people are already pleased with the results - we have one published email address to which an (increasing) number of automatic functions send reports (health monitoring of our customers systems mainly) - unfortunately, it was getting hard to see the wood for the trees. Now I am able to organise the mail into more sensible folders (by customer, function) - which is nicer than having to make and configure a load of new email addresses... It isn't too scary modifying the code on our production server, because in the event of a sieve failure, it simply falls back to the default delivery method - and all the code in cyrus seems pretty robust and straightforward (props. to the developers!). Lawrence Greenfield wrote: > > Date: Mon, 05 Nov 2001 11:02:59 -0500 > From: Ken Murchison <[EMAIL PROTECTED]> > > 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. > > I think this is very reasonable. I have a twitch reaction to it since > CMU's old mail system (AMS) did all bboards with "Flames", the > equivalent of Sieve, and the "bb" user was just an ordinary user. > This turns out to be somewhat painful, but I can imagine situation > where it's more reasonable. > > I think the other trickier is to make sure that nothing breaks because > "bb" doesn't have an INBOX, and making sure that the authz questions > all work out. > > Larry
