 |
|
^ click above ^ |
02.19.04
 By
A.P. Lawrence
The Kerio
Mail Server is a cross platform ( Windows, Linux, and Mac OSX)
mail server. I tested it on RedHat Linux 8.
Before we get into the details, let me say that I was very
impressed. This is well done, and they have paid attention to important
details. I have a few minor nit-picks here and there, but over all
I can highly recommend it.
As some of the people reading this will be aware that I also sell
the SME Mail Server,
I'll also offer some comparisons between these very different approaches
at the end of my review.
Installation
This was actually the most annoying part of the entire process. I
say that not because it was horribly difficult, but only because it
could have been much easier. Neither the enclosed manual nor the CD
were particularly helpful. The manual tells you that you install Linux
RPMS, but doesn't tell you where they are on the CD. Of course, they
aren't very hard to find, but the CD directories are Windows/Mac GUI
style: imbedded spaces in directory names, making it annoying to navigate
from the command line. I've said this more than once: just because
you CAN use spaces in a directory or file name doesn't mean that you
SHOULD. But as all the regular readers know, I'm a grumpy old curmudgeon
and you should ignore me when I start muttering about these things.
(Kerio tech support read this and noted that most people just download
the software rather than getting the CD, but did agree that the spaces
should be changed to underscores and promised to do that).
I found the kerio-mailserver-5.62-rh7.rpm and the kerio-mailserver-admin-5.62-rh7.rpm
and installed both.
The manual tells you to run /opt/kerio/mailserver/wizard for initial
configuration, but it is actually "cfgwizard", not "wizard" (Kerio
says they'll fix that next release of the manual). There is very small
notice of things you will have to do to an existing Linux server,
such as disabling sendmail and other mail related things you may have
running (POP3), changing firewall rules, etc. You probably shouldn't
be installing this if you aren't comfartable with Linux. Yes, they
do have a Windows version, but you can probably well imagine my horror
at running a mail server on Windows!
Kerio tech support noted that I missed this:
When you install the RPM, it gives you a note to read /opt/kerio/mailserver/doc/REDHAT-README,
which actually contains instructions on how to stop and disable both
sendmail and, and how to tell (netstat -tlp) what network servers
are running. |
Admin
Console
The Admin package can administer servers on any platform, so I installed
the Mac OS X version of that. That had a few resolution or screen
placement problems; some controls were slightly distorted or out of
place, but it worked fine. Here's a screenshot:
Kerio Admin
Mac OS X administering Linux Server
Notice the "Edit" button is slightly skewed. No big deal, of course.
The Linux admin console had no such glitches administering its own
server. This screen also shows the definition of IP Address Groups,
which will be mentioned later.
The main Administration Console offers four major
groups: Configuration, Domain Settings, Status, and Logs. There is
some overlap here and there; for example you can configure basic SMTP
access under Configuration->Services, but relaying is configured under
Configuration->SMTP Server. That actually makes sense: if, for example,
you configure SMTP Services to accept connections only from the local
lan, any attempt to access port 25 from outside the lan will be rejected.
Within SMTP Server, you can control relaying (even down to individual
hosts). This is very welcome.
Services
Every service (SMTP,POP3, Secure POP3, Imap, Secure Imap, Webmail,
Secure Webmail, Ldap, Secure Ldap) can be turned on and off, set to
start automatically or manually, can be set to run on a non-standard
port, and access can be set down to the host level.
Access to services means that your connection attempt will be refused
if you aren't allowed access. By default, all services are running,
started automatically, and not blocked at all. To add access control,
simply edit the service you wish to control, and check "Allow access
only from selected ip address group". You'll see this same control
in other places, and it is quite well done. Basically you create "groups".
A group can contain specific hosts, ip ranges (by beginning to end
or by netmask) and other groups. This lets you be very specific about
access control, although there's no exclusion here, only inclusion
(you can blacklist specific hosts/groups at the SMTP server level
though). I'd like to see exclusionary capability here, too (of course
you could always do this at the Linux firewall level).
Domains
Domains can be independent or aliased. For example, I can have "apl.org",
add users to it, and if I add an alias "aplawrence.org", mail to a
user in either domain will go to the same account. However, if I create
a separate domain, "foo.org", a user added there is entirely different
from those in "apl.org" and "aplawrence.org".
Within Domains, you can specify a footer to be added to each email
sent from that domain, forwarding to another SMTP server/port for
unknown users, and even specify active directory or kerberos servers.
A domain can be bound to a specific IP address. Forwarding can be
immediate, scheduled or triggered by ETRN from the other server.
Delivery Queue
Here you have the choice of using direct MX record message delivery,
or a relay server. This section also lets you specify how often to
retry delivery, when to warn the sender of delivery problems, and
how many days to wait before giving up entirely. It is very nice to
have such full control.
SMTP Server
By default, the server won't relay (deliver messages to users outside
of its own domains) for anyone, not even a user logged on to this
machine. You do have the option of setting it to be an open relay,
but it's not likely you'd want to do that. You have the ability to
use the access groups as mentioned under Services above, or you can
require SMTP authentication, or allow relay if the user has authenticated
by POP3 within some period of time you specify.
You can also specify Blacklists. There are built in selections (www.mail-abuse.org
and www,ordb.org), and you can specify your own, again using the Access
List method. The combination of IP address groups and blacklists gives
you very precise control over who can use your server and who can
send you mail.
 |
There are more Security options here: you can specify a maximum number
of messages per hour from one ip address, a maximum number of concurrent
SMTP connections from one address, and also a maximum number of unknown
recipients (that could be an indication of spamming). You can specify
an access group that these limits do not apply to, which might allow
more freedom to local users etc. These types of controls have become
much more important in recent years.
You can block if the sender's address doesn't resolve with DNS (another
anti-spam control) and specify the maximum number of recipients you
will accept in one message. Other useful anti-abuse controls include
limiting the number of failed SMTP commands (for example attempts
to relay or send to unknown users) and can reject messages that have
gone through too many relays prior to getting here. Finally, you can
specify a maximum size for messages. That's a global limit that is
above the user quotas that can be applied individually.
Spam Filter
The Kerio Mail Server uses SpamAssassin,
and gives you full control over its configuration, including the ability
to add rules to accept or reject messages regardless of SpamAssassins
scoring, or increase/decrease the score. You also get full control
over the disposition of messages: add a Spam header, discard it, return
to sender, or forward to some other address. I really like that level
of control, especially being able to "whitelist" senders. Read
The Whole Article
About the Author:
A.P. Lawrence provides SCO Unix and Linux consulting services
http://www.pcunix.com
|
| From the Forum: | | return addresses generated by viruses |  Viruses
generate e mails from an infected computer using any and all
addresses that are in that computer (address book, cached
web pages, etc.) EXCEPT that of the infected computer (usually).
Of course, you will not find those messages in your sent box,
because the virus sets up its own e mail system...
|
|
|
