1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
InterIMAP is a fast bidirectional synchronization program for QRESYNC-capable
IMAP4rev1 servers. PullIMAP retrieves messages a remote IMAP mailbox and
deliver them to an SMTP session. Visit https://guilhem.org/interimap for more
information.
______________________________________________________________________________
Compared to IMAP-to-Maildir synchronization solutions like OfflineIMAP, adding
an IMAP server between the Maildir storage and the MUA saves loads of
readdir(2) system calls and other File System quirks; moreover the abstraction
layer offered by the IMAP server makes the MUA and synchronization program
agnostic to the storage backend (Maildir, mbox, dbox,...) in use.
IMAP synchronization of a mailbox is usually two-folds: 1/ detect and
propagate changes (flag updates and message deletions) to existing messages,
then 2/ copy the new messages. The naive way to perform the first step is to
issue a FETCH command to list all messages in the mailbox along with their
flags and UIDs, causing heavy network usage. Instead, InterIMAP takes
advantage of the QRESYNC extension from [RFC7162] to perform stateful
synchronization: querying changes since the last synchronization only gives a
phenomenal performance boost and drastically reduces the network traffic.
For convenience reasons servers must also support LIST-EXTENDED [RFC5258],
LIST-STATUS [RFC5819] and UIDPLUS [RFC4315]. Other supported extensions are:
* LITERAL+ [RFC2088] non-synchronizing literals (recommended);
* MULTIAPPEND [RFC3502] (recommended);
* COMPRESS=DEFLATE [RFC4978] (recommended);
* SASL-IR [RFC4959] SASL Initial Client Response; and
* UNSELECT [RFC3691].
______________________________________________________________________________
IMAP traffic is mostly text (beside message bodies perhaps) hence compresses
pretty well: enabling compression can save a great amount of network
resources.
However establishing an SSL/TLS connection (type=imaps, or type=imap and
STARTTLS=YES) yields a small overhead due to the SSL/TLS handshake.
On the other hand if SSH access is allowed on the remote server, one can
tunnel the IMAP traffic through SSH and use OpenSSH's ControlPersist feature
to save most of the cryptographic overhead (at the expense of a local 'ssh'
process and a remote 'imap' process). Moreover if the IMAP user is a valid
UNIX user it is possible to use pre-authentication on the remote server as
well, which saves the extra round trip caused by the AUTHENTICATE command.
For instance the following configuration snippet saves bandwidth and brings a
significant speed gain compared to type=imaps.
local: $XDG_CONFIG_HOME/interimap/config:
[remote]
type = tunnel
command = /usr/bin/ssh user@imap.example.net
local: ~/.ssh/config:
Host imap.example.net
IdentityFile ~/.ssh/id-interimap
IdentitiesOnly yes
ControlPath ${XDG_RUNTIME_DIR}/ssh-imap-%C
ControlMaster auto
ControlPersist 10m
StrictHostKeyChecking yes
ServerAliveCountMax 3
ServerAliveInterval 10s
RequestTTY no
Compression yes
remote: ~user/.ssh/authorized_keys:
restrict,command="/usr/bin/doveadm exec imap" ssh-[…] id-interimap
However for long-lived connections (using the --watch command-line option),
the TLS overhead becomes negligible hence the advantage offered by the OpenSSH
ControlPersist feature is not obvious. Furthermore if the remote server
supports the IMAP COMPRESS extension [RFC4978], adding compress=DEFLATE to the
configuration can also greatly reduce bandwidth usage with regular INET
sockets (type=imaps or type=imap).
______________________________________________________________________________
InterIMAP is Copyright© 2015-2020 Guilhem Moulin ⟨guilhem@fripost.org⟩, and
licensed for use under the GNU General Public License version 3 or later. See
‘COPYING’ for specific terms and distribution information.
|
