| Commit message (Collapse) | Author | Age | Files |
|---|
| |
|
|
| |
For background see https://gitlab.com/muttmua/mutt/-/issues/248 .
|
| |
|
|
| |
CAPABILITY listing.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Honor BUILD_DOCDIR and DESTDIR variables.
Also, remove the `use lib` statement from our executables.
|
| |
|
|
| |
comparison tests.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Some LMTP servers, Dovecot's in particular, trims leading dots that are
not doubled (e.g. “.foo” would become “foo”). In RFC 5322 sec. 4.5.2
explicitly says that when an RFC 5322 line starts with a '.', the
character needs to be doubled.
|
| | |
|
| |
|
|
|
|
| |
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 .
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The UNCHANGEDSINCE test from the CONDSTORE extension was incorrectly
placed after the flag list in UID STORE commands. In practice this
meant the server didn't add the MODIFIED code when needed.
The server won't send an untagged FETCH command (and won't increase the
message's MODSEQ) if no change was made to the flag list. A panic() was
incorrectly triggered in that case.
When the flag list was set (by another client) to a superset of the UID
STORE command currently processed, the extra flags were not synchronized.
Cf. RFC 7162 sec. 3.1.3 ex. 10.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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⁹).
|
| |
|
|
|
| |
SSL connections are accepted on TCP port 10993. Also, fix STARTTLS
directive, broken since fba1c36…
|
| | |
|
| |
|
|
|
|
|
| |
Also, introduce new option 'logger-prefix' to determine the prefix of
each log line.
Closes: #942725.
|
| |
|
|
|
| |
Cf. Compress::Raw::Zlib's documentation. Z_STREAM_END denotes a
successful state.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously getpwuid() was called to determine the user's home directory,
while the XDG specification explicitely mentions $HOME.
Conveniently our docs always mentioned ~/, which on POSIX-compliant
systems expands to the value of the variable HOME (and the result is
unspecified when the variable is unset). Cf. Shell and Utilities volume
of POSIX.1-2017, sec. 2.6.1:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01
|
| |
|
|
|
|
|
| |
That is, without leading reference, and where the hierarchy delimiter is
replaced with null characters.
/!\ This changes breaks backward compatibility!
|
| |
|
|
|
| |
In particular, move manpages to the 'doc' directory, and generate HTML
documentation with `make html`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
semantics.
It is passed to `/bin/sh -c` when it contains shell metacharacters; and
split into words and passed to execvp(3) otherwise.
https://perldoc.perl.org/functions/exec.html
(Since c8fb54897f046a5a3fb4c1d45dc21fd8bcd882e3 the value no longer
needs to stard with a forward slash.)
|
| | |
|
| |
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
Rather than two pipe(2). Also, use SOCK_CLOEXEC to save a fcntl() call
when setting the close-on-exec flag on the socket (even though Perl will
likely call fcntl() anyway).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not 1*ATOM-CHAR / string. Also accept LIST responses mailbox names
containing '%', '*', or ']'.
From RFC 3501:
astring = 1*ASTRING-CHAR / string
ASTRING-CHAR = ATOM-CHAR / resp-specials
list = "LIST" SP mailbox SP list-mailbox
list-mailbox = 1*list-char / string
list-char = ATOM-CHAR / list-wildcards / resp-specials
list-wildcards = "%" / "*"
resp-specials = "]"
|
| |
|
|
|
| |
Compression asside, this saves 3 bytes and one round-trip on servers not
supporting non-synchronizing literals, and 4 bytes otherwise.
|
| |
|
|
|
| |
The were returned as escaped quoted specials, like "\\", not as a single
character (backslash in this case).
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Also, change "SSL_protocols" default value from "!SSLv2 !SSLv3" to
"!SSLv2 !SSLv3 !TLSv1 !TLSv1.1". I.e., only enable TLSv1.2 and later,
which is the default in Debian's OpenSSL as of 1.1.1-2, cf.
https://tracker.debian.org/news/998835/accepted-openssl-111-2-source-into-unstable/ .
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
