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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/