Kerio Mailserver has changed its name to Kerio Connect with the 7.0 release. This is a free download for all current licenses and of course retains all previous users, mailboxes and settings.
This is a name change - Kerio Connect is still the same mailserver and no earth-shattering changes have been made. However, there ARE changes in this release that you need to know about. The definitive source for that is the release notes and the manuals, but I'll give you a quick overview here.
Browser based administration
While the administration client is still available, the preferred administration tool for Kerio Connect is now your browser. By default, this is on port 4040, so you would point your browser at http://yourmailhost:4040/admin/login/ to gain access.
There's no control over that port in Administration. However, it is listed in mailserver.cfg, so you could adjust this as necessary.
The first thing you'll probably notice is that account functions have been moved to the top. This makes sense: after initial setup, that's the section you are most likely to be using.
By the way, I really recommend taking the time to run through every section. You may have missed or forgotten about settings that I won't mention here because they have been in previous releases. I do that myself every now and then because I forget things. In most cases the manuals should answer any questions you might have about a particular setting, but do feel free to call me if you are uncertain about anything.
This lets you run a main office mail server and branch office mail servers under one domain. You'll find a separate manual for configuring this setup.
From the manual:
If your company uses more Kerio Connect servers physically scattered (located in different cities, countries, continents), you can now add them to a cluster and move all users across all servers involved into a single email domain (distributed domain).
Note that this isn't load balancing. One server is the master point where all incoming email arrives; it is responsible for relaying any that belong at a satellite server. The "slave" servers should have the master set as their relay also if you want single-point archiving and backup.
The "Master /Slave" designation is arbitrary. All servers are really peer to peer and use the same directory service. You determine which servers mailboxes belong on which server and which is the master. Obviously that would need to be the server that is set as the MX for the domain also.
This is a bit clumsy. For example, if you have 100 users and would like to put 20 of them in a distributed domain, you can't just float your licenses - each server needs specific license counts. While Kerio is certainly willing to adjust licenses as necessary, the process is manual, not automatic. If your users stay relatively static, that's fine, but if you have wide variations at the branches, you'll probably end up paying for more licenses than you need. It would be better if you could just float the licenses or transfer them yourself easily.
The release notes say:
Kerio Connect uses a more efficient file access method to the message store data. This includes the properties.fld database access and listing mailbox folders.
That doesn't tell us much, does it?
I'm really curious to see if this helps with users who simply will not organize or clean out mailboxes. I hope that it will.
The "properties.fld" file is apparently IMAP annotation data. It's interesting to look at what these metadata files are:
index.fld: ASCII text, with CRLF line terminators
properties.fld: Berkeley DB 1.85/1.86 (Btree, version 3, little-endian)
search.fld: SQLite 2.x database
status.fld: ASCII text, with CRLF line terminators
But that still doesn't tell us how any of this helps speed up file access.
Kerio has a problem with very large mailbox folders. They store individual mail messages rather than packing them all into one database as Exchange does. I think that's the right approach, but it can cause performance issues. These files are designed to help that by providing a mix: database files pointing to individual messages.
I'd much prefer to see domain or user controlled folder archiving. I'm not referring to the archiving found in Archiving and Backup but rather moving older messages into another folder at regular intervals. For example, if this were set for monthly archiving, everything in your Inbox from last month would be moved to Inbox-2009-09. But that's not a feature of this release and may never be.
Speaking of config files, there's a new cluster.cfg file. I assume that is for the distributed domains mentioned earlier, but there is also an undocumented Cluster section in the mailserver.cfg, so bigger plans may be afoot. That's pure speculation, of course.
A related feature allows setting message retention policies domain wide. Unfortunately, it's not well done in this release. You can set a policy for Deleted Items and Junk Mail separately but otherwise you either set all other folders (not contacts) to delete items older than what you set or you don't set anything. I think Inbox needs to be a separately controlled item as do calendars and public folders.
This is should also be brought down to the user level and should be able to be set for each folder individually. The current controls are not fine grained enough - it's a welcome addition, but I hope to see improvements in future releases.
Speaking of things I'd like to see: the top-most screen has a link for "Suggest Idea". You need to set a user name and password when you first use this (and be sure to allow popups) but after that you'll be brought to a Kerio page where you can add suggestions and vote on other people's submissions. I hope this will help all of us make Kerio even better in future releases.
Message Submission service
You'll find this in Services, set to run on port 587.
Kerio suggests using this to get around the problem of outgoing port 25 being blocked at hotels and public access points. The user sets his outgoing SMTP port to 587 and the Kerio server listens on that. As this service requires authentication, it can't be used by spammers - unless they've hacked the user's account, of course, but at least we do then absolutely know the source of the spam!
The Message Submission service is defined in RFC 2476 and has much more to do with mail architecture than just bypassing blocked ports. This FAQ: SMTP Message Submission to Proposed Standard describes the reasoning behind the RFC.
HTC Hero, DROID by Motorola, Google Nexus One and Palm Pre support added. I can't begin to tell you how many people asked me about DROID, so I was happy to see that.
That doesn't come up very often, but in older releases it was a bit of a problem. Now it is simple (server restart required).
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Anthony Lawrence
Find me on Google+
© 2011-07-08 Anthony Lawrence