Engineering Confidence

Acknowledgements

About the Author

Introduction

1. qmail did not live in the lab
2. Years of other systems
3. What confidence means here
4. How to read the case
5. Returning to qmail
6. What this book is
7. qmail did not live in the lab
8. Years of other systems
9. What confidence means here
10. How to read the case
11. Returning to qmail
12. What this book is

Chapter 1: The Mail Server Everyone Used

1. Email was messy
2. Sendmail adapted to a moving world
3. Mail servers are dangerous programs
4. The Internet learned this early
5. Why qmail appeared
6. Sendmail adapted, qmail distrusted
7. The question

Chapter 2: Bug-of-the-Month Club

1. Why MTAs were exposed
2. Sendmail was part of that climate
3. The fair version
4. Operational fatigue
5. Why the advisories matter

Chapter 3: Enter D. J. Bernstein

1. The academic outside the vendor economy
2. Code as public argument
3. A larger software style
4. Confidence and refusal

Chapter 4: A Mailing List, a Frustration, a New MTA

1. The mailing list mattered
2. What the workload revealed
3. The early timeline moved fast
4. Compatible at the edge, different inside
5. Impatience with preventable failure

Chapter 5: The Design Bet

1. Three ways to make software safer
2. Eliminate bugs
3. Eliminate code
4. Eliminate trusted code
5. The rules
6. Patterns, not magic

Chapter 6: The First Release

1. Why that matters
2. Adoption
3. Why people used it
4. The frozen core

Chapter 7: No One Program Wears Every Hat

1. Mail transfer is not one job
2. Why this helps security
3. Why this helps reliability
4. Performance comes along for the ride
5. The cost

Chapter 8: The Trust Map

1. What the guarantee says
2. The map
3. Keep privilege narrow
4. Distrust between components
5. A bug is not enough

Chapter 9: Don’t Parse

1. Why parsing is dangerous
2. Sendmail had a reason to parse
3. The concrete contrast
4. Programs and files are not addresses
5. Move the complexity
6. The modern lesson

Chapter 10: The Queue as a Reliability Machine

1. Accepted means accepted
2. Queue insertion and queue management
3. A message has a lifecycle
4. The queue has shape
5. Queue lifecycle diagram
6. Performance is part of reliability
7. Simple does not mean casual

Chapter 11: Maildir and the Filesystem

1. One message, one file
2. Maildir lifecycle diagram
3. Why NFS mattered
4. Unique names are part of the design
5. The qmail pattern again
6. Why it lasted

Chapter 12: Small Code, Fewer Bugs, Less Trusted Code

1. Bernstein’s framework
2. Smaller code
3. Less trusted code
4. Trusted code is a user question
5. The question to ask

Chapter 13: The $500 Security Guarantee

1. What the challenge did
2. What counted
3. The guarantee grew a history
4. The legend simplified the claim
5. Why the guarantee mattered

Chapter 14: What Does “No Security Hole” Mean?

1. What qmail’s guarantee covered
2. Boundaries are contested
3. This is not only a qmail problem
4. Scope is a design artifact
5. A useful table
6. The deployment proof
7. The problem with the phrase

Chapter 15: Guninski, 64-Bit qmail, and the Uncomfortable Edge Case

1. What changed
2. Bernstein’s response
3. Why 64-bit mattered
4. The uncomfortable admission
5. Time is part of the threat model

Chapter 16: Qualys Reopens the Case

1. The main target
2. From qmail-smtpd to qmail-local
3. Documentation and defaults
4. What changed between 2005 and 2020
5. The practical lesson

Chapter 17: The Cost of Being Right in a Particular Way

1. Licensing
2. Patch culture
3. Patches change the artifact
4. The TLS example
5. Correct ideas need a path to users
6. The lesson

Chapter 18: Postfix, OpenSMTPD, and the Children of qmail

1. Postfix
2. OpenSMTPD
3. A comparison
4. The children are not clones
5. What qmail did not decide
6. No hero worship

Chapter 19: What Aged Well

1. Privilege separation
2. Small trusted cores
3. Parsing skepticism
4. Maildir
5. The queue as a promise
6. The public challenge
7. What to keep
8. The best question

Chapter 20: What Did Not

1. The frozen upstream
2. Patch culture
3. Licensing
4. C integer assumptions
5. Documentation of assumptions
6. Mechanisms that spent complexity badly
7. Communication style
8. The guarantee repeated badly

Chapter 21: The qmail Lesson

1. The historical lesson
2. The engineering lesson
3. Confidence is structural
4. The evidence should be visible
5. Definitions matter
6. Maintenance matters too
7. What to take forward
8. Confidence has to pass through reality

Appendix 1: Engineering Confidence Checklist

1. 1. Define the claim
2. 2. Draw the authority map
3. 3. Find hostile input and parsers
4. 4. Separate acceptance from completion
5. 5. Make failure states inspectable
6. 6. Name environmental assumptions
7. 7. Define what would falsify the claim
8. 8. Preserve the argument during change
9. Short version

Appendix 2: The Bernstein Design Family

1. Small programs with hard edges
2. Separate roles other systems combine
3. Privilege is something to shed
4. Directories as control planes
5. Durable success before saying yes
6. User control without broad authority
7. Refusal as a design tool
8. Configuration should be generated, checked, or local
9. The shared argument

Appendix 3: qmail and Zero Trust

1. The perimeter moves inward
2. The closest overlaps
3. Components are not automatically friends
4. Least privilege as structure
5. Blast radius matters
6. Hostile input is not only remote input
7. Fixed policy instead of dynamic policy
8. A useful mapping
9. The lesson