* check that the PUBLIC_IP is not listed in zen.spamhaus.org
* check that the PRIMARY_HOSTNAME is not listed in dbl.spamhaus.org
* check that a connection to Google's MTA is working (i.e. we're not on a residential network that blocks outbound port 25)
Rather than pass `-r /dev/random` to ldns-keygen (it was `-r /dev/urandom`),
don't pass `-r` at all since /dev/random is the default.
Merges branch 'master' of github.com:pysiak/mailinabox
/dev/random should be used for crypto-grade RNG.
To make sure use of /dev/random doesn't stall due to lack of entropy, install haveged which fills the entropy pool with sources such as network traffic, key strokes, etc.
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
modified: setup/dns.sh
modified: setup/system.sh
modified: setup/webmail.sh
This lets roundcube's manageseive plugin do cool things like vacation responses.
Also:
* Run the spam filtering sieve script out of a global sieve file that we'll place in /etc/dovecot. It is no longer necessary to create per-user sieve files for this. Remove them with a new migration. Remove the code that created them.
* Corrects the spam script. Backslashes were double-escaped probably because this script started embedded within the bash script. Not sure how this was working until now.
this adapts work by @h8h in #103
As the scripts keep growing, it's time to split them up to
keep them understandable.
This splits mail.sh into mail-postfix.sh, mail-dovecot.sh,
and mail-users.sh, which has all of the user database-related
configurations shared by Dovecot and Postfix. Also from
spamassassin.sh the core sieve configuration is moved into
mail-dovecot.sh and the virtual transport setting is moved
into mail-postfix.sh.
Also revising one of the sed scripts in mail-dovecot to
not insert a new additional # at the start of a line each
time the script is run.
Intended to be the simplest auth possible: every time the service
starts, a random key is written to `/var/lib/mailinabox/api.key`. In
order to authenticate to the service, the client must pass the contents
of `api.key` in an HTTP basic auth header. In this way, users who do not
have read access to that file are not able to communicate with the
service.
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.
