Mailbox size policy & Cyrus

[oliver.blaha]

Originally Posted by till

Or you introduce a new variable in dist.txt which contains the default cyrus user of the linux distribution.

You can specifiy any user as administrator in /etc/imapd.conf, so this wouldn't really help. Anyway, you have to tell ISPConfig the password somewhere.

1 Vote for isp_server.

Should I store it there also when asking for username and password during setup? If yes, should this be directly changeable through the server tab in ISPConfig? If also yes, should I hide theses two fields as long cyrus is not chosen? (Remember, if yes to the latter it would be necessary to reload the tab to show the fields)

[till]

Originally Posted by oliver.blaha

They can easily be recreated, but mails are lost when the mailbox is deleted. If I'm not completely wrong then currently mbox and Maildir behave different:

mbox: Mails are erased when deleting the user and won't be restored if you restore the mailbox.
Maildir: The mailbox is disabled when deleting, mail stays there until you empty the recycle bin.

Is this intended? Or am I wrong? (I currently have no ISPConfig ready for testing with Maildir or mbox, so I have to ask *g*)

The correct behaviour is to disable the user (if possible) when it is moved to the recycle bin and remove it completely, when the recycle bin is emptied.

[till]

Originally Posted by oliver.blaha

You can specifiy any user as administrator in /etc/imapd.conf, so this wouldn't really help. Anyway, you have to tell ISPConfig the password somewhere.

Ok, then the best way might be to ask during setup. Ask only in expert mode or ask always? Do you want to try to detect the used pop3 / IMAP damon or always ask which daemon is used?

Should I store it there also when asking for username and password during setup?

Yes

If yes, should this be directly changeable through the server tab in ISPConfig?

Yes

If also yes, should I hide theses two fields as long cyrus is not chosen? (Remember, if yes to the latter it would be necessary to reload the tab to show the fields)

I think it is not nescessary to hide these fields.

[oliver.blaha]

Originally Posted by till

Do you want to try to detect the used pop3 / IMAP damon?

Yes. Should be quite easy, if cyrdeliver (the cyrus delivery program) is installed I 'd assume Cyrus. Same should be true for some Courier binary.

Ask only in expert mode or ask always?

I'd choose standard mode, as it is a similar question like postfix and proftpd.

I just see one problem: For automatic detection, I need to adapt the dists.txt file, but I don't have the possibility to examine the directory structure of all supported distributions. What's the best way to manage this?

[till]

Originally Posted by oliver.blaha

I just see one problem: For automatic detection, I need to adapt the dists.txt file, but I don't have the possibility to examine the directory structure of all supported distributions. What's the best way to manage this?

I guess the best way is to add the variables for all dists to the value of your current distribution and we will correct the values if nescessary when we test other linux dists.

[oliver.blaha]

I recently added cyrus support to subversion. I didn't touch the installer yet, cyrus has to be choosed in the isp_server tab, as I'm not really sure how the installer works.

Setting up Cyrus itself is quite easy, but it's very hard to make procmail deliver correctly, as the procmailrc files are run with users' privileges, and these are not sufficient to deliver mails to cyrus (if they were, every local user could pipe unscanned mails to every mailbox).

That means there is the choice between 2 possibilities:

1) Don't use procmail. That would definitly speed up delivery for huge amounts of mails. Filtering could be done with a postfix content_filter or by a sieve script. I'd like doing it with sieve, but that would also mean that both, prochmail AND sieve scripts, would have to be maintained in future. Should not be too hard, but I wanted to mention that Also the MailScanner would have to be replaced by something else, as a procmail script won't work with sieve. But I already found a nice peace of software that might be a perfect substitution (and even cares of partial mails, which currently get through unscanned AFAIK) - I just forgot the name, but I know where I have to look for it *g*

2) Run procmail scripts with delivery rights. Sounds simple, but it isn't that easy. Ok, running itself IS simple... but this way the users' .procmailrc files will also need to be run with these rights.
This means that users could change their .procmailrc file and do something very odd if they wanted to.
The rc files having root as owner and no write privileges for group and others doesn't help, as e.g. renaming the file and creating an own one is still possible.
Only (known) solution: Store the users' .procmailrc files (and all other files called by it) in another, not accessible folder. As all the procmail files shouldn't be changed by users in any case, this seems to be a good solution. I'd make this the standard behavoiur if cyrus is selected.

Comments please

[till]

Hi Oliver,

I think soultion 1) will be cleaner, but might cause incompatibility problems during upgrades.

Solution 2) seems to be a bit more compatible with the current maildelivery implementation.

If we use 1) an upgrade from current ISPCOnfig versions will be problematic as the user will have to reconfigure its postfix manually. And we will have to deliver new filters that are compatible with sendmail too.

I think going with 2) will give us less upgrade problems.