Re: RFC: Sieving mail delivered directly to shared/public folders
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 appropriate sieve script for the folder
being delivered to - i.e. the folder described by the left hand side of
the email address.
The patch is against current CVS (well, CVS of Thursday). It is made
from "cvs diff -u /" - i.e. from the "cyrus-imapd" directory.
It is very much a proof of concept. It compiles and does something ;-) -
but I wouldn't rely on it to do any more than that.
Regards,
Ian
Index: imap/lmtpd.c
===
RCS file: /cvs/src/cyrus/imap/lmtpd.c,v
retrieving revision 1.75
diff -u -r1.75 lmtpd.c
--- lmtpd.c 2001/10/02 21:08:10 1.75
+++ lmtpd.c 2001/11/08 18:29:38
@@ -734,8 +734,14 @@
int ret = 1;
if (sd->mailboxname) {
- strcpy(namebuf, lmtpd_namespace.prefix[NAMESPACE_INBOX]);
- strcat(namebuf, sd->mailboxname);
+/* Sieving a public or user folder ? */
+if ( strcmp( sd->username, "anyone" ) ) {
+ strcpy(namebuf, lmtpd_namespace.prefix[NAMESPACE_INBOX]);
+ strcat(namebuf, sd->mailboxname);
+}
+else {
+strcpy(namebuf, sd->mailboxname);
+}
ret = deliver_mailbox(md->data, &mydata->stage, md->size,
kc->imapflags->flag, kc->imapflags->nflags,
@@ -748,7 +754,13 @@
if (!sd->authstate)
return SIEVE_FAIL;
- strcpy(namebuf, "INBOX");
+ /* sieving a public or user folder ? */
+if ( strcmp( sd->username, "anyone" ) ) {
+ strcpy(namebuf, "INBOX");
+}
+else {
+strcpy( namebuf, sd->mailboxname );
+}
ret = deliver_mailbox(md->data, &mydata->stage, md->size,
kc->imapflags->flag, kc->imapflags->nflags,
@@ -1018,10 +1030,30 @@
}
}
+static int mailbox_parent( char *mailboxname )
+{
+char *p;
+int r = 1;
+p = strrchr ( mailboxname, '.' );
+if ( p ) {
+ *p = '\0';
+ r = 0;
+}
+return r;
+}
+
+
/* returns true if user has a sieve file */
-static FILE *sieve_find_script(const char *user)
+static FILE *sieve_find_script(const char *user, char *mailboxname)
{
char buf[1024];
+char namebuf[MAX_MAILBOX_NAME];
+char namebuf2[MAX_MAILBOX_NAME];
+char script_path[MAX_MAILBOX_PATH];
+const char *sievesystemscripts = config_getstring( "sievedir", "/usr/sieve" );
+int r;
+char *path, *acl;
+FILE *sfp;
if (strlen(user) > 900) {
return NULL;
@@ -1031,28 +1063,83 @@
/* duplicate delivery suppression is needed for sieve */
return NULL;
}
-
-if (sieve_usehomedir) { /* look in homedir */
- struct passwd *pent = getpwnam(user);
- if (pent == NULL) {
- return NULL;
+if ( strcmp( user, "anyone" ) ) {
+if ( mailboxname ) {
+ strcpy(namebuf, lmtpd_namespace.prefix[NAMESPACE_INBOX]);
+ strcat(namebuf, mailboxname);
}
+ else {
+ strcpy( namebuf, "INBOX" );
+}
+
+}
+else {
+strcpy(namebuf, lmtpd_namespace.prefix[NAMESPACE_SHARED]);
+strcat(namebuf, mailboxname);
+}
+
+mboxname_hiersep_toexternal(&lmtpd_namespace, namebuf);
+
+r = (*lmtpd_namespace.mboxname_tointernal)(&lmtpd_namespace, namebuf,
+ user, namebuf2);
+
+if ( mboxlist_lookup( namebuf2, &path, &acl, NULL ) == 0 ) {
+ syslog( LOG_INFO, "1 The folder exists" );
+
+mailbox_hash_mbox( script_path, sievesystemscripts, namebuf2 );
+
+ syslog( LOG_INFO, "4 script is %s", script_path );
+}
+else {
+return NULL;
+}
+
+snprintf(buf, sizeof(buf), "%s/default", script_path );
+
+r = 0;
+while (!r && ( syslog(LOG_INFO, "5 file is %s", buf ), sfp = fopen(buf, "r")) ==
+NULL) {
+ r = mailbox_parent( namebuf2 );
+ mailbox_hash_mbox( script_path, sievesystemscripts, namebuf2 );
+ snprintf(buf, sizeof(buf), "%s/default", script_path );
+}
+
+return sfp;
- /* check ~USERNAME/.sieve */
- snprintf(buf, sizeof(buf), "%s/%s", pent->pw_dir, ".sieve");
-} else { /* look in sieve_dir */
- char hash;
+#if 0
+if ( !strcmp( user, "anyone" ) ) {
+const char *sievesystemscripts = config_getstring( "sievedir", "/usr/sieve" );
- hash = (char) dir_hash_c(user);
+if ( sievesystemscripts == (const char *) 0 ) {
+return NULL; /* Must have a script dir for this to work */
+}
- snprintf(buf, sizeof(buf), "%s/%c/%s/default", sieve_dir, hash, user);
+snprintf(buf, sizeof(buf), "%s/default", sie
Re: RFC: Sieving mail delivered directly to shared/public folders
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" - because it is the mail being sieved - not the user. Think this way - Currently a folder has a set of ACLs - if you like, some properties that belong to the folder. By binding a sieve script to the folder we are extending the set of "properties" to also include a set of "methods". Only at the time when an action is to be taken, is the user taking that action tested against the folder - to see if the action that they want to take is allowable within the context of the security framework.
Re: RFC: Sieving mail delivered directly to shared/public folders
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 would propose: --* In addition to the user sieve directories, add an additional directory tree for system scripts. However, rather than make the directory structure tied to mailbox names, have it be a separately organized general repository for scripts. If you want to get fancy, maintain ACLs on the scripts as to who can read them, activate them, write them, and administrate the rights on them. (rewa?) Munge the namespace on the sieve scripts such that all system scripts start with system: and use colons to demarcate directories, so that $systemscriptdir/spamcontrol/rejectrelays is available in the script namespace as system:spamcontrol:rejectrelays . --* Change the way the scripts are invoked so that a single mailbox may have multiple scripts attached to it. Store this list of attached (activated) scripts in the cyrus.header file of the mailbox. Have lmtpd execute the scripts in the order in which they are listed. --* Allow users to manipulate the scripts in their own private user space, but additionally allow them to activate system scripts. For example, if the user specified the following list: "default myforwards system:spamstopper", mail delivered would execute "default" and "myforwards" in their own personal space, then execute "spamstopper" as stored in the system directory. --* Execute all scripts as the user whose mailbox is being delivered to, or in the case of shared mailboxes, er, refer to earlier discussion... :) This is an awful lot of coding and patching, I realize. I'll be happy to give it a shot, but I unfortunately can't get into it for another month or so (other stuff on the plate). I know this sort of model would work better for us; I'd be interested to hear if this would work for other people. Michael
Re: RFC: Sieving mail delivered directly to shared/public folders
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 it: /var/log/messages:Nov 7 15:27:54 penguin lmtpd[2384]: sieve parse error for anyone: line 1: unsupported feature line one was "require ["redirect"];" So I just assumed that redirect hadn't been implemented Anyway, for the moment I suggest that as a solution for those that want to invoke a subseqent sieve. On Fri, 2001-11-09 at 17:11, Amos Gouaux wrote: > > It's already there. See RFC3028: > > 4.3. Action redirect >
Re: RFC: Sieving mail delivered directly to shared/public folders
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 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 > INBOX, I don't think. Or if it does, then it will be perpetually empty if > your sieve script is written correctly. :-) > > >
Re: RFC: Sieving mail delivered directly to shared/public folders
> 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 nothing but fileinto directives to ns> populate the public folders. This pseudo-user does not even have to have an ns> INBOX, I don't think. Or if it does, then it will be perpetually empty if ns> your sieve script is written correctly. :-) And that's the catch, or at least one of them. Locally, we've kicked this idea around somewhat. If there is a problem with the script, as per the RFC the mail will drop into the inbox. This means we pretty much have to give that folder admin access to both areas. Well, if you do that, what's the point of the shared folder? Of course if you move all the non-user shared folders under "user.", then you've pretty much lost the advantages of having different namespaces. On one hand I can see an argument for having a "user." corresponding folder to represent the admin or moderator of the shared folder area. However, this would be pretty convoluted and complicated to explain to folks, I suspect. If at the beginning of the script you could define the "inbox", then perhaps this might be more feasible. Though, that would break the RFC. What if this define had a typo in it. Mail bounces? Perhaps as a last resort it would drop back to the real default. Oh, my head hurts. -- Amos
Re: RFC: Sieving mail delivered directly to shared/public folders
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 INBOX, I don't think. Or if it does, then it will be perpetually empty if your sieve script is written correctly. :-)
Re: RFC: Sieving mail delivered directly to shared/public folders
> 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 Syntax: redirect The "redirect" action is used to send the message to another user at a supplied address, as a mail forwarding feature does. The "redirect" action makes no changes to the message body or existing headers, but it may add new headers. The "redirect" modifies the envelope recipient. [...] Example: redirect "[EMAIL PROTECTED]"; Seems like that should cover it, right? -- Amos
Re: RFC: Sieving mail delivered directly to shared/public folders
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 implications? > > Interesting. That would probably require quite a big change to the > "deliver" mechanism - as the message would have to be reintroduced into > the process flow... Currently, it is a single "arrives + sieved + stored > in mailbox" > > ... An alternative approach might be to implement the "redirect" feature > in sieve. So that 'fileinto "some.folder"' wouldn't do any extra > processing, but 'redirect "bb+some.folder@localhost"' would cause the > mail to be reintroduced to lmtpd, where it would be processed by the > script for the folder. Potentially, there is more processing overhead - > but the script writer gets to have explicit control of the processing > behaviour, and it would probably be easier to implement - and a bit > easier to understand any "side effects" of the message processing flow. CMU Sieve already has the 'redirect' action as described in RFC3028. The message will go back out to your mail relayer which will in turn will spawn lmtpd So the capabilties that you describe above already exist. 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: RFC: Sieving mail delivered directly to shared/public folders
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 probably require quite a big change to the "deliver" mechanism - as the message would have to be reintroduced into the process flow... Currently, it is a single "arrives + sieved + stored in mailbox" ... An alternative approach might be to implement the "redirect" feature in sieve. So that 'fileinto "some.folder"' wouldn't do any extra processing, but 'redirect "bb+some.folder@localhost"' would cause the mail to be reintroduced to lmtpd, where it would be processed by the script for the folder. Potentially, there is more processing overhead - but the script writer gets to have explicit control of the processing behaviour, and it would probably be easier to implement - and a bit easier to understand any "side effects" of the message processing flow. Ian.
RE: RFC: Sieving mail delivered directly to shared/public folders
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 timesieved where there is 1) no checking that the folder actually exists 2) no checking of access rights to the folder. [This is basically only one function call +some calls to set up the "mbox" gobal data structures. Anway, it compiles and demonstrates the concept... Of course, it is rought, ready, untested and probably breaks easily - so I would recommend even compiling it - let alone running it ;-). I've got the functionality I need at the moment - so I don't have a pressing need to do any more development at the moment. However, if people are interested in this approach - or some modification of it (basically something which delivers filtering on public folders) I would far rather use the common code base rather than my own private patch, so would be willing to go a bit further... So... here it is (lots of cvs diff -u )... [hang on! is it OK to send a 21.5K patch to the list. or is there some other address/place they I should send it to! - Let me know, and I'll follow up with the patch to whereever is appropriate]. Regards, Ian.
Re: RFC: Sieving mail delivered directly to shared/public folders
> 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 in the directory. ic> The symlinks could be prefixed with a number "0001_myscript.script" ic> "0002_mysecondscript" to allow ordering. You could introduce "up down" ic> commands, or just let activate remove things from the list and append to the ic> bottom. A bit clumsy without a gui. Or simply let the file names determine ic> the order. Okay, this is getting a little scary. ;-) ic> A second way would mean be to extend sieve with an "include" statement. So ic> you would have "default" being include "[script1,script2,script3]"; But include from where? If we had a script in 'user.billybob.lists.info-cyrus', then maybe have: include ["user.billybob/default"] ??? Ugh, this is scary too. ic> Anyway, this is perhaps orthogonal to the problem I am particularly ic> interested in which is apply scripts to different folders - i.e. mapping ic> scripts to the folder name space rather than the username space. I'd agree with that. Just being able to bind a script to a folder would be a *huge* win, IMHO. ic> So rather than thinking that "this script applies to this user" I am ic> suggesting that we think "this script applies to this folder". Obviously, if ic> the folder is "user.fred" then the statements are synonymous. However, we ic> can use the second way to, obviously, refer to more than just folders of the ic> category "user.something". If you can set 'anyone p' to a folder, seems like you should be able to bind a script to that folder -- Amos
RE: RFC: Sieving mail delivered directly to shared/public folders
--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. However, > we can use the second way to, obviously, refer to more than just folders > of the category "user.something". I think this is a great idea. 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? Dave McCracken == Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059 [EMAIL PROTECTED]T/L 678-3059
RE: RFC: Sieving mail delivered directly to shared/public folders
> 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 > should apply to any folder or whether multiple Sieve scripts might > apply to incoming messages to one folder, and how they should be > concatenated if so. Well, the mechanism/interface is there. Allow "activate" to apply to more than one script. One way would be to have a subdirectory called "default" with symlinks to all the active scripts in the directory. The symlinks could be prefixed with a number "0001_myscript.script" "0002_mysecondscript" to allow ordering. You could introduce "up down" commands, or just let activate remove things from the list and append to the bottom. A bit clumsy without a gui. Or simply let the file names determine the order. A second way would mean be to extend sieve with an "include" statement. So you would have "default" being include "[script1,script2,script3]"; Anyway, this is perhaps orthogonal to the problem I am particularly interested in which is apply scripts to different folders - i.e. mapping scripts to the folder name space rather than the username space. > > > Yes, what I was emphasizing is that there has to be a coherent > image of what's going on seperate from how we represent things on the > filesystem, since really the filesystem is just a database. Yes. I understand this and agree fully. > > We want the world from outside the server to be a logical system; you > shouldn't need to know how things are implemented behind the scenes. Absolutely! > > Likewise, things like "sieveusehomedirs" are only there for making > things easy for some people; in general, it's not how Cyrus is meant > to be used. Will, my second proposal won't even work with "sieveusehomedirs" ;-). I.e. you either have a script in your home dir or you have scripts associated with folders managed through timsieved. > > Larry > > > > Anyway, to carry on banging my drum, currently scripts have a name space associated with "users". The "users" name space is but a subset of the full folder namespace - i.e. there aren't really users but only "INBOXes" - users are implicitly derived from this. This should be changed so that scripts are set in the same namespace as folders. 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. However, we can use the second way to, obviously, refer to more than just folders of the category "user.something". This seems to me to be both an obvious and more comfortable way of thinking about the relationship of scripts to the rest of the system. Ian.
Re: RFC: Sieving mail delivered directly to shared/public folders
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 them appropriately. > I'm not sure I understand what you mean. By "non-administrators" do you mean "people who need to administer cyrus but don't have any other access to the box than via pop3/imap or sieve ports"? 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 should apply to any folder or whether multiple Sieve scripts might apply to incoming messages to one folder, and how they should be concatenated if so. Currently, a script can be applied to messages delivered to a single folder, for example, the user "fred". So, fred can create a script "myscript.script". "fred" then wants to apply this script to messages delivered to the folder "user.fred". How does he do this? "Magic directories" are used, say /var/lib/sieve/f/fred/default. I don't really see anything suggested that does more "magic" beyond this concept. Yes, what I was emphasizing is that there has to be a coherent image of what's going on seperate from how we represent things on the filesystem, since really the filesystem is just a database. We want the world from outside the server to be a logical system; you shouldn't need to know how things are implemented behind the scenes. Likewise, things like "sieveusehomedirs" are only there for making things easy for some people; in general, it's not how Cyrus is meant to be used. Larry
Re: RFC: Sieving mail delivered directly to shared/public folders
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 ignorant. I've now noticed "hashimapspool" in imapd.conf. Deep Deep magic.
Re: RFC: Sieving mail delivered directly to shared/public folders
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 you
mean "people who need to administer cyrus but don't have any other
access to the box than via pop3/imap or sieve ports"?
Who wants to write a script for a public folder? Just the cyrus
administrator - or some other concept such as the "owner of a particular
folder"? At the moment I am under the impression that public folders are
created by someone using "cyradm" who creates the folder and then grants
rights on that folder to other users.
At the moment I am thinking that only the user of cyradm (i.e."admins:"
in imapd.conf) should be able to create scripts for public folders. But
are you suggesting that anyone with a certain access or combination of
access should be able to edit scripts for folders?
> Magic directories just don't cut it.
Currently, a script can be applied to messages delivered to a single
folder, for example, the user "fred". So, fred can create a script
"myscript.script". "fred" then wants to apply this script to messages
delivered to the folder "user.fred". How does he do this? "Magic
directories" are used, say /var/lib/sieve/f/fred/default. I don't really
see anything suggested that does more "magic" beyond this concept.
We have a folder name space "user.fred", "user.tom", "user.harry" and
somehow the scripts that apply to this particular name space are mapped
to an alternative, filesystem based namespace.
Surely the issue is that in addition to the script itself, there is some
additional information that says which folder (or rather the act of
deliver to which folder) that script applies to.
The alternative to the "magic directories" that we already have would be
to extend the Sieve language itself, so as well as the "requires"
statement you would have an "appliesto" statement, or "scope" e.g.
[scope "user.fred"]
[requires "fileinto" ]
if address :all :is "From" "[EMAIL PROTECTED]" ]
{
fileinto "user.fred.someone";
}
Now, I am sure you don't want to do that - although it has some appeal!
However, the magic is already pretty deep...
Fred thinks of his folder as "INBOX". This is "magicked" to the imap
folder "user.fred", which is "magicked" to the file system name
$partition_default/user/fred. The scripts that apply to this directory
are "magicked" to either $sievedir/hash($user)/$user or
homedir($user)/.sieve.
This mapping could be brought closer still to the imap namespace. So the
imap folder
"user.fred" maps to the system name "$partition_default/user/fred"
So the sieve script could be
"$sievedir/user/fred"
[I'm not really sure why it is necessary to have a hash for the user
folder for sieve scripts, but not for the imap system public folders - I
don't see that deliver has to do any more operations on the sieve
directory than the user directory - or perhaps it is a hangover from
when the sieve user directory was a flat file?]
Apply the _same_ concept to an arbitrary folder name, we have the imap
folder some.interesting.public.folder mapping to the filesystem name
$partition_default/some/interesting/public/folder
and the sieve scripts that apply to that folder would be
$sievedir/some/interesting/public/folder
The magic might still be there - but it is the same magic.
How can we tell? Look at what would be required to extend sieveshell...
all we would need is an extra command, say "folder" which takes as its
parameters an imap folder name. If the folder command (aka "cd") is not
issued, then the script applies to the default folder for the
authenticated user - i.e. INBOX (or user.fred if it was fred logging
in).
sieveshell imap-server
> folder some.interesting.public.folder
> put myscript.script
> list
myscript
> activate myscript
> quit
Because the concept is the same (no extra magic) you don't have to
change the mechanism in an way - if you don't try to change your
"current working folder" then nothing is changed in the behaviour at
all. The folder command can also test some the acl.
sieveshell -u fred imap-server
> folder user.bill
ERR: You can't do this, folder still user.fred
> quit
Anyway. I think I understand that you are saying:
1. It should be possible for non-admins to install scripts on folders
given some undefined set of access rights.
2. New magic is being introduced to map imap folders to file system
directories.
My response is
1. Interesting idea. Can be done given a suitable definition of the
access rights.
2. No new magic. I'm simply *explicitly* defining the magic that is
already there and stating that it *already* applies to *any* imap
folder. The alternative would be to extend the sieve language itself,
which probably isn't a good thing.
And I have a question - why is the existing name space magic cluttered
up with the hash on the
Re: RFC: Sieving mail delivered directly to shared/public folders
> 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 directories just don't cut it. This was a puzzle to me too. Along the tangent of placing the script within the folder itself, I wondered if maybe those with the 'a' ACL might be allowed to modify the script. Though, who knows how they would even get to it. -- Amos
Re: RFC: Sieving mail delivered directly to shared/public folders
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
Re: RFC: Sieving mail delivered directly to shared/public folders
> 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 directory as the intended IMAP folder. It's got to stat that directory anyway ic> Given that sievesystemscripts == /var/lib/sieve/system ic> So.. call sieve_find_script( anyone, "some.interesting.folder" ) ic> if the directory /var/lib/sieve/some exists then look for the directory ic> /var/lib/sieve/some/interesting, if that exists look for the directory ic> /var/lib/some/interesting/folder. ic> so it would try /var/lib/sieve/some/interesting/folder/default, then ic> /var/lib/sieve/some/interesting/default, then /var/lib/sieve/some/default ic> and finally ic> /var/lib/sieve/default. ic> A handy side effect of simply checking the directory, rather than for the ic> presence of the file "default" would be that if default did not exist then ic> no script would be run... so you could have a script applying only to some ic> folders in the middle of the hierarchy... not above, and not below. Interesting ic> I'll code that up if you like an you can try it ;-). That's why we've got a prototype box. ;-) Though, it is running a CVS pull (2.1pre). -- Amos
RE: RFC: Sieving mail delivered directly to shared/public folders
> 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 *all*
> our shared folder mail through one script. I don't know about
> y'all, but we've got at least a hundred or so shared folders. At
> the very least this might make for a somewhat unwieldy script. Some
> of these folders also see a lot of traffic, so for these I'd be
> inclined to not have them go through a script at all.
>
M... That seems to be a reasonable thing to want to do
The concept of "scope" in sieve is a bit lacking.. It could be argued that
there is a similar limitation in the processing of an individuals folders...
Again, you could concievably want different, complex scripts for different
subfolders... At the moment, sieve just applies to "INBOX".
Of course, it would be nice to invoke sieve at arbitrary times - not just at
delivery either...
Oh dear. I can see a whole new imap function coming on - ". SIEVE folder
script"...
Anyway, deliver is doing:
sieve( username, "user.username", default ),
and you want to be able to do
sieve( "anyone", some.arbitrary.folder, default )
ie. sieve( security_context, folder_to_sieve, script_to_sieve_with ).
So... the function sieve_find_script (returns handle to script file) needs
some extra parameters - in addition to the user, it wants the name of a
folder ("INBOX" being the default for a user), then it wants to look in
subdirectories until it finds the best match.
FUNC sieve_find_script( string user, string folder_spec ) {
/* folder_spec might be some.interesting.folder */
directory is firstpart of folderspec
if directory exists then
directory is concat( directory + next element of folderspec )
repeat that bit until it no longer exists
endif
then open the file "default" in the last directory found...
}
Does that make sense?
Given that sievesystemscripts == /var/lib/sieve/system
So.. call sieve_find_script( anyone, "some.interesting.folder" )
if the directory /var/lib/sieve/some exists then look for the directory
/var/lib/sieve/some/interesting, if that exists look for the directory
/var/lib/some/interesting/folder.
so it would try /var/lib/sieve/some/interesting/folder/default, then
/var/lib/sieve/some/interesting/default, then /var/lib/sieve/some/default
and finally
/var/lib/sieve/default.
A handy side effect of simply checking the directory, rather than for the
presence of the file "default" would be that if default did not exist then
no script would be run... so you could have a script applying only to some
folders in the middle of the hierarchy... not above, and not below.
I'll code that up if you like an you can try it ;-).
RFC: Sieving mail delivered directly to shared/public folders
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]".
The facility is enabled using a new option in /etc/imapd.conf -
"sievesystemscripts". If this option is not set then public folder
filtering will not be enabled - ie. if you don't change anything, the
behaviour of the system is unchanged.
"sievesystemscripts" should be set to a directory accessible by the
deliver process - but not accessible by ordinary users! Deliver will
then look for a sieve script in this directory. If one exists then it
will be used to filter the email sent to the public folders. The script
should be sent up in the usual way - called something sensible such as
"public.script" then linked to with the symlink "default". Note that
timsieved will not be able to access this directory. This is probably a
good thing - but you will need to have access to your cyrus server host
in order to set things up.
Public folder filtering is performed with the security context of
"anyone". So for example, your script will only be able to "fileinto" a
folder with an appropriate ACL for "anyone". This is probably the most
contentious point - but I can't see anything wrong in practice - public
folders by there nature are accessible to anyone, and I'm only really
interested in fileto and reject actions (setting flags might be an
issue?). As the concept of "anyone" already exists, there is no need to
mess about creating new "dummy" users etc. And using "anyone" seems to
work quite neatly.
Applications
The obvious application is to do some kind of spam filtering on your
public folders. In addition, I have various automatically generated
reports from customer systems. The systems are configured with to send
to a single well know email address - which maps to a public folder on
our mail store. This has become rather cluttered over time and was being
manually filtered.. which was somewhat time consuming. The sieve script
is set to filter on the basis of the sender address, allow mail to be
automatically organised by customer and/or function. An additional
benefit is that the "well known" email address does not have to be
changed.
Example
---
imapd.conf
..
configdirectory: /var/imap
partition-default: /home/imap
admins: root cyrus
allowanonymouslogin: no
# To use the PAM for authentication (but not /etc/passwd or shadow),
change
# the following line to specify "pam" instead of "sasldb".
# sasl_pwcheck_method: sasldb
sasl_pwcheck_method: pam
# Sieve can send email
sendmail: /usr/sbin/sendmail
sieveusehomedir: false
sievedir: /var/lib/sieve
sievesystemscripts: /var/lib/sieve/system
They key thing here is the addition of sievesystemscripts
...
$ ls -l /var/lib/sieve/system
total 4
lrwxrwxrwx1 cyrusmail 11 Nov 5 12:55 default -> spam.script
-rw---1 cyrusmail499 Nov 7 15:28 spam.script
...
cat spam.script
.
require ["fileinto","reject"];
if address :all :is ["From"] ["[EMAIL PROTECTED]"]
{
fileinto "public.help.customer1.fax";
}
if address :all :is ["From"] ["[EMAIL PROTECTED]"]
{
fileinto "public.help.customer2.fax";
}
if address :all :is ["From"] ["[EMAIL PROTECTED]"]
{
fileinto "public.help.customer1.amanda";
}
if address :localpart :contains ["To"] ["bb+public.test"]
{
reject "This folder has been disabled";
}
if header :is "X-SPAM" "yes"
{
fileinto "public.spam";
}
...
[Note, in case you are wondering - spam *really* does have the header
"X-SPAM" set to yes. Spam detection happens on the way in to our
network, and mail deemed to be spam is labeled. This is a way to
separate mechanism from policy. Individual users can do what they want
with spam - either discard it or file it. And I can set an appropriate
policy for the public folders.]
Implementation
--
My example implementation is against cyrus 2.0.16, not against CVS head.
This is because I am running 2.0.16, so I've been able to test it. I
will redo the diff against CVS if the basic idea seems OK... but I won't
be able to test it so well.
The patch is not very invasive - only imap/lmptd.c is touched (plus the
documentation). It probably ought to be applied to the lmtpproxyd.c -
but again, I won't bother to test that as I won't be using it.
I've tried to follow the same coding conventions that already exist in
the source, so hopefully it should be fairly easy to understand.
.
diff -Naur cyrus-imapd-2.0.16-orig/doc/install-sieve.html
cyrus-imapd-2.0.16/doc/install-sieve.html
--- cyrus-imapd-2.0.16-orig/doc/install-sieve.html Fri Jan 5 01:59:03 2001
+++ cyrus-imapd-2.0.
