--- 1/draft-ordogh-spam-reporting-using-imap-03.txt 2013-04-11 14:15:14.958549152 +0100 +++ 2/draft-ordogh-spam-reporting-using-imap-04.txt 2013-04-11 14:15:14.994550039 +0100 @@ -1,18 +1,18 @@ Network Working Group Z. Ordogh Internet-Draft Research In Motion Limited -Intended status: Experimental August 30, 2012 -Expires: March 3, 2013 +Intended status: Experimental March 11, 2013 +Expires: September 12, 2013 Spam reporting using IMAP: SREP - draft-ordogh-spam-reporting-using-imap-03 + draft-ordogh-spam-reporting-using-imap-04 Abstract This document defines an IMAP extension which allows a client to report spam by reference and allows an IMAP server to perform any action on the reported messages, including leaving the action at the client's discretion. In addition, this document discusses how an IMAP server can tap into spam aggregator services, ultimately allowing the IMAP server to @@ -36,24 +36,24 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 3, 2013. + This Internet-Draft will expire on September 12, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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 @@ -85,21 +85,21 @@ 3.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 8 3.8. Examples to report spam . . . . . . . . . . . . . . . . . 10 3.9. Examples to report messages as no longer spam . . . . . . 10 3.10. Example flows . . . . . . . . . . . . . . . . . . . . . . 11 3.10.1. The server simply flags a message . . . . . . . . . . 11 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 1. Introduction The Internet Message Access Protocol [IMAP4] does not support reporting spam on its own. There are a number of solutions available based on the multipart/report content type defined in [OLD-REPORT] and its revision, [REPORT]. However, these solutions require including the message contents and hence, consume bandwidth to transmit the entire message. In bandwidth-constrained environments - such as mobile networks - it is highly desirable to send only a @@ -286,21 +286,22 @@ NOT include the request action argument; in this case, the server MUST decide the course of action. The client MAY specify either one of the following actions: - The KEYWORD the client requests that only keyword(s) should be added to the message. The server MUST add the appropriate keyword. - The RELOCATE the client requests that the message should be relocated. The server MUST relocate the message by copying the message to the destination mailbox removing the original as if - another connected client requested this action. + another connected client requested this action using an IMAP MOVE + [IMAPMOVE] command. - The DELETE the client requests that the message should be deleted. The server MUST delete the message as if another client performed this action. The server MUST ignore the destination mailbox in case it is nil, or, the request action is KEYWORD or DELETE. It is assumed that the server is pre-configured with the location where user's spam messages are stored. If the server is not configured with such information and the destination mailbox in a RELOCATE action is nil, or, destination mailbox in a RELOCATE action is otherwise inaccessible to the user (does not exist, insufficient permission, etc) the the @@ -344,21 +345,22 @@ configured to use. - The RELOCATE response occurs in case the server decided that the message should be relocated, however leaves this action to the client. The client MAY decide what to do with the message. - The RELOCATED response occurs in case this specific action has been explicitly requested by the client, or, in case the server decided that the message should be relocated and it performed relocation of the message to the appropriate location before the response was sent. The server MUST relocate the message by copying the message to the appropriate location and removing the - original as if another connected client requested this action. + original as if another connected client requested this action + using an IMAP MOVE [IMAPMOVE] command. - The DELETE response occurs in case the server decided that the message should be deleted, however leaves this action to the client. The client MAY decide what to do with the message. - The DELETED response occurs in case this specific action has been explicitly requested by the client, or, in case the server decided that the message should be deleted, and performed deletion of the message before the response was sent. The server MUST delete the message as if another client performed this action. The KEYWORD, RELOCATE and DELETE responses MUST include the list of @@ -649,20 +651,24 @@ 7. References 7.1. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. + [IMAPMOVE] Gulbrandsen, A. and N. Freed, "Internet Message Access + Protocol (IMAP) - MOVE Extension", RFC 6851, + January 2013. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006. [XDASH] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", RFC 6648, June 2012. @@ -682,11 +688,11 @@ Author's Address Zoltan Ordogh Research In Motion Limited 1875 Buckhorn Gate Mississauga, Ontario L4W 5P1 Canada Phone: +19056294746x15674 Fax: +12892615950 - EMail: zordogh@rim.com + EMail: zordogh@blackberry.com