In particular, allow to set Version constant for use when module build
info is not available (executable is built using 'go build' instead
of 'go get').
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.
It fits poorly with limited amount of checks that are (and will be)
implemented in maddy.
Advanced filtering that requires "spam score" logic should be performed
by external software such as rspamd. At this point duplicating that
logic in maddy makes no sense, since it is highly problematic to
integrate it with external software.
Mailing lists break DKIM signatures by modifing Subject and other header
fields. They are supposed to either include their own DKIM signature
and/or ARC (RFC 8617) seal.
Now it is a wrapper around miekg/dns library that reports
whether AD flag is set in the response. It does not perform
any verification on its own. This is not going to be implemented due
to complexity of code required to make it work reasonably fast.
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.
Now modules are documented in separate man pages depending on their
main purpose. This generally keeps things more organised than with
one huge maddy.conf(5) page to document everything.
Supported modes:
- off
No authentication with upstream server.
- forward
Forward username:password pair used by client.
- plain
Authenticate using username:password pair.
- external
Authenticate using SASL EXTERNAL mechanism. Usually this is used for
TLS client certificate auth.
New name more precisely describes what it is doing now. It was initally
meant to be more generic and usable for other purposes, but I don't
think we will need that flexibility.
- fsstore is now required, this is reflected by documentation updates.
Upstream commits:
* 8ee5c96 Fix handling of "null" compression
* d6bc61c Add support for zstd compression
* aa76135 Implement support for LZ4 compression support
* cde9a24 Update VersionStr constant
* 2008a7b Remove schema upgrade operations for older versions
* b6668d0 Remove section about Internal/External BLOBs from README
* e91826c cmd/imapsql-ctl: Remove support for reading driver/DSN from text file
* 0dca68f Rename imapsql.Store -> imapsql.FSStore
* 4071c69 Remove support for handling messages in table rows
* 4c8996e Remove most of the code for storing messages in table rows
* b682ac1 Skip header in openBody if needHeader = false
* 2a263c3 Require fsstore to be used
* 45b437d Remove CI job for testing with MariaDB
* 8d30346 Add 'go 1.12' to go.mod
Storing message contents in table rows (default behavior) creates big
serialization delays for SQLite. With fsstore, message is written
to the disk outside of SQL transaction, thus transaction becomes
small enough to make SQLite synchronization delays non-signficant.
That is, SQLite, while staying strictly serial, processes transactions
fast enough. Though, that highly depends on disk speed. Here are my
measurements so far:
a) Using HDD on my PC, SQLite starts to fail with synchronization
timeouts with two parallel SMTP connections already.
b) Using SSD on my test server, 90 parallel connections flooding server
with total rate of around 550 messages per second (35 KiB each), no
synchronization timeouts.
It should be noted that throughput does not equal latency.
Server-based RDBMS can still provide much smaller write latencies since
they actually perform work in parallel. Though, it is believed that
latency is not critical for email exchange.
Conclusion is: SQLite-based storage works good enough for
moderately-sized email servers. Also, storage of big blobs in table rows
turned out to be much less practical than assumed initially, it may be
worth removing its support from go-imap-sql to simplify code.
* 1679626 Fix wrong order of arguments for setInboxId query
* da0b12c Remove dangling External Store key when message is not added to DB
* c706691 Use Bytes() method on Reader passed to Delivery.Body
* 3d2b5b0 Fix User.inboxId = 0 for newly created users
* 45cd989 Remove schema upgrade restriction
