Postfix is an MTS for UNIX and UNIX-like systems written by Wietse Venema, and is variously also known as "The IBM Secure Mailer" and "VMailer" (which was its original name before IBM's lawyers discovered a trademark conflict).
It supports most of the more recent innovations that one would expect of a modern mail system:
It has an official web page, but no third-party user-run web pages.
Like MMDF, Zmailer, and qmail, Postfix comprises a suite of small programs, each of which does one particular job.
However unlike qmail, there is not a large cottage industry producing third-party extensions and contributions to Postfix. This is because the modules in Postfix are more tightly coupled to one another and the interfaces between them are undocumented, making it harder to write third-party add-ons and replacement modules for Postfix than for qmail.
Also, this modularity does not extend to Postfix' configuration files. Postfix is firmly in the same camp as exim and Sendmail here. It uses two large monolithic configuration files, master.cf and main.cf, rather than multiple simple small task-oriented configuration files. Like with all applications that choose this route, configuring Postfix thus requires that one learn a set of configuration file keywords, and automated configuration cannot be easily done under script control with echo and cat.
Similarly, this modularity does not extend to the various Postfix dæmons. Postfix does not allow direct fine-grained control over running its dæmons. The dæmon supervisor in Postfix is built in and cannot be replaced. All of the dæmon processes in Postfix are invoked and supervised by a single program, master, which is only indirectly accessible via the postfix command. The Postfix dæmons are not manageable by other dæmon management tools.
Postfix was designed to be secure. It employs most of the security partitioning mechanisms that are employed by MMDF and qmail. But, interestingly, it does not employ them all. Moreover, it has a history of doing things insecurely.
The history involves a glaring omission in the security partitioning, a lack of a secure queue submission mechanism. Postfix traded the appearance of security for actual security. Postfix boasted that as standard it had no set-UID or set-GID programs, which superficially appears to be an attractive feature. However, this boast came at a price. The price is that local users could place arbitrary junk into the mail submission area, or delete submitted messages. Both MMDF and qmail avoid this by having a non-world-writable submission directory and the program that does the writing to that directory (qmail-queue and submit, respectively) set-UID to its owner (the only set-UID program in the entire package in the case of qmail).
After much ruckus, Wietse Venema was eventually persuaded that this idea, pioneered by MMDF over a decade and a half earlier ("Those who fail to learn from MMDF are doomed to reinvent it, badly."), was a good one, and later releases of Postfix included the postdrop command. Even so, for a fair while afterwards, although this command was present, it was not enabled by default as part of the standard installation procedure, and had to be manually enabled, and Postfix still did not default to being secure against this sort of local attack. However, after years of kicking and screaming, Postfix has now finally fully adopted the MMDF security model for queue submission, with its sendmail command invoking postdrop internally. Of course, now Postfix can no longer boast (as it once did) that, unlike MMDF and qmail, it has no set-UID or set-GID programs. The postdrop command is set-GID to a group that can write to the queue directory.
Postfix does not have security partitions between individual, mutually distrustful, elements of the mail system as qmail does, either. Most dæmons run under the same, single, global UID (specified by the mail_owner keyword in main.cf). A compromise of one of those dæmons immediately compromises all of the others, therefore.
Furthermore, Postfix does not even fully utilise the user partitioning capabilities of the operating system to fully insulate users from other users as qmail does.
For example: In both Postfix and qmail, local delivery is performed by a process running under the aegis of the user account being delivered to. However, whilst qmail uses the model of an individual process to perform local delivery that irrevocably drops whatever privileges it has inherited (usingsetuid()), Postfix's local delivery agent only temporarily drops privileges (usingseteuid()) and is a single process switching back and forth between running under the aegis of the superuser account and running under the aegis of various user accounts.With the qmail design, any vulnerabilities in qmail-local cannot result in rights amplification, since that process simply has no ability to change to running as any other user. Moreover, such vulnerabilities cannot result in the ability to affect other, subsequent, deliveries to other users.
Whereas since Postfix's local delivery agent requires, and therefore has, the capability to revert to running under the aegis of the superuser once again, any similar vulnerabilities in Postfix can lead to rights amplification. Moreover, since Postfix's local delivery agent is a single process, any corruption of the process' memory as a result of such vulnerabilities can affect all subsequent deliveries to any users.
Indeed, Wietse Venema has publically stated that he has had to leave features out of Postfix's local delivery agent such as regular expression matching capabilities (that could have provided an extension handling system as powerful as that of qmail) because of this concern.
As with qmail, although there are no set-UID root programs in the package some of the dæmons must, by their very nature, run as root. In particular, in Postfix the SMTP Relay dæmon runs as root. (qmail, for comparison, because of its stronger security partitioning subdivides the task of SMTP Relay dæmon into distinct subtasks, and root privileges are in fact dropped before qmail-smtpd is even run. It runs as user "qmailr" instead.)
Which dæmons in Postfix run as root is not documented in the manual pages.
Postfix contains numerous configuration options, particularly in the area of SMTP Relay service. However, the flexibility of Postfix is in many ways illusory. Many of the configuration options control features that are half-baked ideas from the Half-Baked Ideas Brigade.
For examples:
The smtpd_helo_restrictions configuration option in Postfix allows all sorts of incorrect restrictions to be placed upon the argument to a HELO or a EHLO verb in SMTP. This is based upon some erroneous notions of what the purposes of those verbs are, and causes interoperability problems with legitimate and legitimately configured mail softwares.
The reject_unknown_client mechanism in Postfix is based upon the erroneous notion that every IP address used by SMTP Relay clients must have a mapping, published in the public DNS database, to a domain name, and that there must be a further published mapping leading back to that IP address. This is, of course, wrong. The DNS simply doesn't work that way.
By its very nature, the development of Postfix has been unable to resist incorporating most of these half-baked ideas. (Wietse Venema has so far successfully managed to resist incorporating SPF, yet another half-baked idea.)
Worse yet, the Postfix documentation consistently in several places encourages amongst mail administrators the false belief that an SMTP Relay client, that suffers when these half-baked ideas are enabled, is "broken or misconfigured software", and implicitly blames the interoperability problems on the claimed fact that there are "a lot" of such softwares on Internet.
The irony is that the reasons that to Postfix there appears to be "a lot" of such softwares are that the Postfix world view is wrong ("All of the other cars on the highway are driving in the wrong direction."), and that it is in fact the use of these flawed mechanisms in Postfix itself that is what is actually "broken or misconfigured".
There are several different "mbox" formats. MTSes such as qmail use the "mboxrd" format, which uses a reversible encoding of "From " lines in messages. However, Postfix uses the older "mboxo" format instead. The encoding of "From " lines is not reversible in this format, and where the original message contained a "From " line there is no means for an MUA to obtain the message in its original form as it was before Postfix delivered it to the mailbox. This is the very problem that Rahul Dhesi's proposal addressed.
Both MMDF and qmail are capable of minimising the requirements for DNS service that their SMTP Relay clients and servers have.
For example: With qmail, the SMTP Relay client will not perform DNS lookups to find SMTP Relay servers if information in control/smtproutes is available, and if the SMTP Relay server is invoked from tcpserver the SMTP Relay server will not perform DNS lookups if tcpserver has been configured not to actually obtain domain name information.
Whilst Postfix's SMTP Relay client can also be configured to override what is in the public DNS database, and its SMTP Relay server can also be configured to not make use of the domain name information for its clients; the actual DNS lookups are still performed, even if the information that they obtain is never used. Overriding the DNS database and ignoring domain name information does not actually turn the DNS lookups off in Postfix as it does with other MTSes.
This is a significant factor for isolated systems, or for systems with expensive links to their proxy DNS servers.
One further minor annoyance with Postfix when it comes to DNS is that it consistently mis-uses the term fully-qualified domain name (in its reject_non_fqdn_sender mechanism, for example) to mean a domain name that comprises more than one label. A fully-qualified domain name is in fact something else entirely, and may comprise just a single label (localhost. being one commonly used example of a single-label fully-qualified domain name).
With Postfix, each user controls all local parts that begin with the user's username, allowing each user to have an unlimited number of different local parts. Delivery to each local part is (optionally) controlled by a separate ~/.forward+* file in the user's home directory.
However, unlike qmail, Postfix only supports the one level of address extensions, and not an unlimited number of them as qmail does.
Unlike qmail, Postfix does not provide two (either logically or physically) separate paths for locally and remotely injected mail. It has one path for both. Mail received via Postfix's SMTP Relay server is still passed through its cleanup mechanism before it reaches the mail queue.
The unfortunate consequence of this is that inbound or in-transit mail is modified by Postfix locally. Mail that, as sent from the originating system, had missing headers will have those headers added by Postfix. Mail that, as sent from the originating system, had headers with mailbox names that were not in canonical form will have those headers converted to canonical form by Postfix. In both cases, the addition or conversion will occur locally, at the receiving end and using local domain names and transformation rulesets.
Of course, this is invariably wrong, and is the same bad behaviour that has caused many people to switch away from Sendmail over the years. More often than not it obscures actual operation and hampers problem diagnosis. It also causes problems of its own (such as altering the meanings of the headers for in-transit mail that passes through an MTS relay that is using Postfix).
Other MTSes provide drop-in replacements for /usr/lib/sendmail, for the benefit of MUAs that don't know any other way of submitting mail locally. Usually these are just shims around the MTS' own native mail submission mechanisms (such as MMDF's submit, qmail's qmail-inject). In Postfix, however, the sendmail command is the primary interface to using the mail system. (The postfix command is, similarly, the primary interface to administering it.) There is no other official way of submitting mail to Postfix, as there is with other MTSs.
It is debatable whether this is a good design or not. On the one hand, Postfix is compatible with everything that expects to use the name "/usr/lib/sendmail" to communicate with the MTS. On the other hand, however:
Postfix uses /etc/aliases, recognises and obeys ~/.forward files, and delivers to "mbox"-style mailboxes in /var/spool/mail. ("Maildir" format mailboxes are supported as an option, however.) Again, it does not have more powerful mechanisms of its own that can be used instead. These are its native mechanisms. Postfix is largely only as flexible as Sendmail is.
Postfix is only available in source form, not as precompiled or prepackaged binaries. There is a list of FTP sites that hold the source tarball on the official web site.