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!

README.md

@@ -56,30 +56,32 @@ Verify you have a working mox binary:
 
 Note: Mox only compiles/works on unix systems, not on Plan 9 or Windows.
 
-You can also run mox with docker image "moxmail/mox" on hub.docker.com, with
-tags like "latest", "0.0.1", etc. See docker-compose.yml in this repository.
+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.
 
 
 # Quickstart
 
 The easiest way to get started with serving email for your domain is to get a
-vm/machine dedicated to serving email, name it [host].[domain], login as an
-admin user, e.g. /home/service, download mox, and generate a configuration for
-your desired email address at your domain:
+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:
 
 	./mox quickstart you@example.com
 
 This creates an account, generates a password and configuration files, prints
-the DNS records you need to manually create and prints commands to set
-permissions and install mox as a service.
+the DNS records you need to manually create and prints commands to start mox and
+optionally install mox as a service.
 
 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.
 
 A dedicated machine is highly recommended because modern email requires HTTPS,
-also for automatic TLS.  You can combine mox with an existing webserver, but it
-requires more configuration.
+and mox currently needs it for automatic TLS.  You can combine mox with an
+existing webserver, but it requires more configuration.
 
 After starting, you can access the admin web interface on internal IPs.