chasquid: a small SMTP server that is hard to misconfigure

An MTA for one machine, not for a corporation

The scope is stated in the second line of the readme. chasquid is an SMTP server with a focus on simplicity, security and ease of operation, and it is designed mainly for individuals and small groups.

That framing is the most important thing to know about the project, because it decides which parts of the readme are essential. A server for an individual or a small group has different requirements from a carrier grade MTA. It has to be easy to install, easy to configure, hard to break and safe by default, because the person running it is often doing so in their spare time.

It is written in Go and distributed under the Apache licence 2.0, and the project is hosted on its own site with the GitHub repository described as a mirror. The module path reflects that origin, since the module is declared under a blitiri.com.ar domain rather than a GitHub path, which tells you the upstream lives with the author and GitHub is a convenience.

The feature list is organised under three headings, Easy, Useful and Secure, and that organisation is a good summary of the priorities. The easy part is about configuration and packaging, the useful part is about the features an MTA needs beyond delivering mail, and the secure part is about the transport and the sender identity problems that dominate modern email.

There is also a monitoring component that is easy to overlook and very valuable in practice: an HTTP server with exported variables and tracing to help debugging, which is the difference between a server you can diagnose at three in the morning and one you cannot.

The dangerous mistakes are designed out

The easy section makes a specific promise: it is hard to mis-configure in ways that are harmful or insecure, with two examples given, no open relay and no clear-text authentication.

An open relay is a server that will relay mail for anyone, which turns your machine into a spam cannon and gets your address blocklisted. The design answer is that the safe behaviour is the default behaviour, and the readme lists multiple and virtual domains with per-domain users and aliases as the model instead, so a server only accepts mail for the domains it has been told about.

Clear-text authentication is the other one. If a client can authenticate by sending the password in the clear, then a network path is enough to steal credentials. The answer is that the server refuses the unsafe option rather than warning about it, which is the right trade for a tool aimed at people who will not read the manual twice.

The rest of the easy section is about the operational reality. The server is integrated with Debian, Ubuntu, Arch and Alpine, so a distribution package exists, and it supports using Dovecot for authentication, which is a significant decision. Reusing it for SMTP authentication means one set of credentials and one account system rather than two, at the cost of running another service.

The configuration skeleton in the repository matches this story, with an etc directory that is installed to the system configuration location and a state directory created with restrictive permissions and owned by the mail user.

Per-domain TLS, and stopping the downgrade

The security section is where the interesting engineering is, and the first entry sets the tone. chasquid does tracking of per-domain TLS support, and the link points to a security levels document rather than to a configuration reference, which suggests there is a defined policy with named levels rather than a single switch.

The problem being solved is specific. A client connects, the server offers a certificate, and the client decides whether to insist on encryption. If a server can be talked into serving a domain over plain SMTP, then a downgrade is possible, and the policy has to say which domains are allowed to fall back and which are not. Tracking means the server keeps that decision attached to the domain rather than to the connection.

Two supporting features make that practical. Multiple TLS certificates are supported, so one process can serve several domains with a certificate each, rather than needing one certificate per process. And there is easy integration with Let's Encrypt, which removes the operational excuse for letting a domain fall back to plain SMTP, because renewing certificates by hand is exactly the chore that leads to a server quietly serving a stale certificate.

The same security-oriented thinking shows up in the useful section, where international usernames and internationalised domain names are supported, through the SMTPUTF8 extension and IDNA respectively. A server that cannot accept a non-ASCII local part will simply reject legitimate mail from senders whose address is not pure ASCII, and a server that cannot accept a non-ASCII domain will refuse traffic for a domain that exists.

DKIM, SPF and MTA-STS on the sending side too

Three of the security features concern the sender's identity rather than the transport, and the readme lists them together.

SPF checking means the server evaluates the sending policy framework for the envelope sender, which is how a receiver decides whether a message claiming to come from a domain was actually sent by that domain. MTA-STS checking is the mechanism that tells senders, out of band, that a domain requires TLS and which policy to enforce, described in the readme by its RFC number.

DKIM support covers both signing and verification. Signing means the server adds a cryptographic signature to outgoing mail so that receivers can check that the message has not been modified in transit and genuinely came from the domain. Verification means it checks the signatures on incoming mail.

That the server does all three is worth pausing on, because each of these is a place where mail servers have historically been inconsistent. A server that only verifies is fine for receiving, but it will not help its own users with deliverability, and a server that only signs makes it easy to forge mail for a domain it does not even own. Doing both is the coherent choice for a server that is both sending and receiving for the same set of domains, which is the normal case for a small organisation.

None of this is exotic. It is the baseline for a mail server in 2026, and the point of listing it is that this project treats the baseline as in scope rather than as an add-on.

Hooks and the LMTP delivery side

The useful section includes hooks for integration with greylisting, anti-virus and anti-spam, which is the point where an SMTP server stops being self-contained.

A hook is a way to hand a message to another program for a decision, and the three named uses are the three decisions an MTA is usually bad at. Greylisting is the least obvious one: the technique is to accept the first attempt from an unknown sender and reject it, and only accept the retry, because most spam is sent once and never retried while legitimate mail servers do retry. Doing that inside the MTA, rather than in a separate filter, means it applies to everything the server receives.

Anti-virus and anti-spam hooks are the more familiar pattern, where a scanner gets the message and returns a verdict.

The other useful feature is suffix dropping, where an address with a plus suffix is delivered to the base address, so a user with a main address can create per-sender aliases without new accounts. It is a small feature that removes a class of configuration work, and it is also a privacy consideration, because the suffix tells the operator which lists a person is on, so a server that supports it should be aware that the person can see it in the envelope.

The repository also builds a delivery helper, an LMTP delivery agent, and a helper for Dovecot authentication, which is the piece that makes the Dovecot integration work rather than being a mention in a list.

Five binaries, and a test suite that runs in setsid

The Makefile shows the shape of the project better than a feature list does.

The build produces five programs. There is the server itself, a utility program, a tool called smtp-check, an LMTP delivery agent, and a command line tool for Dovecot authentication. Each has its own target, and the install target copies four of them into the local bin directory.

The version and timestamp handling is careful in a way that matters for distribution. The version is taken from a git describe, and the source date epoch from the timestamp of the last commit, and both are injected into the binary with linker flags. The comment above that block points at the Debian reproducible builds proposal for timestamps, which tells you the author cares about the same property that distribution maintainers care about, that two builds of the same source produce the same artefact.

The test target is more interesting. It runs the Go tests, and then it runs a series of shell scripts under setsid with the wait flag, which runs the general test script, a stress test, and separate scripts for the utility, the delivery agent and the Dovecot helper. The setsid call is a way of running those scripts in their own session so that a test that starts a daemon can manage it, and the presence of a dedicated stress script suggests the concurrency and connection handling get their own attention.

The formatting target shows the same attention: go vet, gofmt with the simplify flag, go fix, clang-format for the protocol buffer files, black for a few Python test utilities, and mdformat for the documentation with a line wrap and an exclusion for the generated manual pages.

Documentation, licence and where the code lives

The documentation arrangement is deliberate and worth copying.

The readme points to a how-to guide and an installation guide as the best starting points for installing, configuring and running the server, with all documentation on the project site. The site is built with mkdocs, which the repository configuration shows, and the documentation lives in a docs directory. The feature list links each item to its own page, so a link to hooks, to monitoring, to the security levels, to the Dovecot integration or to the per-distribution installation instructions resolves to a page rather than to a paragraph.

That is what a good configuration-heavy project looks like, and it is a reasonable expectation to hold for the whole documentation.

The licensing needs one note. The readme states the project is distributed under the Apache licence 2.0, while the repository listing records a custom licence that GitHub cannot classify, and there is a LICENSE file in the root. If you intend to redistribute or vendor the code, read that file rather than trusting the badge.

The contact and reporting arrangements are also spelled out. Questions, comments and patches go to a mailing list, security issues can be reported privately to an email address at the author's domain, and there is an IRC channel on the OFTC network. Bug reports and pull requests on GitHub are welcome, and the repository has a go test workflow badge, a coverage badge and a Go Report Card badge.

On the release side, the repository has no GitHub releases, and the last push was on 2026-10-18 with the project not archived, so the source is moving even without tags to point at.

Editorial conclusion

chasquid is a good fit for a person or a small organisation that needs to receive mail for several domains on one machine, and for anyone who wants an MTA whose configuration cannot silently become an open relay. It is not a fit for a large mail operation, since the documentation describes it as designed mainly for individuals and small groups, and the built in DKIM verification and SPF checking assume a particular relationship between the server and the domains it serves. Before you deploy it, read the installation guide for your distribution, decide whether Dovecot will do your authentication, and check the security levels documentation so you know which TLS policy each domain gets.

Frequently asked questions

Official sources

1. albertito/chasquid on GitHub
2. Issues
3. Project website
4. README