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
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Internet Engineering Task Force (IETF) B. Gondwana, Ed.
Request for Comments: 8474 FastMail
Updates: <a href="./rfc3501">3501</a> September 2018
Category: Standards Track
ISSN: 2070-1721
<span class="h1">IMAP Extension for Object Identifiers</span>
Abstract
This document updates <a href="./rfc3501">RFC 3501</a> (IMAP4rev1) with persistent
identifiers on mailboxes and messages to allow clients to more
efficiently reuse cached data when resources have changed location on
the server.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8474">https://www.rfc-editor.org/info/rfc8474</a>.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Gondwana Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Conventions Used in This Document . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. CAPABILITY Identification . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. MAILBOXID Object Identifier . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4.1">4.1</a>. New Response Code for CREATE . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. New OK Untagged Response for SELECT and EXAMINE . . . . . <a href="#page-4">4</a>
<a href="#section-4.3">4.3</a>. New Attribute for STATUS . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. EMAILID Object Identifier and THREADID Correlator . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. EMAILID Identifier for Identical Messages . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. THREADID Identifier for Related Messages . . . . . . . . <a href="#page-6">6</a>
5.3. New Message Data Items in FETCH and UID FETCH Commands . 7
<a href="#section-6">6</a>. New Filters on SEARCH Command . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-7">7</a>. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8">8</a>. Implementation Considerations . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8.1">8.1</a>. Assigning Object Identifiers . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8.2">8.2</a>. Interaction with Special Cases . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8.3">8.3</a>. Client Usage . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8.4">8.4</a>. Advice to Client Implementers . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-9">9</a>. Future Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10">10</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-11">11</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-12">12</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-12.1">12.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-12.2">12.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A">Appendix A</a>. Ideas for Implementing Object Identifiers . . . . . <a href="#page-15">15</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
IMAP stores are often used by many clients. Each client may cache
data from the server so that it doesn't need to redownload
information. [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>] states that a mailbox can be uniquely
referenced by its name and UIDVALIDITY, and a message within that
mailbox can be uniquely referenced by its mailbox (name +
UIDVALIDITY) and unique identifier (UID). The triple of mailbox
name, UIDVALIDITY, and UID is guaranteed to be immutable.
[<a id="ref-RFC4315">RFC4315</a>] defines a COPYUID response that allows a client that copies
messages to know the mapping between the UIDs in the source and
destination mailboxes and, hence, update its local cache.
If a mailbox is successfully renamed by a client, that client will
know that the same messages exist in the destination mailbox name as
previously existed in the source mailbox name.
<span class="grey">Gondwana Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
The result is that the client that copies (or moves [<a href="./rfc6851" title=""Internet Message Access Protocol (IMAP) - MOVE Extension"">RFC6851</a>])
messages or renames a mailbox can update its local cache, but any
other client connected to the same store cannot know with certainty
that the messages are identical, so it will redownload everything.
This extension adds new properties to a message (EMAILID) and mailbox
(MAILBOXID). These properties allow a client to quickly identify
messages or mailboxes that have been renamed by another client.
This extension also adds an optional thread identifier (THREADID) to
messages, which can be used by the server to indicate messages that
it has identified to be related. A server that does not implement
threading will return NIL to all requests for THREADID.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
In examples, "C:" indicates lines sent by a client that is connected
to a server. "S:" indicates lines sent by the server to the client.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. CAPABILITY Identification</span>
IMAP servers that support this extension MUST include "OBJECTID" in
the response list to the CAPABILITY command.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. MAILBOXID Object Identifier</span>
The MAILBOXID is a server-allocated unique identifier for each
mailbox.
The server MUST return the same MAILBOXID for a mailbox with the same
name and UIDVALIDITY.
The server MUST NOT report the same MAILBOXID for two mailboxes at
the same time.
The server MUST NOT reuse the same MAILBOXID for a mailbox that does
not obey all the invariants that [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>] defines for a mailbox that
does not change name or UIDVALIDITY.
<span class="grey">Gondwana Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
The server MUST keep the same MAILBOXID for the source and
destination when renaming a mailbox in a way that keeps the same
messages (but see [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>] for the special case regarding the
renaming of INBOX, which is treated as creating a new mailbox and
moving the messages).
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. New Response Code for CREATE</span>
This document extends the CREATE command to have the response code
MAILBOXID on successful mailbox creation.
A server advertising the OBJECTID capability MUST include the
MAILBOXID response code in the tagged OK response to all successful
CREATE commands.
Syntax: "MAILBOXID" SP "(" objectid ")"
Response code in tagged OK response for successful CREATE command.
Example:
C: 3 create foo
S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Completed
C: 4 create bar
S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)] Completed
C: 5 create foo
S: 5 NO Mailbox already exists
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. New OK Untagged Response for SELECT and EXAMINE</span>
This document adds a new untagged response code to the SELECT and
EXAMINE commands.
A server advertising the OBJECTID capability MUST return an untagged
OK response with the MAILBOXID response code on all successful SELECT
and EXAMINE commands.
Syntax: "OK" SP "[" "MAILBOXID" SP "(" objectid ")" "]" SP text
Untagged OK response to SELECT or EXAMINE.
Example:
C: 27 select "foo"
[...]
S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Ok
[...]
S: 27 OK [READ-WRITE] Completed
<span class="grey">Gondwana Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. New Attribute for STATUS</span>
This document adds the MAILBOXID attribute to the STATUS command
using the extended syntax defined in [<a href="./rfc4466" title=""Collected Extensions to IMAP4 ABNF"">RFC4466</a>].
A server that advertises the OBJECTID capability MUST support the
MAILBOXID status attribute.
Syntax: "MAILBOXID"
The attribute in the STATUS command.
Syntax: "MAILBOXID" SP "(" objectid ")"
The response item in the STATUS response contains the ObjectID
assigned by the server for this mailbox.
Example:
C: 6 status foo (mailboxid)
S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 6 OK Completed
C: 7 status bar (mailboxid)
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: 7 OK Completed
C: 8 rename foo renamed
S: * OK rename foo renamed
S: 8 OK Completed
C: 9 status renamed (mailboxid)
S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 9 OK Completed
C: 10 status bar (mailboxid)
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: 10 OK Completed
When the LIST-STATUS IMAP capability defined in [<a href="./rfc5819" title=""IMAP4 Extension for Returning STATUS Information in Extended LIST"">RFC5819</a>] is also
available, the STATUS command can be combined with the LIST command.
Example:
C: 11 list "" "*" return (status (mailboxid))
S: * LIST (\HasNoChildren) "." INBOX
S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf))
S: * LIST (\HasNoChildren) "." bar
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: * LIST (\HasNoChildren) "." renamed
S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 11 OK Completed (0.001 secs 3 calls)
<span class="grey">Gondwana Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. EMAILID Object Identifier and THREADID Correlator</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. EMAILID Identifier for Identical Messages</span>
The EMAILID data item is an ObjectID that uniquely identifies the
content of a single message. Anything that must remain immutable on
a {name, uidvalidity, uid} triple must also be the same between
messages with the same EMAILID.
The server MUST return the same EMAILID for the same triple; hence,
EMAILID is immutable.
The server MUST return the same EMAILID as the source message for the
matching destination message in the COPYUID pairing after a COPY or
MOVE command [<a href="./rfc6851" title=""Internet Message Access Protocol (IMAP) - MOVE Extension"">RFC6851</a>].
The server MAY assign the same EMAILID as an existing message upon
APPEND (e.g., if it detects that the new message has exactly
identical content to that of an existing message).
NOTE: EMAILID only identifies the immutable content of the message.
In particular, it is possible for different messages with the same
EMAILID to have different keywords. This document does not specify a
way to STORE by EMAILID.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. THREADID Identifier for Related Messages</span>
The THREADID data item is an ObjectID that uniquely identifies a set
of messages that the server believes should be grouped together when
presented.
THREADID calculation is generally based on some combination of
References, In-Reply-To, and Subject, but the exact logic is left up
to the server implementation. [<a href="./rfc5256" title=""Internet Message Access Protocol - SORT and THREAD Extensions"">RFC5256</a>] describes some algorithms
that could be used; however, this specification does not mandate any
particular strategy.
The server MUST return the same THREADID for all messages with the
same EMAILID.
The server SHOULD return the same THREADID for related messages, even
if they are in different mailboxes; for example, messages that would
appear in the same thread if they were in the same mailbox SHOULD
have the same THREADID, even if they are in different mailboxes.
The server MUST NOT change the THREADID of a message once reported.
<span class="grey">Gondwana Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
THREADID is OPTIONAL; if the server doesn't support THREADID or is
unable to calculate relationships between messages, it MUST return
NIL to all FETCH responses for the THREADID data item, and a SEARCH
for THREADID MUST NOT match any messages.
The server MUST NOT use the same ObjectID value for both EMAILIDs and
THREADIDs. If they are stored with the same value internally, the
server can generate prefixed values (as shown in the examples below
with M and T prefixes) to avoid clashes.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. New Message Data Items in FETCH and UID FETCH Commands</span>
This document defines two FETCH items:
Syntax: "EMAILID"
The EMAILID message data item causes the server to return EMAILID
FETCH response data items.
Syntax: "THREADID"
The THREADID message data item causes the server to return THREADID
FETCH response data items.
This document defines the following responses:
Syntax: "EMAILID" SP "(" objectid ")"
The EMAILID response data item contains the server-assigned ObjectID
for each message.
Syntax: "THREADID" SP "(" objectid ")"
The THREADID response data item contains the server-assigned ObjectID
for the set of related messages to which this message belongs.
Syntax: "THREADID" SP nil
The NIL value is returned for the THREADID response data item when
the server mailbox does not support THREADID calculation.
<span class="grey">Gondwana Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
Example:
C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733}
[...]
Subject: Message A
Message-ID: <fake.1521475657.54797@example.com>
[...]
S: 5 OK [APPENDUID 1521475658 1] Completed
C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793}
[...]
Subject: Re: Message A
Message-ID: <fake.1521475657.21213@example.org>
References: <fake.1521475657.54797@example.com>
[...]
S: 11 OK [APPENDUID 1521475658 2] Completed
C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736}
[...]
Subject: Message C
Message-ID: <fake.1521475657.60280@example.com>
[...]
S: 17 OK [APPENDUID 1521475658 3] Completed
C: 22 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9))
S: * 2 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9))
S: * 3 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5))
S: 22 OK Completed (0.000 sec)
C: 23 move 2 foo
S: * OK [COPYUID 1521475659 2 1] Completed
S: * 2 EXPUNGE
S: 23 OK Completed
C: 24 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9))
S: * 2 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5))
S: 24 OK Completed (0.000 sec)
C: 25 select "foo"
C: 25 select "foo"
[...]
S: 25 OK [READ-WRITE] Completed
C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9))
S: 26 OK Completed (0.000 sec)
<span class="grey">Gondwana Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
Example: (no THREADID support)
C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M00000001) THREADID NIL)
S: * 2 FETCH (EMAILID (M00000002) THREADID NIL)
S: 26 OK Completed (0.000 sec)
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. New Filters on SEARCH Command</span>
This document defines the filters EMAILID and THREADID on the SEARCH
command.
Syntax: "EMAILID" SP objectid
Messages whose EMAILID is exactly the specified ObjectID.
Syntax: "THREADID" SP objectid
Messages whose THREADID is exactly the specified ObjectID.
Example: (as if run before the MOVE shown above when the mailbox had
three messages)
C: 27 search emailid M6d99ac3275bb4e
S: * SEARCH 1
S: 27 OK Completed (1 msgs in 0.000 secs)
C: 28 search threadid T64b478a75b7ea9
S: * SEARCH 1 2
S: 28 OK Completed (2 msgs in 0.000 secs)
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Formal Syntax</span>
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] notation. Elements not defined here can be
found in the formal syntax of the ABNF [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>], IMAP [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>], and
IMAP ABNF extensions [<a href="./rfc4466" title=""Collected Extensions to IMAP4 ABNF"">RFC4466</a>] specifications.
Except as noted otherwise, all alphabetic characters are case
insensitive. The use of uppercase or lowercase characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
Please note specifically that ObjectID values are case sensitive.
<span class="grey">Gondwana Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
capability =/ "OBJECTID"
fetch-att =/ "EMAILID" / "THREADID"
fetch-emailid-resp = "EMAILID" SP "(" objectid ")"
; follows tagged-ext production from [<a href="./rfc4466" title=""Collected Extensions to IMAP4 ABNF"">RFC4466</a>]
fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil )
; follows tagged-ext production from [<a href="./rfc4466" title=""Collected Extensions to IMAP4 ABNF"">RFC4466</a>]
msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp
objectid = 1*255(ALPHA / DIGIT / "_" / "-")
; characters in object identifiers are case
; significant
resp-text-code =/ "MAILBOXID" SP "(" objectid ")"
; incorporated before the expansion rule of
; atom [SP 1*<any TEXT-CHAR except "]">]
; that appears in [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>]
search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid
status-att =/ "MAILBOXID"
status-att-val =/ "MAILBOXID" SP "(" objectid ")"
; follows tagged-ext production from [<a href="./rfc4466" title=""Collected Extensions to IMAP4 ABNF"">RFC4466</a>]
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Implementation Considerations</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Assigning Object Identifiers</span>
All ObjectID values are allocated by the server.
In the interest of reducing the possibilities of encoding mistakes,
ObjectIDs are restricted to a safe subset of possible byte values; in
order to allow clients to allocate storage, they are restricted in
length.
An ObjectID is a string of 1 to 255 characters from the following set
of 64 codepoints: a-z, A-Z, 0-9, _, -. These characters are safe to
use in almost any context (e.g., filesystems, URIs, IMAP atoms).
These are the same characters defined as base64url in [<a href="./rfc4648" title=""The Base16, Base32, and Base64 Data Encodings"">RFC4648</a>].
<span class="grey">Gondwana Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
For maximum safety, servers should also follow defensive allocation
strategies to avoid creating risks where glob completion or data type
detection may be present (e.g., on filesystems or in spreadsheets).
In particular, it is wise to avoid:
o IDs starting with a dash
o IDs starting with digits
o IDs that contain only digits
o IDs that differ only by ASCII case (for example, A vs. a)
o the specific sequence of three characters NIL in any case (because
this sequence can be confused with the IMAP protocol expression of
the null value)
A good solution to these issues is to prefix every ID with a single
alphabetical character.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Interaction with Special Cases</span>
The case of RENAME INBOX may need special handling because it has
special behavior, as defined in <a href="./rfc3501#section-6.3.5">[RFC3501], Section 6.3.5</a>.
It is advisable (though not required) to have MAILBOXID be globally
unique, but it is only required to be unique within messages offered
to a single client login to a single server hostname. For example, a
proxy that aggregates multiple independent servers MUST NOT advertise
the OBJECTID capability unless it can guarantee that different
objects will never use the same identifiers, even if backend object
identifiers collide.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Client Usage</span>
Servers that implement both <a href="./rfc6154">RFC 6154</a> and this specification should
optimize their execution of commands like UID SEARCH OR EMAILID 1234
EMAILID 4321.
Clients can assume that searching the all-mail mailbox using OR/
EMAILID or OR/THREADID is a fast way to find messages again if some
other client has moved them out of the mailbox where they were
previously seen.
Clients that cache data offline should fetch the EMAILID of all new
messages to avoid redownloading already-cached message details.
<span class="grey">Gondwana Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
Clients should fetch the MAILBOXID for any new mailboxes before
discarding cache data for any mailbox that is no longer present on
the server so that they can detect renames and avoid redownloading
data.
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. Advice to Client Implementers</span>
In cases of server failure and disaster recovery, or misbehaving
servers, it is possible that a client will be sent invalid
information, e.g., identical ObjectIDs or ObjectIDs that have changed
where they MUST NOT change according to this document.
In a case where a client detects inconsistent ObjectID responses from
a server, it SHOULD fall back to relying on the guarantees of <a href="./rfc3501">RFC</a>
<a href="./rfc3501">3501</a>. For simplicity, a client MAY instead choose to discard its
entire cache and resync all state from the server.
Client authors protecting against server misbehavior MUST ensure that
their design cannot get into an infinite loop of discarding cache and
fetching the same data repeatedly without user interaction.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Future Considerations</span>
This extension is intentionally defined to be compatible with the
data model in [<a href="#ref-JMAP-MAIL">JMAP-MAIL</a>].
A future extension could be proposed to give a way to SELECT a
mailbox by MAILBOXID rather than name.
A future extension to [<a href="./rfc5228" title=""Sieve: An Email Filtering Language"">RFC5228</a>] could allow fileinto by MAILBOXID
rather than name.
An extension to allow fetching message content directly via EMAILID
and message listings by THREADID could be proposed.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
IANA has added "OBJECTID" to the "IMAP Capabilities" registry located
at <<a href="https://www.iana.org/assignments/imap-capabilities">https://www.iana.org/assignments/imap-capabilities</a>> with a
reference to this document.
IANA has added "MAILBOXID" to the "IMAP Response Codes" registry
located at <<a href="https://www.iana.org/assignments/imap-response-codes">https://www.iana.org/assignments/imap-response-codes</a>>
with a reference to this document.
<span class="grey">Gondwana Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Security Considerations</span>
It is strongly advised that servers generate ObjectIDs that are safe
to use as filesystem names and unlikely to be autodetected as
numbers. See implementation considerations.
If a digest is used for ID generation, it must have a collision-
resistant property, so server implementations are advised to monitor
current security research and choose secure digests. As the IDs are
generated by the server, it will be possible to migrate to a new hash
by just using the new algorithm when creating new IDs. This is
particularly true if a prefix is used on each ID, which can be
changed when the algorithm changes.
The use of a digest for ID generation may be used as proof that a
particular sequence of bytes was seen by the server. However, this
is only a risk if IDs are leaked to clients who don't have permission
to fetch the data directly. Servers that are expected to handle
highly sensitive data should consider this when choosing how to
create IDs.
See also the security considerations in <a href="./rfc3501#section-11">[RFC3501], Section 11</a>.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3501">RFC3501</a>] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", <a href="./rfc3501">RFC 3501</a>, DOI 10.17487/RFC3501, March 2003,
<<a href="https://www.rfc-editor.org/info/rfc3501">https://www.rfc-editor.org/info/rfc3501</a>>.
[<a id="ref-RFC4315">RFC4315</a>] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", <a href="./rfc4315">RFC 4315</a>, DOI 10.17487/RFC4315,
December 2005, <<a href="https://www.rfc-editor.org/info/rfc4315">https://www.rfc-editor.org/info/rfc4315</a>>.
[<a id="ref-RFC4466">RFC4466</a>] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", <a href="./rfc4466">RFC 4466</a>, DOI 10.17487/RFC4466, April 2006,
<<a href="https://www.rfc-editor.org/info/rfc4466">https://www.rfc-editor.org/info/rfc4466</a>>.
[<a id="ref-RFC5228">RFC5228</a>] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", <a href="./rfc5228">RFC 5228</a>, DOI 10.17487/RFC5228,
January 2008, <<a href="https://www.rfc-editor.org/info/rfc5228">https://www.rfc-editor.org/info/rfc5228</a>>.
<span class="grey">Gondwana Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
DOI 10.17487/RFC5234, January 2008,
<<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>>.
[<a id="ref-RFC5256">RFC5256</a>] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", <a href="./rfc5256">RFC 5256</a>,
DOI 10.17487/RFC5256, June 2008,
<<a href="https://www.rfc-editor.org/info/rfc5256">https://www.rfc-editor.org/info/rfc5256</a>>.
[<a id="ref-RFC5819">RFC5819</a>] Melnikov, A. and T. Sirainen, "IMAP4 Extension for
Returning STATUS Information in Extended LIST", <a href="./rfc5819">RFC 5819</a>,
DOI 10.17487/RFC5819, March 2010,
<<a href="https://www.rfc-editor.org/info/rfc5819">https://www.rfc-editor.org/info/rfc5819</a>>.
[<a id="ref-RFC6851">RFC6851</a>] Gulbrandsen, A. and N. Freed, Ed., "Internet Message
Access Protocol (IMAP) - MOVE Extension", <a href="./rfc6851">RFC 6851</a>,
DOI 10.17487/RFC6851, January 2013,
<<a href="https://www.rfc-editor.org/info/rfc6851">https://www.rfc-editor.org/info/rfc6851</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>
[<a id="ref-JMAP-MAIL">JMAP-MAIL</a>]
Jenkins, N. and C. Newman, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22JMAP+for+Mail%22'>"JMAP for Mail"</a>, Work in
Progress, <a href="./draft-ietf-jmap-mail-07">draft-ietf-jmap-mail-07</a>, August 2018.
[<a id="ref-RFC4122">RFC4122</a>] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", <a href="./rfc4122">RFC 4122</a>,
DOI 10.17487/RFC4122, July 2005,
<<a href="https://www.rfc-editor.org/info/rfc4122">https://www.rfc-editor.org/info/rfc4122</a>>.
[<a id="ref-RFC4648">RFC4648</a>] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", <a href="./rfc4648">RFC 4648</a>, DOI 10.17487/RFC4648, October 2006,
<<a href="https://www.rfc-editor.org/info/rfc4648">https://www.rfc-editor.org/info/rfc4648</a>>.
<span class="grey">Gondwana Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Ideas for Implementing Object Identifiers</span>
Ideas for calculating MAILBOXID:
o Universally Unique Identifier (UUID) [<a href="./rfc4122" title=""A Universally Unique IDentifier (UUID) URN Namespace"">RFC4122</a>]
o Server-assigned sequence number (guaranteed not to be reused)
Ideas for implementing EMAILID:
o Digest of message content (<a href="./rfc822">RFC822</a> bytes) -- expensive unless
cached
o UUID [<a href="./rfc4122" title=""A Universally Unique IDentifier (UUID) URN Namespace"">RFC4122</a>]
o Server-assigned sequence number (guaranteed not to be reused)
Ideas for implementing THREADID:
o Derive from EMAILID of first seen message in the thread.
o UUID [<a href="./rfc4122" title=""A Universally Unique IDentifier (UUID) URN Namespace"">RFC4122</a>]
o Server-assigned sequence number (guaranteed not to be reused)
There is a need to index and look up reference/in-reply-to data at
message creation to efficiently find matching messages for threading.
Threading may be either across mailboxes or within each mailbox only.
The server has significant leeway here.
Acknowledgments
The author would like to thank the EXTRA working group at IETF for
feedback and advice -- in particular, Arnt Gulbrandsen, Brandon Long,
Chris Newman, and Josef Sipek.
This document drew inspiration from the Gmail X-GM-THRID and X-GM-
MSGID implementations as currently defined at
<<a href="https://developers.google.com/gmail/imap/imap-extensions">https://developers.google.com/gmail/imap/imap-extensions</a>>, as well
as the X-GUID implementation in the Dovecot server.
<span class="grey">Gondwana Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8474">RFC 8474</a> IMAP ObjectID September 2018</span>
Author's Address
Bron Gondwana (editor)
FastMail
Level 2, 114 William St
Melbourne VIC 3000
Australia
Email: brong@fastmailteam.com
URI: <a href="https://www.fastmail.com">https://www.fastmail.com</a>
Gondwana Standards Track [Page 16]
</pre>
|
