178c587654
* Stop generating RSASHA1-NSEC3-SHA1 keys on new installs since it is no longer recommended, but preserve the key on existing installs so that we continue to sign zones with existing keys to retain the chain of trust with existing DS records. * Start generating ECDSAP256SHA256 keys during setup, the current best practice (in addition to RSASHA256 which is also ok). See https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 and https://www.cloudflare.com/dns/dnssec/ecdsa-and-dnssec/. * Sign zones using all available keys rather than choosing just one based on the TLD to enable rotation/migration to the new key and to give the user some options since not every registrar/TLD supports every algorithm. * Allow a user to drop a key from signing specific domains using DOMAINS= in our key configuration file. Signing the zones with extraneous keys may increase the size of DNS responses, which isn't ideal, although I don't know if this is a problem in practice. (Although a user can delete the RSASHA1-NSEC3-SHA1 key file, the other keys will be re-generated on upgrade.) * When generating zonefiles, add a hash of all of the DNSSEC signing keys so that when the keys change the zone is definitely regenerated and re-signed. * In status checks, if DNSSEC is not active (or not valid), offer to use all of the keys that have been generated (for RSASHA1-NSEC3-SHA1 on existing installs, RSASHA256, and now ECDSAP256SHA256) with all digest types, since not all registers support everything, but list them in an order that guides users to the best practice. * In status checks, if the deployed DS record doesn't use a ECDSAP256SHA256 key, prompt the user to update their DS record. * In status checks, if multiple DS records are set, only fail if none are valid. If some use ECDSAP256SHA256 and some don't, remind the user to delete the DS records that don't. * Don't fail if the DS record uses the SHA384 digest (by pre-generating a DS record with that digest type) but don't recommend it because it is not in the IANA mandatory list yet (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml). See #1953 |
||
|---|---|---|
| api | ||
| conf | ||
| management | ||
| setup | ||
| tests | ||
| tools | ||
| .editorconfig | ||
| .gitignore | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
| Vagrantfile | ||
| security.md | ||
README.md
Mail-in-a-Box
By @JoshData and contributors.
Mail-in-a-Box helps individuals take back control of their email by defining a one-click, easy-to-deploy SMTP+everything else server: a mail server in a box.
Please see https://mailinabox.email for the project's website and setup guide!
Our goals are to:
- Make deploying a good mail server easy.
- Promote decentralization, innovation, and privacy on the web.
- Have automated, auditable, and idempotent configuration.
- Not make a totally unhackable, NSA-proof server.
- Not make something customizable by power users.
Additionally, this project has a Code of Conduct, which supersedes the goals above. Please review it when joining our community.
In The Box
Mail-in-a-Box turns a fresh Ubuntu 18.04 LTS 64-bit machine into a working mail server by installing and configuring various components.
It is a one-click email appliance. There are no user-configurable setup options. It "just works."
The components installed are:
- SMTP (postfix), IMAP (Dovecot), CardDAV/CalDAV (Nextcloud), and Exchange ActiveSync (z-push) servers
- Webmail (Roundcube), mail filter rules (thanks to Roundcube and Dovecot), and email client autoconfig settings (served by nginx)
- Spam filtering (spamassassin) and greylisting (postgrey)
- DNS (nsd4) with SPF, DKIM (OpenDKIM), DMARC, DNSSEC, DANE TLSA, MTA-STS, and SSHFP policy records automatically set
- TLS certificates are automatically provisioned using Let's Encrypt for protecting https and all of the other services on the box
- Backups (duplicity), firewall (ufw), intrusion protection (fail2ban), and basic system monitoring (munin)
It also includes system management tools:
- Comprehensive health monitoring that checks each day that services are running, ports are open, TLS certificates are valid, and DNS records are correct
- A control panel for adding/removing mail users, aliases, custom DNS records, configuring backups, etc.
- An API for all of the actions on the control panel
It also supports static website hosting since the box is serving HTTPS anyway. (To serve a website for your domains elsewhere, just add a custom DNS "A" record in you Mail-in-a-Box's control panel to point domains to another server.)
For more information on how Mail-in-a-Box handles your privacy, see the security details page.
Installation
See the setup guide for detailed, user-friendly instructions.
For experts, start with a completely fresh (really, I mean it) Ubuntu 18.04 LTS 64-bit machine. On the machine...
Clone this repository and checkout the tag corresponding to the most recent release:
$ git clone https://github.com/mail-in-a-box/mailinabox
$ cd mailinabox
$ git checkout v0.53
Begin the installation.
$ sudo setup/start.sh
The installation will install, uninstall, and configure packages to turn the machine into a working, good mail server.
For help, DO NOT contact Josh directly --- I don't do tech support by email or tweet (no exceptions).
Post your question on the discussion forum instead, where maintainers and Mail-in-a-Box users may be able to help you.
Note that while we want everything to "just work," we can't control the rest of the Internet. Other mail services might block or spam-filter email sent from your Mail-in-a-Box. This is a challenge faced by everyone who runs their own mail server, with or without Mail-in-a-Box. See our discussion forum for tips about that.
Contributing and Development
Mail-in-a-Box is an open source project. Your contributions and pull requests are welcome. See CONTRIBUTING to get started.
The Acknowledgements
This project was inspired in part by the "NSA-proof your email in 2 hours" blog post by Drew Crawford, Sovereign by Alex Payne, and conversations with @shevski, @konklone, and @GregElin.
Mail-in-a-Box is similar to iRedMail and Modoboa.
The History
- In 2007 I wrote a relatively popular Mozilla Thunderbird extension that added client-side SPF and DKIM checks to mail to warn users about possible phishing: add-on page, source.
- In August 2013 I began Mail-in-a-Box by combining my own mail server configuration with the setup in "NSA-proof your email in 2 hours" and making the setup steps reproducible with bash scripts.
- Mail-in-a-Box was a semifinalist in the 2014 Knight News Challenge, but it was not selected as a winner.
- Mail-in-a-Box hit the front page of Hacker News in April 2014, September 2014, May 2015, and November 2016.
- FastCompany mentioned Mail-in-a-Box a roundup of privacy projects on June 26, 2015.