User Tools

Site Tools


Sendmail has been around for as long as email, even before the '@' sign was invented. It still has the ability to deliver by UUCP if it must. So why choose the upstart Postfix as your mail server?

To truly understand that, we have to start with why NOT Sendmail.

The first, last and all in between reasons are all related to security. when sendmail started life, the Internet was 'arpanet' and consisted almost entirely of a few universities. The net was a small place where most of the people on it were no more distant than a colleague of a colleague or perhaps one of their grad students. It was a place of acedemic discussion and commercial use was strictly prohibited. Abuse was practically non-existant and was primarily in the form of one time pranks.

Literally every mail server on the net was an open relay by design. At that time, the risk of someone not being able to use a mail server was a far greater problem than the risk of serious abuse.

In that sense, the amazing thing about Sendmail is that it was secure and flexible enough to evolve from that environment into the modern Internet and still be a credible choice at all. It is probably the most flexible single piece of software in wide use today (other than Emacs perhaps).

That flexibility comes at a price. The native sendmail configuration is a turing complete pattern matching language! That is, using that language, sendmail can, in theory, be programmed to do anything a computer can do at all. Unfortunately, it's also a completely abstract language that makes few if any concessions to human readability. There's a reason complete sendmail manuals look like a phone book!

In other words, is not ACTUALLY a configuration file, it is a significant part of sendmail itself. It is a computer program written in one of the least readable languages in existance. You don't so much configure sendmail as rewrite it. Even calling it a config file is a terrible boundary violation.

The purpose of a config file is to limit options and narrow the scope of change down so that things that likely need changing are all there and things that shouldn't be changed without a great deal more understanding, consideration, and QA are just not there at all. Configuring software isn't supposed to require advanced programming skills. As a rule, the old method of reconfiguring by modifying the code is best left in the 70's. While there are exceptions to every rule, common configuration of a mail server is not one of them.

In addition, sendmail's unfortunate reaction to a line in that it can't read is to silently ignore it. This means that the slightest little mistake that a doen people can read without spotting the problem can leave you with an open relay.

The config language is, in fact, so obtuse that ANOTHER config manguage has been laid on top of it. That is, you edit (a macro language), and it builds for you. Of course, that too is a bit obscure so most distros layer an additional config file on top of THAT which then builds the mc file that builds the cf file. This cannot be good!

That's not really a slam on sendmail, just evidence that the problem it was written to solve has changed enough that it is no longer the best tool for the job.

Postfix was written from scratch to do the job needed from a modern mail system using the best modern security practices. It mkes liberal use of chroot to limit potential security problems. It also divides the problem into logical seperate programs connected together through TCP and unix socket connections.

By tightly constraining the interaction of modules through narrow communications channels, unexpected interactions are limited. That is, unlike a monolithic system, unrelated functions cannot just call each other (unwisely) at will.

In addition, since it was written with the modern problem in mind, it typically does the right thing by default. The result is short, simple and uncluttered config files that don't overload the admin with irrelevant details.

Further, the most security sensitive portions of the config that might contain database passwords are seperate files that can have access permissions reduced for better security.

Any special requirements are handled by writing new programs in a human readable programming language to take care of it rather than hacking it into a so-called configuration file.

From another perspective, Postfix is designed with the same philosophy that Unix itself is. A series of small simple componants that are good at what they do AND that don't even try to do everything themselves tied together by file like communications channels.

postfix/why.txt · Last modified: 2010/04/15 21:19 (external edit)