Vivian Voss

The Two Dollars Between dma and the Inbox

lean software freebsd email deliverability

The entire mail system on the machine I measured this morning weighs 67,792 bytes. That is dma, sitting in /usr/libexec, with three lines in /etc/mail/mailer.conf pointing the old sendmail commands at it. Its configuration file ships with 63 lines and not one of them is active. Sixty-three, and I counted twice. Every directive is commented out, because the defaults are the whole arrangement.

$ ls -l /usr/libexec/dma
-r-xr-sr-x  1 root  mail  67792 Nov 28  2025 /usr/libexec/dma

$ grep -v '^#' /etc/dma/dma.conf | grep -vc '^$'
0

I piped a line of text into mail and addressed it to root. The timer said 0.00 seconds. The queue was empty again before I could look at it, and the message was waiting in /var/mail/root, which is where it belongs.

Nothing about that is clever, and nothing about it is new. It is worth sitting with for a moment anyway, because the thing I have just described is the part of email that people believe they are buying.

The part that was finished before the web

The protocol is from August 1982. Sendmail followed a year later, grew into one of the most famous large programs in Unix, and sat in the FreeBSD base system for three decades. It is still there: 802,856 bytes of it, close to twelve times the size of the thing that took its place as the default in FreeBSD 14.0. The release notes give that change one sentence, which feels about right.

What arrived instead came from DragonFly BSD, written by Matthias Schmidt and Simon Schubert, and it is unusually frank about its own borders. The manual runs to 197 lines against sendmail's 458, and it says that the agent does not listen on port 25 and is no replacement for a large MTA. It takes mail from programs on this machine and hands it onwards to a smarthost. That is the job, and for the things a web application actually sends, the password reset and the alert at four in the morning, that job is the entire requirement.

One message, and where it stops application password reset dma 67,792 bytes queue, TLS, no listener port 25, direct shut at the host port 587, relay metered the door SPF, DKIM DMARC complaint rate reverse lookup The dashed route is the one the protocol was written for.

So the sending side has been finished, in the base system, for longer than most of the stack around it has existed. Which raises the awkward question of what the monthly bill is for.

The door at the end of the wire

From the jail I keep for measurements I opened a connection to Google's inbound mail exchanger on port 25. Nothing came back. Microsoft's inbound exchanger, port 25: nothing. Port 465: nothing. Port 587, the submission port, answered in well under a second.

$ nc -z -w 5 gmail-smtp-in.l.google.com 25      # no answer
$ nc -z -w 5 outlook-com.olc.protection.outlook.com 25   # no answer
$ nc -z -w 5 smtp.gmail.com 465                 # no answer
$ printf 'EHLO test.example\r\nQUIT\r\n' | nc -w 8 smtp.gmail.com 587
220 smtp.gmail.com ESMTP ... - gsmtp
250-smtp.gmail.com at your service, [192.0.2.10]
250-SIZE 35882577
250-STARTTLS

My own firewall has no opinion on the matter. There is no rule in it that mentions port 25 in any direction, so the closure comes from further up the wire. It sits at the host, where outbound 25 and 465 are shut for new accounts as standard practice, openable on request once you have been a customer for a month and settled an invoice. Their reasoning is sound and they publish it: people who send mail nobody asked for like cloud servers very much.

The result is a machine that speaks the protocol perfectly and cannot reach anybody it wants to speak to. One door is open, it leads to somebody else's relay, and that relay would like to know who I am before it carries anything for me.

What the two dollars buy

Here the concession comes before the arithmetic, because the receiving side has a genuinely strong case.

Since 1 February 2024, anybody sending five thousand messages a day or more to Gmail has had to authenticate with SPF and DKIM, publish a DMARC record, offer one-click unsubscribe on marketing mail under RFC 8058, and keep the spam complaint rate away from 0.30 per cent, with 0.10 as the number to aim at. Yahoo asked for the same. Microsoft followed on 5 May 2025 for its consumer domains, and a failure there now gets refused at the door with 550 5.7.15 Access denied, where it would once have been dropped quietly in the junk folder. Google's own guidance now reads, in the flat tone of a company that has stopped negotiating, that from November 2025 it is ramping up enforcement on non-compliant traffic, with temporary and permanent rejections.

None of that is in the protocol. RFC 5321 has no opinion on your complaint rate. These are membership rules for somebody else's building, and the building is worth defending, because the inbox of 2005 was close to useless and these rules are a large part of why yours is not.

Sending, and being accepted in the base system, 67,792 bytes speaks SMTP queues and retries STARTTLS to the smarthost authenticates with a password delivers locally in 0.00 s finished, documented, unchanged for longer than the web has existed asked for at the door SPF and DKIM DMARC, aligned one-click unsubscribe complaint rate under 0.30% reverse lookup that matches and a sending history which no package installs

The apparatus on my side is not free either. dma cannot sign DKIM at all, so the signature has to come from somewhere else: pkg install -n opendkim answers with nine packages and 80 megabytes, a Perl interpreter and a DNS resolver among them. After that come the DNS records, and after those the reverse lookup and the alignment between them. Then the component that no package installs, which is a history of having sent mail that people wanted.

That history is what the invoice is for, and the invoices vary in a way the protocol cannot explain. Amazon charges ten cents per thousand messages à la carte, sixteen on its entry plan. Resend asks twenty dollars for fifty thousand, which works out at forty cents per thousand, and ninety beyond the allowance. Postmark takes fifteen dollars for ten thousand and a dollar eighty per thousand after that. Mailgun sells the same shape at the same entry price, and in October 2025 it told its pay-as-you-go customers that the rate would double on 1 December, from one dollar per thousand to two, citing improvements to the platform.

Price per thousand messages Amazon SES $0.10 Resend $0.40 Postmark, above allowance $1.80 Mailgun, pay as you go doubled from one dollar on 1 December 2025 $2.00

Twenty to one, top to bottom, for a transaction that is byte for byte identical on the wire.

Who profits, who pays

The providers are selling access to inboxes they do not own, which is a fine business if you can get it, and they earn part of it honestly: the compliance tooling is real work, the deliverability engineering is real work, and somebody has to answer the telephone when a bank's payment confirmations stop arriving.

The mailbox operators do rather better. They set entry rules for an open protocol, and an entire industry grew up to police those rules on their behalf, funded by the senders. All it took from Google and Microsoft was a published document and the will to enforce it.

The bill lands, as usual, further down. It lands on every product that sends a password reset or a one-time code, which is every product. And it lands hardest on the operator nobody counts: the small sender whose machine is technically impeccable and whose records align, and who still cannot begin, because the standing that gets mail accepted comes from having sent a great deal of it already, and nobody will carry the first lot. An attacker starting this morning has precisely the same difficulty, which is what the arrangement was built for and what it costs.

The limit

Four things, and the first one matters most.

For a product sending at volume, renting the relay is frequently the correct engineering decision, and pretending otherwise would be posturing. You are buying a warm address and somebody else's standing with four large companies, and no shell script produces either of those.

The base system is not the whole answer, and I have said the uncomfortable half already: the agent cannot sign DKIM and does not accept inbound mail, and it never claimed to. A full mail server is a different project with a different maintenance bill, and anybody who has run one for a decade will tell you what it costs in attention.

My measurement is one machine at one host on one morning, and port policies differ. A machine in a colocation rack with an address block of its own may have port 25 open and a clean neighbourhood.

And the rules work. The honest comparison runs against the mid-2000s, when the spam filter was the most-used feature of every mail client and the wanted mail arrived somewhere in the middle of the rest. The people who fixed that were not being greedy, and the fix has a price, and the price is now a line item on the bill of everybody who sends a letter.

The 67 kilobytes still do their part. They will hand your letter to whoever opens the door, which is all the protocol ever asked of them, and the door is the product.

The whole mail system on this machine is 67,792 bytes with no active configuration, and a local message is delivered in 0.00 seconds. Outbound port 25 is shut by the host, port 587 is open and belongs to somebody who charges for it, and the entry rules that came in from February 2024 onwards are not in the protocol at all. The prices for the missing piece run from ten cents to two dollars per thousand for an identical transaction, which tells you what is actually being sold.