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 similar hash needed in the folder directory?
Hope I am making sense....
Regards,
Ian.
