Naren | 14 Apr 17:11 2015
Picon

Re: imapext Digest, Vol 32, Issue 14

The charter text looks ok.
Both the deliverable are related to each other.

Thanks
-Naren

On Tue, Mar 31, 2015 at 3:00 PM, <imapext-request <at> ietf.org> wrote:
Send imapext mailing list submissions to
        imapext <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/imapext
or, via email, send a message with subject or body 'help' to
        imapext-request <at> ietf.org

You can reach the person managing the list at
        imapext-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of imapext digest..."

Today's Topics:

   1. Charter Proposal for a new IMAP related Working Group
      (Alexey Melnikov)


---------- Forwarded message ----------
From: Alexey Melnikov <alexey.melnikov <at> isode.com>
To: IMAPEXT <imapext <at> ietf.org>
Cc: 
Date: Tue, 31 Mar 2015 03:08:19 +0100
Subject: [imapext] Charter Proposal for a new IMAP related Working Group
Hi,

I've asked Barry earlier what he would like to do about
draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he
asked for a charter for a new short term IMAP related WG. Here is a
proposal:


The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for transferring email messages between a server
that implements a message store, and a client. It also includes commands
for manipulating the message store -- creating, deleting, and renaming
mailboxes, adding a message to a mailbox, and copying messages from one
mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for
transferring blocks of data. When sending a literal from a client to a server,
RFC 3501 requires the client to wait for the server to send a command
continuation request between sending the octet count and the string data.
This complicates client implementations and resulted in definition
of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form
of literal which does not require this network round trip. While this
extension is quite commonly supported by servers, some implementations
decided to disable it because it is frequently abused by naive clients
that try to upload big messages without checking whether servers can
accept big messages.

The IMAP APPEND extension (imapappend) working group has two related
deliverables which are targeted at improving the current situation. One
deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03
and defines a way for servers to announce APPEND limit for a particular
server or a particular mailbox. The second deliverable is based on
draft-melnikov-rfc2088bis-01. It describes implementation choices for
server supporting LITERAL+ extension and also defines LITERAL- extension
which have similar properties, but is easier for servers to implement
while preventing denial of service attacks from malicious and naive IMAP
clients. Both deliverables will be Standards Track documents.

As part of the protocol development, implementation experience on both
the client and server side is highly desireable, so that the actual
operational value of this extension can be assessed. The working group
will document the results of this experience on the working group wiki.

No other IMAP extension work is in scope for this working group.

------
Comments:


1) I don't particularly care if LITERAL- is standardized or not, but I would like the problem to be solved. If we can't agree on LITERAL-, then draft-melnikov-rfc2088bis can just become a revision of LITERAL+.

2) I've also heard some interest in standardizing the SNAPSHOT facility. I am ambivalent on whether it should be added to the above. (If you think it should, please suggest a new paragraph to add). I would like to keep the charter to no more than 3 deliverables.

Any opinions on the proposal?

Best Regards,
Alexey



_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext



_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
narendra singh bisht | 2 Apr 17:19 2015
Picon

Problem with Yahoo SMTP server SIZE attribute.

Hi all,

I am facing a problem with Yahoo account.

Yahoo SMTP server broadcast the SIZE as "SIZE 41697280".

So when I am trying to send a mail with ~28.8 MB of attachment to Gmail/AOL,
sending of the mail succeeds but I am getting a MAILER-DAEMON saying :
Remote host said:
552-5.2.3 Your message exceeded Google's message size limits.


What should I do, as a mail client. Should i not honor the SIZE attribute and use 25 MB as the upper limit?

--
Thanks & Regards
-Naren
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Alexey Melnikov | 31 Mar 04:08 2015

Charter Proposal for a new IMAP related Working Group

Hi,

I've asked Barry earlier what he would like to do about
draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he
asked for a charter for a new short term IMAP related WG. Here is a
proposal:

The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for transferring email messages between a server
that implements a message store, and a client. It also includes commands
for manipulating the message store -- creating, deleting, and renaming
mailboxes, adding a message to a mailbox, and copying messages from one
mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for
transferring blocks of data. When sending a literal from a client to a server,
RFC 3501 requires the client to wait for the server to send a command
continuation request between sending the octet count and the string data.
This complicates client implementations and resulted in definition
of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form
of literal which does not require this network round trip. While this
extension is quite commonly supported by servers, some implementations
decided to disable it because it is frequently abused by naive clients
that try to upload big messages without checking whether servers can
accept big messages.

The IMAP APPEND extension (imapappend) working group has two related
deliverables which are targeted at improving the current situation. One
deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03
and defines a way for servers to announce APPEND limit for a particular
server or a particular mailbox. The second deliverable is based on
draft-melnikov-rfc2088bis-01. It describes implementation choices for
server supporting LITERAL+ extension and also defines LITERAL- extension
which have similar properties, but is easier for servers to implement
while preventing denial of service attacks from malicious and naive IMAP
clients. Both deliverables will be Standards Track documents.

As part of the protocol development, implementation experience on both
the client and server side is highly desireable, so that the actual
operational value of this extension can be assessed. The working group
will document the results of this experience on the working group wiki.

No other IMAP extension work is in scope for this working group.

------
Comments:

1) I don't particularly care if LITERAL- is standardized or not, but I 
would like the problem to be solved. If we can't agree on LITERAL-, then 
draft-melnikov-rfc2088bis can just become a revision of LITERAL+.

2) I've also heard some interest in standardizing the SNAPSHOT facility. 
I am ambivalent on whether it should be added to the above. (If you 
think it should, please suggest a new paragraph to add). I would like to 
keep the charter to no more than 3 deliverables.

Any opinions on the proposal?

Best Regards,
Alexey

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Pete Maclean | 20 Mar 17:10 2015

Re: The IMAP APPENDLIMIT Extension - version 04

Thanks, Bron.  I am aware of Java's lack of unsigned integers having 
had to work around it before.  (I find it a curious lack although I 
have no idea of the rationale behind it.)  So, yes, I come to agree 
that UINT64_MAX would be a poor choice, never mind an unnecessarily 
large one.  So how about a compromise of, say, UINT48_MAX?

Pete

At 02:18 AM 3/19/2015, Bron Gondwana wrote:
>On Thu, Mar 19, 2015, at 09:02 AM, Pete Maclean wrote:
> >
> > >1.  APPENDLIMIT value should be UINT32_MAX or UINT64_MAX ?
> >
> > UINT64_MAX
>
>Most of the world is going with half that in new standards, for
>compatibility with languages that offer a signed 64 bit numeric value
>only (aka - java 7 and below).  It makes mapping the values through said
>languages a lot easier, and 63 bits should be enough for anyone (or
>something).
>
>Alternatively, there's 53 bits, which is the maximum that javascript can
>represent:
>
>http://stackoverflow.com/questions/307179/what-is-javascripts-highest-integer-value-that-a-number-can-go-to-without-losin
>
>It's not going to matter in practice, because that's still fricking huge.
>
>Bron.
>
>--
>   Bron Gondwana
>   brong <at> fastmail.fm
>
>_______________________________________________
>imapext mailing list
>imapext <at> ietf.org
>https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Pete Maclean | 18 Mar 23:02 2015

Re: The IMAP APPENDLIMIT Extension - version 04


>1.  APPENDLIMIT value should be UINT32_MAX or UINT64_MAX ?

UINT64_MAX

>2.  APPENDLIMIT value in SELECT/STATUS response: Whether APPENDLIMIT 
>is needed in both SELECT

I don't feel strongly about this but, considering the recent 
arguments on the matter, I lean toward having it only in STATUS.

Pete Maclean

>and STATUS response?
At 03:47 PM 3/18/2015, Jayantheesh S B wrote:
>All,
>
>Can you please share your views regarding the below item to come to 
>a consensus?
>
>1.  APPENDLIMIT value should be UINT32_MAX or UINT64_MAX ?
>
>2.  APPENDLIMIT value in SELECT/STATUS response: Whether APPENDLIMIT 
>is needed in both SELECT and STATUS response?
>
>Please share your thoughts.
>
>Regards,
>Jay
>
>-----Original Message-----
>From: Alexey Melnikov [mailto:alexey.melnikov <at> isode.com]
>Sent: Monday, March 09, 2015 8:00 AM
>To: Michael M Slusarz; imapext <at> ietf.org
>Subject: Re: [imapext] The IMAP APPENDLIMIT Extension - version 04
>
>Hi,
>After thinking more about this topic (I might have changed my 
>position on a few minor issues):
>
>On 06/03/2015 21:27, Michael M Slusarz wrote:
> > Quoting Chris Newman <chris.newman <at> oracle.com>:
> >
> >> Q for list: If the server has a message larger than UINT32_MAX in the
> >> store and a client tries to fetch it, should the server just go ahead
> >> and violate the base-spec's UINT32_MAX limit or should the data be
> >> NIL unless the client uses ENABLE to tell the server it accepts
> >> larger-than-uint32-max literals on messages? If this extension fixes
> >> that base spec limitation in addition to enabling better client
> >> diagnostics for overlarge messages, I think that's cool.
> >
> > I agree that the max limit should be extended.  However, it doesn't
> > seem like the APPENDLIMIT document is the (best) place to do that
> > since burying a change in a document devoted to APPEND behavior that
> > affects a general IMAP limit, e.g. changing FETCH behavior, doesn't
> > seem to be the model of clarity.
>I agree.
> >
> >> Having two different ways to access a per-folder limit is a violation
> >> of good protocol design practices. Specifically 3.1 and 3.2 provide
> >> two ways to access the same appendlimit. I believe the document would
> >> be improved by the removal of section 3.1. Some problems with the
> >> current two-mechanism proposal:
> >
> > +1.  This is what I had written about previously.
>Not really a violation, because the data is the same whether 
>returned by STATUS or SELECT
> >> * Which limit will the client use if the two limits are different?
> >> * Should a client SELECT a mailbox before doing an APPEND? This is
> >> not required by the base spec and is less efficient. The presence of
> >> section 3.1 implies a client should do this. I do not think a client
> >> should do this.
> >> Removing section
> >> 3.1 removes this issue as a problem.
> >
> > More important... this may be a non-trivial value to calculate for the
> > server.
>(Depending on how accurate a server might want to make this information.
>This is a quality of implementation issue.)
> >
> >> * The addition of APPENDLIMIT as a response to SELECT even for
> >> clients that don't understand it penalizes all clients with
> >> unnecessary network traffic.
> >> While it's not a big response by itself, we're starting to get a
> >> death-of-1000-cuts problem with SELECT responses, so unless it's
> >> really important (and in most cases I think the capability is good
> >> enough) I'd rather not add that extra traffic (and potential battery
> >> life cost on mobile devices).
> >
> > To me the most common use case for APPEND is sent-mail saving.
> > Generally this will occur in one of two situations:
> >
> > 1.) Replying/Forwarding to an existing message. In these cases, it is
> > likely that at the time of sending that the client will still be in
> > the same mailbox - most people tend to write a message in one sitting
> > so they won't change their mailbox - and this mailbox will NOT be the
> > sent-mail mailbox.
> > 2.) Composing a New Message. The client IMAP connection may be in
> > either a selected or non-selected state depending on their previous
> > actions in the client UI, but odds are high that they are unlikely to
> > be in the Sent mailbox.
> >
> > In either of these cases it is going to be a MUCH less expensive
> > operation to grab the APPENDLIMIT with a STATUS(-like) call followed
> > by an APPEND rather than SELECTing the mailbox and then APPENDing.
> > Not only will the client code have to do the normal state
> > initalization of opening a mailbox, which probably isn't necessary
> > from a UI perspective since the user doesn't care about the
> > contents/status of the sent-mail mailbox, but this initialization
> > could involve other delays if the server is doing things like
> > on-demand new message tasks within that mailbox (e.g. header caching,
> > search indexing).
> >
> > TLDR: APPENDs to a sent mail mailbox are the most common real-world
> > APPEND action, and these APPENDs rarely occur when in selected state
> > within the sent mail mailbox.
>Ok, I don't have a strong preference one way or another, but I find 
>your argument convincing and I can live without APPENDLIMIT be 
>returned on SELECT.
> >> * The document does not state if the APPENDLIMIT response is a
> >> MUST/SHOULD/MAY.
> >> If it's a MAY, my server implementation won't send it, in which case
> >> why is it in the spec? If it's a SHOULD, I'll include a product
> >> option so admins can disable it. If it's a MUST, I object to
> >> advancing the proposal.
> >
> > Agree.  It can be argued that this would actually make things slightly
> > slower for the vast majority of clients, with no (or microscopic) gain
> > to APPENDLIMIT aware clients.
>Right.
>
>   [snip]
>
>
>_______________________________________________
>imapext mailing list
>imapext <at> ietf.org
>https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Valerio Valerio | 12 Mar 08:06 2015

NIL boundary in multipart emails

Hi All,

while chasing a bug in our IMAP implementation noticed that one server 
replies to a BODYSTRUCTURE fetch command with a structure containing NIL 
boundary for multipart emails, e.g:

SEND UID FETCH 36 (FLAGS UID INTERNALDATE RFC822.SIZE BODYSTRUCTURE 
RFC822.HEADER)
RECV: * 7 FETCH (FLAGS (\Unseen) UID 36 INTERNALDATE "12-Mar-2015 
09:25:30 +0300" RFC822.SIZE 18142 BODYSTRUCTURE (("text" "plain" 
("charset" "utf-8") NIL NIL "quoted-printable" 34433 0 NIL NIL NIL 
NIL)("text" "html" ("charset" "utf-8") NIL NIL "quoted-printable" 108403 
0 NIL NIL NIL NIL) "alternative" ("boundary" NIL)) RFC822.HEADER {2558}

I can gracefully handle this situation, but by my understanding of RFC 
2046[1], this is invalid, first the boundary does exist and is not empty 
and in case it was empty server should send something like "". Since 
this server always reply like that and is a big provider in 
Russia(mail.ru) I was wondering if I'm missing something here ?

Thanks in advance.

Best regards,

Valério

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jayantheesh S B | 10 Mar 22:08 2015

IMAP COMPRESS=DEFLATE Support

All,

 

I am facing an issue with IMAP COMPRESS=DEFLATE feature. After COMPRESS DEFLATE command,

deflate stream is opened and sent the NAMESPACE request to server.  Request is sent successfully, but response was not received.

 

After Socket read timeout, it’s coming out from the Read block. Currently I am using java.util.zip.* package for creating the deflate stream.

Please share if you face any similar issues, during the implementation.  Kindly throw some light on this issue.

 

Log Snippet:

03-10 17:42:31.482 18173 18182 D MailTransport: *** IMAP open demo.isode.com:143

 

03-10 17:42:32.072 18173 18182 D MailTransport: >>> 1 CAPABILITY

03-10 17:42:32.392 18173 18182 D Email   : <<< #null# ["CAPABILITY", "IMAP4rev1", "UIDPLUS", "LITERAL+", "UNSELECT", "NAMESPACE", "SORT", "BINARY", "MULTIAPPEND", "THREAD=ORDEREDSUBJECT", "THREAD=REFERENCES", "ESEARCH", "LIST-EXTENDED", "IDLE", "URLAUTH", "CATENATE", "CONDSTORE", "QRESYNC", "ENABLE", "STARTTLS", "ACL", "RIGHTS=kxet", "QUOTA", "COMPRESS=DEFLATE", "SASL-IR", "WITHIN", "CONTEXT=SEARCH", "SEARCHRES", "SPECIAL-USE", "MOVE", "AUTH=SCRAM-SHA-1", "AUTH=DIGEST-MD5", "AUTH=CRAM-MD5", "AUTH=PLAIN"]

03-10 17:42:32.472 18173 18182 D Email   : <<< #1# ["OK", "CAPABILITY Completed"]

 

03-10 17:42:32.492 18173 18182 D MailTransport: >>> 2 AUTHENTICATE DIGEST-MD5

……………………….

 

03-10 17:42:33.222 18173 18182 D MailTransport: >>> 3 COMPRESS DEFLATE

03-10 17:42:33.352 18173 18182 D Email   : <<< #3# ["OK", "Compression active"]

 

03-10 17:42:33.392 18173 18182 D MailTransport: >>> 4 NAMESPACE

03-10 17:42:33.412 18173 18182 D IMAPSocketOutputStream: RawBytes >>78 9C

03-10 17:42:33.422 18173 18182 D IMAPSocketOutputStream: RawBytes >>120

03-10 17:42:33.462 18173 18182 D IMAPSocketOutputStream: RawBytes >>-100

 

03-10 17:42:33.532 18173 18182 D ImapResponseParser: parseResponse

03-10 17:42:33.552 18173 18182 D IMAPSocketInputStream: read

 

Regards,

Jay

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Arnt Gulbrandsen | 3 Mar 19:46 2015
Picon

create-special-use

Hi,

do any servers implement that? If so, which?

Some Gmail-specific clients create an x-gm-label called Later. I don't see 
a way to do anything equivalent using create-special-use, am I overlooking 
anything?

Arnt

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Jayantheesh S B | 27 Feb 21:57 2015

The IMAP APPENDLIMIT Extension - version 04

Hi All,

 

Please find the next version (04) of the draft attached with review comments addressed.

 

Changes in this version:

1.       Append-limit-value changed from 32 bits to 64 bits unsigned number

 

Regards,

Jay

INTERNET-DRAFT                                           Jayantheesh S B 
Intended status: Standards Track                                 Samsung
Expires: August 2015                                Narendra Singh Bisht
                                                                 Samsung
                                                       February 27, 2015

                      The IMAP APPENDLIMIT Extension
                draft-jayantheesh-imap-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, SELECT/EXAMINE and LIST command.

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 August, 2015.

Copyright Notice

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

Jayantheesh & Narendra     Expires August, 2015               [Page 1]

Internet-Draft               IMAP APPENDLIMIT            February 2015

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1. Conventions and Terminology . . . . . . . . . .  . . . . .   2
   2. APPENDLIMIT Extension . . . . . . . . . . . . . . . . . . . . .  2
   3. Mailbox specific APPENDLIMIT . . . . . . . . . . . . . . . . . . 3
     3.1. SELECT response . . . . . . . . . . . . . . . . . . . . . .  4
     3.2. LIST response . . . . . . . . . . . . . . . . . . . . . . .  4
   4. APPEND response . . . . . . . . . . . . . . . . . . . . . . . .  5
   5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
    8.1 Normative References . . . . . . . . . . . . . . . . . . . . . 6
    8.2 Informative References . . . . . . . . . . . . . . . . . . . . 7
   9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . .  7
   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 RFC 2119.

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.

2. APPENDLIMIT Extension

An IMAP server that supports APPENDLIMIT advertises this by including
the word APPENDLIMIT in its capability list.  IMAP server shall publish
the supported mail upload size as part of CAPABILITY response.  The

Jayantheesh & Narendra     Expires August, 2015              [Page 2]

Internet-Draft               IMAP APPENDLIMIT           February 2015

advertised upload limit is common across the mailboxes, but client
can still issue SELECT/EXAMINE or LIST command to get the mailbox
specific upload limit set by the IMAP server.  In this case,
APPENDLIMIT value obtained as part of SELECT/EXAMINE or LIST command
takes precedence over the value returned as part of CAPABILITY
response.

The following example, demonstrates the APPENDLIMIT capability with
mailbox limit.

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

If APPENDLIMIT value is omitted in CAPABILITY response, then client
SHOULD issue SELECT/EXAMINE or LIST command to get the mailbox specific
limit set by the server.  New response code APPENDLIMIT is added to get
the mailbox specific limit.  Refer section 5 for response code syntax.

The following example demonstrates, its usage.

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

C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [APPENDLIMIT 257890] Maximum upload limit
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: t2 OK [READ-WRITE] SELECT completed

By looking at the upload size restriction set by the IMAP server, client
MUST not try to upload mail more than advertised limit in the APPEND
command. 

3. Mailbox specific APPENDLIMIT

IMAP server can still have mailbox specific APPENDLIMIT restriction,
which may not be advertised as part of CAPABILITY response.  In this
case, client can issue SELECT/EXAMINE command to get the per mailbox
specific limit set by the server.  Similarly, if client wish to know
the mailbox specific limit in authenticated state, can be done by
issuing the LIST command in combination with STATUS command.

Jayantheesh & Narendra     Expires August, 2015              [Page 3]

Internet-Draft               IMAP APPENDLIMIT           February 2015

3.1 SELECT response

Client can get the per mailbox append limit by issuing the SELECT/
EXAMINE command.  APPENDLIMIT size to this mailbox is obtained as part
of untagged OK response.  In this case, this APPENDLIMIT value will
supersede the value received as part of CAPABILITY response.  If no
per-mailbox APPENDLIMIT is specified for a folder, but the server did
specify a common APPENDLIMIT in the CAPABILITY response, then the
common APPENDLIMIT applies to that folder.

C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [APPENDLIMIT 257890] Maximum upload limit
S: [...]
S: t2 OK [READ-WRITE] SELECT completed

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

OK [APPENDLIMIT <n>] Maximum upload limit for this mailbox, in bytes.
                     Refer to section 5 for more information.  If this
                     is missing, the client can always honour the
                     value received as part of CAPABILITY response.

3.2 LIST response

IMAP client can get the mailbox specific APPENDLIMIT in authenticated
state, where it do not need to issue SELECT/EXAMINE command.  LIST
command in combination with STATUS command can be issued to get the per
mailbox specific APPENDLIMIT set by the server.  Refer RFC 5819 for the
usage of LIST command in combination with STATUS command.  Note that a
server implementing this extension, is syntactically compatible with
RFC 5819, however support for RFC 5258 or RFC 5819 is not required,
when implementing this 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.

New attribute APPENDLIMIT is added to get the limit set by the server
for this mailbox as part of STATUS command.  The STATUS response occurs
as a result of an STATUS command.  It returns the mailbox name that

Jayantheesh & Narendra     Expires August, 2015              [Page 4]

Internet-Draft               IMAP APPENDLIMIT           February 2015

matches the STATUS specification and the requested mailbox status
information.  IMAP server should 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.

Invoking STATUS command with APPENDLIMIT is also acceptable.  Below
example demonstrates, its usage.

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

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 RFC 4469 Section (4) for various
APPEND response codes and its handling.

Client can avoid use of LITERAL+, when maximum upload size
supported by the IMAP server is unknown. 

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" ["=" append-limit-value]
capability /= appendlimit-cap

appendlimit-respcode = "APPENDLIMIT" SP append-limit-value
resp-text-code /= appendlimit-respcode

append-limit-value = 1*DIGIT
                     ; Unsigned 64-bit integer
                     ; (0 <= n < 18,446,744,073,709,551,615)

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

A number indicating the fixed maximum message size in bytes that the
server will accept.  APPENDLIMIT=0 indicates the server SHALL not
Jayantheesh & Narendra     Expires August, 2015              [Page 5]

Internet-Draft               IMAP APPENDLIMIT           February 2015

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

It is believed that this extension doesn't add any new security
considerations that are not already present in the base IMAP
protocol [RFC3501].

7. IANA Considerations

The IANA is requested to add APPENDLIMIT to the IMAP4 Capabilities
Registry.  [[Note to RFC-editor: please remove the following before
publication: This registration should take place at the following
location: http://www.iana.org/assignments/imap4-capabilities]]

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", RFC 2119, 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

[RFC5322]  P. Resnick, Ed, "Internet Message Format", RFC 5322,
           Qualcomm Incorporated, October 2008

[RFC2088]  J. Myers, Carnegie Mellon, "IMAP4 non-synchronizing
           literals",  January 1997
		   
[RFC4469]  P. Resnick, "Internet Message Access Protocol (IMAP)
           CATENATE Extension",  April 2006
		   
[RFC5819]  A. Melnikov, T. Sirainen, "IMAP4 Extension for Returning
           STATUS Information in Extended LIST",  March 2010
		   
Jayantheesh & Narendra     Expires August, 2015               [Page 6]

Internet-Draft               IMAP APPENDLIMIT            February 2015

[RFC5258]  A. Melnikov, B. Leiba, "Internet Message Access Protocol
           version 4 - LIST Command Extensions",  March 2010
		   
8. 2 Informative References

The following documents describe related protocols:

[RFC2087]  Myers, J., "IMAP4 QUOTA extension", RFC 2087,
           January 1997

[RFC7377]  B. Leiba, A. Melnikov, "IMAP4 Multimailbox SEARCH
           Extension", RFC 7377, October 2014

9. Acknowledgement

TBD

10. Author's Address

Jayantheesh S B
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: jayantheesh.sb <at> gmail.com

Narendra Singh Bisht
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: narendrasingh.bisht <at> gmail.com

Jayantheesh & Narendra     Expires August, 2015               [Page 7]
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jayantheesh S B | 18 Feb 21:05 2015

IMAP Idle for Multiple folders

Dear All,

 

As part of IMAP IDLE connection (https://tools.ietf.org/html/rfc2177) any changes like EXISTS, EXPUNGE, FETCH to one particular mailbox can be pushed to IMAP client.

 

But in case, if IMAP client want to receive notification for multiple folders then multiple IMAP connection has to be opened.

 

Is there a way to receive updates for multiple folders in same IMAP connection ? Please share your thoughts.

Regards,

Jay

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jayantheesh S B | 5 Jan 18:50 2015

Re: The IMAP APPENDLIMIT Extension

Hi Pete,

Thanks for your review comments. 

Please find my comments inline. 

Regards,
Jay

-----Original Message-----
From: Pete Maclean [mailto:groups <at> maclean.com] 
Sent: Saturday, January 03, 2015 8:11 AM
To: Jayantheesh S B; 'imapext <at> ietf.org'
Subject: Re: [imapext] The IMAP APPENDLIMIT Extension

Jay,

I have not said anything on APPENDLIMIT before but, reading your latest draft now, there are a few things I
wonder about.  I don't think any of these necessarily requires any changes to the draft but some may merit
additional consideration.

In section 5 you make reference to "the server's fixed maximum mail upload size".  What is the intended scope
of said fixedness.  Should a client assume that a maximum upload size obtained in one session applies in a
later session?  I think it should not.  Hardware or other changes at the server could surely lead to a maximum
upload size changing over time.

[Jay] Upload size obtained using SELECT/EXAMINE always overrides the CAPABILITY response. So, maximum
upload size obtained in one session does not apply for another session.

How should a client behave if it obtains a maximum upload size for a given mailbox in a LIST command and then
later in the same session it does a SELECT/EXAMINE for the same mailbox that quotes a different maximum
upload size?  For that matter, is it valid for a server to return different maximum upload sizes in
CAPABILITY responses within a single session?  In cases where a maximum upload size is dependent on a
quota, it could make sense for these things to happen.

Surely it would be very valuable to include in this extension a means for a server to indicate that it does not
accept APPENDs at all.  For IMAP servers fronting email archives, it is entirely reasonable for APPENDs to
be unsupported.  In other cases, it seems reasonable for APPENDs to be disallowed for certain mailboxes
(as, for example, in a proxy situation or when a mailbox reaches maximum capacity).  An easy way to deal with
this would perhaps be to change the syntax to allow an append limit of 0 with the meaning, not that
zero-length messages may be APPENDed (something that my checks show that many servers disallow anyway),
but that APPENDs are not allowed period.  This could avoid a lot of trouble, I believe.

[Jay] This is the good idea. I will change the next version of the draft to accept the APPENDLIMIT=0,
indicates the server will not accept any APPEND command due to size restriction.

Pete Maclean

At 05:12 PM 12/19/2014, Jayantheesh S B wrote:
>Hi All,
>
>Please find the next version of the draft attached with all the review 
>comments addressed.
>
>If you have any comments/suggestions in the attached version, kindly share it.
>
>Regards,
>Jay
>
>_______________________________________________
>imapext mailing list
>imapext <at> ietf.org
>https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext


Gmane