Open-source project
vdukhovni/postfix avatar
vdukhovni/postfix

Postfix: the source tree of a mail system that has outlived its corporate owner

Postfix MTA by Wietse Venema

579 stars159 forksCNOASSERTION

At a glance

What is it?
This repository mirrors the Postfix MTA by Wietse Venema, a C mail transfer agent that IBM funded and then released, and it is organised as a set of small daemons with a shared IPC contract. It suits an administrator reading the source to understand the queue, and the licensing and maintenance picture is unusual.
Who is it for?
This repository fits an administrator or a systems programmer who wants to read the Postfix source to understand how a real mail system splits queueing, delivery and filtering into separate daemons, because the README lays the whole tree out as a map of the system. It does not fit a user looking for a modern web mail or a hosted mail service, and it does not fit a team that wants a maintained upstream community rather than a single maintainer with a limited time commitment.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 2 days ago.
What is it written in?
Mainly C, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The README is a road map of the source distribution, not a project page

The document that opens this repository states its own purpose plainly. It provides a road map of the Postfix mail system source code distribution, and it asks the reader to take a few minutes to read the file, to review the RELEASE_NOTES file for incompatible changes, and then to proceed with the INSTALL instructions. That three step instruction is the real documentation structure. The README then maps out the distribution. The RELEASE_NOTES file describes new features and lists incompatible changes with respect to previous Postfix versions. The INSTALL file provides a step-by-step guide for building and installing Postfix on many popular UNIX platforms. The COMPATIBILITY file lists features that Postfix does or does not yet implement, and how well it works with other software. The HISTORY file gives a detailed log of changes to the software, and there is a PORTING file for porting to other UNIX platforms. Documentation is shipped in two formats, an html directory and a man directory, with the man pages reached through the MANPATH environment variable pointed at an absolute path, and the README suggests the HTML interface for faster navigation.

Every daemon has its own directory, and the names describe the job

The Postfix daemons list is the most informative part of the tree, because the names describe function rather than implementation. The anvil directory is the connection count and rate limiter, the bounce directory bounces or defers mail, cleanup canonicalises and enqueues mail, and the discard and error directories are trivial mailers for those two outcomes. The flush directory supports ETRN, sendmail -qI and sendmail -qR. Local delivery lives in local, pipe delivery in pipe, and virtual mailbox only delivery in virtual. The master directory holds the Postfix resident superserver, which is the process that spawns and supervises the rest. The qmgr directory is the queue manager, with oqmgr kept alongside it as the old queue manager, and pickup handles local pickup. On the server side there is smtpd for the SMTP server, smtp for the SMTP and LMTP client, qmqpd for the QMQPD server, and postscreen, described as a zombie blocker, with dnsblog as its DNS agent. There is also a set of less obvious ones, tlsproxy as a TLS proxy for postscreen and outbound connection reuse, scache as the SMTP session cache, tlsmgr for TLS session keys and the random pool, trivial-rewrite for address rewriting and resolving, and verify as the address verification service.

The library routines are shared, and so are the command line tools

Below the daemons sit the pieces that everything else is built from. The library directories are src/dns for a DNS client library, src/global for Postfix specific support routines, src/milter for the Milter mail filter client, src/tls for TLS client and server support, src/util for general purpose support routines, and src/xsasl for the SASL plug-in API. The command line utilities are separate from the daemons and separate from the library, with postalias for alias database management, postcat to list Postfix queue files, postconf as the configuration utility, postdrop for mail submission, postfix as the administrative interface, postkick and postlock for IPC and locking for shell scripts, postlog for logging from shell scripts, postmap for lookup table management, postmulti as the multi-instance manager, postqueue for queue control, postsuper as the housekeeping program, and a sendmail compatibility interface for scripts that expect the old interface. That last one is worth noting for anyone migrating, since it exists so that existing sendmail-style shell scripts keep working.

Ownership was deliberately handed over, and that shapes the project

The history behind the code is stated in the README and it explains a lot about how the project is run. Postfix aims to be an alternative to the widely used sendmail program. Although IBM supported the Postfix development, it abstains from control over its evolution, and the goal is to have Postfix installed on as many systems as possible. To that end the software is given away with no strings attached, so that it can evolve with input from and under control by its users. In other words, IBM releases Postfix only once, and Wietse Venema says he will be around to guide its development for a limited time. That is an unusual and, for a mail system, a deliberate position: the code is complete and the design is settled, and the ongoing work is maintenance and security response rather than feature expansion. The acknowledgements name the alpha testers whose names appear in the HISTORY file, and four colleagues at the IBM Global Security Analysis Laboratory, along with Charles Palmer, under whose leadership the project began and who had the privilege of naming the software, twice.

What is in the source tree beyond the daemons

The rest of the distribution is what makes it buildable and testable. There is a bin directory for the command executables, a conf directory for configuration files and run-time scripts, an include directory for header files, a lib directory for object libraries, a libexec directory for the daemon executables, and a mantools directory for documentation utilities with a proto directory holding the documentation source. Example files come in a conf directory and an examples directory whose contents are described as chroot environments and virtual domains, and a README_FILES directory holds instructions for specific Postfix features. The test programs are worth naming, because they are what a person evaluating the code should look at. fsstone measures file system overhead, posttls-finger is an SMTP and LMTP TLS probe utility, and smtpstone is an SMTP and QMQP server torture test. The implementation-notes directory holds background information. At the top level of the repository itself there is very little, a .gitignore, a LICENSE file, this README, and a postfix directory holding the distribution itself, which tells you this is a mirror of the upstream tree rather than the canonical repository.

Where to send questions, and what the licence requires of you

Support for Postfix is organised around a mailing list rather than a tracker, and the README is emphatic about it. Questions should go to the postfix users mailing list at [email protected], and to subscribe you see the site at postfix.org. The web site there is described as the source of current release information, and the README also points your browser at html/index.html for the documentation and the hyperlinked versions of the manual pages, noting that updated versions are expected to appear online. The licence is the other thing to settle before you copy anything. You must read the LICENSE file if you have not already, and a copy of the LICENSE must be distributed with every original, modified, complete, source or binary copy of the software or parts of it. The README suggests keeping a copy of the file in /etc/postfix/LICENSE. There are no GitHub releases attached to this repository, and the last push was on 2026-09-26, so the version information a package manager gives you will not come from this page.

Editorial conclusion

This repository fits an administrator or a systems programmer who wants to read the Postfix source to understand how a real mail system splits queueing, delivery and filtering into separate daemons, because the README lays the whole tree out as a map of the system. It does not fit a user looking for a modern web mail or a hosted mail service, and it does not fit a team that wants a maintained upstream community rather than a single maintainer with a limited time commitment. Before you build on it, read the LICENSE file and keep a copy of it with any distribution as the README instructs, treat the current upstream site at postfix.org as the source for release information, and read the RELEASE_NOTES and COMPATIBILITY files before changing anything, since both list what changed and what is not implemented.

Frequently asked questions

What is this Postfix repository?

It is a public release mirror of the Postfix mail system by Wietse Venema, a C mail transfer agent that aims to be an alternative to the widely used sendmail program. The top level holds a LICENSE file, the README and a postfix directory containing the distribution itself.

What files does the Postfix README point me to before I build?

The RELEASE_NOTES file for new features and incompatible changes, the INSTALL file for a step-by-step build and install guide across many popular UNIX platforms, the COMPATIBILITY file for what Postfix does and does not implement and how it works with other software, the HISTORY file for a detailed log of changes, and the PORTING file for porting to other UNIX platforms.

How is the Postfix source tree organised?

Into library routines under src including the DNS client, milter client, TLS, SASL and utility code, command line utilities such as postconf, postmap, postqueue, postsuper and a sendmail compatibility interface, and a directory per daemon, among them anvil, cleanup, master, postscreen, qmgr, smtpd, tlsproxy and trivial-rewrite.

Who owns Postfix and what does IBM's role mean?

IBM supported the Postfix development but abstained from control over its evolution, and released Postfix only once. The goal is to have Postfix installed on as many systems as possible, with the software given away with no strings attached, and Wietse Venema says he will be around to guide its development for a limited time.

Where should I ask questions about Postfix?

The mailing list, [email protected], with the README asking that questions be sent there rather than elsewhere. The project site at postfix.org carries current release information and links for subscribing to the list.

Official sources

  1. Issues
  2. README
  3. vdukhovni/postfix on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/vdukhovni-postfix.svg)](https://hysenlabs.com/projects/vdukhovni-postfix)

Was this useful?