Is there a way to configure Dovecut (version: dovecot-stable) to prevent
the removal of an IMAP folder?
We are planning on rolling out the @Mail webmail client to our user
base in the next few weeks. This package has an internal Spam folder
that we use to deliver spam into to allow our users to get to both their
main mailbox and also their spam repository in one location.
We are a Maildir shop, so the folder appears as:
'~username/Maildir/..Spam'
We want to use a sym-link to point '..Spam' to a location on another
filesystem. Our testing shows that dovecot will happily follow a
sym-link properly and no badness occurs as a result.
Our concern, however, is that a user will attempt to remove their
Spam folder, which will break the symlink and the next time a
spam message is delivered the folder will be re-created as a
directory and will reside on the same filesystem as their Maildir.
Preventing the removal of the folder would be the easiest solution.
If such a restriction is not already present in dovecot, might something
be added to allow admins to lock down removal of folders?
If this question has already been asked and answered on the list I
apologize - I did quickly browse some of the back list and did not
see a reference to the topic, but I admit, I may have missed it.
Thank you in advance,
John
--
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.
"My other computer is your windows box."
Ralf Hildebrandt
Hi John,> We want to use a sym-link to point '..Spam' to a location on another > filesystem. Our testing shows that dovecot will happily follow a > sym-link properly and no badness occurs as a result.Did you test what happens when a user creates another folder within the symlinked folder? In our situation, the new folder was created on the filesystem which contains the symlink and not the filesystem to which the symlinks links. Just FYI. -Remy
Am Mittwoch, 27. Juli 2005 21:46 schrieb John R. Dennison:> Our concern, however, is that a user will attempt to remove their > Spam folder, which will break the symlink and the next time a > spam message is delivered the folder will be re-created as a > directory and will reside on the same filesystem as their Maildir.Did you try to set the permission in a way the link cannot be deleted? eg. chown it to another user and set the sticky bit on the enclosing directory... (Untested, but might work.) Greetings, Gunter -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + http://aachen.uni-dsl.de/ - Der direkte Draht in's Hochschulnetz! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "Students?" barked the Archchancellor. "Yes, Master. You know? They're the thinner ones with the pale faces? Because we're a *university*? They come with the whole thing, like rats --" -- (Terry Pratchett, Moving Pictures) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + PGP-verschl?sselte Mails bevorzugt! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20050727/13762411/attachment-0001.bin>