imapext-2007

annotate docs/rfc/rfc3503.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group A. Melnikov
yuuji@0 8 Request for Comments: 3503 ACI Worldwide/MessagingDirect
yuuji@0 9 Category: Standards Track March 2003
yuuji@0 10
yuuji@0 11
yuuji@0 12 Message Disposition Notification (MDN) profile for
yuuji@0 13 Internet Message Access Protocol (IMAP)
yuuji@0 14
yuuji@0 15 Status of this Memo
yuuji@0 16
yuuji@0 17 This document specifies an Internet standards track protocol for the
yuuji@0 18 Internet community, and requests discussion and suggestions for
yuuji@0 19 improvements. Please refer to the current edition of the "Internet
yuuji@0 20 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 21 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 22
yuuji@0 23 Copyright Notice
yuuji@0 24
yuuji@0 25 Copyright (C) The Internet Society (2003). All Rights Reserved.
yuuji@0 26
yuuji@0 27 Abstract
yuuji@0 28
yuuji@0 29 The Message Disposition Notification (MDN) facility defined in RFC
yuuji@0 30 2298 provides a means by which a message can request that message
yuuji@0 31 processing by the recipient be acknowledged as well as a format to be
yuuji@0 32 used for such acknowledgements. However, it doesn't describe how
yuuji@0 33 multiple Mail User Agents (MUAs) should handle the generation of MDNs
yuuji@0 34 in an Internet Message Access Protocol (IMAP4) environment.
yuuji@0 35
yuuji@0 36 This document describes how to handle MDNs in such an environment and
yuuji@0 37 provides guidelines for implementers of IMAP4 that want to add MDN
yuuji@0 38 support to their products.
yuuji@0 39
yuuji@0 40
yuuji@0 41
yuuji@0 42
yuuji@0 43
yuuji@0 44
yuuji@0 45
yuuji@0 46
yuuji@0 47
yuuji@0 48
yuuji@0 49
yuuji@0 50
yuuji@0 51
yuuji@0 52
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Melnikov Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 3503 MDN profile for IMAP March 2003
yuuji@0 61
yuuji@0 62
yuuji@0 63 Table of Contents
yuuji@0 64
yuuji@0 65 1. Conventions Used in this Document............................. 2
yuuji@0 66 2. Introduction and Overview..................................... 2
yuuji@0 67 3. Client behavior............................................... 3
yuuji@0 68 3.1. Client behavior when receiving a message................. 5
yuuji@0 69 3.2. Client behavior when copying a message................... 5
yuuji@0 70 3.3. Client behavior when sending a message................... 5
yuuji@0 71 3.4. Client behavior when saving a temporary message.......... 5
yuuji@0 72 4. Server behavior............................................... 5
yuuji@0 73 4.1. Server that supports arbitrary keywords.................. 5
yuuji@0 74 4.2. Server that supports only $MDNSent keyword............... 5
yuuji@0 75 4.3. Interaction with IMAP ACL extension...................... 6
yuuji@0 76 5. Examples...................................................... 6
yuuji@0 77 6. Security Considerations....................................... 7
yuuji@0 78 7. Formal Syntax................................................. 7
yuuji@0 79 8. Acknowledgments............................................... 7
yuuji@0 80 9. Normative References.......................................... 8
yuuji@0 81 10. Author's Address.............................................. 8
yuuji@0 82 11. Full Copyright Statement...................................... 9
yuuji@0 83
yuuji@0 84 1. Conventions Used in this Document
yuuji@0 85
yuuji@0 86 "C:" and "S:" in examples show lines sent by the client and server
yuuji@0 87 respectively.
yuuji@0 88
yuuji@0 89 The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
yuuji@0 90 this document when typed in uppercase are to be interpreted as
yuuji@0 91 defined in "Key words for use in RFCs to Indicate Requirement Levels"
yuuji@0 92 [KEYWORDS].
yuuji@0 93
yuuji@0 94 2. Introduction and Overview
yuuji@0 95
yuuji@0 96 This memo defines an additional [IMAP4] mailbox keyword that allows
yuuji@0 97 multiple Mail User Agents (MUAs) to know if a requested receipt
yuuji@0 98 notification was sent.
yuuji@0 99
yuuji@0 100 Message Disposition Notification [MDN] does not require any special
yuuji@0 101 support of IMAP in the case where a user has access to the mailstore
yuuji@0 102 from only one computer and is using a single MUA. In this case, the
yuuji@0 103 MUA behaves as described in [MDN], i.e., the MUA performs automatic
yuuji@0 104 processing and generates corresponding MDNs, it performs requested
yuuji@0 105 action and, with the user's permission, sends appropriate MDNs. The
yuuji@0 106 MUA will not send MDN twice because the MUA keeps track of sent
yuuji@0 107 notifications in a local configuration. However, that does not work
yuuji@0 108 when IMAP is used to access the same mailstore from different
yuuji@0 109 locations or is using different MUAs.
yuuji@0 110
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Melnikov Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 3503 MDN profile for IMAP March 2003
yuuji@0 117
yuuji@0 118
yuuji@0 119 This document defines a new special purpose mailbox keyword $MDNSent
yuuji@0 120 that must be used by MUAs. It does not define any new command or
yuuji@0 121 response for IMAP, but describes a technique that MUAs should use to
yuuji@0 122 achieve interoperability.
yuuji@0 123
yuuji@0 124 When a client opens a mailbox for the first time, it verifies that
yuuji@0 125 the server is capable of storing the $MDNSent keyword by examining
yuuji@0 126 the PERMANENTFLAGS response code. In order to support MDN in IMAP, a
yuuji@0 127 server MUST support either the $MDNSent keyword, or arbitrary message
yuuji@0 128 keywords.
yuuji@0 129
yuuji@0 130 3. Client behavior
yuuji@0 131
yuuji@0 132 The use of IMAP requires few additional steps in mail processing on
yuuji@0 133 the client side. The following timeline modifies the timeline found
yuuji@0 134 in Section 4 of [MDN].
yuuji@0 135
yuuji@0 136 -- User composes message.
yuuji@0 137
yuuji@0 138 -- User tells MUA to send message.
yuuji@0 139
yuuji@0 140 -- MUA passes message to MSA (original recipient information passed
yuuji@0 141 along). MUA [optionally] saves message to a folder for sent mail
yuuji@0 142 with $MDNSent flag set.
yuuji@0 143
yuuji@0 144 -- MSA sends message to MTA.
yuuji@0 145
yuuji@0 146 -- Final MTA receives message.
yuuji@0 147
yuuji@0 148 -- Final MTA delivers message to MUA (possibly generating DSN).
yuuji@0 149
yuuji@0 150 -- MUA logs into IMAP server, opens mailbox, verifies if mailbox can
yuuji@0 151 store $MDNSent keyword by examining PERMANENTFLAGS response.
yuuji@0 152
yuuji@0 153 -- MUA performs automatic processing and generates corresponding MDNs
yuuji@0 154 ("dispatched", "processed", "deleted", "denied" or "failed"
yuuji@0 155 disposition type with "automatic-action" and "MDN-sent-
yuuji@0 156 automatically" disposition modes) for messages that do not have
yuuji@0 157 $MDNSent keyword, or \Draft flag set. (*)
yuuji@0 158
yuuji@0 159 -- MUA sets the $MDNSent keyword for every message that required an
yuuji@0 160 automatic MDN to be sent, whether or not the MDN was sent.
yuuji@0 161
yuuji@0 162 -- MUA displays a list of messages to user.
yuuji@0 163
yuuji@0 164 -- User selects a message and requests that some action be performed
yuuji@0 165 on it.
yuuji@0 166
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Melnikov Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 3503 MDN profile for IMAP March 2003
yuuji@0 173
yuuji@0 174
yuuji@0 175 -- MUA performs requested action and, with user's permission, sends
yuuji@0 176 appropriate MDN ("displayed", "dispatched", "processed",
yuuji@0 177 "deleted", "denied" or "failed" disposition type with "manual-
yuuji@0 178 action" and "MDN-sent-manually" or "MDN-sent-automatically"
yuuji@0 179 disposition mode). If the generated MDN is saved to a mailbox
yuuji@0 180 with the APPEND command, the client MUST specify the $MDNSent
yuuji@0 181 keyword in the APPEND.
yuuji@0 182
yuuji@0 183 -- MUA sets the $MDNSent keyword for all messages for which the user
yuuji@0 184 confirmed the dispatching of disposition (or was explicitly
yuuji@0 185 prohibited to do so).
yuuji@0 186
yuuji@0 187 -- User possibly performs other actions on message, but no further
yuuji@0 188 MDNs are generated.
yuuji@0 189
yuuji@0 190 (*) Note: MUA MUST NOT use \Recent flag as an indicator that it
yuuji@0 191 should send MDN, because according to [IMAP4], "If multiple
yuuji@0 192 connections have the same mailbox selected simultaneously, it is
yuuji@0 193 undefined which of these connections will see newly-arrived
yuuji@0 194 messages with \Recent set and which will see it without \Recent
yuuji@0 195 set". Thus, using \Recent as an indicator will cause
yuuji@0 196 unpredictable client behavior with different IMAP4 servers.
yuuji@0 197 However, the client MAY use \Seen flag as one of the indicators
yuuji@0 198 that MDN must not be sent. The client MUST NOT use any other
yuuji@0 199 standard flags, like \Draft or \Answered, to indicate that MDN
yuuji@0 200 was previously sent, because they have different well known
yuuji@0 201 meaning. In any case, in the presence of the $MDNSent keyword,
yuuji@0 202 the client MUST ignore all other flags or keywords for the
yuuji@0 203 purpose of generating an MDN and MUST NOT send the MDN.
yuuji@0 204
yuuji@0 205 When the client opens a mailbox for the first time, it must verify
yuuji@0 206 that the server supports the $MDNSent keyword, or arbitrary message
yuuji@0 207 keywords by examining PERMANENTFLAGS response code.
yuuji@0 208
yuuji@0 209 The client MUST NOT try to set the $MDNSent keyword if the server is
yuuji@0 210 incapable of storing it permanently.
yuuji@0 211
yuuji@0 212 The client MUST be prepared to receive NO from the server as the
yuuji@0 213 result of STORE $MDNSent when the server advertises the support of
yuuji@0 214 storing arbitrary keywords, because the server may limit the number
yuuji@0 215 of message keywords it can store in a particular mailbox. A client
yuuji@0 216 SHOULD NOT send MDN if it fails to store the $MDNSent keyword.
yuuji@0 217
yuuji@0 218 Once the $MDNSent keyword is set, it MUST NOT be unset by a client.
yuuji@0 219 The client MAY set the $MDNSent keyword when a user denies sending
yuuji@0 220 the notification. This prohibits all other MUAs from sending MDN for
yuuji@0 221 this message.
yuuji@0 222
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Melnikov Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 3503 MDN profile for IMAP March 2003
yuuji@0 229
yuuji@0 230
yuuji@0 231 3.1. Client behavior when receiving a message
yuuji@0 232
yuuji@0 233 The client MUST NOT send MDN if a message has the $MDNSent keyword
yuuji@0 234 set. It also MUST NOT send MDN if a message has \Draft flag, because
yuuji@0 235 some clients use this flag to mark a message as incomplete.
yuuji@0 236
yuuji@0 237 See the timeline in section 3 for details on client behavior when
yuuji@0 238 receiving a message.
yuuji@0 239
yuuji@0 240 3.2. Client behavior when copying a message
yuuji@0 241
yuuji@0 242 The client SHOULD verify that $MDNSent is preserved on a COPY
yuuji@0 243 operation. Furthermore, when a message is copied between servers
yuuji@0 244 with the APPEND command, the client MUST set the $MDNSent keyword
yuuji@0 245 correctly.
yuuji@0 246
yuuji@0 247 3.3. Client behavior when sending a message
yuuji@0 248
yuuji@0 249 When saving a sent message to any folder, the client MUST set the
yuuji@0 250 $MDNSent keyword to prevent another client from sending MDN for the
yuuji@0 251 message.
yuuji@0 252
yuuji@0 253 3.4. Client behavior when saving a temporary message
yuuji@0 254
yuuji@0 255 When saving an unfinished message to any folder client MUST set
yuuji@0 256 $MDNSent keyword to prevent another client from sending MDN for the
yuuji@0 257 message.
yuuji@0 258
yuuji@0 259 4. Server behavior
yuuji@0 260
yuuji@0 261 Server implementors that want to follow this specification must
yuuji@0 262 insure that their server complies with either section 4.1 or section
yuuji@0 263 4.2. If the server also supports the IMAP [ACL] extension, it MUST
yuuji@0 264 also comply with the section 4.3.
yuuji@0 265
yuuji@0 266 4.1. Server that supports arbitrary keywords
yuuji@0 267
yuuji@0 268 No changes are required from the server to make it compatible with
yuuji@0 269 the extension described in this document if it supports arbitrary
yuuji@0 270 keywords.
yuuji@0 271
yuuji@0 272 4.2. Server that supports only $MDNSent keyword
yuuji@0 273
yuuji@0 274 Servers that support only the $MDNSent keyword MUST preserve it on
yuuji@0 275 the COPY operation. It is also expected that a server that supports
yuuji@0 276 SEARCH <flag> will also support the SEARCH KEYWORD $MDNSent.
yuuji@0 277
yuuji@0 278
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Melnikov Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 3503 MDN profile for IMAP March 2003
yuuji@0 285
yuuji@0 286
yuuji@0 287 4.3. Interaction with IMAP ACL extension
yuuji@0 288
yuuji@0 289 Any server that conforms to either 4.1 or 4.2 and also supports the
yuuji@0 290 IMAP [ACL] extension, SHOULD preserve the $MDNSent keyword on COPY
yuuji@0 291 even if the client does not have 'w' right. This will prevent the
yuuji@0 292 generation of a duplicated MDN for the same message. Note that the
yuuji@0 293 server MUST still check if the client has rights to perform the COPY
yuuji@0 294 operation on a message according to [ACL].
yuuji@0 295
yuuji@0 296 5. Examples
yuuji@0 297
yuuji@0 298 1) MUA opens mailbox for the first time.
yuuji@0 299
yuuji@0 300 a) The server supports storing of arbitrary keywords
yuuji@0 301
yuuji@0 302 C: a100 select INBOX
yuuji@0 303 S: * FLAGS (\Flagged \Draft \Deleted \Seen)
yuuji@0 304 S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)]
yuuji@0 305 S: * 5 EXISTS
yuuji@0 306 S: * 3 RECENT
yuuji@0 307 S: * OK [UIDVALIDITY 894294713]
yuuji@0 308 S: a100 OK [READ-WRITE] Completed
yuuji@0 309
yuuji@0 310 b) The server supports storing of the $MDNSent keyword
yuuji@0 311
yuuji@0 312 C: a100 select INBOX
yuuji@0 313 S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)
yuuji@0 314 S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)]
yuuji@0 315 S: * 5 EXISTS
yuuji@0 316 S: * 3 RECENT
yuuji@0 317 S: * OK [UIDVALIDITY 894294713]
yuuji@0 318 S: a100 OK [READ-WRITE] Completed
yuuji@0 319
yuuji@0 320 2) The MUA successfully sets the $MDNSent keyword
yuuji@0 321
yuuji@0 322 C: a200 STORE 4 +FLAGS ($MDNSent)
yuuji@0 323 S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent))
yuuji@0 324 S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen)
yuuji@0 325 S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen \*)]
yuuji@0 326 S: a200 OK STORE completed
yuuji@0 327
yuuji@0 328 3) The server refuses to store the $MDNSent keyword
yuuji@0 329
yuuji@0 330 C: a200 STORE 4 +FLAGS ($MDNSent)
yuuji@0 331 S: a200 NO STORE failed : no space left to store $MDNSent keyword
yuuji@0 332
yuuji@0 333
yuuji@0 334
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Melnikov Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 3503 MDN profile for IMAP March 2003
yuuji@0 341
yuuji@0 342
yuuji@0 343 4) All clients and servers MUST treat the $MDNSent keyword as case
yuuji@0 344 insensitive in all operations, as stated in [IMAP].
yuuji@0 345
yuuji@0 346 C: a300 FETCH 1:* FLAGS
yuuji@0 347 S: * 1 FETCH (FLAGS (\Seen))
yuuji@0 348 S: * 2 FETCH (FLAGS (\Answered \Seen $MdnSENt))
yuuji@0 349 S: * 3 FETCH (FLAGS ())
yuuji@0 350 S: * 4 FETCH (FLAGS (\Flagged \Seen $MdnSENT))
yuuji@0 351 S: * 5 FETCH (FLAGS ($MDNSent))
yuuji@0 352 S: * 6 FETCH (FLAGS (\Recent))
yuuji@0 353 S: a300 OK FETCH completed
yuuji@0 354 C: a400 SEARCH KEYWORDS $mdnsent
yuuji@0 355 S: * SEARCH 2 4 5
yuuji@0 356 S: a400 OK SEARCH completed
yuuji@0 357
yuuji@0 358 6. Security Considerations
yuuji@0 359
yuuji@0 360 There are no known security issues with this extension, not found in
yuuji@0 361 [MDN] and/or [IMAP4].
yuuji@0 362
yuuji@0 363 Section 4.3 changes ACL checking requirements on an IMAP server that
yuuji@0 364 implements IMAP [ACL] extension.
yuuji@0 365
yuuji@0 366 7. Formal Syntax
yuuji@0 367
yuuji@0 368 The following syntax specification uses the augmented Backus-Naur
yuuji@0 369 Form (BNF) notation as specified in [RFC-822], as modified by
yuuji@0 370 [IMAP4]. Non-terminals referenced, but not defined below, are as
yuuji@0 371 defined by [IMAP4].
yuuji@0 372
yuuji@0 373 Except as noted otherwise, all alphabetic characters are case-
yuuji@0 374 insensitive. The use of upper or lower case characters to define
yuuji@0 375 token strings is for editorial clarity only. Implementations MUST
yuuji@0 376 accept these strings in a case-insensitive fashion.
yuuji@0 377
yuuji@0 378 flag_keyword ::= "$MDNSent" / other_keywords
yuuji@0 379
yuuji@0 380 other_keywords ::= atom
yuuji@0 381
yuuji@0 382 8. Acknowledgments
yuuji@0 383
yuuji@0 384 This document is the product of discussions that took place on the
yuuji@0 385 IMAP mailing list. Special gratitude to Cyrus Daboo and Randall
yuuji@0 386 Gellens for reviewing the document.
yuuji@0 387
yuuji@0 388 Thank you to my father who as he has helped to make me what I am. I
yuuji@0 389 miss you terribly.
yuuji@0 390
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Melnikov Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 3503 MDN profile for IMAP March 2003
yuuji@0 397
yuuji@0 398
yuuji@0 399 9. Normative References
yuuji@0 400
yuuji@0 401 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 402 Requirement Levels", BCP 14, RFC 2119, March 1997.
yuuji@0 403
yuuji@0 404 [MDN] Fajman, R., "An Extensible Message Format for Message
yuuji@0 405 Disposition Notifications", RFC 2298, March 1998.
yuuji@0 406
yuuji@0 407 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
yuuji@0 408 4rev1", RFC 3501, March 2003.
yuuji@0 409
yuuji@0 410 [ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
yuuji@0 411
yuuji@0 412 10. Author's Address
yuuji@0 413
yuuji@0 414 Alexey Melnikov
yuuji@0 415 ACI Worldwide/MessagingDirect
yuuji@0 416 59 Clarendon Road
yuuji@0 417 Watford, Hertfordshire
yuuji@0 418 United Kingdom, WD17 1FQ
yuuji@0 419
yuuji@0 420 Phone: +44 1923 81 2877
yuuji@0 421 EMail: mel@messagingdirect.com
yuuji@0 422
yuuji@0 423
yuuji@0 424
yuuji@0 425
yuuji@0 426
yuuji@0 427
yuuji@0 428
yuuji@0 429
yuuji@0 430
yuuji@0 431
yuuji@0 432
yuuji@0 433
yuuji@0 434
yuuji@0 435
yuuji@0 436
yuuji@0 437
yuuji@0 438
yuuji@0 439
yuuji@0 440
yuuji@0 441
yuuji@0 442
yuuji@0 443
yuuji@0 444
yuuji@0 445
yuuji@0 446
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Melnikov Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 3503 MDN profile for IMAP March 2003
yuuji@0 453
yuuji@0 454
yuuji@0 455 11. Full Copyright Statement
yuuji@0 456
yuuji@0 457 Copyright (C) The Internet Society (2003). All Rights Reserved.
yuuji@0 458
yuuji@0 459 This document and translations of it may be copied and furnished to
yuuji@0 460 others, and derivative works that comment on or otherwise explain it
yuuji@0 461 or assist in its implementation may be prepared, copied, published
yuuji@0 462 and distributed, in whole or in part, without restriction of any
yuuji@0 463 kind, provided that the above copyright notice and this paragraph are
yuuji@0 464 included on all such copies and derivative works. However, this
yuuji@0 465 document itself may not be modified in any way, such as by removing
yuuji@0 466 the copyright notice or references to the Internet Society or other
yuuji@0 467 Internet organizations, except as needed for the purpose of
yuuji@0 468 developing Internet standards in which case the procedures for
yuuji@0 469 copyrights defined in the Internet Standards process must be
yuuji@0 470 followed, or as required to translate it into languages other than
yuuji@0 471 English.
yuuji@0 472
yuuji@0 473 The limited permissions granted above are perpetual and will not be
yuuji@0 474 revoked by the Internet Society or its successors or assigns.
yuuji@0 475
yuuji@0 476 This document and the information contained herein is provided on an
yuuji@0 477 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
yuuji@0 478 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
yuuji@0 479 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
yuuji@0 480 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
yuuji@0 481 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 482
yuuji@0 483 Acknowledgement
yuuji@0 484
yuuji@0 485 Funding for the RFC Editor function is currently provided by the
yuuji@0 486 Internet Society.
yuuji@0 487
yuuji@0 488
yuuji@0 489
yuuji@0 490
yuuji@0 491
yuuji@0 492
yuuji@0 493
yuuji@0 494
yuuji@0 495
yuuji@0 496
yuuji@0 497
yuuji@0 498
yuuji@0 499
yuuji@0 500
yuuji@0 501
yuuji@0 502
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Melnikov Standards Track [Page 9]
yuuji@0 507

UW-IMAP'd extensions by yuuji