Re: Sieving mail sent to shared/public folders
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
Re: Sieving mail sent to shared/public folders
On 05 Nov 2001 14:39:44 +, Ian Castle [EMAIL PROTECTED] (ic) writes: ic I have quite a large number of shared/public folders to which mail is ic sent/posted directly using the [EMAIL PROTECTED] convention. ic I want to sieve mail sent to these folders (to remove spam and other ic nasties). ic Currently (2.0.16 and CVS HEAD) only mail sent to a user's folders is ic sieved. ic The relevant file is imap/lmtpd.c, in the function deliver(). What I'm ic thinking of doing is modifying this function, so that in the case of a ic post to a public folder it will find the script for the pseudo user bb ic (or rather the value of the BB string) (sieveusehomddir is false). ic My plan is to add the code to sieve the email for case 1 shared mailbox ic resource in the source. From my cursory look at the source, I can't see ic any obvious issues with doing this (thinking about security - ic mydata.authuser, mydata.authstate etc). ic However, before embarking on this, I was wondering if any one more ic knowledgeable than me had any comments about this (it seems like a ic fairly obvious thing to want to do - so I suspect that there are some ic gotchas that are not obvious to me - or it has already been done). Ken and I kicked around this issue not too long ago. We've got a ton of non-users folders as well and were wondering if Sieve might be usable for these. Though, we're using the altnamespace so no longer using bb. prefix. Yet another wrinkle? I forget where we ended up with this. Ken? -- Amos
Re: Sieving mail sent to shared/public folders
On Mon, 05 Nov 2001 11:02:59 -0500, Ken Murchison [EMAIL PROTECTED] (km) writes: km I don't really remember where we left off. I *think* that Ian's idea is km what we were talking about -- checking sieveusehomedir==false and if km postuser!= using postuser as the owner of the script. When again is postuser==? Would this be the case if lmtpd -a is used? -- Amos
Re: Sieving mail sent to shared/public folders
Amos Gouaux wrote: On Mon, 05 Nov 2001 11:02:59 -0500, Ken Murchison [EMAIL PROTECTED] (km) writes: km I don't really remember where we left off. I *think* that Ian's idea is km what we were talking about -- checking sieveusehomedir==false and if km postuser!= using postuser as the owner of the script. When again is postuser==? It's the default value unless specified otherwise in imapd.conf(5). It's whatever the admin decides to use for the left-hand side of plus addressing to public folders. Would this be the case if lmtpd -a is used? No, that's an authentication issue. When you use lmtpd over a UNIX socket or use lmtpd -a, the client is automatically authenticated as the postman user. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Sieving mail sent to shared/public folders
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 sievesharedfoldersscriptdir=/something to specify the location of the script. Anyway, I'll test it out using postuser
Re: Sieving mail sent to shared/public folders
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
