scalix

Scalix runs its own instance of OpenLDAP for authentication purposes and by default this operates on port 389 which is the standard port for LDAP. The only problem with this is that you cannot run a 'proper' LDAP service (OpenLDAP, FedoraDS, eDirectory) on the standard LDAP ports without there being a conflict with the Scalix service. Fortunately there is a simple workaround that lets you run the Scalix service on a non-standard port.

Edit the /var/opt/scalix/sys/slapd.conf file and change the setting portNum to a non-standard (preferably high-level) port. In this example I will use port 6389 but it can be any port that is not currently being used by another service.

portNum 6389

Now edit the /etc/opt/scalix/caa/scalix.res/config/ubermanager.properties file and set the ubermanager.query.server.port to the same value:

ubermanager.query.server.port=6389

Save the changes and restart Scalix for the new LDAP port settings to take effect.

OSX Mail is a typical Apple product, it has some great features that make it fantastic but it is let down by the tiny details. For example I've been battling with it's 'Synchronize IMAP Account' feature and its ability to almost crash my Scalix mail server. The feature is useful because it creates a local copy of an on-line IMAP account for SpotLight searching and general offline use. Unfortunately if this process is run after a long period of time offline it can cause the Scalix IMAP server to trip up and not allow further IMAP connections.

I've been on the Scalix forums trying to resolve this issue and it seems like the root cause is a hard-coded limit of 17 simultaneous IMAP connections within Scalix. Unfortunately OSX Mail creates multiple simultaneous connections when performing the synchronization process and just to make matters worse it takes its own sweet time in closing them. Consequently it does not take long for the 16 process limit to be reached, the Scalix IMAP server to trip over and the Mail client to be left out in the cold.

The most annoying thing about the problem is that unlike Thunderbird, OSX Mail offers no way to limit the number of simultaneous connections, thus getting around the issue. Fortunately it sounds like the server team will resolve this hard coded process limit bug, perhaps in time for Scalix 11, so the annoying issue maybe resolved once and for all.

The Scalix Webmail client requires an authenticated smtp connection in order to be able to successfully send messages. If the Scalix smtpd service is not configured to allow annoymous smtp connections from the Webmail host then the client will receive the following Javascript error:

methodname = send

To correct this edit the Scalix smtpd configuration file at /var/opt/scalix/sys/smtpd.cfg and ensure the Webmail server is added as a source that can send annoymous email.

By default Scalix configures itself to operate as a standalone mail server which is normally what client's want. Unfortunately the IP range my ISP owns is frequently flagged by anti-spam services  making mail delivery to certain recipients challenging. Fortunately my ISP provides an SMTP relay server for customers on the network which is not effected by the broad blocks applied to the IP range I am on.

To configure Scalix to use the SMTP relay for outgoing mail edit /etc/mail/sendmail.cf and find the line that reads:

DS

And change it to:

DSrelay.smtpserver.com

Restart sendmail and you will find all your external mail sent via Scalix is relayed via the ISP's SMTP server. To check it is all working send an email and then view the /var/logs/mail file, the last entry should show a log of the outgoing mail with the relay recorded next to it.

Scalix is a powerful, stable and soon to be almost completely open sourced email server. Unfortunately like many commercial products it is still a little rough round the edges when it comes to doing things outside of the supported method. Here is a couple of tips that may help you out when wanting to take Scalix "off-road" so to speak...

This morning after making some file changes and performing a server restart I found the Scalix 10 email server would not load. As I have never had to resolve major problems with Scalix determining the cause and solution to this error turned out to be a worthwhile experience.

Manually starting and stopping Scalix

According to the Scalix startup script (/etc/init.d/scalix) the service was successfully starting, but on closer inspection none of the actual processes were beginning. Unfortunately whilst the /etc/init.d/scalix script is a tidy way of controlling Scalix it does not provide any console logging to explain any issues that maybe encountered. For more useful output the two console commands that start/stop Scalix are:

Last week this post on my local Linux user group got me rethinking email servers. The last time I did this was about six months ago when I made the move away from Hula onto Zimbra. At the time I looked at Scalix 9 but was deterred by its need for X-Windows during the install process and the overwhealming amount of installation documentation that came with the 100+mb download. I decided to go with Zimbra because it offered a text-based installer and some very nice looking UI features on the webmail client.