rfc3503.txt

广泛使用的邮件服务器！同时

   When saving an unfinished message to any folder client MUST set
   $MDNSent keyword to prevent another client from sending MDN for the
   message.

4.  Server behavior

   Server implementors that want to follow this specification must
   insure that their server complies with either section 4.1 or section
   4.2.  If the server also supports the IMAP [ACL] extension, it MUST
   also comply with the section 4.3.

4.1.  Server that supports arbitrary keywords

   No changes are required from the server to make it compatible with
   the extension described in this document if it supports arbitrary
   keywords.

4.2.  Server that supports only $MDNSent keyword

   Servers that support only the $MDNSent keyword MUST preserve it on
   the COPY operation.  It is also expected that a server that supports
   SEARCH <flag> will also support the SEARCH KEYWORD $MDNSent.





Melnikov                    Standards Track                     [Page 5]

RFC 3503                  MDN profile for IMAP                March 2003


4.3.  Interaction with IMAP ACL extension

   Any server that conforms to either 4.1 or 4.2 and also supports the
   IMAP [ACL] extension, SHOULD preserve the $MDNSent keyword on COPY
   even if the client does not have 'w' right.  This will prevent the
   generation of a duplicated MDN for the same message.  Note that the
   server MUST still check if the client has rights to perform the COPY
   operation on a message according to [ACL].

5.  Examples

   1) MUA opens mailbox for the first time.

   a) The server supports storing of arbitrary keywords

   C: a100 select INBOX
   S: * FLAGS (\Flagged \Draft \Deleted \Seen)
   S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)]
   S: * 5 EXISTS
   S: * 3 RECENT
   S: * OK [UIDVALIDITY 894294713]
   S: a100 OK [READ-WRITE] Completed

   b) The server supports storing of the $MDNSent keyword

   C: a100 select INBOX
   S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)
   S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)]
   S: * 5 EXISTS
   S: * 3 RECENT
   S: * OK [UIDVALIDITY 894294713]
   S: a100 OK [READ-WRITE] Completed

   2) The MUA successfully sets the $MDNSent keyword

   C: a200 STORE 4 +FLAGS ($MDNSent)
   S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent))
   S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen)
   S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen \*)]
   S: a200 OK STORE completed

   3) The server refuses to store the $MDNSent keyword

   C: a200 STORE 4 +FLAGS ($MDNSent)
   S: a200 NO STORE failed : no space left to store $MDNSent keyword






Melnikov                    Standards Track                     [Page 6]

RFC 3503                  MDN profile for IMAP                March 2003


   4) All clients and servers MUST treat the $MDNSent keyword as case
   insensitive in all operations, as stated in [IMAP].

   C: a300 FETCH 1:* FLAGS
   S: * 1 FETCH (FLAGS (\Seen))
   S: * 2 FETCH (FLAGS (\Answered \Seen $MdnSENt))
   S: * 3 FETCH (FLAGS ())
   S: * 4 FETCH (FLAGS (\Flagged \Seen $MdnSENT))
   S: * 5 FETCH (FLAGS ($MDNSent))
   S: * 6 FETCH (FLAGS (\Recent))
   S: a300 OK FETCH completed
   C: a400 SEARCH KEYWORDS $mdnsent
   S: * SEARCH 2 4 5
   S: a400 OK SEARCH completed

6.  Security Considerations

   There are no known security issues with this extension, not found in
   [MDN] and/or [IMAP4].

   Section 4.3 changes ACL checking requirements on an IMAP server that
   implements IMAP [ACL] extension.

7.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [RFC-822], as modified by
   [IMAP4].  Non-terminals referenced, but not defined below, are as
   defined by [IMAP4].

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

   flag_keyword    ::= "$MDNSent" / other_keywords

   other_keywords  ::= atom

8.  Acknowledgments

   This document is the product of discussions that took place on the
   IMAP mailing list.  Special gratitude to Cyrus Daboo and Randall
   Gellens for reviewing the document.

   Thank you to my father who as he has helped to make me what I am.  I
   miss you terribly.




Melnikov                    Standards Track                     [Page 7]

RFC 3503                  MDN profile for IMAP                March 2003


9.  Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [MDN]      Fajman, R., "An Extensible Message Format for Message
              Disposition Notifications", RFC 2298, March 1998.

   [IMAP4]    Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 3501, March 2003.

   [ACL]      Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.

10.  Author's Address

   Alexey Melnikov
   ACI Worldwide/MessagingDirect
   59 Clarendon Road
   Watford, Hertfordshire
   United Kingdom, WD17 1FQ

   Phone: [phone]
   EMail: [e-mail]




























Melnikov                    Standards Track                     [Page 8]

RFC 3503                  MDN profile for IMAP                March 2003


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Melnikov                    Standards Track                     [Page 9]