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).
|
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
|
|
|
- SMTP (with extensions) for receiving, submitting and delivering email.
|
2023-02-16 12:09:33 +03:00
|
|
|
- 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.
|
2023-07-18 09:58:01 +03:00
|
|
|
- SPF, verifying that a remote host is allowed to send email for a domain.
|
2023-01-30 16:27:06 +03:00
|
|
|
- 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).
|
add webmail
it was far down on the roadmap, but implemented earlier, because it's
interesting, and to help prepare for a jmap implementation. for jmap we need to
implement more client-like functionality than with just imap. internal data
structures need to change. jmap has lots of other requirements, so it's already
a big project. by implementing a webmail now, some of the required data
structure changes become clear and can be made now, so the later jmap
implementation can do things similarly to the webmail code. the webmail
frontend and webmail are written together, making their interface/api much
smaller and simpler than jmap.
one of the internal changes is that we now keep track of per-mailbox
total/unread/unseen/deleted message counts and mailbox sizes. keeping this
data consistent after any change to the stored messages (through the code base)
is tricky, so mox now has a consistency check that verifies the counts are
correct, which runs only during tests, each time an internal account reference
is closed. we have a few more internal "changes" that are propagated for the
webmail frontend (that imap doesn't have a way to propagate on a connection),
like changes to the special-use flags on mailboxes, and used keywords in a
mailbox. more changes that will be required have revealed themselves while
implementing the webmail, and will be implemented next.
the webmail user interface is modeled after the mail clients i use or have
used: thunderbird, macos mail, mutt; and webmails i normally only use for
testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed,
but still the goal is to make this webmail client easy to use for everyone. the
user interface looks like most other mail clients: a list of mailboxes, a
search bar, a message list view, and message details. there is a top/bottom and
a left/right layout for the list/message view, default is automatic based on
screen size. the panes can be resized by the user. buttons for actions are just
text, not icons. clicking a button briefly shows the shortcut for the action in
the bottom right, helping with learning to operate quickly. any text that is
underdotted has a title attribute that causes more information to be displayed,
e.g. what a button does or a field is about. to highlight potential phishing
attempts, any text (anywhere in the webclient) that switches unicode "blocks"
(a rough approximation to (language) scripts) within a word is underlined
orange. multiple messages can be selected with familiar ui interaction:
clicking while holding control and/or shift keys. keyboard navigation works
with arrows/page up/down and home/end keys, and also with a few basic vi-like
keys for list/message navigation. we prefer showing the text instead of
html (with inlined images only) version of a message. html messages are shown
in an iframe served from an endpoint with CSP headers to prevent dangerous
resources (scripts, external images) from being loaded. the html is also
sanitized, with javascript removed. a user can choose to load external
resources (e.g. images for tracking purposes).
the frontend is just (strict) typescript, no external frameworks. all
incoming/outgoing data is typechecked, both the api request parameters and
response types, and the data coming in over SSE. the types and checking code
are generated with sherpats, which uses the api definitions generated by
sherpadoc based on the Go code. so types from the backend are automatically
propagated to the frontend. since there is no framework to automatically
propagate properties and rerender components, changes coming in over the SSE
connection are propagated explicitly with regular function calls. the ui is
separated into "views", each with a "root" dom element that is added to the
visible document. these views have additional functions for getting changes
propagated, often resulting in the view updating its (internal) ui state (dom).
we keep the frontend compilation simple, it's just a few typescript files that
get compiled (combined and types stripped) into a single js file, no additional
runtime code needed or complicated build processes used. the webmail is served
is served from a compressed, cachable html file that includes style and the
javascript, currently just over 225kb uncompressed, under 60kb compressed (not
minified, including comments). we include the generated js files in the
repository, to keep Go's easily buildable self-contained binaries.
authentication is basic http, as with the account and admin pages. most data
comes in over one long-term SSE connection to the backend. api requests signal
which mailbox/search/messages are requested over the SSE connection. fetching
individual messages, and making changes, are done through api calls. the
operations are similar to imap, so some code has been moved from package
imapserver to package store. the future jmap implementation will benefit from
these changes too. more functionality will probably be moved to the store
package in the future.
the quickstart enables webmail on the internal listener by default (for new
installs). users can enable it on the public listener if they want to. mox
localserve enables it too. to enable webmail on existing installs, add settings
like the following to the listeners in mox.conf, similar to AccountHTTP(S):
WebmailHTTP:
Enabled: true
WebmailHTTPS:
Enabled: true
special thanks to liesbeth, gerben, andrii for early user feedback.
there is plenty still to do, see the list at the top of webmail/webmail.ts.
feedback welcome as always.
2023-08-07 22:57:03 +03:00
|
|
|
- Webmail for reading/sending email from the browser.
|
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config
- make builtin http handlers serve on specific domains, such as for mta-sts, so
e.g. /.well-known/mta-sts.txt isn't served on all domains.
- add logging of a few more fields in access logging.
- small tweaks/bug fixes in webserver request handling.
- add config option for redirecting entire domains to another (common enough).
- split httpserver metric into two: one for duration until writing header (i.e.
performance of server), another for duration until full response is sent to
client (i.e. performance as perceived by users).
- add admin ui, a new page for managing the configs. after making changes
and hitting "save", the changes take effect immediately. the page itself
doesn't look very well-designed (many input fields, makes it look messy). i
have an idea to improve it (explained in admin.html as todo) by making the
layout look just like the config file. not urgent though.
i've already changed my websites/webapps over.
the idea of adding a webserver is to take away a (the) reason for folks to want
to complicate their mox setup by running an other webserver on the same machine.
i think the current webserver implementation can already serve most common use
cases. with a few more tweaks (feedback needed!) we should be able to get to 95%
of the use cases. the reverse proxy can take care of the remaining 5%.
nevertheless, a next step is still to change the quickstart to make it easier
for folks to run with an existing webserver, with existing tls certs/keys.
that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
|
|
|
- Webserver with serving static files and forwarding requests (reverse
|
|
|
|
|
proxy), so port 443 can also be used to serve websites.
|
2023-01-30 16:27:06 +03:00
|
|
|
- Prometheus metrics and structured logging for operational insight.
|
2023-03-12 12:38:02 +03:00
|
|
|
- "localserve" subcommand for running mox locally for email-related
|
2023-03-12 17:16:01 +03:00
|
|
|
testing/developing, including pedantic mode.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
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-27 16:05:10 +03:00
|
|
|
GOBIN=$PWD CGO_ENABLED=0 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
|
2023-07-18 09:58:01 +03:00
|
|
|
https://beta.gobuilds.org/github.com/mjl-/mox@latest/linux-amd64-latest/, and
|
|
|
|
|
symlink or rename it to "mox".
|
2023-02-05 23:25:48 +03:00
|
|
|
|
|
|
|
|
Verify you have a working mox binary:
|
|
|
|
|
|
|
|
|
|
./mox version
|
|
|
|
|
|
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config
- make builtin http handlers serve on specific domains, such as for mta-sts, so
e.g. /.well-known/mta-sts.txt isn't served on all domains.
- add logging of a few more fields in access logging.
- small tweaks/bug fixes in webserver request handling.
- add config option for redirecting entire domains to another (common enough).
- split httpserver metric into two: one for duration until writing header (i.e.
performance of server), another for duration until full response is sent to
client (i.e. performance as perceived by users).
- add admin ui, a new page for managing the configs. after making changes
and hitting "save", the changes take effect immediately. the page itself
doesn't look very well-designed (many input fields, makes it look messy). i
have an idea to improve it (explained in admin.html as todo) by making the
layout look just like the config file. not urgent though.
i've already changed my websites/webapps over.
the idea of adding a webserver is to take away a (the) reason for folks to want
to complicate their mox setup by running an other webserver on the same machine.
i think the current webserver implementation can already serve most common use
cases. with a few more tweaks (feedback needed!) we should be able to get to 95%
of the use cases. the reverse proxy can take care of the remaining 5%.
nevertheless, a next step is still to change the quickstart to make it easier
for folks to run with an existing webserver, with existing tls certs/keys.
that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
|
|
|
Note: Mox only compiles for/works on unix systems, not on Plan 9 or Windows.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-03-20 11:28:17 +03:00
|
|
|
You can also run mox with docker image `r.xmox.nl/mox`, with tags like `v0.0.1`
|
2023-08-20 19:45:19 +03:00
|
|
|
and `v0.0.1-go1.20.1-alpine3.17.2`, see https://r.xmox.nl/r/mox/. See
|
2023-03-20 11:28:17 +03:00
|
|
|
docker-compose.yml in this repository for instructions on starting. You must run
|
|
|
|
|
docker with host networking, because mox needs to find your actual public IP's
|
|
|
|
|
and get the remote IPs for incoming connections, not a local/internal NAT IP.
|
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.
|
2023-03-04 02:49:02 +03:00
|
|
|
mail.example.com), login as root, and run:
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-03-04 02:49:02 +03:00
|
|
|
# Create mox user and homedir (or pick another name or homedir):
|
|
|
|
|
useradd -m -d /home/mox mox
|
|
|
|
|
|
|
|
|
|
cd /home/mox
|
|
|
|
|
... compile or download mox to this directory, see above ...
|
|
|
|
|
|
|
|
|
|
# Generate config files for your address/domain:
|
2023-01-30 16:27:06 +03:00
|
|
|
./mox quickstart you@example.com
|
|
|
|
|
|
2023-03-04 02:49:02 +03:00
|
|
|
The quickstart creates an account, generates a password and configuration
|
|
|
|
|
files, prints 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
|
|
|
|
2023-02-10 21:43:02 +03:00
|
|
|
A dedicated machine is highly recommended because modern email requires HTTPS,
|
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config
- make builtin http handlers serve on specific domains, such as for mta-sts, so
e.g. /.well-known/mta-sts.txt isn't served on all domains.
- add logging of a few more fields in access logging.
- small tweaks/bug fixes in webserver request handling.
- add config option for redirecting entire domains to another (common enough).
- split httpserver metric into two: one for duration until writing header (i.e.
performance of server), another for duration until full response is sent to
client (i.e. performance as perceived by users).
- add admin ui, a new page for managing the configs. after making changes
and hitting "save", the changes take effect immediately. the page itself
doesn't look very well-designed (many input fields, makes it look messy). i
have an idea to improve it (explained in admin.html as todo) by making the
layout look just like the config file. not urgent though.
i've already changed my websites/webapps over.
the idea of adding a webserver is to take away a (the) reason for folks to want
to complicate their mox setup by running an other webserver on the same machine.
i think the current webserver implementation can already serve most common use
cases. with a few more tweaks (feedback needed!) we should be able to get to 95%
of the use cases. the reverse proxy can take care of the remaining 5%.
nevertheless, a next step is still to change the quickstart to make it easier
for folks to run with an existing webserver, with existing tls certs/keys.
that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
|
|
|
and mox currently needs it for automatic TLS. You could combine mox with an
|
|
|
|
|
existing webserver, but it requires more configuration. If you want to serve
|
2023-03-04 02:49:02 +03:00
|
|
|
websites on the same machine, consider using the webserver built into mox. If
|
|
|
|
|
you want to run an existing webserver on port 443/80, see "mox help quickstart",
|
|
|
|
|
it'll tell you to run "./mox quickstart -existing-webserver you@example.com".
|
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
|
|
|
|
|
|
2023-09-21 17:08:43 +03:00
|
|
|
Mox will receive funding for essentially full-time continued work from August
|
|
|
|
|
2023 to August 2024 through NLnet/EU's NGI0 Entrust, see
|
|
|
|
|
https://nlnet.nl/project/Mox/.
|
|
|
|
|
|
2023-02-25 15:38:07 +03:00
|
|
|
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
|
|
|
|
|
|
2023-07-24 12:03:53 +03:00
|
|
|
- DANE and DNSSEC
|
2023-09-22 15:30:34 +03:00
|
|
|
- Non-HTTP-based authentication for webmail/webadmin/webaccount.
|
|
|
|
|
- Per-domain webmail and imap/smtp host name (and TLS cert) and client settings.
|
2023-07-24 12:03:53 +03:00
|
|
|
- Sending DMARC and TLS reports (currently only receiving)
|
implement message threading in backend and webmail
we match messages to their parents based on the "references" and "in-reply-to"
headers (requiring the same base subject), and in absense of those headers we
also by only base subject (against messages received max 4 weeks ago).
we store a threadid with messages. all messages in a thread have the same
threadid. messages also have a "thread parent ids", which holds all id's of
parent messages up to the thread root. then there is "thread missing link",
which is set when a referenced immediate parent wasn't found (but possibly
earlier ancestors can still be found and will be in thread parent ids".
threads can be muted: newly delivered messages are automatically marked as
read/seen. threads can be marked as collapsed: if set, the webmail collapses
the thread to a single item in the basic threading view (default is to expand
threads). the muted and collapsed fields are copied from their parent on
message delivery.
the threading is implemented in the webmail. the non-threading mode still works
as before. the new default threading mode "unread" automatically expands only
the threads with at least one unread (not seen) meessage. the basic threading
mode "on" expands all threads except when explicitly collapsed (as saved in the
thread collapsed field). new shortcuts for navigation/interaction threads have
been added, e.g. go to previous/next thread root, toggle collapse/expand of
thread (or double click), toggle mute of thread. some previous shortcuts have
changed, see the help for details.
the message threading are added with an explicit account upgrade step,
automatically started when an account is opened. the upgrade is done in the
background because it will take too long for large mailboxes to block account
operations. the upgrade takes two steps: 1. updating all message records in the
database to add a normalized message-id and thread base subject (with "re:",
"fwd:" and several other schemes stripped). 2. going through all messages in
the database again, reading the "references" and "in-reply-to" headers from
disk, and matching against their parents. this second step is also done at the
end of each import of mbox/maildir mailboxes. new deliveries are matched
immediately against other existing messages, currently no attempt is made to
rematch previously delivered messages (which could be useful for related
messages being delivered out of order).
the threading is not yet exposed over imap.
2023-09-13 09:51:50 +03:00
|
|
|
- Require TLS SMTP extension (RFC 8689)
|
|
|
|
|
- Prepare data storage for JMAP
|
add webmail
it was far down on the roadmap, but implemented earlier, because it's
interesting, and to help prepare for a jmap implementation. for jmap we need to
implement more client-like functionality than with just imap. internal data
structures need to change. jmap has lots of other requirements, so it's already
a big project. by implementing a webmail now, some of the required data
structure changes become clear and can be made now, so the later jmap
implementation can do things similarly to the webmail code. the webmail
frontend and webmail are written together, making their interface/api much
smaller and simpler than jmap.
one of the internal changes is that we now keep track of per-mailbox
total/unread/unseen/deleted message counts and mailbox sizes. keeping this
data consistent after any change to the stored messages (through the code base)
is tricky, so mox now has a consistency check that verifies the counts are
correct, which runs only during tests, each time an internal account reference
is closed. we have a few more internal "changes" that are propagated for the
webmail frontend (that imap doesn't have a way to propagate on a connection),
like changes to the special-use flags on mailboxes, and used keywords in a
mailbox. more changes that will be required have revealed themselves while
implementing the webmail, and will be implemented next.
the webmail user interface is modeled after the mail clients i use or have
used: thunderbird, macos mail, mutt; and webmails i normally only use for
testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed,
but still the goal is to make this webmail client easy to use for everyone. the
user interface looks like most other mail clients: a list of mailboxes, a
search bar, a message list view, and message details. there is a top/bottom and
a left/right layout for the list/message view, default is automatic based on
screen size. the panes can be resized by the user. buttons for actions are just
text, not icons. clicking a button briefly shows the shortcut for the action in
the bottom right, helping with learning to operate quickly. any text that is
underdotted has a title attribute that causes more information to be displayed,
e.g. what a button does or a field is about. to highlight potential phishing
attempts, any text (anywhere in the webclient) that switches unicode "blocks"
(a rough approximation to (language) scripts) within a word is underlined
orange. multiple messages can be selected with familiar ui interaction:
clicking while holding control and/or shift keys. keyboard navigation works
with arrows/page up/down and home/end keys, and also with a few basic vi-like
keys for list/message navigation. we prefer showing the text instead of
html (with inlined images only) version of a message. html messages are shown
in an iframe served from an endpoint with CSP headers to prevent dangerous
resources (scripts, external images) from being loaded. the html is also
sanitized, with javascript removed. a user can choose to load external
resources (e.g. images for tracking purposes).
the frontend is just (strict) typescript, no external frameworks. all
incoming/outgoing data is typechecked, both the api request parameters and
response types, and the data coming in over SSE. the types and checking code
are generated with sherpats, which uses the api definitions generated by
sherpadoc based on the Go code. so types from the backend are automatically
propagated to the frontend. since there is no framework to automatically
propagate properties and rerender components, changes coming in over the SSE
connection are propagated explicitly with regular function calls. the ui is
separated into "views", each with a "root" dom element that is added to the
visible document. these views have additional functions for getting changes
propagated, often resulting in the view updating its (internal) ui state (dom).
we keep the frontend compilation simple, it's just a few typescript files that
get compiled (combined and types stripped) into a single js file, no additional
runtime code needed or complicated build processes used. the webmail is served
is served from a compressed, cachable html file that includes style and the
javascript, currently just over 225kb uncompressed, under 60kb compressed (not
minified, including comments). we include the generated js files in the
repository, to keep Go's easily buildable self-contained binaries.
authentication is basic http, as with the account and admin pages. most data
comes in over one long-term SSE connection to the backend. api requests signal
which mailbox/search/messages are requested over the SSE connection. fetching
individual messages, and making changes, are done through api calls. the
operations are similar to imap, so some code has been moved from package
imapserver to package store. the future jmap implementation will benefit from
these changes too. more functionality will probably be moved to the store
package in the future.
the quickstart enables webmail on the internal listener by default (for new
installs). users can enable it on the public listener if they want to. mox
localserve enables it too. to enable webmail on existing installs, add settings
like the following to the listeners in mox.conf, similar to AccountHTTP(S):
WebmailHTTP:
Enabled: true
WebmailHTTPS:
Enabled: true
special thanks to liesbeth, gerben, andrii for early user feedback.
there is plenty still to do, see the list at the top of webmail/webmail.ts.
feedback welcome as always.
2023-08-07 22:57:03 +03:00
|
|
|
- Calendaring
|
2023-02-25 15:38:07 +03:00
|
|
|
- Add special IMAP mailbox ("Queue?") that contains queued but
|
2023-07-24 12:03:53 +03:00
|
|
|
not-yet-delivered messages
|
2023-08-23 15:27:21 +03:00
|
|
|
- OAUTH2 support, for single sign on
|
2023-02-27 17:04:53 +03:00
|
|
|
- Sieve for filtering (for now see Rulesets in the account config)
|
implement message threading in backend and webmail
we match messages to their parents based on the "references" and "in-reply-to"
headers (requiring the same base subject), and in absense of those headers we
also by only base subject (against messages received max 4 weeks ago).
we store a threadid with messages. all messages in a thread have the same
threadid. messages also have a "thread parent ids", which holds all id's of
parent messages up to the thread root. then there is "thread missing link",
which is set when a referenced immediate parent wasn't found (but possibly
earlier ancestors can still be found and will be in thread parent ids".
threads can be muted: newly delivered messages are automatically marked as
read/seen. threads can be marked as collapsed: if set, the webmail collapses
the thread to a single item in the basic threading view (default is to expand
threads). the muted and collapsed fields are copied from their parent on
message delivery.
the threading is implemented in the webmail. the non-threading mode still works
as before. the new default threading mode "unread" automatically expands only
the threads with at least one unread (not seen) meessage. the basic threading
mode "on" expands all threads except when explicitly collapsed (as saved in the
thread collapsed field). new shortcuts for navigation/interaction threads have
been added, e.g. go to previous/next thread root, toggle collapse/expand of
thread (or double click), toggle mute of thread. some previous shortcuts have
changed, see the help for details.
the message threading are added with an explicit account upgrade step,
automatically started when an account is opened. the upgrade is done in the
background because it will take too long for large mailboxes to block account
operations. the upgrade takes two steps: 1. updating all message records in the
database to add a normalized message-id and thread base subject (with "re:",
"fwd:" and several other schemes stripped). 2. going through all messages in
the database again, reading the "references" and "in-reply-to" headers from
disk, and matching against their parents. this second step is also done at the
end of each import of mbox/maildir mailboxes. new deliveries are matched
immediately against other existing messages, currently no attempt is made to
rematch previously delivered messages (which could be useful for related
messages being delivered out of order).
the threading is not yet exposed over imap.
2023-09-13 09:51:50 +03:00
|
|
|
- Expose threading through IMAP extension
|
2023-07-24 12:03:53 +03:00
|
|
|
- Privilege separation, isolating parts of the application to more restricted
|
|
|
|
|
sandbox (e.g. new unauthenticated connections)
|
|
|
|
|
- Using mox as backup MX
|
2023-07-26 20:23:20 +03:00
|
|
|
- ARC, with forwarded email from trusted source
|
2023-02-27 17:04:53 +03:00
|
|
|
- JMAP
|
2023-06-24 13:07:22 +03:00
|
|
|
- Autoresponder (out of office/vacation)
|
|
|
|
|
- HTTP-based API for sending messages and receiving delivery feedback
|
2023-07-24 12:03:53 +03:00
|
|
|
- Milter support, for integration with external tools
|
2023-02-25 15:38:07 +03:00
|
|
|
|
|
|
|
|
There are many smaller improvements to make as well, search for "todo" in the code.
|
|
|
|
|
|
|
|
|
|
## Not supported
|
|
|
|
|
|
|
|
|
|
But perhaps in the future...
|
|
|
|
|
|
|
|
|
|
- Functioning as SMTP relay
|
|
|
|
|
- Forwarding (to an external address)
|
|
|
|
|
- POP3
|
|
|
|
|
- Delivery to (unix) OS system users
|
|
|
|
|
- Mailing list manager
|
|
|
|
|
- Support for pluggable delivery mechanisms
|
2023-06-22 22:27:52 +03:00
|
|
|
- iOS Mail push notifications (with XAPPLEPUSHSERVICE undocumented imap
|
2023-05-31 11:24:48 +03:00
|
|
|
extension and hard to get APNS certificate)
|
2023-02-25 15:38:07 +03:00
|
|
|
|
|
|
|
|
|
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-07-24 12:00:11 +03:00
|
|
|
Importing large mailboxes may require a lot of memory (a limitation of the
|
|
|
|
|
current database). Splitting up mailboxes in smaller parts would help.
|
|
|
|
|
|
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.
|
|
|
|
|
|
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config
- make builtin http handlers serve on specific domains, such as for mta-sts, so
e.g. /.well-known/mta-sts.txt isn't served on all domains.
- add logging of a few more fields in access logging.
- small tweaks/bug fixes in webserver request handling.
- add config option for redirecting entire domains to another (common enough).
- split httpserver metric into two: one for duration until writing header (i.e.
performance of server), another for duration until full response is sent to
client (i.e. performance as perceived by users).
- add admin ui, a new page for managing the configs. after making changes
and hitting "save", the changes take effect immediately. the page itself
doesn't look very well-designed (many input fields, makes it look messy). i
have an idea to improve it (explained in admin.html as todo) by making the
layout look just like the config file. not urgent though.
i've already changed my websites/webapps over.
the idea of adding a webserver is to take away a (the) reason for folks to want
to complicate their mox setup by running an other webserver on the same machine.
i think the current webserver implementation can already serve most common use
cases. with a few more tweaks (feedback needed!) we should be able to get to 95%
of the use cases. the reverse proxy can take care of the remaining 5%.
nevertheless, a next step is still to change the quickstart to make it easier
for folks to run with an existing webserver, with existing tls certs/keys.
that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
|
|
|
Instead of switching 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
|
2023-09-21 17:08:43 +03:00
|
|
|
work. It's best to get started with a small change, and go from there!
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-03-02 22:22:26 +03:00
|
|
|
By contributing (e.g. code), you agree your contributions are licensed under the
|
|
|
|
|
MIT license (like mox), and have the rights to do so.
|
|
|
|
|
|
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-03-20 14:49:40 +03:00
|
|
|
at the account page, e.g. http://localhost/. Or you can set a password with "mox
|
2023-02-16 11:57:27 +03:00
|
|
|
setaccountpassword".
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-03-20 14:49:40 +03:00
|
|
|
The admin can change the password of any account through the admin page, at
|
|
|
|
|
http://localhost/admin/ by default (leave username empty when logging in).
|
|
|
|
|
|
|
|
|
|
The account and admin pages are served on localhost on your mail server.
|
|
|
|
|
To access these from your browser, run
|
|
|
|
|
`ssh -L 8080:localhost:80 you@yourmachine` locally and open
|
|
|
|
|
http://localhost:8080/[...].
|
|
|
|
|
|
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,
|
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config
- make builtin http handlers serve on specific domains, such as for mta-sts, so
e.g. /.well-known/mta-sts.txt isn't served on all domains.
- add logging of a few more fields in access logging.
- small tweaks/bug fixes in webserver request handling.
- add config option for redirecting entire domains to another (common enough).
- split httpserver metric into two: one for duration until writing header (i.e.
performance of server), another for duration until full response is sent to
client (i.e. performance as perceived by users).
- add admin ui, a new page for managing the configs. after making changes
and hitting "save", the changes take effect immediately. the page itself
doesn't look very well-designed (many input fields, makes it look messy). i
have an idea to improve it (explained in admin.html as todo) by making the
layout look just like the config file. not urgent though.
i've already changed my websites/webapps over.
the idea of adding a webserver is to take away a (the) reason for folks to want
to complicate their mox setup by running an other webserver on the same machine.
i think the current webserver implementation can already serve most common use
cases. with a few more tweaks (feedback needed!) we should be able to get to 95%
of the use cases. the reverse proxy can take care of the remaining 5%.
nevertheless, a next step is still to change the quickstart to make it easier
for folks to run with an existing webserver, with existing tls certs/keys.
that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
|
|
|
spammers could use a backup MX to get their spam accepted. Until mox has a
|
2023-01-30 16:27:06 +03:00
|
|
|
proper solution, you can simply run a single SMTP server.
|
|
|
|
|
|
2023-02-27 17:04:53 +03:00
|
|
|
## How do I stay up to date?
|
|
|
|
|
|
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config
- make builtin http handlers serve on specific domains, such as for mta-sts, so
e.g. /.well-known/mta-sts.txt isn't served on all domains.
- add logging of a few more fields in access logging.
- small tweaks/bug fixes in webserver request handling.
- add config option for redirecting entire domains to another (common enough).
- split httpserver metric into two: one for duration until writing header (i.e.
performance of server), another for duration until full response is sent to
client (i.e. performance as perceived by users).
- add admin ui, a new page for managing the configs. after making changes
and hitting "save", the changes take effect immediately. the page itself
doesn't look very well-designed (many input fields, makes it look messy). i
have an idea to improve it (explained in admin.html as todo) by making the
layout look just like the config file. not urgent though.
i've already changed my websites/webapps over.
the idea of adding a webserver is to take away a (the) reason for folks to want
to complicate their mox setup by running an other webserver on the same machine.
i think the current webserver implementation can already serve most common use
cases. with a few more tweaks (feedback needed!) we should be able to get to 95%
of the use cases. the reverse proxy can take care of the remaining 5%.
nevertheless, a next step is still to change the quickstart to make it easier
for folks to run with an existing webserver, with existing tls certs/keys.
that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
|
|
|
Please set "CheckUpdates: true" in mox.conf. Mox will check for a new version
|
|
|
|
|
through a DNS TXT request for `_updates.xmox.nl` once per 24h. Only if a new
|
|
|
|
|
version is published will the changelog be fetched and delivered to the
|
2023-02-27 17:04:53 +03:00
|
|
|
postmaster mailbox.
|
|
|
|
|
|
2023-03-09 18:50:24 +03:00
|
|
|
The changelog, including latest update instructions, is at
|
|
|
|
|
https://updates.xmox.nl/changelog.
|
2023-02-27 17:04:53 +03:00
|
|
|
|
2023-03-09 18:50:24 +03:00
|
|
|
You can also monitor newly added releases on this repository with the github
|
|
|
|
|
"watch" feature, or use the github RSS feed for tags
|
|
|
|
|
(https://github.com/mjl-/mox/tags.atom) or releases
|
|
|
|
|
(https://github.com/mjl-/mox/releases.atom), or monitor the docker images.
|
2023-02-27 17:04:53 +03:00
|
|
|
|
|
|
|
|
Keep in mind you have a responsibility to keep the internect-connected software
|
|
|
|
|
you run up to date and secure.
|
|
|
|
|
|
2023-05-31 11:30:34 +03:00
|
|
|
## How do I upgrade my mox installation?
|
|
|
|
|
|
|
|
|
|
We try to make upgrades effortless and you can typically just put a new binary
|
|
|
|
|
in place and restart. If manual actions are required, the release notes mention
|
|
|
|
|
them. Check the release notes of all version between your current installation
|
|
|
|
|
and the release you're upgrading to.
|
|
|
|
|
|
|
|
|
|
Before upgrading, make a backup of the data directory with `mox backup
|
|
|
|
|
<destdir>`. This writes consistent snapshots of the database files, and
|
|
|
|
|
duplicates message files from the queue and accounts. Using the new mox
|
|
|
|
|
binary, run `mox verifydata <backupdir>` (do NOT use the "live" data
|
|
|
|
|
directory!) for a dry run. If this fails, an upgrade will probably fail too.
|
|
|
|
|
Important: verifydata with the new mox binary can modify the database files
|
|
|
|
|
(due to automatic schema upgrades). So make a fresh backup again before the
|
|
|
|
|
actual upgrade. See the help output of the "backup" and "verifydata" commands
|
|
|
|
|
for more details.
|
|
|
|
|
|
|
|
|
|
During backup, message files are hardlinked if possible. Using a destination
|
|
|
|
|
directory like `data/tmp/backup` increases the odds hardlinking succeeds: the
|
|
|
|
|
default systemd service file specifically mounts the data directory, causing
|
|
|
|
|
attempts to outside it to fail with an error about cross-device linking.
|
|
|
|
|
|
|
|
|
|
If an upgrade fails and you have to restore (parts) of the data directory, you
|
|
|
|
|
should run `mox verifydata <datadir>` (with the original binary) on the
|
|
|
|
|
restored directory before starting mox again. If problematic files are found,
|
|
|
|
|
for example queue or account message files that are not in the database, run
|
|
|
|
|
`mox verifydata -fix <datadir>` to move away those files. After a restore, you may
|
|
|
|
|
also want to run `mox bumpuidvalidity <account>` for each account for which
|
|
|
|
|
messages in a mailbox changed, to force IMAP clients to synchronize mailbox
|
|
|
|
|
state.
|
|
|
|
|
|
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.
|
2023-02-27 17:04:53 +03:00
|
|
|
|
|
|
|
|
## I'm now running an email server, but how does email work?
|
|
|
|
|
|
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config
- make builtin http handlers serve on specific domains, such as for mta-sts, so
e.g. /.well-known/mta-sts.txt isn't served on all domains.
- add logging of a few more fields in access logging.
- small tweaks/bug fixes in webserver request handling.
- add config option for redirecting entire domains to another (common enough).
- split httpserver metric into two: one for duration until writing header (i.e.
performance of server), another for duration until full response is sent to
client (i.e. performance as perceived by users).
- add admin ui, a new page for managing the configs. after making changes
and hitting "save", the changes take effect immediately. the page itself
doesn't look very well-designed (many input fields, makes it look messy). i
have an idea to improve it (explained in admin.html as todo) by making the
layout look just like the config file. not urgent though.
i've already changed my websites/webapps over.
the idea of adding a webserver is to take away a (the) reason for folks to want
to complicate their mox setup by running an other webserver on the same machine.
i think the current webserver implementation can already serve most common use
cases. with a few more tweaks (feedback needed!) we should be able to get to 95%
of the use cases. the reverse proxy can take care of the remaining 5%.
nevertheless, a next step is still to change the quickstart to make it easier
for folks to run with an existing webserver, with existing tls certs/keys.
that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
|
|
|
Congrats and welcome to the club! Running an email server on the internet comes
|
|
|
|
|
with some responsibilities so you should understand how it works. See
|
2023-02-27 17:04:53 +03:00
|
|
|
https://explained-from-first-principles.com/email/ for a thorough explanation.
|
2023-03-04 03:04:54 +03:00
|
|
|
|
|
|
|
|
## What are the minimum requirements to run mox?
|
|
|
|
|
|
|
|
|
|
Mox does not need much. Nowadays most machines are larger than mox needs. You
|
|
|
|
|
can start with a machine with 512MB RAM, any CPU will do. For storage you
|
|
|
|
|
should account for the size of the email messages (no compression currently),
|
|
|
|
|
an additional 15% overhead for the meta data, and add some more headroom.
|
|
|
|
|
Expand as necessary.
|
2023-04-20 17:44:07 +03:00
|
|
|
|
|
|
|
|
## Can I see some screenshots?
|
|
|
|
|
|
|
|
|
|
Yes, see https://www.xmox.nl/screenshots/.
|
|
|
|
|
|
2023-08-16 11:16:48 +03:00
|
|
|
Mox has a webmail for reading/writing messages.
|
|
|
|
|
|
|
|
|
|
Mox also has an "account" web interface where users can view their account and
|
2023-04-20 17:44:07 +03:00
|
|
|
manage their address configuration, such as rules for automatically delivering
|
|
|
|
|
certain incoming messages to a specific mailbox.
|
|
|
|
|
|
2023-08-16 11:16:48 +03:00
|
|
|
And mox has an "admin" web interface where the administrator can make changes,
|
|
|
|
|
e.g. add/remove/modify domains/accounts/addresses.
|
2023-06-12 17:25:35 +03:00
|
|
|
|
|
|
|
|
## Won't the big email providers block my email?
|
|
|
|
|
|
|
|
|
|
It is a common misconception that it is impossible to run your own email server
|
|
|
|
|
nowadays. The claim is that the handful big email providers will simply block
|
|
|
|
|
your email. However, you can run your own email server just fine, and your
|
|
|
|
|
email will be accepted, provided you are doing it right.
|
|
|
|
|
|
|
|
|
|
If your email is rejected, it is often because your IP address has a bad email
|
|
|
|
|
sending reputation. Email servers often use IP blocklists to reject email
|
|
|
|
|
networks with a bad email sending reputation. These blocklists often work at
|
|
|
|
|
the level of whole network ranges. So if you try to run an email server from a
|
|
|
|
|
hosting provider with a bad reputation (which happens if they don't monitor
|
|
|
|
|
their network or don't act on abuse/spam reports), your IP too will have a bad
|
|
|
|
|
reputation and other mail servers (both large and small) may reject messages
|
|
|
|
|
coming from you. During the quickstart, mox checks if your IPs are on a few
|
|
|
|
|
often-used blocklists. It's typically not a good idea to host an email server
|
|
|
|
|
on the cheapest or largest cloud providers: They often don't spend the
|
|
|
|
|
resources necessary for a good reputation, or they simply block all outgoing
|
|
|
|
|
SMTP traffic. It's better to look for a technically-focused local provider.
|
2023-06-12 17:35:03 +03:00
|
|
|
They too may initially block outgoing SMTP connections on new machines to
|
|
|
|
|
prevent spam from their networks. But they will either automatically open up
|
|
|
|
|
outgoing SMTP traffic after a cool down period (e.g. 24 hours), or after you've
|
|
|
|
|
contacted their support.
|
2023-06-12 17:25:35 +03:00
|
|
|
|
|
|
|
|
After you get past the IP blocklist checks, email servers use many more signals
|
|
|
|
|
to determine if your email message could be spam and should be rejected. Mox
|
|
|
|
|
helps you set up a system that doesn't trigger most of the technical signals
|
|
|
|
|
(e.g. with SPF/DKIM/DMARC). But there are more signals, for example: Sending to
|
|
|
|
|
a mail server or address for the first time. Sending from a newly registered
|
|
|
|
|
domain. Sending messages with content that resembles known spam messages.
|
|
|
|
|
|
|
|
|
|
Should your email be rejected, you will typically get an error message that
|
|
|
|
|
explains why. In the case of big email providers the error message often has
|
|
|
|
|
instructions on how to prove to them you are a legimate sender.
|
2023-07-02 16:05:55 +03:00
|
|
|
|
|
|
|
|
## Can I use existing TLS certificates/keys?
|
|
|
|
|
|
|
|
|
|
Yes. The quickstart command creates a config that uses ACME with Let's Encrypt,
|
|
|
|
|
but you can change the config file to use existing certificate and key files.
|
|
|
|
|
|
|
|
|
|
You'll see "ACME: letsencrypt" in the "TLS" section of the "public" Listener.
|
|
|
|
|
Remove or comment out the ACME-line, and add a "KeyCerts" section like in the
|
|
|
|
|
example config file in
|
|
|
|
|
https://pkg.go.dev/github.com/mjl-/mox/config#hdr-mox_conf. You can have
|
|
|
|
|
multiple certificates and keys: The line with the "-" (dash) is the start of a
|
|
|
|
|
list item. Duplicate that line up to and including the line with KeyFile for
|
|
|
|
|
each certificate/key you have. Mox makes a TLS config that holds all specified
|
|
|
|
|
certificates/keys, and uses it for all services for that Listener (including a
|
|
|
|
|
webserver), choosing the correct certificate for incoming requests.
|
|
|
|
|
|
|
|
|
|
Keep in mind that for each email domain you host, you will need a certificate
|
|
|
|
|
for `mta-sts.<domain>` and `autoconfig.<domain>`, unless you disable MTA-STS
|
|
|
|
|
and autoconfig for that domain.
|
|
|
|
|
|
|
|
|
|
Mox opens the key and certificate files during initial startup, as root (and
|
|
|
|
|
passes file descriptors to the unprivileged process). No special permissions
|
|
|
|
|
are needed on the key and certificate files.
|