2023-01-30 16:43:50 +03:00
|
|
|
Mox is a modern full-featured open source secure mail server for low-maintenance self-hosted email.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
See Quickstart below to get started.
|
|
|
|
|
|
2023-02-25 15:38:07 +03:00
|
|
|
## Features
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-02-10 21:43:02 +03:00
|
|
|
- Quick and easy to start/maintain mail server, for your own domain(s).
|
2023-02-16 12:09:33 +03:00
|
|
|
- SMTP (with extensions) for receiving and submitting email.
|
|
|
|
|
- IMAP4 (with extensions) for giving email clients access to email.
|
2023-01-30 16:27:06 +03:00
|
|
|
- Automatic TLS with ACME, for use with Let's Encrypt and other CA's.
|
|
|
|
|
- SPF, verifying that a remote host is allowed to sent email for a domain.
|
|
|
|
|
- DKIM, verifying that a message is signed by the claimed sender domain,
|
|
|
|
|
and for signing emails sent by mox for others to verify.
|
|
|
|
|
- DMARC, for enforcing SPF/DKIM policies set by domains. Incoming DMARC
|
|
|
|
|
aggregate reports are analyzed.
|
|
|
|
|
- Reputation tracking, learning (per user) host- and domain-based reputation from
|
2023-02-10 21:43:02 +03:00
|
|
|
(Non-)Junk email.
|
2023-01-30 16:27:06 +03:00
|
|
|
- Bayesian spam filtering that learns (per user) from (Non-)Junk email.
|
2023-02-08 23:45:32 +03:00
|
|
|
- Slowing down senders with no/low reputation or questionable email content
|
|
|
|
|
(similar to greylisting). Rejected emails are stored in a mailbox called Rejects
|
2023-02-10 21:43:02 +03:00
|
|
|
for a short period, helping with misclassified legitimate synchronous
|
2023-01-30 16:27:06 +03:00
|
|
|
signup/login/transactional emails.
|
|
|
|
|
- Internationalized email, with unicode names in domains and usernames
|
|
|
|
|
("localparts").
|
|
|
|
|
- TLSRPT, parsing reports about TLS usage and issues.
|
|
|
|
|
- MTA-STS, for ensuring TLS is used whenever it is required. Both serving of
|
|
|
|
|
policies, and tracking and applying policies of remote servers.
|
|
|
|
|
- Web admin interface that helps you set up your domains and accounts
|
|
|
|
|
(instructions to create DNS records, configure
|
|
|
|
|
SPF/DKIM/DMARC/TLSRPT/MTA-STS), for status information, managing
|
|
|
|
|
accounts/domains, and modifying the configuration file.
|
|
|
|
|
- Autodiscovery (with SRV records, Microsoft-style and Thunderbird-style) for
|
|
|
|
|
easy account setup (though not many clients support it).
|
|
|
|
|
- Prometheus metrics and structured logging for operational insight.
|
|
|
|
|
|
2023-02-25 15:38:07 +03:00
|
|
|
Mox is available under the MIT-license and was created by Mechiel Lukkien,
|
|
|
|
|
mechiel@ueber.net. Mox includes the Public Suffix List by Mozilla, under Mozilla
|
|
|
|
|
Public License, v2.0.
|
2023-02-11 15:35:07 +03:00
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
# Download
|
|
|
|
|
|
2023-02-05 23:25:48 +03:00
|
|
|
You can easily (cross) compile mox if you have a recent Go toolchain installed
|
|
|
|
|
(see "go version", it must be >= 1.19; otherwise, see https://go.dev/dl/ or
|
|
|
|
|
https://go.dev/doc/manage-install and $HOME/go/bin):
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-02-05 23:25:48 +03:00
|
|
|
GOBIN=$PWD go install github.com/mjl-/mox@latest
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-02-05 23:25:48 +03:00
|
|
|
Or you can download a binary built with the latest Go toolchain from
|
|
|
|
|
https://beta.gobuilds.org/github.com/mjl-/mox, and symlink or rename it to
|
|
|
|
|
"mox".
|
|
|
|
|
|
|
|
|
|
Verify you have a working mox binary:
|
|
|
|
|
|
|
|
|
|
./mox version
|
|
|
|
|
|
|
|
|
|
Note: Mox only compiles/works on unix systems, not on Plan 9 or Windows.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
change mox to start as root, bind to network sockets, then drop to regular unprivileged mox user
makes it easier to run on bsd's, where you cannot (easily?) let non-root users
bind to ports <1024. starting as root also paves the way for future improvements
with privilege separation.
unfortunately, this requires changes to how you start mox. though mox will help
by automatically fix up dir/file permissions/ownership.
if you start mox from the systemd unit file, you should update it so it starts
as root and adds a few additional capabilities:
# first update the mox binary, then, as root:
./mox config printservice >mox.service
systemctl daemon-reload
systemctl restart mox
journalctl -f -u mox &
# you should see mox start up, with messages about fixing permissions on dirs/files.
if you used the recommended config/ and data/ directory, in a directory just for
mox, and with the mox user called "mox", this should be enough.
if you don't want mox to modify dir/file permissions, set "NoFixPermissions:
true" in mox.conf.
if you named the mox user something else than mox, e.g. "_mox", add "User: _mox"
to mox.conf.
if you created a shared service user as originally suggested, you may want to
get rid of that as it is no longer useful and may get in the way. e.g. if you
had /home/service/mox with a "service" user, that service user can no longer
access any files: only mox and root can.
this also adds scripts for building mox docker images for alpine-supported
platforms.
the "restart" subcommand has been removed. it wasn't all that useful and got in
the way.
and another change: when adding a domain while mtasts isn't enabled, don't add
the per-domain mtasts config, as it would cause failure to add the domain.
based on report from setting up mox on openbsd from mteege.
and based on issue #3. thanks for the feedback!
2023-02-27 14:19:55 +03:00
|
|
|
You can also run mox with docker image "docker.io/moxmail/mox", with tags like
|
|
|
|
|
"latest", "0.0.1" and "0.0.1-go1.20.1-alpine3.17.2", etc. See docker-compose.yml
|
|
|
|
|
in this repository for instructions on starting.
|
2023-02-24 16:16:51 +03:00
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
# Quickstart
|
|
|
|
|
|
|
|
|
|
The easiest way to get started with serving email for your domain is to get a
|
change mox to start as root, bind to network sockets, then drop to regular unprivileged mox user
makes it easier to run on bsd's, where you cannot (easily?) let non-root users
bind to ports <1024. starting as root also paves the way for future improvements
with privilege separation.
unfortunately, this requires changes to how you start mox. though mox will help
by automatically fix up dir/file permissions/ownership.
if you start mox from the systemd unit file, you should update it so it starts
as root and adds a few additional capabilities:
# first update the mox binary, then, as root:
./mox config printservice >mox.service
systemctl daemon-reload
systemctl restart mox
journalctl -f -u mox &
# you should see mox start up, with messages about fixing permissions on dirs/files.
if you used the recommended config/ and data/ directory, in a directory just for
mox, and with the mox user called "mox", this should be enough.
if you don't want mox to modify dir/file permissions, set "NoFixPermissions:
true" in mox.conf.
if you named the mox user something else than mox, e.g. "_mox", add "User: _mox"
to mox.conf.
if you created a shared service user as originally suggested, you may want to
get rid of that as it is no longer useful and may get in the way. e.g. if you
had /home/service/mox with a "service" user, that service user can no longer
access any files: only mox and root can.
this also adds scripts for building mox docker images for alpine-supported
platforms.
the "restart" subcommand has been removed. it wasn't all that useful and got in
the way.
and another change: when adding a domain while mtasts isn't enabled, don't add
the per-domain mtasts config, as it would cause failure to add the domain.
based on report from setting up mox on openbsd from mteege.
and based on issue #3. thanks for the feedback!
2023-02-27 14:19:55 +03:00
|
|
|
vm/machine dedicated to serving email, name it [host].[domain] (e.g.
|
|
|
|
|
mail.example.com), login as root, create user "mox" and its homedir by running
|
|
|
|
|
"useradd -d /home/mox mox && mkdir /home/mox", download mox to that directory,
|
|
|
|
|
and generate a configuration for your desired email address at your domain:
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
./mox quickstart you@example.com
|
|
|
|
|
|
2023-02-10 21:43:02 +03:00
|
|
|
This creates an account, generates a password and configuration files, prints
|
change mox to start as root, bind to network sockets, then drop to regular unprivileged mox user
makes it easier to run on bsd's, where you cannot (easily?) let non-root users
bind to ports <1024. starting as root also paves the way for future improvements
with privilege separation.
unfortunately, this requires changes to how you start mox. though mox will help
by automatically fix up dir/file permissions/ownership.
if you start mox from the systemd unit file, you should update it so it starts
as root and adds a few additional capabilities:
# first update the mox binary, then, as root:
./mox config printservice >mox.service
systemctl daemon-reload
systemctl restart mox
journalctl -f -u mox &
# you should see mox start up, with messages about fixing permissions on dirs/files.
if you used the recommended config/ and data/ directory, in a directory just for
mox, and with the mox user called "mox", this should be enough.
if you don't want mox to modify dir/file permissions, set "NoFixPermissions:
true" in mox.conf.
if you named the mox user something else than mox, e.g. "_mox", add "User: _mox"
to mox.conf.
if you created a shared service user as originally suggested, you may want to
get rid of that as it is no longer useful and may get in the way. e.g. if you
had /home/service/mox with a "service" user, that service user can no longer
access any files: only mox and root can.
this also adds scripts for building mox docker images for alpine-supported
platforms.
the "restart" subcommand has been removed. it wasn't all that useful and got in
the way.
and another change: when adding a domain while mtasts isn't enabled, don't add
the per-domain mtasts config, as it would cause failure to add the domain.
based on report from setting up mox on openbsd from mteege.
and based on issue #3. thanks for the feedback!
2023-02-27 14:19:55 +03:00
|
|
|
the DNS records you need to manually create and prints commands to start mox and
|
|
|
|
|
optionally install mox as a service.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
If you already have email configured for your domain, or if you are already
|
|
|
|
|
sending email for your domain from other machines/services, you should modify
|
|
|
|
|
the suggested configuration and/or DNS records.
|
|
|
|
|
|
2023-02-10 21:43:02 +03:00
|
|
|
A dedicated machine is highly recommended because modern email requires HTTPS,
|
change mox to start as root, bind to network sockets, then drop to regular unprivileged mox user
makes it easier to run on bsd's, where you cannot (easily?) let non-root users
bind to ports <1024. starting as root also paves the way for future improvements
with privilege separation.
unfortunately, this requires changes to how you start mox. though mox will help
by automatically fix up dir/file permissions/ownership.
if you start mox from the systemd unit file, you should update it so it starts
as root and adds a few additional capabilities:
# first update the mox binary, then, as root:
./mox config printservice >mox.service
systemctl daemon-reload
systemctl restart mox
journalctl -f -u mox &
# you should see mox start up, with messages about fixing permissions on dirs/files.
if you used the recommended config/ and data/ directory, in a directory just for
mox, and with the mox user called "mox", this should be enough.
if you don't want mox to modify dir/file permissions, set "NoFixPermissions:
true" in mox.conf.
if you named the mox user something else than mox, e.g. "_mox", add "User: _mox"
to mox.conf.
if you created a shared service user as originally suggested, you may want to
get rid of that as it is no longer useful and may get in the way. e.g. if you
had /home/service/mox with a "service" user, that service user can no longer
access any files: only mox and root can.
this also adds scripts for building mox docker images for alpine-supported
platforms.
the "restart" subcommand has been removed. it wasn't all that useful and got in
the way.
and another change: when adding a domain while mtasts isn't enabled, don't add
the per-domain mtasts config, as it would cause failure to add the domain.
based on report from setting up mox on openbsd from mteege.
and based on issue #3. thanks for the feedback!
2023-02-27 14:19:55 +03:00
|
|
|
and mox currently needs it for automatic TLS. You can combine mox with an
|
|
|
|
|
existing webserver, but it requires more configuration.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
After starting, you can access the admin web interface on internal IPs.
|
|
|
|
|
|
|
|
|
|
|
2023-02-25 15:38:07 +03:00
|
|
|
# Future/development
|
|
|
|
|
|
|
|
|
|
Mox has automated tests, including for interoperability with Postfix for SMTP.
|
|
|
|
|
Mox is manually tested with email clients: Mozilla Thunderbird, mutt, iOS Mail,
|
|
|
|
|
macOS Mail, Android Mail, Microsoft Outlook. Mox is also manually tested to
|
|
|
|
|
interoperate with popular cloud providers: gmail.com, outlook.com, yahoo.com,
|
|
|
|
|
proton.me.
|
|
|
|
|
|
|
|
|
|
The code is heavily cross-referenced with the RFCs for readability/maintainability.
|
|
|
|
|
|
|
|
|
|
## Roadmap
|
|
|
|
|
|
|
|
|
|
- Strict vs lax mode, defaulting to lax when receiving from the internet, and
|
|
|
|
|
strict when sending.
|
|
|
|
|
- "developer server" mode, to easily launch a local SMTP/IMAP server to test
|
|
|
|
|
your apps mail sending capabilities.
|
|
|
|
|
- Rate limiting and spam detection for submitted/outgoing messages, to reduce
|
|
|
|
|
impact when an account gets compromised.
|
|
|
|
|
- Privilege separation, isolating parts of the application to more restricted
|
|
|
|
|
sandbox (e.g. new unauthenticated connections).
|
|
|
|
|
- DANE and DNSSEC.
|
|
|
|
|
- Sending DMARC and TLS reports (currently only receiving).
|
|
|
|
|
- OAUTH2 support, for single sign on.
|
|
|
|
|
- Basic reverse proxy, so port 443 can be used for regular web serving too.
|
|
|
|
|
- Using mox as backup MX.
|
|
|
|
|
- ACME verification over HTTP (in addition to current tls-alpn01).
|
|
|
|
|
- Add special IMAP mailbox ("Queue?") that contains queued but
|
|
|
|
|
not-yet-delivered messages.
|
|
|
|
|
- Old-style internationalization in messages.
|
|
|
|
|
- Calendaring
|
|
|
|
|
- Webmail
|
|
|
|
|
|
|
|
|
|
There are many smaller improvements to make as well, search for "todo" in the code.
|
|
|
|
|
|
|
|
|
|
## Not supported
|
|
|
|
|
|
|
|
|
|
But perhaps in the future...
|
|
|
|
|
|
|
|
|
|
- Sieve for filtering (for now see Rulesets in the account config)
|
|
|
|
|
- HTTP-based API for sending messages and receiving delivery feedback
|
|
|
|
|
- Functioning as SMTP relay
|
|
|
|
|
- Forwarding (to an external address)
|
|
|
|
|
- Autoresponders
|
|
|
|
|
- POP3
|
|
|
|
|
- Delivery to (unix) OS system users
|
|
|
|
|
- PGP or S/MIME
|
|
|
|
|
- Mailing list manager
|
|
|
|
|
- Support for pluggable delivery mechanisms
|
|
|
|
|
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
# FAQ - Frequently Asked Questions
|
|
|
|
|
|
2023-02-11 15:35:07 +03:00
|
|
|
## Why a new mail server implementation?
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
Mox aims to make "running a mail server" easy and nearly effortless. Excellent
|
|
|
|
|
quality mail server software exists, but getting a working setup typically
|
|
|
|
|
requires you configure half a dozen services (SMTP, IMAP, SPF/DKIM/DMARC, spam
|
|
|
|
|
filtering). That seems to lead to people no longer running their own mail
|
2023-02-10 21:43:02 +03:00
|
|
|
servers, instead switching to one of the few centralized email providers. Email
|
|
|
|
|
with SMTP is a long-time decentralized messaging protocol. To keep it
|
|
|
|
|
decentralized, people need to run their own mail server. Mox aims to make that
|
|
|
|
|
easy.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-02-11 15:35:07 +03:00
|
|
|
## Where is the documentation?
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-01-30 16:43:50 +03:00
|
|
|
See all commands and help text at https://pkg.go.dev/github.com/mjl-/mox/, and
|
|
|
|
|
example config files at https://pkg.go.dev/github.com/mjl-/mox/config/.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-01-30 16:43:50 +03:00
|
|
|
You can get the same information by running "mox" without arguments to list its
|
2023-02-10 21:43:02 +03:00
|
|
|
subcommands and usage, and "mox help [subcommand]" for more details.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-01-30 16:43:50 +03:00
|
|
|
The example config files are printed by "mox config describe-static" and "mox
|
|
|
|
|
config describe-dynamic".
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
Mox is still in early stages, and documentation is still limited. Please create
|
|
|
|
|
an issue describing what is unclear or confusing, and we'll try to improve the
|
|
|
|
|
documentation.
|
|
|
|
|
|
2023-02-11 15:35:07 +03:00
|
|
|
## How do I import/export email?
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-02-16 11:57:27 +03:00
|
|
|
Use the import functionality on the accounts web page to import a zip/tgz with
|
|
|
|
|
maildirs/mbox files, or use the "mox import maildir" or "mox import mbox"
|
|
|
|
|
subcommands. You could also use your IMAP email client, add your mox account,
|
|
|
|
|
and copy or move messages from one account to the other.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-02-16 11:57:27 +03:00
|
|
|
Similarly, see the export functionality on the accounts web page and the "mox
|
|
|
|
|
export maildir" and "mox export mbox" subcommands to export email.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-02-11 15:35:07 +03:00
|
|
|
## How can I help?
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
Mox needs users and testing in real-life setups! So just give it a try, send
|
|
|
|
|
and receive emails through it with your favourite email clients, and file an
|
|
|
|
|
issue if you encounter a problem or would like to see a feature/functionality
|
|
|
|
|
implemented.
|
|
|
|
|
|
|
|
|
|
Instead of switching your email for your domain over to mox, you could simply
|
2023-02-10 21:43:02 +03:00
|
|
|
configure mox for a subdomain, e.g. [you]@moxtest.[yourdomain].
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
If you have experience with how the email protocols are used in the wild, e.g.
|
|
|
|
|
compatibility issues, limitations, anti-spam measures, specification
|
|
|
|
|
violations, that would be interesting to hear about.
|
|
|
|
|
|
|
|
|
|
Pull requests for bug fixes and new code are welcome too. If the changes are
|
|
|
|
|
large, it helps to start a discussion (create a ticket) before doing all the
|
|
|
|
|
work.
|
|
|
|
|
|
2023-02-25 15:38:07 +03:00
|
|
|
## Where can I discuss mox?
|
|
|
|
|
|
|
|
|
|
Join #mox on irc.oftc.net, or #mox on the "Gopher slack".
|
|
|
|
|
|
|
|
|
|
For bug reports, please file an issue at https://github.com/mjl-/mox/issues/new.
|
|
|
|
|
|
2023-02-11 15:35:07 +03:00
|
|
|
## How do I change my password?
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
Regular users (doing IMAP/SMTP with authentication) can change their password
|
2023-02-16 11:57:27 +03:00
|
|
|
at the account page, e.g. http://127.0.0.1/. Or you can set a password with "mox
|
|
|
|
|
setaccountpassword".
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
The admin password can be changed with "mox setadminpassword".
|
|
|
|
|
|
2023-02-11 15:35:07 +03:00
|
|
|
## How do I configure a second mox instance as a backup MX?
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
Unfortunately, mox does not yet provide an option for that. Mox does spam
|
|
|
|
|
filtering based on reputation of received messages. It will take a good amount
|
|
|
|
|
of work to share that information with a backup MX. Without that information,
|
|
|
|
|
spammer could use a backup MX to get their spam accepted. Until mox has a
|
|
|
|
|
proper solution, you can simply run a single SMTP server.
|
|
|
|
|
|
2023-02-11 15:35:07 +03:00
|
|
|
## How secure is mox?
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-02-10 21:43:02 +03:00
|
|
|
Security is high on the priority list for mox. Mox is young, so don't expect no
|
2023-01-30 16:27:06 +03:00
|
|
|
bugs at all. Mox does have automated tests for some security aspects, e.g. for
|
|
|
|
|
login, and uses fuzzing. Mox is written in Go, so some classes of bugs such as
|
|
|
|
|
buffer mishandling do not typically result in privilege escalation. Of course
|
|
|
|
|
logic bugs will still exist. If you find any security issues, please email them
|
|
|
|
|
to mechiel@ueber.net.
|