Re: The IMAP APPENDLIMIT Extension

Jay -

Where things are getting muddled for me, at least, is the possible 
conflation of per-mailbox policy based limits (which I suspect is a rare 
case) with Quota.

If a server has a rarely changing, policy based Append limit that 
applies the same to all mailboxes of the authenticated user, would an 
implementation that simply advertises the server's global limit via the 
new Capability be sufficient, or are changes expected to 
Select/Examine/Status/List responses in order to cover the pending quota 
exhaustion case?

- Stuart

On 2/19/15 3:55 PM, Jayantheesh S B wrote:
> Hi Michael,
>
> The intension of this draft to inform client about the supported APPENDLIMIT by the server beforehand to avoid any failure.
> Most of the time, in normal uses cases, if an attachment with huge size is appended, server rejects with error response.
> Form the client side, it's not aware of the server side supported limit. Please find the failure transaction snippet below.
>
>>>>   APPEND "Drafts" (\SEEN \DRAFT) {50287114}
> <<<  ["BAD", "parse error: request too long"]
>
>>>> APPEND inbox (\SEEN) {50287114}
> <<< BAD [ALERT] Message too large. http://support.google.com/mail/bin/answer.py?answer=8770
>
> That too when LITERAL+ is used, then it consumes more battery power and mobile data in the mobile environment.
> To avoid these kind of issues, this draft proposes two recommendation.
>
> 1.   Avoid using LITERAL+ for APPEND
> 2.   Advertise IMAP server supported APPENDLIMIT to client, so that client will not try appending the huge attachments.
>
> By implementing the first recommendation, issue will get solved halfway. But still client will not know the exact size supported by the server.
> IMAP Client has to do hit and trail to find out the exact size supported by the IMAP server.
>
> The second recommendation is similar to that of "SMTP Service Extension for Message Size Declaration" (https://tools.ietf.org/html/rfc1870).
> Supported APPENDLIMIT value is advertised as part of CAPABILITY response. In case, if IMAP server has mailbox specific limit restriction,
>   then it can be published as part of SELECT/EXAMINE, and LIST response.  This value is static in most of the cases, except the corner case,
>   where server is critically running short of memory to accommodate new emails.
>
> To summarize , APPENDLIMIT is a recommendation to the client about the APPEND size supported by the server, rather than the real physical
>   memory in server.  It gives an idea to the client that how much it can APPEND, rather than trying appending huge data and then fail.
>
> Regards,
> Jay
>
> -----Original Message-----
> From: Michael M Slusarz [mailto:[email protected]]
> Sent: Wednesday, February 18, 2015 4:04 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [imapext] The IMAP APPENDLIMIT Extension
>
> Quoting [email protected]:
>
>> If a client wants what appendlimit offers, it can just send an append
>> without literal+, right?
>
> I tend to agree that APPENDLIMIT that doesn't provide a precise size doesn't provide anything better than the current situation of simply not using literal+ for APPENDs.
>
> I think that if the append limit is static on a server and can be provided with the CAPABILITY string, that is a win.  And I have no issues with providing a client-side way of *proactively* requesting the limit for a mailbox via STATUS.
>
> But passively including this information in SELECT/EXAMINE responses is a poor decision if that data is not accurate.  As a client author, I would ignore APPENDLIMIT if it is not 100% accurate since there is a chance that I might actually be able to add the message notwithstanding the value provided.
>
> michael
>
> ___________________________________
> Michael Slusarz [[email protected]]
>
>
> _______________________________________________
> imapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext
>

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext