| Commit message (Collapse) | Author | Age | Files |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| | |
This seems to cause timing issues.
|
| | | |
|
| | |
| |
| |
| | |
Closes: #946727.
|
| | |
| |
| |
| | |
In an attempt to fix FTBFS (`make -j4 test` failure) on the buildds.
|
| | | |
|
| | |
| |
| |
| |
| | |
Cf. Policy § 5.6.31 “Rules-Requires-Root”
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-rules-requires-root
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Cf. https://lintian.debian.org/tags/uses-debhelper-compat-file.html .
|
| |\|
| |
| |
| | |
Upstream version 0.5-rc
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Cf. https://www.imapwiki.org/ClientImplementation/MailboxList#Hierarchy_separators
“Some clients cache the hierarchy separator forever. This has problems
if the server configuration is changed (e.g. server software changed).
Try to avoid this problem.”
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
#944812: 5d55a14fa52981ae2a8bb6e65a65bf410c773464
#944859: 0a2558aabfefd6800fe74c24e5aff2b0d47cc5e2
|
| |\| |
|
| | |
| |
| |
| | |
Along with a comparison with OfflineIMAP.
|
| | |
| |
| |
| |
| | |
As of 0.4 --notify is no longer used in the systemd service file, cf.
d19ba0a20d0d7a7ec288c93df329210b31bf3c51.
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
Mention the name of the problematic mailbox. (We may detect the
violation while not in SELECTED state.)
|
| | |
| |
| |
| | |
This uses the ‘header_attributes’ markdown extension.
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| | |
Some of these pages, for instance https://wiki.dovecot.org/UserDatabase ,
are now redirecting to https://doc.dovecot.org/configuration_manual/… .
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
The package is pulled by libdbd-sqlite3-perl (DBD::SQLite).
|
| | |
| |
| |
| |
| | |
The test suite uses c_rehash(1) since a7c364b, and Dovecot's LMTPd since
dac4ab1.
|
| |\| |
|
| | |
| |
| |
| |
| | |
This adds a dependency on Dovecot's LMTPd, which will bind to
to TCP port 10024 on the loopback interface.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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⁹).
|
