The IMAP APPENDLIMIT Extension
draft-ietf-imapapnd-appendlimit-extension-04

INTERNET-DRAFT                                           Jayantheesh S B 
Intended status: Standards Track                                 Samsung
Expires: April, 2016                                Narendra Singh Bisht
                                                                 Samsung
                                                        October 08, 2015

                      The IMAP APPENDLIMIT Extension
               draft-ietf-imapapnd-appendlimit-extension-04

Abstract

This memo defines an extension to the IMAP service whereby a server can
advertise its capability, to support maximum mail upload size using
CAPABILITY, STATUS and LIST commands.

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, and
derivative works of it may not be created, except to publish it as an
RFC and to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This Internet-Draft will expire on April, 2016.

Copyright Notice

Copyright (c) 2015 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

Jayantheesh & Narendra       Expires April, 2016              [Page 1]
Internet-Draft               IMAP APPENDLIMIT             October 2015

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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1. Conventions and Terminology . . . . . . . . . .  . . . . .   2
   2. APPENDLIMIT Extension . . . . . . . . . . . . . . . . . . . . .  3
   3. Mailbox specific APPENDLIMIT . . . . . . . . . . . . . . . . . . 3
     3.1. STATUS response . . . . . . . . . . . . . . . . . . . . . .  3
     3.2. LIST response . . . . . . . . . . . . . . . . . . . . . . .  4
   4. APPEND response . . . . . . . . . . . . . . . . . . . . . . . .  4
   5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  5
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
    8.1 Normative References . . . . . . . . . . . . . . . . . . . . . 6
    8.2 Informative References . . . . . . . . . . . . . . . . . . . . 6
   9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . .  6
   10. Author's Address . .. . . . . . . . . . . . . . . . . . . . . . 7
   

1. Introduction

Several IMAP server have limitation for mail upload size which is not
published to the email client.  When email client APPEND a mail with
huge attachments, it fails due to size restriction set by the IMAP
server.  This results in unnecessary resource usage.  Especially in the 
mobile device environment, appending mail with huge attachment consumes
device resources like device battery power and mobile data.

The IMAP APPENDLIMIT extension provides an ability to advertise maximum
upload size allowed by the IMAP server, so that email client knows the
size limitation beforehand.

1.1. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].

Example lines prefaced by "C:" are sent by the client and ones prefaced
by "S:" by the server.  The five characters [...] means that something
has been elided.

Jayantheesh & Narendra       Expires April, 2016             [Page 2]
Internet-Draft               IMAP APPENDLIMIT            October 2015

2. APPENDLIMIT Extension

An IMAP server that supports APPENDLIMIT extension advertises this by
including the name APPENDLIMIT in its capability list. IMAP server
SHOULD advertise this capability after user has logged in. IMAP server
can publish the APPENDLIMIT capability in two formats.

(a) APPENDLIMIT=<number>

This indicates that the IMAP server has the same upload limit for all
the mailboxes. The following example, demonstrates the APPENDLIMIT
capability with same upload limit for all mailboxes.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
S: t1 OK foo

(b) APPENDLIMIT

APPENDLIMIT capability without any value indicates that the IMAP server
has specific upload limit for different mailboxes. The following
example, demonstrates the APPENDLIMIT capability without any value.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT
S: t1 OK foo

In this case the client should get APPENDLIMIT value by issuing
STATUS or LIST command. New response code APPENDLIMIT is added to get
the mailbox specific limit.  Refer section 5 for response code syntax.

IMAP client SHOULD be able to parse both kind of formats. By looking
at the upload size advertised by the IMAP server, client MUST NOT try
to APPEND mail more than advertised limit.

3. Mailbox specific APPENDLIMIT

IMAP server can have mailbox specific APPENDLIMIT value, which will not
be advertised as part of CAPABILITY response.  In this case, client can
issue STATUS or LIST in combination with STATUS command, if the server
supports LIST-STATUS capability, to get the per mailbox specific limit.  

3.1 STATUS response

A new attribute APPENDLIMIT is added to get the limit set by the server
for a mailbox as part of STATUS command. IMAP client should issue STATUS
command with APPENDLIMIT item to get the mailbox specific upload value.
The following example, demonstrates its usage.
Jayantheesh & Narendra       Expires April, 2016             [Page 3]
Internet-Draft               IMAP APPENDLIMIT            October 2015

C: t1 STATUS INBOX (APPENDLIMIT)
S: * STATUS INBOX (APPENDLIMIT 257890)
S: t1 OK STATUS completed

IMAP server MUST return the mailbox name that matches the STATUS
specification and the requested mailbox status information.

In the above example, APPENDLIMIT represents the maximum upload size for
INBOX.

3.2 LIST-STATUS response

IMAP client can issue LIST in combination with STATUS command to get
the mailbox specific upload value, if the server supports LIST-STATUS
extension. The following example, demonstrates its usage.

C: t1 LIST "" % RETURN (STATUS (APPENDLIMIT))
S: * LIST () "."  "INBOX"
S: * STATUS "INBOX" (APPENDLIMIT 257890)
S: t1 OK List completed.

IMAP server MUST recognize an extra "RETURN (STATUS (APPENDLIMIT))"
at the end of a LIST command and emit an extra STATUS response for each
matching mailbox.  Refer to section 5 for the syntax. Refer [RFC5819]
for the usage of LIST in combination with STATUS command.

If the server does not support this extension, then client should use
STATUS command instead.

4. APPEND response

If client uploads a mail which exceeds the maximum upload size set
to that mailbox, then server SHALL reject the APPEND command with a
tagged TOOBIG response code.  Refer [RFC4469] Section (4) for various
APPEND response codes and its handling.

Client can avoid use of LITERAL+ [RFC2088], when maximum upload size
supported by the IMAP server is unknown. Refer [RFC4549] section 4.2.2.3
for usage of LITERAL+ and its risk for disconnected IMAP clients.

STATUS APPENDLIMIT should be fast and there is no need to evaluate 
remaining quotas (if any) when returning APPENDLIMIT values. APPEND can
still fail due to ACL and quota related issues, even if the message
being appended is smaller than the APPENDLIMIT.

Jayantheesh & Narendra       Expires April, 2016             [Page 4]
Internet-Draft               IMAP APPENDLIMIT            October 2015

5. Formal syntax

The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234] including the core
rules in Appendix B.1.  [RFC3501] defines the non-terminals
"capability", "resp-text-code" and "status-att".
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.
    
appendlimit-cap = "APPENDLIMIT" ["=" number]
capability /= appendlimit-cap

appendlimit-respcode = "APPENDLIMIT" SP number
resp-text-code /= appendlimit-respcode

appendlimit-status-att = "APPENDLIMIT"
status-att /=appendlimit-status-att

A number indicating the fixed maximum message size in octets that
the server will accept.  APPENDLIMIT=0 indicates the server SHALL NOT
accept APPEND command due to size restriction.  The syntax of the
parameter follows the augmented BNF notation of [RFC5234].  If this
capability is omitted, no information is conveyed about the server's
fixed maximum mail upload size.

6. Security Consideration

The IMAP APPENDLIMIT extension described in this document can
conceivably be used to facilitate Denial-of-Service attacks.
Specifically, the information contained in the APPENDLIMIT capability
and use of the APPEND command make it somewhat quicker and easier to
devise an efficacious Denial-of-Service attack.  However, unless
implementations are very weak, these extensions do not create any
vulnerability that has not always existed with IMAP. In addition, no
issues are addressed involving trusted systems and possible release
of information via the mechanisms described in this document.
   
IMAP APPENDLIMIT extension doesn't add any new security considerations
that are not already present in the base IMAP protocol [RFC3501].

7. IANA Considerations

IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC.  The registry is currently located at:

Jayantheesh & Narendra       Expires April, 2016             [Page 5]
Internet-Draft               IMAP APPENDLIMIT            October 2015

http://www.iana.org/assignments/imap-capabilities

This document requests that IANA adds "APPENDLIMIT" capability
pointing to this document to the above registry.

8. References

8.1 Normative References

The following documents contain definitions or specifications that
are necessary to understand this document properly
[RFC2119]  Bradner, "Key words for use in RFCs to Indicate
           Requirement Levels", Harvard University, March
           1997.

[RFC3501]  Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
           University of Washington, March 2003

[RFC5234]  Crocker, Overell, "Augmented BNF for Syntax
           Specifications: ABNF", RFC 5234, Brandenburg
           Internetworking, Demon Internet Ltd, January 2008

[RFC5819]  A. Melnikov, T. Sirainen, "IMAP4 Extension for Returning
           STATUS Information in Extended LIST",  March 2010

[RFC4469]  P. Resnick, "Internet Message Access Protocol (IMAP)
           CATENATE Extension",  April 2006

[RFC2088]  J. Myers, Carnegie Mellon, "IMAP4 non-synchronizing
           literals",  January 1997

8. 2 Informative References

The following documents describe related protocols:

[RFC4549]  A. Melnikov, Ed. "Synchronization Operations for Disconnected
           IMAP4 Clients", June 2006
                   
9. Acknowledgement

Thanks to Alexey Melnikov, Dave Cridland, Adrien de Croy,
Michael M Slusarz, Timo Sirainen, Chris Newman,
Pete Maclean, Jamie Nicolson, Stu Brandt, Bron Gondwana,
Arnt Gulbrandsen, Cyrus Daboo, Jan Kundrat, Brandon Long
and Barry Leiba for providing valuable comments. 

Jayantheesh & Narendra       Expires April, 2016              [Page 6]
Internet-Draft               IMAP APPENDLIMIT             October 2015

10. Author's Address

Jayantheesh S B
Samsung Telecommunications America
685 US Highway 202/206
Bridgewater, NJ 08807
USA

Email: jayantheesh.sb@gmail.com

Narendra Singh Bisht
Samsung Telecommunications America
685 US Highway 202/206
Bridgewater, NJ 08807
USA

Email: narendrasingh.bisht@gmail.com

Jayantheesh & Narendra       Expires April, 2016              [Page 7]