New script build.sh is much more suitable for downstream packaging
(e.g. ./build.sh package) than hacked together package.sh wrapper for
get.sh while still being usable for "effort-less" installation.
Additionally, hostname setting in get.sh is flawed in many ways and is
not reimplemented in build.sh.
build.sh has proper command line options that allow to customize build
configuration and installation prefixes.
Documentation page get.sh is removed since all applicable environment
variables and flags are documented in ./build.sh --help.
build.sh can be called from the source directory to build maddy from
*this* source instead of forced 'go get' that was used in get.sh.
However, if build.sh is called not from the source directory, it clones
the repo and (optionally) uses the specified commit. This keeps build.sh
usable in curl|bash commands.
Due to the way source code is fetched, build.sh uses Git tags instead of
Go module versions as get.sh did.
Given amount of steps actually needed to install maddy, it makes sense
to automate at least some of them.
Also, since maddy repo is replicated on foxcpp.dev/maddy,
it can be used like this:
curl https://foxcpp.dev/maddy/get.sh | bash
That's, of course, is a partial solution. In future, package
repository least for Debian will be created with properly built
packages.
Response to possible complaints about curl|bash:
There is not that much difference between that and cloning repo
to run 'make install'. People who care can inspect the script
either way and ones who don't care... well, don't care.
This support is based on github.com/foxcpp/go-msgauth fork until
emerison/go-msgauth#13 gets merged.
Further extensions are required to make sure only messages we can
actually "take responsibility for" are signed.
RSA-2048 is used as a default algorithm when generating new keys.
RSA-4096 can cause trouble with UDP-only DNS due to responses being
bigger than 512 octets. RSA-1024 is too weak and explicitly
disallowed in maddy for new keys. It could be possible to use Ed25519
but support is not widely deployed yet (according to warning in rspamd
docs dated 2019-09). Users concerned about security of RSA-2048 can
switch to RSA-4096 or Ed25519, keeping relevant problems in mind.
Ed25519 key format uses PKCS#8, this seems to be different from other
implementations that just dump key material into a file without any
wrapping. Interoperability is not considered to encourage key
rotation when migration, which is a good thing to do anyway.
There is no option to use "body limit", since it is dangerous
and go-msgauth/dkim does not support it for signing.
The default set of signed header fields is the list used by rspamd.
Most "core" fields are oversigned to provide strict integrity.
"Conditional oversigning" similar to rspamd is not implemented, though
it may be useful, further research is required.
Multi-tentant configuration with DKIM and DMARC is much more verbose,
configuration example is added to config.d/multitentant-dkim.conf to
explain how to make it work.
Now it is not tied go-imap-sql details (with the exception of special
features), allowing it to be used with other storage backends that will
be added in the future.
--unsafe flag is removed and now maddyctl explicitly asks for
confirmation in cases where transaction may be unsafe for connected
clients. --yes flag disables that. In the future, maddy can be
extended with IPC interface to push updates so it this restriction
can be lifted altogether.
1. There is only one version for maddy and imapsql-ctl utility.
This prevents confusion about compatibility.
2. Modified imapsql-ctl understands maddy config format, this allows
it to read needed values from it without the need for lengthy commmand
line arguments.
Closes#148.
Due to .gitignore, target/queue directory got ignored and was not
commited.
This commit makes problematic ignore filter more strict and adds
accidentally removed directory.
