Changing the LDAP port Scalix uses

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/ file and set the ubermanager.query.server.port to the same value:


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

Recent email rumblings

Email as a technology is pretty boring but it is hard to tell that this morning with two really interesting announcements coming from Eudora and the Hula-Project.

Eudora are the creators of of the first usable pieces of email software for normal people. Since that time in the early 90's they have fostered a relatively small but loyal user base. Recently however they have announced that the latest version of Eudora email client will be their last based on the traditional code-base. As a replacement Eudora are going to build their unique interface and feature-set on top of the Mozilla Thunderbird code-base which is a win/win for both parties. The move allows Eudora to focus on specialised functionality rather than maintenance of general features whilst for Mozilla it increases their overall user-base and in theory should result in a more stable product overall.

Ensuring mail can be sent via Scalix Webmail

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.

Enabling SMTP relay (smarthost) in Scalix

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/ and find the line that reads:


And change it to:

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.

A few useful OSX Mail bundles to correct its shortcomings

Apple's Mail application by itself is not the most fully featured of email tools, it lacks proper calendar integration, column views and more technical things like always connected IMAP IDLE mode. Fortunately it makes up for these shortcomings in its interface, great search functionality and integration with the rest of OSX. But still its nice to have the functionality that is available within contemporary applications like Thunderbird and Outlook and that is where Bundles come in.

Bundles are Apple Mail-speak for functionality extensions similar to Firefox's. Unlike Thunderbird which has the ability to be extended but has so many inbuilt features its almost pointless, Mail has a wide array of Bundles that provide nearly all of the functionality missing within the base application.

Sorting out Scalix tantrums

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:

Migrating to and using Scalix 10

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.

Three very useful tools

Over the last couple of days I have come across three very useful tools:

Google Browser Sync
Just released it keeps all your Firefoxes in sync with each other. Great if you have more than one computer (or virtual computer). I have used other bookmark management tools in the past but as this is integrated right into Firefox, automatic and free it is hard to beat.

Widescreen view for provides a three panel view very similar to that of Outlook or Thunderbird. When you have a widescreen display it makes a lot of sense.

SORBS: An anti-spam service worse than spam?


SORBS is a Realtime spam BlackList (RBL) that is far from helping the spam problem. I am not alone in thinking that rather than being professionally run and attempting to target real spammers SORBS solution to the spam problem is just to add half the Internet (figurately speaking) to a blacklist. Case in point yesterday I got a call from a friend who mysteriously could not send email to certain people on the Linux server I had setup a few years ago. I checked on the server and found nothing wrong yet still some mail just was not going through. He rang up his ISP (TelstraClear in this case) only to be told that his entire subnet (about 500-odd TelstraClear users) had been added to the SORBS blacklist two days ago. On the blacklist there is no reason given as to why this subnet is banned nor is there any attempt made by SORBS to contact effected parties. The only clue for the ban is that SORBS considers the ip range dynamically distributed even though TelstraClear issues static addresses to their business customers on this ip range.

Windows Live to host college email

I talked about Windows Live a while back and so news that 72 U.S. colleges will be using Windows Live for student email services seemed quite relevant. It makes sense financially for the colleges and from Microsoft's perspective it gets customers early before they have made a definite decision on who their email provider will be. No doubt Google and Yahoo will soon be following this same path with their mail services in an effort to build (Google) and maintain (Yahoo) their user-base.

The move is another vindication of the software as a service concept and will help bring some sanity to educational IT departments. Victoria University should adopt the same policy for student email and file storage. If not sponsored by Microsoft/Google/Yahoo they should at least scrap student email and file storage services in favour of Google/Microsoft/Yahoo email and personal USB keys. The savings whilst not huge would add up over time, plus I am in no doubt that the big players could provide a better level of service and featureset than what any over-stretched educational IT department could ever provide.