| Commit message (Collapse) | Author | Age | Files |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Honor BUILD_DOCDIR and DESTDIR variables.
Also, remove the `use lib` statement from our executables.
|
| | |
|
| |
|
|
|
|
| |
Like we do for zero-length messages.
Closes: #944812.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UID EXPUNGE|FETCH|STORE commands are now split into multiple (sequential)
commands when their set representation exceeds 4096 bytes in size. Without
splitting logic set representations could grow arbitrarily large, and
exceed the server's maximum command size.
This adds roundtrips which could be eliminated by pipelining, but it's
unlikely to make any difference in typical synchronization work. While set
representations seem to remain small in practice, they might grow
significantly if many non-contiguous UIDs were flagged and/or expunged, and
later synchronized at once.
Furthermore, for MULTIAPPEND-capable servers, the number of messages is
limited to 128 per APPEND command (also subject to a combined literal size of
1MiB like before).
These numbers are currently not configurable. They're intentionally lower
than Dovecot's default maximum command size (64k) in order to avoid a
deadlock situation after sending 8k-long commands under COMPRESS=DEFLATE:
https://dovecot.org/pipermail/dovecot/2019-November/117522.html .
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A n-bytes set covers at least ⌊(n+1)/11⌋ UIDs (UIDs are at most 10 bytes
of size), hence 23 UIDs for 256 bytes long sets.
However we exceed it by another range, so in the worst case (if the the
higher UIDs are sparse) we'll sample ⌊(n+1)/11+1⌋ UIDs:
1000000000,1000000002,1000000004,…,1000000046
This was 6 UIDs for n=64 which is a tad low; this is now raised to 24
UIDs. The actual set size returned by sample() is of max size n+22
bytes (extra "$UID1:$UID2," where $UID1 and $UID2 are both ≥10⁹).
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Also, introduce new option 'logger-prefix' to determine the prefix of
each log line.
Closes: #942725.
|
| | |
|
| |
|
|
|
|
| |
In --debug mode in order to avoid inadvertently receiving credentials in
bug reports. --debug can be set twice to spell out these commands in
full.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is useful for synchronizing multiple remote servers against
different namespaces belonging to the same local IMAP server (using a
different InterIMAP instance for each local namespace ↔ remote
synchronization, for instance with the newy provided systemd template
unit file).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SQLite processes every INTEGER values as a 8-byte signed integer, so we
need to manually do the conversion from/to uint64_t client-side if we
don't want to overflow or receive floats.
https://www.sqlite.org/datatype3.html#storage_classes_and_datatypes
http://jakegoulding.com/blog/2011/02/06/sqlite-64-bit-integers/
We could also do the same trick for local/remote UIDs, UIDVALITY and
UIDNEXT values to slim the database down at the expense of pre/post-
processing. (Values of SQLite's INTEGER class are 1, 2, 3, 4, 6, or 8
bytes signed integers depending on the manitudes, so we could save some
space for values ≥2³¹.) But that seems a little overkill.
|
| |
|
|
|
|
|
|
| |
Setting the 'foreign_keys' PRAGMA during a multi-statement transaction
(when SQLite is not in autocommit mode) is a no-op.
https://www.sqlite.org/pragma.html#pragma_foreign_keys
https://www.sqlite.org/foreignkeys.html#fk_enable
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following recommendation from
https://www.imapwiki.org/ClientImplementation/MailboxList#Hierarchy_separators
Instead, use null characters internally, and substitute them with the
local and remote hierarchy delimiters (which thus no longer need to
match) for IMAP commands. This require a database schema upgrade to
alter the mailbox name column type from TEXT to BLOB. We're using
SQLite's user_version PRAGMA to keep track of schema version; beware
that `.dump` doesn't export its value!
In logging messages, local and remote mailbox names are shown as is
(with their respective delimiters) while database mailbox names are
shown by replacing null characters with the *local* hierarchy delimiter.
Moreover for mailbox names specified on the command line or the
configuration file (with the "list-mailbox" option) the *local*
hierarchy delimiter should be used.
|
| |
|
|
| |
Also, accept comma-separated values for --target.
|
| |
|
|
|
|
| |
This never happens for a single LIST command, but may happen if
mailboxes from different namespaces are being listed. The workaround
here is to run a new interimap instance for each namespace.
|
| |
|
|
|
| |
This is useful for defining names containing control characters (incl.
\0 for unspecified hierarchy delimiter).
|
| |
|
|
| |
Also, write which --target to use in --delete command suggestions.
|
| |
|
|
|
| |
The were returned as escaped quoted specials, like "\\", not as a single
character (backslash in this case).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(instead of rolling our own)
|
| |
|
|
|
| |
Unsollicited LIST responses are currently ignored, hence interimap won't
detect mailbox creation/deletion/subcription/unsubscription.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
