Using ISPConfig with Cyrus (or: Cyrus support in ISPConfig)

When using ISPConfig with Cyrus, auto responders and custom rules are not available. However, the options are still visible, which is confusing. I'd like to contribute a patch to resolve this issue, but I am unsure what would be the best solution. I am hoping to receive some feedback on this issue in this thread, so the patch can really contribute something worthwhile which is aligned with the software philosophy of the ISPConfig project.

2) Add complete support for cyrus, making it possible to select the Cyrus mailserver as imapd. The aforementioned options can be hidden when Cyrus is selected.

As I'm unsure which path would be the best, and I'm not yet able to oversee the implications of such a change within the project, I'm hoping to receive some feedback from the developers/community so I can define the solution clearly and eventually contribute it.

Adding support for a third imap daemon will require more time for testing and maintenance in future, so before we decide if we want to support cyrus imap in ispconfig we should discuss what the benefits over the existing imap implementations are. Why do you want to implement Cyrus support and whyich benefits does cyrus has that are not available in dovecot imap and courier?

In my case, we prefer Cyrus because it scales better than either dovecot or courier do, and adheres more strictly to RFC's. But in the end, the reasons for choosing cyrus over dovecot/courier may vary per situation.

I understand the implications such a change would have on future testing/maintenance work, so I guess the big question is: is it worth the (large) effort? We can measure this by the number of people sending in feature requests for cyrus support. I did a search for "cyrus" in the feature request bugtracker, and I get only one result which has two votes, so it doesn't appear to be worth the effort

Regardless, we are still able to use cyrus with ISPConfig, but the issue we are having, is that we don't use mail filtering or autoresponders. However, these options cannot be turned off and are always visible to resellers/clients, which results in unnecessary load on our support desk because people get confused.

In light of the above, how would you feel about a patch which makes it possible to turn filtering and autoresponders on/off by using a checkbox per mailserver? We could set them to 'enabled' by default so the current behaviour is not broken. Then we could hide or show the options for filtering and autoresponders depending on these checkboxes.

In light of the above, how would you feel about a patch which makes it possible to turn filtering and autoresponders on/off by using a checkbox per mailserver? We could set them to 'enabled' by default so the current behaviour is not broken. Then we could hide or show the options for filtering and autoresponders depending on these checkboxes.

Click to expand...

This seems to be a good option in my opinion, the checkbox to enable autoresponder and filtering can be added to e.g. System > server config > mail if it shall be configurable per mail server or in System > Interface config > Mail if it shall be configurable for all servers that belong to this ispconfig installation. I guess the second option might be better. The first option might confuse users as we can not hide the filtering and autoresponder tabs until they saved the new mailbox as we dont know the target mailserver before the address is saved. If more users get interested in cyrus support in future, then we can still develop cyrus support then.

Thanks again for your reply. The per-installation option does seem the most logical one indeed.

Making it configurable per mailserver could work, if we can somehow (javascript?) dynamically hide tabs depending on the selected domain. We could show or hide the tabs by default, depending on the user's default mailserver. It is more complex than the first option.

Could you let me know, which option would be best for the ISPConfig project? I will then start the development work.

1. I've tried setting the checkbox to checked by default, but it doesn't appear to work.

Click to expand...

The defaults for these fields get applied during installation and are stored in the file install/tpl/system.ini

2. I'd like to commit the code. What's the best way to do that?

Click to expand...

Do you have a svn account for the ispconfig svn server? If not, please send a email to dev [at] ispconfig [dot] org with your forum username and if available your sourceforge.net username and request a svn login.

Just a FWIW but one compelling reason to include Cyrus, either partially or fully, is that the Kolab server uses it by default and I am very keen to offer Kolab services along side of ISPConfig. Perhaps even eventually provide some ISPConifg customizations that manage Kolab availability to clients. Kolab also uses Roundcube.

Hi, sorry to revive such an old thread. I was wondering if/where this patch made it into the releases. I was actually doing this for a customer and they say the additions have disappeared since they upgraded to 3.0.5.3.

If you want to include the patch in the next major release, then please register for an account at our git server http://git.ispconfig.org , fork the ispconfig master branch, add the changes and then submit a merge request on the git server so the patch can be reviewed and gets integrated into the master branch.