Sponsorship Open: “Run Your Own Mail Server”

The title kind of says it all.

I have also made an early draft of Chapter 0 available to help explain what the book is and is not. Before you start sending me corrections, check the disclaimer at the top.

Despite inflation, I have not raised the price of sponsorships. I have passed through the shipping charge for print sponsors, however, so I’ve totally raised the price. But it’s transparent, and relative to where you live. Note that the shipping is per-continent, not calculated live. I can’t calculate shipping for something that doesn’t even exist yet.

And yes, I’m building a Kickstarter into this book’s production plan. That will be more of a pre-order, although I do have some thoughts on how I can use Kickstarter to enhance the book. The Kickstarter will replace a direct pre-order, as an experiment.

Running your own email is a struggle against an opponent you can’t see. That’s why the cover is a take on Battle of Vimy Ridge. You’ll be able to buy Eddie Sharam’s original painting, either through the Kickstarter or direct auction. It will be a full wraparound cover, but here’s the first draft of the front.

Now, if you’ll pardon me, I have to go shell gmail. Uh, figure out why they’re not taking my mails, I mean.

“Run Your Own Mail Server” chapter 0

I’m about to open “Run Your Own Mail Server” for sponsorships. This book is a little different than most other books I’ve written, so I’m sharing the introductory chapter.

This is uncopyedited. Unreviewed. It exists to illustrate scope, not for folks to send me corrections. Yet. Before I complete the book, I will probably discard and redraft this chapter. Bridge Out Ahead. Slippery When Wet. No warranty of fitness for purpose. Probably causes cancer, chin hemorrhoids, and alternaria leaf blight.


Chapter 0: Introduction

Email is the beating heart of the Internet. Yes, over the last couple of decades online forums and social media and chat systems have blossomed and thrived, but we keep returning to email. Email works everywhere with an Internet connection, and many places without. Unlike chats, where the other people involved see that you’ve received their message and are choosing to ignore them, you can answer email when you feel like it. Your correspondents don’t get a notification that you’re typing a reply and watch the screen until you compose words. Email is one of the few surviving asynchronous communication tools, making it uniquely useful.

The first email was sent in 1965, when the Internet was only a drunken dream of comp sci grad students. When computers finally achieved a network, those ragtag students developed the primordial Internet protocols. Today’s email looks nothing like theirs—for one, email addresses have those esoteric @ symbols in them rather than nice simple exclamation points. Modern email is built on those primordial protocols and the lessons learned from them, however. That’s not bad—all broadly used protocols evolved the same way, even if they’re not as ancient. Today, a handful of providers dominate email services. Companies like Google and Microsoft control most email addresses. They’re an Email Empire, while those of us who run out own email form our own ragtag band struggling for independence. It can be done. The protocols are comprehensible, the software freely available, the debugging tools comprehensible and the hardware affordable.

The problem with running email has nothing to do with the technology. With the right knowledge, you can set up an email server in moments. The problem is that the email server is only one part of running an email server.

Consider setting up your first web server. You install the program, start it, and point your web browser at the server’s IP address. You get the server’s default page and a warm thrill of victory. You have a web server! If you put content on it, you can tell your colleagues “Hey, browse to and you’ll find my new web site!” It’s a thing. Add an entry in the Domain Name Service (DNS) and you can offer folks a link like http://mwl.io. More testing and you add TLS, granting you the precious S in https. Step by step, you build a web site that complies with modern standards.[1]

Email isn’t like that.

Running email in the real world is not configuration problem. It is about citizenship. Once the Email Empire decides that your server is inadequate or untrustworthy, it’s very hard to get them to change their mind. You must solidly participate in the email society before sending your first email to the outside world. Sure, you can set up a couple of throwaway hosts on expendable domains and and bounce email exclusively between them to see how the software works, but if you want to run a real email server, you must do it correctly right from the beginning.

Once you establish your system as a good citizen that follows standard practices, however, operating a mail server is comparatively low maintenance. Most of the time I spend on my email server is spent applying security patches. Running a mail server for a large corporation is a full time job, yes, but most of that is spent explaining to users that a bounce message of “The recipient’s email account is over quota” means that the email bounced because the recipient’s email account is over quota.

Run Your Own Mail Server uses common freely available software to illustrate the mechanics of serving email, but the book’s main focus is on establishing that citizenship. You can use any software you like that fulfills the necessary roles.

Why Bother?

If email is such a pain, why run it?

First, for privacy. Service providers often scan email for advertising keywords or saleable personal data. While ad blockers keep the ads from your face, it solves the problem at the wrong end. Yes, if you email someone in the Email Empire address the Empire can tie the content to their records about your email address, but when you correspond with other outsiders they can’t. Email can be intercepted, but that interception takes work.

Privacy is especially important in business. A service provider might promise to not mine your company emails, but a sysadmin might have to examine your email to fix issues. A long time ago, at an employer far far away, I had to troubleshoot a server problem caused by a user innocently attaching a word processor document to a mail. That was its own special fun, but—I had to examine the characters in the document to solve the problem. I saw parts of the document. While most of email’s rough edges have been burnished off since, violating privacy during troubleshooting remains a real possibility.

You control your own email. Many service providers offer fancy dashboards that let you add and delete users or set quotas, but when something goes sideways you’re stuck working with their support department. The quickest way to identify a problem is to check the log. Waiting for a support tech to answer your trouble ticket is infuriating. When you run your own email, you control the problem.

Perhaps the least valid but most important reason for many is pure “geek cred.” We want to know how things work. Just as building your own firewall is a great way to learn about networking, running your own email server is the best way to understand this ecosystem. You run your own web server, DNS server, cloud storage and home automation, why not run your own email? You can, and you will learn a lot.


Operating an email server is not a task for a beginner sysadmin. You must have a specific skill set before you can start.

You must have used email. You must be aware of things like email addresses, attachments, and related concepts.

You must know how to manage your operating system. This book assumes and recommends open source software. You need to back up your servers, apply security updates, and in general make your hosts fit to sit on the naked Internet. I demonstrate everything with Postfix on FreeBSD, but provide the context for all my configuration choices so you can make your own decisions.

You need at least two test hosts attached to the Internet. These could be minimal virtual machines out in the cloud, hosts in your lab, or whatever. Tests inflict negligible hardware load. These hosts need different, unchanging IP addresses. You must also control the world’s access to those addresses, as email requires opening several TCP/IP ports to and from the servers. Most home Internet providers specifically block these ports.

You must control the forward and reverse DNS for your test hosts. Supporting email for a domain requires creating several DNS entries, and you might need to change those entries. Similarly, the reverse DNS must match the hostname and the forward DNS. If your host advertises its name as mail.solveamurder.org, but reverse DNS identifies your host as customer87.chicago.bighosting.com, your email will go nowhere. You must have correct reverse DNS on all IPv4 and IPv6 addresses. Follow best practices and have separate authoritative and recursive nameservers. The recursive nameservers should validate DNSSEC.

An understanding of basic public key cryptography is also essential. You don’t need to grind through Diffie-Hellman calculations by hand, but you do need to know the difference between public and private keys and how they’re used. You must routinely protect private keys. Similarly, you need a basic understanding of TLS. Users must authenticate to check their email, and sending usernames and passwords in clear text across the Internet is unwise. The X.509 certificates needed for TLS used to be very expensive, so by tradition SMTP does not require TLS. Certificates prices have plunged to zero, so there’s no longer an excuse to not use TLS. This book uses Let’s Encrypt certificates.

We will also use outside services to support email troubleshooting. These are all services that require writing custom code, a skill orthogonal to running a mail server. I’m certain that someone will release a package that handles these features, probably immediately after this book comes out.

If you lack any of these skills, permit me to recommend my books Absolute FreeBSD, 3rd Edition (No Starch Press, 2018), Networking for System Administrators (Tilted Windmill Press, 2015), and TLS Mastery (Tilted Windmill Press, 2021). I also recommend Cricket Liu’s DNS and BIND (O’Reilly, 2006).[2]

From now on, I will toss around terms like network port and X.509 certificate and floccinaucinihilipilification and expect you to know what they mean. You cannot suffer from hippopotomonstrosesquippedaliophobia and run an email server.

Email Tools In This Book

Email isn’t a server, it’s a system with several components. The most obvious is a “mail server.” The mail server accepts email from users and exchanges mail with other servers. Most of the system speaks the Simple Mail Transport Protocol (SMTP). This book uses Postfix (https://www.postfix.org) as a reference platform.

Your users would probably like an option to check their email from their desktop. This might use a mail client like Thunderbird, using a protocol like IMAP. We’ll demonstrate clients and IMAP with Dovecot. Other users prefer a web interface, so we’ll discuss <<<pick one that speaks imap>>>. We’ll debug with mutt (https://www.mutt.org).

Once you have the core system working and can send email locally, you’ll need basic antispam protections. We’ll discuss greylisting and DNSBLs.

You can now risk telling the world about your mail system via DNS. This routes us into topics like Send Permitted From (SPF), and Domain Keys for Internet Mail (DKIM). With those basics you can look at acronyms like DMARC, BIMI, MTA-STS, and TLS-RPT. The main goal of this book is to teach you about these tools and protocols so that you can improve deliverability of your email.

We will focus on modern email. While some networks still rely on UUCP and bangpaths and POP3, those are vanishingly rare. Don’t deploy them on the modern Internet.[3] We will also ignore proprietary replacements for these protocols. Many mail service providers offer a convenient API that replaces SMTP or IMAP. There’s nothing wrong with using these if you’re willing to accept the vendor lock-in, but this book doesn’t cover them.


Your users expect their email to reach the intended recipient. Deliverability is how well mail from your system fulfills this expectation. Before spam, deliverability wasn’t a huge issue. In the 1970s and early 1980s you might have to route your email through U of C Berkeley to MIT to the Imperial College of London to TAMK, but it was a well-understood problem. The decade of 1983 to 1993, after the standardization of the Simple Mail Transfer Protocol but before spam, was a golden age of email connectivity.

If mail from your server looks like spam, the destination server will discard it. Your email is not deliverable. As all mail systems have different spam-identification systems configured in different ways, deliverability varies by domain. The goal of this book is to help you make your email as deliverable as possible by configuring protocols that allow recipients to verify your mail’s authenticity.

Even with all of these defensive and authenticy protocols configured properly, you can still trash your deliverability by sending spam.


Unsolicited advertising is the scourge of email. While you’ll hear junk mail called things like “unsolicited commercial email,” the most common term is “spam” because the Internet was built to a Monty Python soundtrack.

For about thirty years, people considered email a miracle. You could write a message at your desk and hours or even minutes later it would reach the other side of the planet. The early Internet was populated by computer science university students, select computer-related companies, and the US military. Blissfully free of broader commercial interests, SMTP was designed for that open network. Sysadmins ran open mail relays for the convenience of other sysadmins who suffered outages. Everyone worked together to sustain the miracle, with little concern about abuse.

In 1978 Gary Thuerk, an employee of the Digital Equipment Corporation, emailed several hundred people he didn’t know an invitation to a demonstration of the new DEC packet-switching systems.  Nobody had ever tried commercial advertising over email. Reactions were overwhelmingly negative, but reasoned. The broader community agreed that commercial advertisements were unacceptable. Five days after the message went out the chief of the US Air Force’s ARPAnet Management Branch, Major Raymond Czahor, called Thuerk’s boss to tell them to never do it again on pain of disconnection.

This first advertising email sold twelve million dollars of computers.

Thuerk’s email established the “do not advertise in email” precedent. It also sold twelve million dollars of servers, establishing the “random email marketing is highly profitable” precedent. Going forward, the network relied on the social contract to prevent junk mail. Email protocols remained unchanged.

In 1993, UUnet began selling Internet access to any company that could pay, beginning the commercialization of the Internet. While people that run businesses might be fine, most corporations are indifferent to feeble social contracts. The first spam hit Usenet, not email, in April 1994, but spam email followed immediately afterwards.

The first spam hit the Internet like an unexpected toxic spill at the kindergarten playground. Mail administrators panicked, implemented short-term fixes, and quickly learned that a protocol optimized for deliverability was unable to stop delivering messages. Sysadmins blocked junk mail domains, so mailers forged their originating domain. Blocking spammers’ networks led the spammers to relay their junk through well-meaning third parties or hacking into unrelated but unpatched mail servers. Despite spending time and money abusing the protocol, spammers made money.

Unchecked spam makes email useless. Almost every change in SMTP in the last thirty years has been propelled by the need to eliminate spam while retaining broad interoperability.

Opt-in email marketing is fine. If you want your favorite creator to tell you when their next big thing escapes,  great! You should get those emails until you opt out. I live and work in Detroit, though, and the company that keeps trying to sell me online courses on South African taxation law can take a long walk out of a short airlock.

If you wonder why email-related software works as it does, or why we have all these add-on protocols, the answer is almost certainly “spam.”

IP Addresses and Email

“I need full control of a test machine on the public Internet? I’ll go to my favorite provider and spin up a VM!”

Not so fast.

In the email ecosystem, IP addresses have reputations. Addresses previously used by spammers are distrusted. Anyone with an email address and a credit card can create a virtual machine in moments. Spammers have no problem setting up a cheap VM and spewing garbage into everyone’s inbox. While this violates every hosting company’s Terms of Service, spammers don’t care.

One of the tools mail administrators use to block spam is blocking network addresses of known spammers. Hosting provider IP addresses have almost certainly been used before. If a spammer previously used your address, it’s probably on one or more block lists of known bad addresses (Chapter XXX). Your email is undeliverable before you start.

With proper automation, a spammer can send millions of emails before the provider’s Network Operations Center can shut them down. A hosting provider will receive dozens or hundreds of complaints within minutes of this flood. While most providers shut down spammers quickly, those complaints cause extra work. Many providers will send lists of the IP addresses that they provide to customers to block list maintainers, so that those systems will proactively block email from those addresses.

Other providers take no action against spammers. Their terms of service declare that spam is not allowed, but they do not enforce it. Block list maintainers quickly identify IP addresses assigned to these providers and add them to their lists. No matter how much you intend to be a good citizen, any email server on these providers will have poor deliverability.

Before choosing a hosting provider for your email systems, ask around to see if other people run email servers on that provider and if that email is broadly deliverable. If you have no contacts who run mail servers, go ahead and try on your favorite provider but be prepared to move. I will not offer recommendations, as they will be obsolete within months.

Perhaps your organization has IP addresses issued by an ISP, or owns its own addresses. A previous owner could have soiled those addresses. Also, some Internet Service Providers block outgoing email at their network border. Check these before starting.

If your addresses have never been used for email, they have no reputation. “No reputation” does not mean that they are trusted, merely that they are not untrusted. You get to make your own reputation. This book will help you do it well.

If you have no control over your test system’s location, you can still educate yourself but remember that your tests will be limited in scope.

Email Components

If you’re accustomed to web-based email, you’ve probably picked up how mail works. When you send an email your web browser talks to the mail server. That mail server talks to the recipient’s mail server. When the human wants to read the email, they open their browser and see it.

If you use a desktop email client you know it’s a little more complex. You compose a message on the client and send it to your mail server. Your mail server sends the message to the recipient’s server. When the recipient opens their email client, the client downloads the email.

Even that’s a shallow view, however. Email was designed by actual computer scientists, and email systems have an actual architecture as documented in RFC 5598. Every email you send flows through the system. Here’s a slightly less shallow view.

ryoms fig 1-1 message flow through email

Any email user interface is called the Mail User Agent (MUA). The MUA is most often called the mail client. It might be Thunderbird, a web page, or part of an office suite. You can even use a program like netcat to manually send mail to the server. (There are also command-line programs that you can run on the mail server itself, like mutt. They unfairly leverage their location, so we will ignore them for now.) When you send the email, the MUA transmits it to the Mail Submission Agent via SMTP. Usually, but not always, the client copies the message to the Message Store.

The Message Store (MS) is the server’s copy of the user’s emails. Most Message Stores retain a copy of both the ingoing and outgoing messages, at least until the user deletes them. Mail clients use the Internet Message Access Protocol (IMAP) to synchronize their messages with the server. Message Stores might also offer additional features such as filtering incoming mail into folders. On Unix systems the Message Store is often in the user’s home directory, something like /var/mwl/Mail.

The Mail Submission Agent (MSA) runs on a server. It accepts mail from mail clients and send it to the Mail Transfer Agent. The MSA communicates with SMTP.

The Mail Transfer Agent (MTA) receives emails from the Message Submission Agent and other Mail Transfer Agents, identifies their destination, and forwards them. The sender’s MTA stores outgoing email in a mail spool or a mail queue and attempts to identify and contact the recipient’s MTA. The two servers have a dialog over SMTP that boils down to “Hi, I have an email for one of your users.” “Yes, that’s my user, please send the mail.” You might hear the MTA called a mail exchange or an MX.

A MTA that receives a message forwards it to the Mail Delivery Agent (MDA). The MDA accepts the message and stores it safely on disk. If you’re accustomed to managing Unix systems, the MDA places user messages in /var/mail. The MDA also handles tasks like server-side email forwarding and automated responses like out-of-office messages.

When the recipient’s MUA checks for new email and downloads it, the messages move into the recipient’s Message Store. The recipient’s MUA might sort the messages into folders, delete certain messages, or any other sort of automatic processing configured by the user.

Finally, the user’s mail client downloads the mail. The email is complete.

Out of all these components, which is the “mail server?” None of them, and all. Each component might be on a separate machine, or any of them could be combined with their peers. A single organization might have different MTAs for receiving and sending email. It depends entirely on the system load, the number of users, and which headaches each organization prefers. A user might call the Message Store or the MSA the mail server. Outside organizations might think that your MTAs that receive email from the outside world are your mail servers, unless they’re having trouble receiving emails from you and realize that you have entirely different MTAs for outbound mail. Even if you have only one server that controls all of these roles, stop using the phrase “mail server.” Look more deeply.

This book avoids saying mail server, except when I want to confuse you.

Email Security

Before spam, email clients authenticated only when connecting to the message store. Clients did not need to authenticate to send mail to the mail submission agent. Mail submission agents could dump email straight into the MTA. MTAs did not verify each others’ identity, and could often fling messages at any server that looked suitable. An unprivileged user could trivially forge emails from tax agencies. Everybody knew that email was public, and that someone with a carefully placed packet sniffer could capture messages.

The appearance of spam made everyone say “Maybe we should lock down these other connections?”

The server-to-server protocol is still called Simple Mail Transfer Protocol, but it’s much less simple. It now supports TLS. It uses different TCP/IP ports depending on which piece of the system you’re talking to.  The protocol commands are still plain text, however, and can be replicated by a sysadmin with netcat and knowledge. Even wrapping the connections in TLS only prevents eavesdropping.

SMTP itself is not enough to successfully exchange mail with another network, however. Email has added protocols that help secure, restrict, and authenticate email. Most of this book discusses those ancillary protocols. We’ll cover them briefly here to orient you, then delve deep into each.


The Domain Name Service maps hostnames and IP addresses to one another. You must have solid control of your DNS to successfully run email. Domains publish their MTAs in DNS, and many of email’s ancillary security protocols provide their information in DNS.

This raises the question of DNS security. Like email, DNS was created when the Internet was largely a private network. Also like email, security was integrated afterwards. DNS Security Extensions (DNSSEC) are today’s standard for securing DNS, but have not yet been widely deployed.p

Every domain that receives email should publish a Mail Exchanger (MX) record in DNS, telling remote MTAs the hostnames of the domain’s own receiving MTAs. You’ll need additional DNS records for each protocol you deploy.

Sender Policy Framework (SPF)

Where the MX record tells the world which hosts receive a domain’s email, the Sender Policy Framework (SPF) tells the world which hosts may transmit mail for a domain. SPF declares the hostnames and networks of MTAs, not clients or mail submission agents. SPF is distributed via DNS TXT records.

SPF syntax lets you declare who can send mail. You can make rules like “only these addresses,” “any of the MTAs for this other domain,” or even “this domain does not send mail.” For example, the SPF record for my domain mwl.io contains a few IP addresses and a hostname.

When a MTA receives a connection claiming to have mail from a particular domain, the MTA checks the SPF against the incoming machine’s IP address. If they don’t match, the connection is bogus and should be rejected. If someone sends email from mwl.io to a Gmail user, Gmail’s server checks the SPF record for mwl.io. If the forger’s IP address is not in my domain’s SPF record, Gmail drops the connection and records that the forger’s IP is untrustworthy.[4]

SPF is considered the lowest level of authenticity, and is easy to implement in new domains. It requires no maintenance, until you add a new mail host.

DomainKeys Identified Mail (DKIM)

Where SPF declares where email comes from, DomainKeys Identified Mail (DKIM) authenticates the email’s sender. DKIM information is published in DNS TXT records tied to a _domainkey record.

DKIM lets an organization publish a policy on how to authenticate mail from the domain. You can tell receivers to validate or ignore SPF, to report or ignore DKIM failures, and how to test messages.

DKIM is more difficult to implement than SPF, but not difficult. Best practices say you should rotate your keys regularly, so it does require more maintenance.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

SPF and then DKIM improved mail authentication. Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the next evolution. Like SPF, it identifies legitimate mail sources. Like DKIM, it uses public key authentication.  Its robust policy language lets organizations define how recipients can identify legitimate mail and report failures.

DMARC records are distributed via TXT records, tied to a _dmarc record.

Brand Indicators for Message Identification (BIMI)

If your organization uses a trademark for marketing, you might have an interest in Brand Indicators for Message Identification (BIMI). If the end user has a BIMI-aware email client, it will check for BIMI DNS records and use them to display a digitally signed corporate logo next to the email. BIMI is built on DMARC, so it cryptographically verified.

Deploying BIMI starts with “register an expensive trademark” and “purchase an artificially expensive certificate,” so these two paragraphs are this book’s only coverage of the topic.

Mail Transfer Agent Strict Transport Security (MTA-STS)

Originally, email was transmitted unencrypted. Anyone with a properly placed packet sniffer could eavesdrop on all email transactions. We eventually added encryption to user authentication, securing usernames and passwords, but using TLS between MTAs was optional. Most mail operators who deployed TLS considered large-scale capture programs like Carnivore their primary risk, so self-signed certificates became acceptable.

Mail Transfer Agent Strict Transport Security (MTA-STS) is a declaration that your mail server only accepts SMTP over TLS. Your mail server must offer a policy statement on a web site. MTA-STS is activated via a DNS record, using the _mta_sts identifier.

TLS Reporting (TLS-RPT)

Every sysadmin has seen email bounce messages, declaring that the recipient has no account or that a server is misconfigured or that the receiving MTA is on an unscheduled vacation. These messages go between MTAs via SMTP.

If your MTA uses MTA-STS to declare it only accepts connections over TLS, and it has a TLS problem, those SMTP messages will not go through. Your MTA will continue merrily rejecting connections, leaving you ignorant of the problems. TLS reporting, or TLS-RPT, is how you MTAs exchange reports of TLS problems. If you deploy MTA-STS, you also need TLS reporting.

Like everything else in email, TLS-RPT information is distributed via DNS.

DNS-based Authentication of Named Entities (DANE)

One of the big objections to common X.509 certificates is the existence of Certificate Authorities (CA). While certificate prices have plunged, a compromised CA could still do immense damage to the confidentiality and integrity of its users.

DNS-based Authentication of Named Entities (DANE) is a way for organizations to publish X.509 certificate fingerprints in DNS, as documented in RFC 7671. DANE is one of those contentious topics in security circles, and bringing it up at a technical conference is a great way to start the kind of argument that makes people call law enforcement. The arguments about certificate authorities will not be settled by myself or (probably) anyone reading this book. Different people have different concerns about different risks and pain points, that’s all.[5] If someone has gone to the trouble of publishing DANE information for their mail servers, we should respect them.

DANE records are published in TLSA DNS records.

Which Do You Need?

These protocols were developed years apart. Some of their functions overlap. Which do you need, and which can you ignore?

Many people deployed the protocols available when they set up their server and never went circled back to add new ones. You’ll see servers with only SPF, or only SPF and DKIM. Some folks deployed DMARC but skipped SPF and DKIM. Which you need isn’t just a question of what you want to offer the world. It’s about what other servers can validate. If an MTA can validate only SPF, but you offer only DMARC, the recipient might consider your mails suspicious.

To maximize deliverability, implement SPF, DKIM, and DMARC.

Do you need MTA-TLS and TLS-RPT? That depends on your threat model. Maybe you don’t care incoming connections are encrypted or not. It’s fairly new, so perhaps your MTA doesn’t yet support it. If you’re deploying a new mail system or taking the time to polish your existing system, however, you might as well experiment with it. Use a very low timeout when testing, so remote servers won’t cache your mistakes for months or years.

What’s In This Book?

Chapter 0 is this introduction.

<<<add in as I write more>>>

[1] Hopefully you stop before you install WordPress and join the dark side. Unlike me.

[2] While I have written books on TLS, DNSSEC, and OpenPGP, as well as the infamous Networknomicon, I retain enough sanity and self-respect to not write a core DNS book.

[3] Unless your network connection involves phrases like “UDP over carrier pachyderm,” “we get phone service every third Sunday,” or “Mars Colony One.” Then do what you gotta.

[4] If the forger’s address is in my SPF record, I am having a very bad day.

[5] Rule of System Administration #3 applies here. “Nothing is secure. Everything is terrible.”

When Will I Open “Run Your Own Mail Server” sponsorships?

[edit, 17 March 2023: Sponsorships are now open.]

My next tech book will be “Run Your Own Mail Server,” part of the IT Mastery series. I would like a snappier title. “Lay Down All Hope, You That Go In By Me” is accurate to the spirit, but doesn’t inform about the content. Now that the Devotion & Corrosion Kickstarter is over, I could theoretically open sponsorships for the new book. I’m not doing it yet.

I work to be honest in my books. I can’t yet express this book’s truth in a short pithy way suitable for a catalog.

Email is a huge topic. Postfix, exim or Exchange? Dovecot, Cyrus, or Courier? Sendmail or syphilis? What exactly is this book about, anyway? I’m using a couple programs for my reference implementation, but this is not exactly a book about system administration. It is about citizenship and society. A novice sysadmin will not be able to use this book without reading a bunch of other books first. This is mostly about how the system hangs together, and about the less well-known services that help email happen. SPF and DKIM, DMARC, MTA-STS, and TLS-RPT. How not to warm up your IP address. Defeating Google. IPv4 or IPv6?

The easiest way to communicate this is by posting Chapter 0 before I open sponsorships.

Which means that the chapter must be vaguely readable. It will be riddled with errors, but it will discuss what’s further in the book.

A handful of you don’t care what the book is about. You’ll sponsor it anyway. You’d sponsor a book about ls(1). You folks are the best, and I appreciate your eagerness to give me money for no good reason. Most folks are not so enraptured, however, and want to know something about what I’m writing.

Maybe next week? The week after? I write nonfiction in order but not linearly, so it’s taking longer than I hoped.

But book is happening. Eddie Sharam’s cover art is glorious, and it’s an actual painting again. It might be a Kickstarter reward, though I think he’d make more if he put it up for direct auction. We’ll find out.

I do know that email is overwhelmingly dominated by a handful of big companies. An Email Empire, if you will. Those of us who run our own email are a ragtag band of rebels struggling against the Empire, constantly hoping not to be crushed as we carve out our little space. Gmail has altered the email agreement, and we pray they do not alter it further. All we need is a Bigfoot with an energy-crossbow-thingamajig…

Order Books for BSDCan Delivery

BSDCan 2023 is happening in meatspace.

Folks like getting books from me personally, so normally I bring a few copies of each old title and about ten copies of each book released since the previous con. I’ve released eighteen books since the last meatspace BSDCan, plus innumerable chapbooks and collections and anthologies and who knows what all. 18 titles, ten of each? I am fifty-six years old and am not lugging one hundred eighty books into a con knowing full well that most won’t sell and I must lug them back to the car and unload them at home and let them collect dust. Nope. Ain’t gonna. Can’t make me.

Plus, there’s this.

One copy of every edition of everything I’ve written, 2023 February

I have written too many books to drag “a couple copies” of everything anywhere, let alone to BSDCan. Also, I haven’t done cons for years and have methodically reduced inventory. Other than the copies on this brag shelf I own very few copies of anything. I can buy more from the printer, but I’m not going to buy 180 dust collectors books.

The obvious answer is to let y’all preorder for delivery at BSDCan. I can get exactly what I need, plus a couple extras here and there.

To order a book for delivery at BSDCan, check my meatspace catalog for titles of interest. All prices are USD. Send your list to mwl at mwl dot io on or before before 1 April 2023, specifying paperback or hardcover when there’s a choice. Use the subject “BSDCan Preorder.” I will confirm the total price.

Payment? If you want one or two books, you can pay me cash at BSDCan. Three or more books, I need payment before 3 April. (Otherwise, some jerk who isn’t even attending BSDCan will order thousands of dollars worth of crap just to screw me and call it a joke.) I’ll use my tip jar for prepayments because it takes credit cards or paypal, or you can paypal to accounts at tiltedwindmillpress dot com.

I will place my order on 2 April. I must have prepayments by then.

I will deliver at BSDCan, 19-20 May 2023. Folks who haven’t prepaid should pick up on the 19th (or tell me why not), otherwise I’ll assume you’ve changed your mind and try to get rid of them on the 20th.

Will I bring books for people who don’t preorder? Yep. A few. Not many. You’re better off preordering. Price increases on print books are coming this month, but I will honor these prices for these preorders.

While the meatspace catalog includes everything I can get, here’s what’s come out since the last BSDCan.

Tech books since BSDCan 2019

  • Sudo Mastery, 2nd edition
  • SNMP Mastery
  • The Networknomicon
  • TLS Mastery (Beastie Edition, Tux Edition, and combined hardcover available, be specific, although I’m sure you fine folks will all want Beastie or the hardcover)
  • DNSSEC Mastery, 2nd edition
  • OpenBSD Mastery: Filesystems

Other Nonfiction since BSDCan 2019

  • Cash Flow for Creators
  • Only Footnotes
  • Domesticate Your Badgers
  • Letters from ed(1): The FreeBSD Journal Letters column, years 1-3

Fiction Since BSDCan 2019

  • Drinking Heavy Water (Montague Portal)
  • Terrapin Sky Tango (Beaks #2)
  • Aidan Redding Against the Universes (Montague Portal all-inclusive omnibus)
  • $ git sync murder ($ git commit murder #2)
  • Prohibition Orcs (collection)
  • Frozen Talons (Prohibition Orcs #2)
  • Devotion and Corrosion (collection)

Huh. I feel like I’ve been slow during the pandemic, but this is a modestly respectable number of books. The years know things that the hours and days cannot.

Anyway. Check the meatspace catalog for what you want. Send me a list. Specify paperback or hardcover. I will verify price. Three or more, pay me beforehand. Pick up at BSDCan.

Otherwise, take your chances that I’ll bother to bring the book you want and won’t sell it before you can grab it.

“OpenBSD Mastery: Filesystems” Print Status

I got the print proofs of OpenBSD Mastery: Filesystems yesterday, and they came out lovely.

I’ve gone through them and fixed some less-than-optimal layout decisions. You never know what a print book will look like until you hold it in your hands. Several folks read the ebook already and sent some corrections that I, the tech editors, and the copyeditor missed, so I fixed them. The ebook has been updated to match. The printer now has the print files.

So, when will the print book be in stores?

That depends on the printer. I expect they’ll approve the print in the next few days, unless they pull another Orcibus and sit on it for a month. After a week or so, though, I have nothing better to do than give them pain every. single. day.

I will release the print book to the public when I can. I’ll be ordering the pre-orders directly from the printer at the same time.

Why “OpenBSD Mastery: Filesystems” is not in Amazon’s Kindle store

I expect folks to ask this, so here’s a pre-emptive blog post.

You can get OpenBSD Mastery: Filesystems for Kindle direct from me at Tilted Windmill Press or at Gumroad. You can get a Kindle-friendly ebook from any number of other retailers, but while they’re all supposed to be DRM-free I can’t advise on prying the file out of another vendor’s ecosystem. The one place you cannot buy OMF for Kindle is Amazon’s Kindle bookstore.

TLDR: Amazon pays roughly 70% of retail price for books priced up to $9.99, and 35% for books $10 and over. Amazon is the only retailer that does this. Other retailers, I make somewhere around 65%-70% no matter the retail price. Everything follows from that math, but if you want the details read on.

According to economists, prices have gone up about 30% since I started releasing the Mastery books. According to my wallet, not so much. In 2012 I could get a cheap lunch for my wife and I for $10. I paid $18 last weekend. But let’s go with the official numbers. Just as “dime novels” now cost $10, I must raise prices. While book pricing is hotly debated, $11.99 is a reasonable price for a short tech book like OpenBSD Mastery: Filesystems.

If I charge $9.99 for this ebook, I make about $7.

If I charge $11.99 for the ebook, I make about $8.40 everywhere but Amazon. At Amazon, I make $4.20. For me to make that $8.40 at Amazon, I must price the book at $23.99. I’m fond of the book, but it ain’t worth that! And if I did, giving Amazon a $15.59 slice of every sale for no reason sticks in my craw.

Charge $23.99 at Amazon and $11.99 elsewhere? Amazon’s program has a Most Favored Nation clause. They can price match any other major vendor.

Will Amazon change their business because of this? No. Authors are plentiful and of low value. I am not worth Amazon’s time.

Amazon’s business model is based on squeezing prices down, and they play a long game. I don’t expect them to ever raise that $9.99 limit. A novel might sell tens or hundreds of thousands of copies. If I’m lucky, a book like OpenBSD Mastery: Filesystems might sell four thousand. The few extra bucks I’ll make by raising prices are important. That’s also why I’ve focused so hard on disintermediation through my Patronizers, sponsorships, and lately Kickstarter.

I have been expecting this for years now. I do not expect to publish future Mastery books on Amazon’s Kindle store, unless by some chance I write another very short one.

“OpenBSD Mastery: Filesystems” ebook leaking out

I had wanted the ebook before Christmas, but before New Years’ Day isn’t terrible.

The ebook of OpenBSD Mastery: Filesystems went to sponsors, Patronizers, and pre-order folks yesterday. It’s in my online bookstore today, and will appear elsewhere through the weekend as I upload to all the stores and all the databases churn.

Well, almost all the stores. The DRM-free ebooks sold in any store can be loaded onto a Kindle, but the book won’t be in Amazon’s Kindle store. I’ll do a blog post dedicated to this later, because I want it to come up easily on a search and I suspect this will quickly become a FAQ, but in short: when SSH Mastery came out in 2012, it was $9.99. That’s $12.81 today. OMF is about the same length as that book and took longer to write, so I’m comfy charging $11.99 for it. Amazon does not want me to price books between $10 and $20, so any book in that price range won’t be available there.

Print will take a little longer, because of the pre-orders.

Normally, between sponsors and backers, I have to order and ship about 30 print books. No big deal.

This time I tried pre-orders. I ignored the pre-orders as they happened, but now that it’s time to fulfill I took a look and–wow. 69 preorders? Yes, nice, but it’s tripled how many books I must order and ship. I’ll be rushing print proofs to my door but still, shuffling physical books around the country takes time. Once they arrive at my door I’ll drop everything to ship.

“OpenBSD Mastery: Filesystems” print layout notes

The cost of printing books is going up, just like everything. I don’t want to increase the price of my tech print books. I consider $25 reasonable.

For the second edition of DNSSEC Mastery, I developed a new print interior layout, using every trick I know to reduce page count while remaining readable. It worked. I was able to cut page count by about 30%. There’s only one problem with it:

I don’t like it.

Print books, especially tech books, occupy a weird niche these days. Books are no longer confined to paper. I have several thousand e-books on my reader, and as my eyes age I find myself increasingly unwilling to purchase print books unless they serve some special role. A paper book must be a unique physical artifact for me to consider offering it precious physical space in my overflowing bookshelves. My home already has libraries in three rooms, and we refuse let books bully us into moving again.

So I’m reverting to the previous design for OpenBSD Mastery: Filesystems. It might result in a price increase. Maybe not, because it’s a little shorter than the SNMP book. But the result will be a nicer physical artifact that provides a better reading experience.

“OpenBSD Mastery: Filesystems” status

I just finished indexing the manuscript. That’s normally a hard day’s work, but this being the week before a major holiday I was unable to get a full day to dedicate to the task. I wound up spending about two hard man-days on the task, because context switching in and out of indexing has a higher cost than any other task my brain runs.

With luck, I’ll have the print book laid out next week and ebooks by the end of the week. Yes, I could prepare ebooks first, but the print layout forces me to go through the manuscript one last time searching for errors. I always find one or two warts in the process.

I am, however, taking the weekend off for my family’s choice of Winter Solstice Holiday. May you all have a delightful WSH of your choice.

The Spite Bezos sale ends, Filesystems, and my Next Kickstarter

A trio of updates, which is super annoying because I’m trying to blog more often but this all happened late yesterday so I guess I’m stuck.

The Amazon Spends Money To Sell Montague Portal hardcover and ebook sale has ended. Amazon has reverted the price to normal everywhere except for Kindle in the UK, and I’m sure that’ll follow soon. At first, I thought The Algorithm was drunk, but the hardcover sale stopped right when their spend crossed $500. That could be a coincidence, sure, but it’s a strangely regular number. Maybe someone at Amazon knew I’d take advantage of this and decided to give my career a hug? I will never know. This goes down as a Christmas miracle, and is hereby dubbed “the gift of the Bezi.”

“OpenBSD Mastery: Filesystems” is back from copyedit. Diving into that in the next few days. It’s my first tech book that won’t be available in Amazon’s Kindle store, so this will be interesting.

The pre-launch page for my next Kickstarter is live. Devotion & Corrosion is a collection of short fiction. It’s a bunch of stories about love that aren’t love stories. Welder Wings’ art completely blew me away.

Despite popular opinion the cover is not a glimpse inside my skull, but only because it lacks Molotov cocktails.

Anyway, watch that space.