Hi, I’m sure that’s very welcome by a lot of people.
One thing I noticed is that a self-hosted email server seems to require some particular hoops to actually allow it to work well.
Possibly you already know and planed for testing these things, but here are some things I remembered:
These options possibly undermine the self-hosting, depending on the external server’s owner, but they may be required to make an email server work on a dynamic IP:
-
Option to use and specify an external, outgoing smtp relayhost (sometimes misleadingly called “smarthost”), e.g. the ISP provider’s smtp-out server (needed if own, possibly dynamic IP is not usable, because of a blocked port 25, or because emails with this source IP address are rejected by the recipient’s email providers). Debian’s debconf has an option for that, but I’m not sure if safely encrypts and stores the password into a separate postix config file. (Example: Configure SMTP relay | Yunohost Documentation)
-
Option to use and specify an external smtp-submission server, e.g. as fallback for users to still be able to communicate (send emails) during offline- or down-times of the self-hosted email server.
The self-hosted smtp server would need to accept emails from the smtp-submission server even if their FROM field contains the own email domain (to allow internal communication to function once the self-hosed smtp server comes up again). Ideally sort such emails into a “from external smtp-submission server” imap folder to make users aware to switch back to using the self-hosted smtp server.
Fallback operation:
Note 1: If the external smtp-submission server is not configured as default in the email clients, i.e. to prefer the self-hosted one during normal operation, users may have to manually select or switch to a fallback configuration (sending identity or account) in some email clients.
Note 2: Continuous receiving of email during self-hosting down-time would require a second IMAP mailbox, possibly on the external backup MX server (backup freedombox?), or using a provider’s IMAP server, and configuring the email clients to always check the external backup inboxes as well. (While the external MX or inboxes are configured to forwarding to the internal MX or domain to enable the normal operation.) -
Option to use and specify an an external MX (main, fallback or backup) (incoming smtp server, possibly but not necessarily same as smtp-out relay). The freedombox smtp would then have to allow (accept) all incoming emails from it: Whitelist the domain or IP to allow receiving email from it after offline- or downtimes of the selfhosted server. The self-hosted smtp server would explicitly need to also accept emails from this external MX server (after an outage) if the FROM field contains the own email domain (smtp-submission server may deliver to backup MX).
EDIT added later:
-
Option to use and specify an external forwarding domain (and an optional server name/IP). The emails could be received by the standard MX email server from the domain registrar (a not-preferable workaround undermining the self-hosting) or a freedombox install on a public server, and configuring it to forward the emails. For example, example.org may be the external forwarding domain, and configured with a wildcard forwarding rule, or having individual (backup) mailboxes that are configured e.g. with sieve rules to forward emails to the internal freedombox’es (sub)domain, e.g. mail.example.org.
The local freedombox smtp sever would be configured mail.example.org and have to only accept emails coming from the specified IMAP/SMTP server name or IP (and from the external forwarding domain’s MX, determined by dns lookup?), but not from anywhere else. And use that external email domain as sender’s domain in all outgoing emails. (An outgoing relay would only be used if configured with the corresponding option above.) -
Another and possibly most elegant configuration for a self-hosted smtp server on a dynamic IP may be a VPN or SSH connection to a server with a (static) public IP that has proper (forward and reverse) DNS entries and an open port 25. (Allowing to reach and receive the world without having to use or maintain any external email relaying setup while self-hosting on a dynamic IP.)
The required MX and SPF dns records, and even more external configs like email forwarding or catch-alls, will depend on the chosen options. And consequently the domain (zone) configuration information (i.e. configuration request shown to the freedombox admin) would heavily depend on the chosen options.
Edit 2: A very helpful feature could be if the freedombox smtp setup could detect any preexisting configuration from the published dns zone, and use the current dns entries to populate the presented default values of the freedombox email configuration options (i.e. outgoing smtp/submission/MX), but still allow for adjustments (e.g. to switch over from the current email provider to self-hosting on a static public IP or an internal mail.(sub)domain, and present the required updated dns records to the admin).