What is notqmail?
It's not qmail. It's also not netqmail.
We all use email, so we all use email servers. notqmail is software for running an email server. Someday, if we do a good job, some of the many articles about how and why to run your own will recommend notqmail.
notqmail is a community-driven fork of qmail, beginning where netqmail left off: providing stable, compatible, small releases to which existing qmail users can safely update. notqmail also aims higher: developing an extensible, easily packaged, and increasingly useful modern mail server.
Why should I trust notqmail?
Watch what we do and how we do it; then decide.
This is a big question and it deserves a thorough answer.
We have come to trust qmail, as you have, for at least these reasons:
- Simple, elegant design
- Very few bugs
- Stable in production
It's for these reasons that we're motivated to continue developing qmail to meet modern needs.
None of us can do what DJB did. One mitigating factor here is, we're not trying to do what DJB did. He had to write qmail from scratch; we have the advantage of existing designs, interfaces, implementations, and decades of running in production. We also enjoy the privilege of using the latest techniques and tooling. But the two biggest mitigations we have are:
- Working in public
- Shipping frequent small releases
"Working in public" means we're thinking out loud, showing our work, reacting to reviewer feedback, and making our decision-making process as explicit as possible.
"Shipping frequent small releases" means
- Our previous release will always have been fairly recent, so we’ll remember how to do it carefully
- Our next release is always fairly soon, so we’ll design and review a little extra carefully
- Any given release contains relatively few changes, so our users can probably vet them a little extra carefully
None of us can hold in mind all simultaneous details the way it seems DJB must have. As a community, though, we might manage to make very few terrible mistakes that survive for long.
DJB's code was trustworthy. netqmail's small, conservative patchset was trustworthy. We intend for our development process to be trustworthy. If you find otherwise, we'd be extremely grateful to hear your doubts and concerns. But if you decide we're being consistently careful, thoughtful, reasonable, and practical, we hope you'll update to notqmail.
Our starting point for this project is netqmail 1.06, with previous netqmail and qmail releases also tagged in the repo.
What are the project's goals?
We'll trade away other things to get these.
- Preserving qmail's hard-earned security properties
- Implementing new features (or alternatives to core components) as "extensions"
- Adding interfaces and seams, where needed, to make extensions possible
- Encouraging multiple initial implementations of X, for any X
- Following consensus, merging the best aspects into one implementation
- Providing sensible defaults and easily configured runtime options
- Providing a safe update path for qmail and netqmail users
- Providing safe, easy, regular updates for notqmail users
- Gradually reducing the marginal cost of developing notqmail
- Being easily packaged by OS integrators
- Meeting all common needs with OS-provided packages
- Earning community trust as the authoritative open-source successor to qmail and netqmail
What are the project's non-goals?
We'll trade very little of these to get other things.
We wish to avoid:
- Breaking compatibility
- Breaking existing features of the architecture
- Breaking your patches more than necessary
- Modifying or replacing core components
Given the reasons qmail is valuable to us, the cost of a change that exhibits any of the preceding non-goals is high. Proposing one such change will require unusually strong justification, documentation, testing, and design. For the community to accept such a change, the risk must be demonstrably very low and the benefit very high.
Which features will eventually be implemented?
All the important ones.
Some known big ones:
- SMTP recipient validation
Need something else? Tell us about it.
Our roadmap describes our plans in somewhat more detail.
Which implementations won't last forever?
Some designs are more qmail than others.
There are many, many patches out there. Needless to say, not all of them meet notqmail's design goals. Two examples of popular, well-loved patches we've personally used and appreciated that could make useful "extensions" starting with 1.9, but would likely be superseded in the course of time:
- The Qmail-TLS patch, because a more qmail-ish design is available: Erwin Hoffmann's ucspi-ssl implements UCSPI-TLS, handling TLS in a separate and privilege-separated address space
- Any of the usual SMTP AUTH patches, because a more qmail-ish design is available: Amitai Schleier's acceptutils extends qmail's POP3 authentication architecture to SMTP and OFMIP, enabling new user-controlled features
What happens to my custom patchset?
Expect your patchset to:
- Mostly continue to apply
- Gradually shrink as new notqmail releases include more of the features and bugfixes you need
- Eventually shrink to zero, if your needs are widely shared by others
For more, see Patches.
How do I install notqmail?
It's not incapable of installing to
How can I get more involved?
Be part of the revival!
We invite users or enthusiasts of qmail to join us. We especially hope for:
- Ideas and feedback from those of you running (or not quite running) qmail
- Code from those of you with custom patchsets or forks
Say hi on the list or IRC and one of us will help you get started on your first contribution.
Are DJB or any of the netqmail authors involved?
We'd love to have them, of course.
Neither netqmail nor DJB were asked to approve of this distribution.
qmail security guarantee apply?Does the
We warrant that we've made a good-faith attempt to ensure that the software behaves correctly.
Sorry, no. We're not DJB, and notqmail is not qmail.
Why not Postfix?
We know you're wondering.
Postfix is very good. We also really like qmail.