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
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
|
<!DOCTYPE html>
<html class="writer-html5" lang="en" >
<head>
<meta charset="utf-8" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Cyrus IMAP Murder (Server Aggregation) — Cyrus IMAP 3.10.2 documentation</title>
<link rel="stylesheet" href="../../../_static/pygments.css" type="text/css" />
<link rel="stylesheet" href="../../../_static/css/theme.css" type="text/css" />
<link rel="stylesheet" href="../../../_static/graphviz.css" type="text/css" />
<link rel="stylesheet" href="../../../_static/cyrus.css" type="text/css" />
<script data-url_root="../../../" id="documentation_options" src="../../../_static/documentation_options.js"></script>
<script src="../../../_static/jquery.js"></script>
<script src="../../../_static/underscore.js"></script>
<script src="../../../_static/_sphinx_javascript_frameworks_compat.js"></script>
<script src="../../../_static/doctools.js"></script>
<script src="../../../_static/sphinx_highlight.js"></script>
<script src="../../../_static/js/theme.js"></script>
<link rel="index" title="Index" href="../../../genindex.html" />
<link rel="search" title="Search" href="../../../search.html" />
<link rel="next" title="Concepts" href="../overview_and_concepts.html" />
<link rel="prev" title="Single-Instance Store" href="single-instance-store.html" />
</head>
<body class="wy-body-for-nav">
<div class="wy-grid-for-nav">
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
<div class="wy-side-scroll">
<div class="wy-side-nav-search" >
<a href="../../../index.html" class="icon icon-home">
Cyrus IMAP
</a>
<div class="version">
3.10.2
</div>
<div role="search">
<form id="rtd-search-form" class="wy-form" action="../../../search.html" method="get">
<input type="text" name="q" placeholder="Search docs" aria-label="Search docs" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div><div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="Navigation menu">
<p class="caption" role="heading"><span class="caption-text">Cyrus IMAP</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../../../download.html">Download</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../../quickstart.html">Quickstart Guide</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="../../../overview.html">Overview</a><ul class="current">
<li class="toctree-l2 current"><a class="reference internal" href="../features.html">Features</a><ul class="current">
<li class="toctree-l3"><a class="reference internal" href="../features.html#security-and-authentication">Security and Authentication</a></li>
<li class="toctree-l3"><a class="reference internal" href="../features.html#mailbox-management">Mailbox Management</a></li>
<li class="toctree-l3"><a class="reference internal" href="../features.html#message-management">Message Management</a></li>
<li class="toctree-l3"><a class="reference internal" href="../features.html#calendar-and-contact-dav-collection-management">Calendar and Contact (DAV) Collection Management</a></li>
<li class="toctree-l3"><a class="reference internal" href="../features.html#storage">Storage</a></li>
<li class="toctree-l3 current"><a class="reference internal" href="../features.html#load-management">Load Management</a><ul class="current">
<li class="toctree-l4 current"><a class="current reference internal" href="#">Cyrus IMAP Murder (Server Aggregation)</a></li>
</ul>
</li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="../overview_and_concepts.html">Concepts</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../../../setup.html">Setup</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../../operations.html">Operations</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../../developers.html">Developers</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../../support.html">Support/Community</a></li>
</ul>
<p class="caption" role="heading"><span class="caption-text">Cyrus SASL</span></p>
<ul>
<li class="toctree-l1"><a class="reference external" href="http://www.cyrusimap.org/sasl">Cyrus SASL</a></li>
</ul>
</div>
</div>
</nav>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap"><nav class="wy-nav-top" aria-label="Mobile navigation menu" >
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="../../../index.html">Cyrus IMAP</a>
</nav>
<div class="wy-nav-content">
<div class="rst-content">
<div role="navigation" aria-label="Page navigation">
<ul class="wy-breadcrumbs">
<li><a href="../../../index.html" class="icon icon-home" aria-label="Home"></a></li>
<li class="breadcrumb-item"><a href="../../../overview.html">Overview</a></li>
<li class="breadcrumb-item"><a href="../features.html">Features</a></li>
<li class="breadcrumb-item active">Cyrus IMAP Murder (Server Aggregation)</li>
<li class="wy-breadcrumbs-aside">
<a href="https://github.com/cyrusimap/cyrus-imapd/blob/master/docsrc/imap/concepts/features/server-aggregation.rst" class="fa fa-github"> Edit on GitHub</a>
</li>
</ul>
<hr/>
</div>
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
<div itemprop="articleBody">
<section id="cyrus-imap-murder-server-aggregation">
<span id="imap-features-murder"></span><h1>Cyrus IMAP Murder (Server Aggregation)<a class="headerlink" href="#cyrus-imap-murder-server-aggregation" title="Permalink to this heading"></a></h1>
<p>A Cyrus IMAP Murder consists of a group of Cyrus IMAP servers
functioning as one large, transparent IMAP cluster.</p>
<p>In a Cyrus IMAP Murder, one or more servers with a <em>frontend</em> role
receive client connections, and proxy connections through to one of the
servers with a <em>backend</em> role -- these host the payload for the cluster
-- on the basis of where the current mailbox selected resides.</p>
<p>This makes access to mailboxes transparent to the client, even though
different mailboxes to which the user has access reside on different
servers.</p>
<p>To illustrate, let John's IMAP client connect to <code class="docutils literal notranslate"><span class="pre">imap.example.org</span></code>:</p>
<div class="graphviz"><img src="../../../_images/graphviz-aac7da08f43846f8664240603228a082601a3d55.png" alt="digraph john {
rankdir = LR;
splines = true;
overlab = prism;
edge [color=gray50, fontname=Calibri, fontsize=11];
node [shape=record, fontname=Calibri, fontsize=11];
"Desktop Client" -> "imap.example.org" [label="Client Connection"];
}" class="graphviz" /></div>
<p>John's mailbox may not reside on the node that the client connects to,
though, and instead be located on a <a class="reference internal" href="../../../glossary.html#term-backend"><span class="xref std std-term">backend</span></a> node -- as is
typical for larger deployments.</p>
<p>The client connection is therefore to be proxied to the appropriate
<a class="reference internal" href="../../../glossary.html#term-backend"><span class="xref std std-term">backend</span></a> node.</p>
<div class="graphviz"><img src="../../../_images/graphviz-26c71bf0933a3f07db0adb06736a204d6ba2e7e2.png" alt="digraph john {
rankdir = LR;
splines = true;
overlab = prism;
edge [color=gray50, fontname=Calibri, fontsize=11];
node [shape=record, fontname=Calibri, fontsize=11];
"Desktop Client" -> "imap.example.org" [label="Client Connection"];
"imap.example.org" -> "backend1.example.org" [label="Proxied Connection"];
}" class="graphviz" /></div>
<p>It is not at all uncommon to (reverse) proxy client connections like
this (a task that <code class="docutils literal notranslate"><span class="pre">imap.example.org</span></code> takes on in this example).</p>
<p>In the case of webservers for example, reverse proxying is a very
common practice:</p>
<div class="graphviz"><img src="../../../_images/graphviz-ba6d524e5f7adb073a02dc4d7f0d53971018d133.png" alt="digraph www {
rankdir = LR;
splines = true;
overlab = prism;
edge [color=gray50, fontname=Calibri, fontsize=11];
node [shape=record, fontname=Calibri, fontsize=11];
"Desktop Browser" -> "http://www.example.org/" [label="Client Connection"];
"http://www.example.org/" -> "assets1.example.org" [label="Static Content"];
"http://www.example.org/" -> "www1.example.org" [label="Dynamic Content"];
}" class="graphviz" /></div>
<p>In the case of reverse web proxies, the proxy looks at (for example)
the request URI, and based on a set of rules, forwards (proxies) the
request on to the appropriate (internal) node. This architecture allows
application servers (www[0-9]+.example.org) to be scaled up and down by
application processing needs <em>separately</em> from the few web servers
typically needed to serve static files such as images and scripts (that
require no server-side processing).</p>
<p>In the case of IMAP, a commonly used IMAP proxy is NGINX. However,
NGINX can proxy John's connection to only one backend at a time. NGINX
allows an external script to respond with a target backend address
based on the authentication of the user <a class="footnote-reference brackets" href="#id6" id="id1" role="doc-noteref"><span class="fn-bracket">[</span>1<span class="fn-bracket">]</span></a>.</p>
<p>As such, NGINX is a socket proxy, and not a fully-featured
application proxy:</p>
<div class="graphviz"><img src="../../../_images/graphviz-47bed0896a2bb672d4f54b18722750dbf3b11f90.png" alt="digraph joe {
rankdir = LR;
splines = true;
overlab = prism;
edge [color=gray50, fontname=Calibri, fontsize=11];
node [shape=record, fontname=Calibri, fontsize=11];
"imap.example.org" [label="imap.example.org\n(NGINX)"];
"backend1.example.org" [label="backend1.example.org\n(user/john)"];
"backend2.example.org" [label="backend2.example.org\n(user/jane)"];
"Desktop Client" -> "imap.example.org" [label="Client Connection"];
"imap.example.org" -> "backend1.example.org" [label="Proxied Connection",color="green"];
"imap.example.org" -> "backend2.example.org" [label="Not Available",color="red"];
}" class="graphviz" /></div>
<p>This means that John could not open a mailbox that does not reside on
the same backend node his client connection is proxied to, and John nor
Jane can share their mailboxes with one another <a class="footnote-reference brackets" href="#id7" id="id2" role="doc-noteref"><span class="fn-bracket">[</span>2<span class="fn-bracket">]</span></a>.</p>
<p>For the proxy to be fully-featured, the proxy would need to catch all
IMAP commands that John's client issues <a class="footnote-reference brackets" href="#id8" id="id3" role="doc-noteref"><span class="fn-bracket">[</span>3<span class="fn-bracket">]</span></a>, and determine what is the
most appropriate backend to serve the request -- not unlike the
aforementioned web proxies.</p>
<p>So, when John's client issues a <code class="docutils literal notranslate"><span class="pre">SELECT</span> <span class="pre">INBOX</span></code>, the connection is to
be proxied to <code class="docutils literal notranslate"><span class="pre">backend1.example.org</span></code>, but when John's client is to
issue a <code class="docutils literal notranslate"><span class="pre">SELECT</span> <span class="pre">"Other</span> <span class="pre">Users/jane"</span></code>, the connection is to be proxied
to <code class="docutils literal notranslate"><span class="pre">backend2.example.org</span></code>.</p>
<p><strong>This</strong> is where the Cyrus IMAP Murder functionality kicks in:</p>
<ul>
<li><p>Mailbox location data is maintained through a central MUPDATE
server.</p>
<p>Each backend submits its list of local mailboxes when it starts up,
and maintains new, renamed and deleted mail folders, and Access
Control List (ACL) changes while running.</p>
</li>
<li><p>The MUPDATE server replicates its aggregated database from across
all backends to all nodes with a <a class="reference internal" href="../../../glossary.html#term-frontend"><span class="xref std std-term">frontend</span></a> role.</p></li>
<li><p>Nodes with a <a class="reference internal" href="../../../glossary.html#term-frontend"><span class="xref std std-term">frontend</span></a> role capture connections on the
protocol level and decide where the connection needs to be proxied
to</p></li>
<li><p>Nodes with a <a class="reference internal" href="../../../glossary.html#term-frontend"><span class="xref std std-term">frontend</span></a> role also arbiter between backends
when a message is moved from John's <code class="docutils literal notranslate"><span class="pre">INBOX</span></code> to Jane's <code class="docutils literal notranslate"><span class="pre">INBOX</span></code> or
vice-versa.</p></li>
</ul>
<section id="use-cases-for-the-cyrus-imap-murder">
<h2>Use-Cases for the Cyrus IMAP Murder<a class="headerlink" href="#use-cases-for-the-cyrus-imap-murder" title="Permalink to this heading"></a></h2>
<ul class="simple">
<li><p>Transparent access to content distributed over multiple (backend)
nodes,</p></li>
<li><p>Sharing content distributed over multiple nodes (calendars, address
books, mail folders),</p></li>
<li><p>High-availability and/or load-balanced frontends,</p></li>
<li><p>Transport Layer Security termination, so frontends do connection
encryption and backends spend CPU cycles on mailboxes.</p></li>
<li><p>Access Control enforcement at the perimeter</p></li>
</ul>
<p>Administrators of larger infrastructures will be aware of the fact that
vertical scaling a single node only stretches so far.</p>
<p>When mail environments are to serve many thousands of users' mailboxes
(or more), multiple nodes are put to purpose, effectively scaling
horizontally rather than vertically.</p>
<p>In such environments it is likely that multiple backends are used to
store mailboxes, and depending on the requirements for the environment,
users with mailboxes distributed over these backends may be required to
share content with one another -- shared folders.</p>
<p>Should John be required to be able to share one or more of his mailboxes
with Jane, or vice-versa, one could attempt to ensure both users'
mailboxes reside on the same backend node (read: both users' client
connections are proxied to the same backend node).</p>
<p>In larger environments however (again), users that are required to be
able to share content often results in groups of several dozens,
hundreds or even thousands, making it very, very hard to maintain.</p>
</section>
<section id="cyrus-imap-murder-topologies">
<h2>Cyrus IMAP Murder Topologies<a class="headerlink" href="#cyrus-imap-murder-topologies" title="Permalink to this heading"></a></h2>
<p>A Cyrus IMAP Murder topology serves the need to <strong>aggregate</strong> the
mailboxes hosted by more than one Cyrus IMAP server with the <em>backend</em>
role.</p>
<p>Cyrus IMAP can do so in either one of three topologies:</p>
<ol class="arabic">
<li><p><a class="reference internal" href="#imap-features-murder-discrete"><span class="std std-ref">Discrete Murder</span></a></p>
<p>The frontend and backend servers are separate.</p>
</li>
<li><p><a class="reference internal" href="#imap-features-murder-replicated"><span class="std std-ref">Replicated Murder</span></a></p>
<p>All backends have access to all mailboxes.</p>
</li>
<li><p><a class="reference internal" href="#imap-features-murder-unified"><span class="std std-ref">Unified Murder</span></a></p>
<p>There's no distinction between backends and frontends, and all
backends perform frontend roles, but not all frontends are
automatically also backends.</p>
</li>
</ol>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>In the context of a Cyrus IMAP Murder, the terms <em>frontend</em> and
<em>backend</em> are server roles, and while these roles may be performed
by separate servers, such as in a
<a class="reference internal" href="#imap-features-murder-discrete"><span class="std std-ref">Discrete Murder</span></a>, but they need not be, such as
in a <a class="reference internal" href="#imap-features-murder-unified"><span class="std std-ref">Unified Murder</span></a>.</p>
</div>
<p>All Cyrus IMAP Murder topologies exchange information about where
mailboxes reside through the MUPDATE protocol (<span class="target" id="index-0"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc3656.html"><strong>RFC 3656</strong></a>).</p>
<section id="discrete-murder">
<span id="imap-features-murder-discrete"></span><h3>Discrete Murder<a class="headerlink" href="#discrete-murder" title="Permalink to this heading"></a></h3>
<p>The simplest discrete murder topology puts each role on one or more
separate systems;</p>
<ul class="simple">
<li><p>the MUPDATE master (m),</p></li>
<li><p>one or more frontend servers (f),</p></li>
<li><p>one or more backend servers (b).</p></li>
</ul>
<p>Each of the systems communicates with one another via the following
connection model:</p>
<figure class="align-default" id="id9">
<div class="graphviz"><img src="../../../_images/graphviz-26540d7e5534673feba1dcb17d4339c46a5bb59d.png" alt="digraph {
rankdir=LR;
nodesep=2;
splines = true;
overlab = prism;
edge [color=gray50, fontname=Calibri, fontsize=11];
node [shape=record, fontname=Calibri, fontsize=11];
"m" -> "f+" [dir=back];
"m" -> "b+" [dir=back];
"f+" -> "b+";
}" class="graphviz" /></div>
<figcaption>
<p><span class="caption-text">Connection model for a Discrete Murder topology</span><a class="headerlink" href="#id9" title="Permalink to this image"></a></p>
</figcaption>
</figure>
<ol class="arabic">
<li><p>A frontend (f) connects to the mupdate (m) master server and
receives updates from the mupdate master server.</p>
<p>The frontend continues to receive updates about deleted, renamed or
created mailboxes for as long as the connection from the frontend to
the mupdate master server exists.</p>
<p>The frontend reconnects if the connection is interrupted.</p>
</li>
<li><p>A backend connects to the mupdate master server and pushes updates
to the mupdate server.</p>
<p>A backend reconnects to the mupdate master server as needed.</p>
</li>
</ol>
<section id="murder-backend-startup-process">
<h4>Murder Backend Startup Process<a class="headerlink" href="#murder-backend-startup-process" title="Permalink to this heading"></a></h4>
<figure class="align-default" id="id10">
<div class="graphviz"><img src="../../../_images/graphviz-56b6da7ce3446b1cfe25825c038101f97149e331.png" alt="digraph {
rankdir=LR;
nodesep=2;
splines = true;
overlab = prism;
edge [color=gray50, fontname=Calibri, fontsize=11];
node [shape=record, fontname=Calibri, fontsize=11];
"m" -> "f+" [color=white];
"m" -> "b+" [color=red,dir=back,label="(1)"];
"f+" -> "b+" [color=white];
}" class="graphviz" /></div>
<figcaption>
<p><span class="caption-text">Communication during Backend startup (1)</span><a class="headerlink" href="#id10" title="Permalink to this image"></a></p>
</figcaption>
</figure>
<figure class="align-default" id="id11">
<div class="graphviz"><img src="../../../_images/graphviz-576b968661b0cdf14d09ee6a30d7edbf8fb5f3f0.png" alt="digraph {
rankdir=LR;
nodesep=2;
splines = true;
overlab = prism;
edge [color=gray50, fontname=Calibri, fontsize=11];
node [shape=record, fontname=Calibri, fontsize=11];
"m" -> "f+" [color=red,label="(2)"];
"m" -> "b+" [color=green,dir=back,label="(1)"];
"f+" -> "b+" [color=white];
}" class="graphviz" /></div>
<figcaption>
<p><span class="caption-text">Communication during Backend startup (2)</span><a class="headerlink" href="#id11" title="Permalink to this image"></a></p>
</figcaption>
</figure>
<ol class="arabic">
<li><p>The backend (b) pushes its list of mailboxes to the mupdate master
(m) using <code class="docutils literal notranslate"><span class="pre">ctl_mboxlist</span> <span class="pre">-m</span></code>.</p>
<p>The list of local mailboxes on the backend is routinely compared
with the current state of the rest of the murder topology;</p>
<ul>
<li><p>Mailboxes that exist locally but are not in MUPDATE are pushed
to the mupdate master server.</p></li>
<li><p>Mailboxes that exist locally but for which the mupdate master
server has an entry for the mailbox to live on a different
server are deleted locally.</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>Additional options to
<a class="reference internal" href="../../reference/manpages/systemcommands/ctl_mboxlist.html#imap-reference-manpages-systemcommands-ctl-mboxlist"><span class="std std-ref">ctl_mboxlist</span></a> allow the deletion
to be prevented.</p>
</div>
</li>
<li><p>Mailboxes that do not exist locally but exists in MUPDATE as
living locally are removed from the mupdate master server.</p></li>
</ul>
</li>
<li><p>The mupdate (m) master server pushes updates to the existing list of
mailboxes to the frontend (f) server.</p></li>
</ol>
<div class="graphviz"><img src="../../../_images/graphviz-eb1b90869007c5278c2a2e65037cb2e36874e3de.png" alt="digraph {
rankdir=LR;
nodesep=2;
splines = true;
overlab = prism;
edge [color=gray50, fontname=Calibri, fontsize=11];
node [shape=record, fontname=Calibri, fontsize=11];
"m" -> "f+" [dir=both];
"m" -> "b+" [dir=both];
"f+" -> "b+" [dir=both];
}" class="graphviz" /></div>
</section>
</section>
<section id="replicated-murder">
<span id="imap-features-murder-replicated"></span><h3>Replicated Murder<a class="headerlink" href="#replicated-murder" title="Permalink to this heading"></a></h3>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>This section needs to be written. Would you like to <a class="reference internal" href="../../developer/documentation.html#contribute-docs"><span class="std std-ref">help out</span></a>?</p>
</div>
</section>
<section id="unified-murder">
<span id="imap-features-murder-unified"></span><h3>Unified Murder<a class="headerlink" href="#unified-murder" title="Permalink to this heading"></a></h3>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>This section needs to be written. Would you like to <a class="reference internal" href="../../developer/documentation.html#contribute-docs"><span class="std std-ref">help out</span></a>?</p>
</div>
<p>Back to <a class="reference internal" href="../features.html#imap-features"><span class="std std-ref">Features</span></a></p>
<p class="rubric">Footnotes</p>
<aside class="footnote-list brackets">
<aside class="footnote brackets" id="id6" role="note">
<span class="label"><span class="fn-bracket">[</span><a role="doc-backlink" href="#id1">1</a><span class="fn-bracket">]</span></span>
<p>See also: <a class="reference internal" href="../../reference/admin/nginx-proxy.html#imap-howto-nginx-proxy"><span class="std std-ref">HOWTO: Using an NGINX IMAP Proxy</span></a>.</p>
</aside>
<aside class="footnote brackets" id="id7" role="note">
<span class="label"><span class="fn-bracket">[</span><a role="doc-backlink" href="#id2">2</a><span class="fn-bracket">]</span></span>
<p>More literally speaking, John and Jane can <em>share</em>, just neither can
make use of the privilege.</p>
</aside>
<aside class="footnote brackets" id="id8" role="note">
<span class="label"><span class="fn-bracket">[</span><a role="doc-backlink" href="#id3">3</a><span class="fn-bracket">]</span></span>
<p>Including but not limited to <code class="docutils literal notranslate"><span class="pre">SELECT</span></code>, <code class="docutils literal notranslate"><span class="pre">UID</span> <span class="pre">MOVE</span></code>, <code class="docutils literal notranslate"><span class="pre">RENAME</span></code>,
etc.</p>
</aside>
</aside>
</section>
</section>
</section>
</div>
</div>
<footer><div class="rst-footer-buttons" role="navigation" aria-label="Footer">
<a href="single-instance-store.html" class="btn btn-neutral float-left" title="Single-Instance Store" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left" aria-hidden="true"></span> Previous</a>
<a href="../overview_and_concepts.html" class="btn btn-neutral float-right" title="Concepts" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right" aria-hidden="true"></span></a>
</div>
<hr/>
<div role="contentinfo">
<p>© Copyright 1993–2025, The Cyrus Team.</p>
</div>
Built with <a href="https://www.sphinx-doc.org/">Sphinx</a> using a
<a href="https://github.com/readthedocs/sphinx_rtd_theme">theme</a>
provided by <a href="https://readthedocs.org">Read the Docs</a>.
</footer>
</div>
</div>
</section>
</div>
<script>
jQuery(function () {
SphinxRtdTheme.Navigation.enable(true);
});
</script>
</body>
</html>
|
