Saturday, May 14, 2011

mailserver A is "inherently" better than mailserver B

For GNU / Linux there are several good mailserver packages.

Here are a handful (in alphabetical order):
  • Exim
  • Postfix
  • Qmail
  • Sendmail
There are others, but for the purposes of this article that is enough to go on.

Each of these packages will have their own fanbase. If you have a long history with Plesk hosting automation, then you might well love Qmail ... why? Because you know it inside out.


Exim 4 is inherently more secure than Postfix:

No it is not.

Neither is Exim 4 inherently less secure than Postfix.

But there was recently a vulnerability in Exim 4 around dkim signatures?

Yes there was. Debian users should have the security repository of Debian active (by default) and automatic updates (usually active by default on login to Gnome).
( See links at the end for further information about Debian and automatic updates)

However postfix does get vulnerabilities also.

Mailservers are complicated and involve a huge codebase. Recent changes have been made, particularly to incorporate functionality around dkim.

When humans code, other humans will review and sometimes mistakes will be found and then corrected.


But what about Qmail - there is a stable codebase that has changed little in 10 years? Well Qmail has a small core codebase and recent functionality is added via patches. Is this a better way to maintain a mailserver? You decide.


Debian and Automatic Updates:

For Gnome desktop users (including Ubuntu migrants), the easiest way is to install update-manager-gnome

Here are some other useful packages if you run a different desktop, or prefer to have updates happen, without a graphical interaction:
  • cron-apt which is a utility for background download (optional email output)

        [ once installed issue  ln -s /usr/sbin/cron-apt /etc/cron.daily/ ]
  • aptdaemon another daemon, that can be used with user privileges and an optional frontend

  • package named unattended-upgrades (see below)


If you are really comfortable with cron anyway, you might just want something like this for your updates:

50 11  * * * ( apt-get -q update && apt-get -qy upgrade -u )



The Debian project, and how an active upstream can influence choice:

Distributions are a little like biological systems in some ways, things become more popular, things become less popular. Not unlike natural selection in a fashion.

One of the things that Debian novices and even some experienced SysAdmins do not appreciate, is the importance of 'upstream'

It might be the tastiest code morsal your system has chewed in years, however somebody has to package the thing and maintain it
  
If upstream is inactive or uncooperative (it does happen), then it sometimes can put undue pressure on the maintainer.

With no upstream support, a complex package, will perhaps, have more outstanding bugs, or the maintainer might decide the weight it too much to carry alone.

Even if you are not doing Debian packaging, but might be making a commitment to a certain mailserver, then do ask about upstream.

How active is the upstream of Mailserver A?
How active is the upstream of Mailserver B?


If you are going to build a business around systems that include mailserver installs, then you want to know this!

Here is Exim own bug tracking system - how convenient :)


Crackers and mailservers - the case for mailserver diversity:

( Crackers: Folks who break into systems - think hackers if that is clearer for you )

If there was only one single GNU / Linux distribution, and every desktop and server in the world was GNU / Linux - wouldn't the world be great!

Well actually, NO.

Folks who make a business out of breaking into systems, have a skillset, just like regular developers and System Administrators.

The less the diversity in commonly run server based services, the better for the cracker.

In todays diverse GNU / Linux world that cracker is not going to just crack mailservers, he will likely have a toolkit of useful things s/he is knowledgeable in. SSL, file obfuscation, whatever.

However the wider the skill set required to be effective, the fewer people will be drawn into seeing 'blackhat' activities as an easy career.

Now if that cracker wants to compromise the mail server on a Red Hat system, then he needs to know Sendmail and it's vulnerabilities / attack vectors.

Now if that cracker wants to compromise the mail server on a Plesk automation system, then he needs to know Qmail and it's vulnerabilities / attack vectors.

Now if that cracker wants to compromise the mail server on a Debian system, then he needs to know Exim and it's vulnerabilities / attack vectors.

This is all assuming that the mailserver administrator has just 'gone with the flow'. They might not, they might have installed any of the 4 mailservers in my original list.

You know the Red Hat admin might have installed Exim, or the Debian admin might have installed Postfix.

My point is, that reducing diversity in mailservers, to the point that there is only one type of mailserver, might be considered making it easy for crackers.

Modern day cracking toolkits have lowered the barriers to entry for crackers somewhat. Let's not make it too easy for intruders by trying to extinguish choice through rabid fanboyism.

There are arguments for 'biodiversity' in the plant world. In this article, I have presented one argument for diversity in server based services.

I personally hope Qmail is around for another decade ... my argument for diversity.


Notes and Further reading:

An Extract from the Exim4 description:
If you build exim4 from the source package locally, you can also build an exim4-daemon-custom package tailored to your own feature set.

If your business is going to create some custom functionality around a mailserver, then that sort of thing might appeal.

Here is an example of the type of debate that starts up when somebody asks "What mailserver for Debian".
( Nothing wrong with that sort of discussion, however do bear in mind my earlier point, about mailservers and fanbase. )
Posted by at
Labels: , , , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)