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: Second attempt at sieving for public folders
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. The number of calls would be determined by how many folders there are in the specification (number of . + 1). Of course, if there was a hit sooner then this limit wouldn't be reached. Hard to say what affect this would have in practice - obviously, a script.db or an entry in mailboxes.db could cut down this lookup - there would be just a single open on the db file, followed by an open on the script. So you would still be doing two opens. So for many cases (user's folders) this lookup would be longer or as long as the case without the lookup. So it really depends on 1) how many folders have scripts and 2) the ration of deliver to deeply nest folders and none nested folders. Of course, it is only lmtpd that is affected - I think it would be better to do some analysis as it may be the case the the script database slows down the general case, and only improves performance on rarer cases.
Sieving mail sent to shared/public folders
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 relevant file is imap/lmtpd.c, in the function deliver(). What I'm thinking of doing is modifying this function, so that in the case of a post to a public folder it will find the script for the pseudo user bb (or rather the value of the BB string) (sieveusehomddir is false). My plan is to add the code to sieve the email for case 1 shared mailbox resource in the source. From my cursory look at the source, I can't see any obvious issues with doing this (thinking about security - mydata.authuser, mydata.authstate etc). However, before embarking on this, I was wondering if any one more knowledgeable than me had any comments about this (it seems like a fairly obvious thing to want to do - so I suspect that there are some gotchas that are not obvious to me - or it has already been done). Regards, Ian.
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
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
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.16/doc/install-sieve.html Wed Nov 7 15:57:56 2001
@@ -44,6
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 user name? Not saying it is unneeded - but if it
is needed, then why isn't a
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.
RFC: Second attempt at sieving for public folders
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 want to allow different people to maintain different policies (i.e. scripts) for different folders, or sets of folders in the hierarchy. The following implementation addresses this concern. In addition, the problems of a confusing name space (i.e. where are these scripts stored) together with administering them (i.e. how can I get to these scripts) were raised. Again, I've attempted to address this. 1. Namespace issues The imap server presents a unified hierarchy of folders and subfolders. I'll call this the IMAP namespace. Typically, the . is used as a delimiter, although this can be overridden. Each folder and items in the folder are mapped through to directories and files on the server. This mapping is invisible to users of the imap server. The system administrator creates this mapping by specifying partitions - folder storage is assigned to a partition. In addition, a simple hash mechanism can be used in order to add an additional directory level to the system storage for performance reasons. Consequently the mapping of the the IMAP namespace to the system name space is non trivial. The key point to note is that it is hidden from the user of the imap server. In general terms. folder user.ian might map to partition/[hash]/user/ian. In a system with a single default partition set to /var/spool/imap, with hashing enabled, the folder would map to /var/spool/imap/i/user/ian. 2. What is being sieved. Messages are sieved on delivery. The sieve specification doesn't explicitly say how a given sieve script should apply to a particular message. Currently, this is defined by the implementation is Cyrus. In this case, messages delivered to user.someuser are filtered with a script located using a _different_ namespace mapping to the one used for folder storage. In particular, for sieving purposes, the folder user.someuser.[folders] will map to the same internal name space as the folder user.someuser. Additionally, there is no valid mapping for any other folder. i.e. anothertoplevelfolder.[folders] will never match against a sieve script. [OK, this is a somewhat baroque way of saying that currently, you can't sieve public folders, and a user can have only one script - but I'm trying to show that sieving functionality can be extended without altering any fundamental concepts]. 3. A single name space for folder storage and sieve scripts If we use the same name space mapping rules that we have for folders to scripts, then we can solve the problem. So a message being delivered to user.fred should be sieved with a script associated with that particular name. Then a message being delivered to a folder public.interesting.messages should be filtered with a script associated with that folder name. 4. How should the mapping be performed Essentially, the same way that the mapping for folders is performed. I.e. a given imap namespace (folder) will map to a unique/distinct system directory. We want the same to hold true for scripts.A logical thing to do would be to use exactly the same mapping, and store the script for the folder with the rest of the files. However, the current implementation doesn't do that, and we don't want to break it.. so: a folder a.b.c maps to partition/[hash]/a/b/c, so if we use sievedir we can simply do: sievedir/[hash]/a/b/c for ths folder. In this case, wether or not the hash function is used is determined by hashimapspool. The name space (apart from the root) will be the same. Of course, if you have a single partition_default: mapping to /var/spool/imap, and make sievedir map to /var/spool/imap then you will have exactly the same imap - physical mapping. 5. Compatibility issues. The suggested implementation should be compatible with the existing one. In this case, we would want the folder [user.ian.my.sub.folder] to map to the script for [user.ian] - which it does now. This can be achieved by saying, if there is no script for this pariticular namespace, then try the script for the mapping of the folders parent. Keep doing this until you find the script. So if the only active script was associated with user.ian, then all subfolders would use this script. This is nice because it is both compatible with the existing implementation, and also allows a single script to be used for a collection of similar folders. I.e. a script has a scope of its specified folder together with all its children. Or you can say that subfolders inherit the script of the parent. 6. Script Execution. This isn't changed in anyway. Deliver is simply determining what script to run. In security terms, scripts run with the rights of the user with which they are associated. This is again implicitly defined as folders do
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
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
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
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 dir/file - 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, sievesystemscripts );
}
+else {
+if (sieve_usehomedir) { /*
Re: Question: how to disable duplicate delivery mode?
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 look at (2.0.16) imap/lmtpd.c line 281...
/* initialize duplicate delivery database */
dupelim = 1;
if (duplicate_init(0) != 0) {
syslog(LOG_ERR,
deliver: unable to init duplicate delivery database\n);
dupelim = 0;
}
dupelim is a global variable. It is tested whenever the duplicate
deliver mechanism is to be invoked. You could try commenting out the
call to duplicate_init() and make sure dupelim is set to 0.
However, it is probably worth checking that dupelim is used
consistently...
If it does work, then the thing to do would be to add a config to
imapd.conf to control wether or not you want duplicate elimination.
Hope that helps.
Ian.
PS. 1,500,000 mailboxes does sound interesting!
On Wed, 2001-11-14 at 08:19, Birger Toedtmann wrote:
Hi,
within the Cyrus IMAP package (2.0.16) there is much talk about sieve only
working with duplicate delivery suppression and disabling that would also
disable sieve.
No more information is supplied, only the configure switch --disable-sieve.
My point is: I need *fast* delivery (you may find out why in a different
post Patch: config file for master as argument on this list). I don't
need sieve, and I don't need the duplicate delivery suppression code.
What I did not find is: how can I disable that code? Is there a hidden
switch in configure? (read the source to no avail)
When I install Cyrus IMAP with most features turned off, I'll still get
the duplicate-X.db files and Cyrus working on them, which wastes my
ressources (it boils down to that - I know that duplicate delivery supp-
ression and sieve are good ideas in general, but I cannot use them in the
situation at hand).
Your ideas?
Regards,
Birger
