two more cases of shelling out external programs in a more secure way, see cecda9ce

Now that dns_update is a part of the management daemon, we no
longer are using STORAGE_ROOT/dns for anything.

Duplicity will manage the process of creating incremental backups for us.
Although duplicity can both encrypt & copy files to a remote host, I really
don't like PGP and so I don't want to use that.

Instead, we'll back up to a local directory unencrypted, then manually
encrypt the full & incremental backup files. Synchronizing the encrypted
backup directory to a remote host is a TODO.

Support dual-stack IPv4/IPv6 mail servers

Testing showed that it may take a few seconds for the default values to
populate.  If the help text is shown, “Enter the public IP address…,”
but no prompt is shown, the user may get confused and try to enter the
IP address before mailinabox has had a chance to figure out and display
a suitable default value.

This re-implements part of PR #69 by @mkropat, who wrote:

By default, Postfix adds a Received header — on all mail that you send —
that lists the IP of the device you sent the mail from.  This feature is
great if you're a mail provider and you need to debug why one user is
having sending issues.  This feature is not so great if you run your own
mail server and you don't want every recipient of every email you send
to know the device and IP you sent the email from.

To limit this filtering to outgoing mail only, we apply the filters just
to the submission port.  See these guides [1] [2] for more context.

  [1] http://askubuntu.com/a/78168/11259
  [2] http://www.void.gr/kargig/blog/2013/11/24/anonymize-headers-in-postfix/

Addresses #3

Added support by adding parallel code wherever `$PUBLIC_IP` was used.
Providing an IPv6 address is completely optional.

Playing around on my IPv6-enabled mail server revealed that — before
this change — mailinabox might try to use an IPv6 address as the value
for `$PUBLIC_IP`, which wouldn't work out well.

* using it to enable the Postfix submission service
* per @mkropat's suggestion in #69, set an option to distinguish submission from regular smpd in syslog by giving submission a new name (doing this here to test that editconf is working right on master.cf)

adding a new script archive_conf_files.sh to dump the contents of all files modified by editconf.py so testing is easier

Protect private key from being world-readable

Postfix, Dovecot, and nginx all read the key file while they're running
as root — before dropping permissions — so no authorization is needed on
the private key file beyond being root-readable.

Merges branch 'mkropat-populate-hostname-ip'

add comments to the new get_default_hostname etc. functions, and simplify the logic in the Vagrantfile and start.sh so that we always call into the same two functions

Default IP+hostname values were incorrect for my VPS provider. I
improved the detection, which should give correct results results for
almost any provider. Specific issues addressed:

- icanhazip.com detection was only enabled in non-interactive mode
- `hostname` is by convention a short (non-fqdn) name in Ubuntu
- `hostname --fqdn` fails if provider does not pouplate `hosts` file
- `hostname -i` fails if provider does not populate `hosts` file
- `curl` without `--fail` will someday return crazy results
  when icanhazip.com returns 500 errors or similar

Mask password input on stdin in tools/mail.py

allow dashes in emails during validation, and for aliases allow a much wider range of characters, fixes #64

* for local mail users, also disallows periods at the beginning or end of the local or domain parts
* Dovecot gets confused if the string contains any unusual characters, so local mail users are restricted to a narrow regex
* for mail aliases Postfix is not confused so use a regex based on RFC 2822

* use a public box (the official Ubuntu 14.04 box which contra the description does have VBox Guest Additions installed)
* now that we allow SSH password logins, since Vagrant requires it, dont muck with sshd_config here
* don't put the machine on the public network because that will allow anyone to log into it with Vagrant's default username/password, duh

move the SSH password login check out of setup because it interfers with Vagrant and into a separate script that we'll use for auditing in a later phase

* adding a Vagrantfile
* in a non-interactive setup like this, create the user's first email account for them
* let the machine auto-detect its IP address using http://icanhazip.com/
* use our own justtesting.email domain to provision a subdomain for users so they can quickly get started

script to check the SSL certificate, with instructions for turning the self-signed certificate into a properly signed certificate