Subject: [imapext] [IMAP] APPEND Command Usage

From: Jayantheesh S B <[email-masked]>
Date: Wed, 29 Oct 2014 16:26:16 +0000

Dear All,

We are facing an issue while uploading (APPEND) a mail to a IMAP mailbox.

We see IMAP server rejects the APPEND command, if the mail size exceeds certain limit.

Email client is not aware of the maximum size supported by the IMAP server.

Is there any way for email client to know the IMAP server maximum supported size limit  ?

Please find the success and failure APPEND command transaction below.

Failure Transaction

>>> 290 APPEND "Drafts" (\SEEN \DRAFT) {50287114}

<<< #290# ["BAD", "parse error: request too long"]

Successful Transaction

>>> 90 APPEND "Drafts" (\SEEN \DRAFT) {42222}

<<< #+# [" "]

<<< #null# ["49", "EXISTS"]

<<< #90# ["OK", ["APPENDUID", "1", "5340"], "APPEND completed"]

Regards,
Jay

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 30 Oct 2014 16:58:01 +0100

> maximum supported size limit  ?

Sadly, there is no such way.

Arnt

---

From: Brandon Long <[email-masked]>
Date: Thu, 30 Oct 2014 14:50:06 -0700

Theoretically we could add it to the GETQUOTA command, though the resources
there expect a triple, but there is no real corresponding "current usage"
for the mail size limit.  It could just be NIL, though that probably
doesn't match the ABNF, so I guess 0 would be the next choice.

Other alternatives are in the CAPABILITY string or on SELECT/EXAMINE,
though neither is great.

Brandon

On Thu, Oct 30, 2014 at 8:58 AM, Arnt Gulbrandsen <[email-masked]>
wrote:

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 30 Oct 2014 22:53:08 +0100

Another alternative would be a new response code, like LIMIT, but 
specifically for messages and with a named size.

Arnt

---

From: Brandon Long <[email-masked]>
Date: Thu, 30 Oct 2014 15:01:46 -0700

Sure, though you have to hit the limit first in that case.  I'm fine with
that, especially since we disabled LITERAL+ so that we could respond to
APPEND directly with a NO without having to eat the overly large message or
drop the connection.

Brandon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 30 Oct 2014 23:28:24 +0100

Actually, it's legal to send response codes in an untagged OK, and not just 
during APPEND processing, so...

C: foo select inbox
S: ...
S: * OK [MESSAGESIZE 12341234] woo hoo
S: ...
S: foo OK done

Or even for LOGIN.

Arnt

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 30 Oct 2014 22:44:28 +0000

Hi Brandon.

Interesting approach dropping LITERAL+

how do you find in general clients deal with being bounced on APPEND 
instead of getting the command continuation request?

Adrien

------ Original Message ------
From: "Brandon Long" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 31/10/2014 11:01:46 a.m.
Subject: Re: [imapext] [IMAP] APPEND Command Usage

>Sure, though you have to hit the limit first in that case.  I'm fine 
>with that, especially since we disabled LITERAL+ so that we could 
>respond to APPEND directly with a NO without having to eat the overly 
>large message or drop the connection.
>
>Brandon
>
>On Thu, Oct 30, 2014 at 2:53 PM, Arnt Gulbrandsen 
><[email-masked]> wrote:

---

From: Brandon Long <[email-masked]>
Date: Thu, 30 Oct 2014 17:10:58 -0700

We haven't noticed any issues and no one has complained, and were having a
lot of issues before that.

Our problem is that we also have an upload bandwidth quota, and if we read
through the full 50MB upload before saying NO, the client would just keep
retrying indefinitely, and the user would get locked out for exceeding
quota.

Granted, now international searches in particular look really ugly and take
multiple round-trips, but they're less used, and now that we accept UTF8
directly, theoretically clients could upgrade to using that instead.

Brandon

On Thu, Oct 30, 2014 at 3:44 PM, Adrien de Croy <[email-masked]> wrote:

> On Thu, Oct 30, 2014 at 2:53 PM, Arnt Gulbrandsen <
> [email-masked]> wrote:
>

---

From: Brandon Long <[email-masked]>
Date: Thu, 30 Oct 2014 17:11:43 -0700

Sure, and I guess if folks have different values for different folders,
they could just use a "latest wins" approach or something.

Ie, APPEND doesn't require selected state.

Brandon

On Thu, Oct 30, 2014 at 3:28 PM, Arnt Gulbrandsen <[email-masked]>
wrote:

> Actually, it's legal to send response codes in an untagged OK, and not
> just during APPEND processing, so...
>
> C: foo select inbox
> S: ...

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 30 Oct 2014 21:22:09 -0400

Hi Arnt,

> S: * OK [MESSAGESIZE 12341234] woo hoo

It is a shame METADATA never got any tranaction because this would be a 
perfect case where it could be used.

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 31 Oct 2014 08:59:39 +0100

Well, it'll work on SELECT too. And yes, latest wins, just like UIDNEXT, 
UIDVALIDITY, PERMANENTFLAGS and whatnot.

I'll publish a short document when I get around to it.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 31 Oct 2014 11:01:06 +0000

If it is a system wide limit, I would rather advertise it in a new CAPABILITY response. But a response code is also a good idea.

Sent from my iPhone

> On 30 Oct 2014, at 22:01, Brandon Long <[email-masked]> wrote:
> 
> Sure, though you have to hit the limit first in that case.  I'm fine with that, especially since we disabled LITERAL+ so that we could respond to APPEND directly with a NO without having to eat the overly large message or drop the connection.
> 
> Brandon
> 
>> On Thu, Oct 30, 2014 at 2:53 PM, Arnt Gulbrandsen <[email-masked]> wrote:
>> Another alternative would be a new response code, like LIMIT, but specifically for messages and with a named size.
>> 
>> 
>> Arnt
>>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 31 Oct 2014 11:01:42 +0000

Hi,

> On 31 Oct 2014, at 00:10, Brandon Long <[email-masked]> wrote:
> 
> We haven't noticed any issues and no one has complained, and were having a lot of issues before that.

Well, my client doesn't support IMAP servers without LITERAL+ (which works with pretty much all of them) and the only common server that doesn't advertise it is Gmail. And then I discovered that you still support the syntax (which is great). So I had to add a hack to treat your Gmail capability as implicit indication of LITERAL+ support.

I wish you guys added a new capability advertising your APPEND limit or that you only don't support LITERAL+ in APPEND.
> 
> Our problem is that we also have an upload bandwidth quota, and if we read through the full 50MB upload before saying NO, the client would just keep retrying indefinitely, and the user would get locked out for exceeding quota.
> 
> Granted, now international searches in particular look really ugly and take multiple round-trips, but they're less used, and now that we accept UTF8 directly, theoretically clients could upgrade to using that instead.
> 
> Brandon
> 
> 
>> how do you find in general clients deal with being bounced on APPEND instead of getting the command continuation request?
>>  
>> Adrien
>>  
>>

---

From: Jayantheesh S B <[email-masked]>
Date: Sat, 1 Nov 2014 00:37:15 +0000

Hi All,

I have created a short document “IMAP APPENDLIMIT extension” , which proposes the CAPABILITY based solution for the APPEND command usage issue.

Proposed to add new capability APPENDLIMIT as part of the CAPABILITY response, which will be used to advertise the mail upload size restriction set by the IMAP server.

Kindly go through the same and share your comments.

Regards,
Jay
From: Alexey Melnikov [mailto:[email-masked]]
Sent: Friday, October 31, 2014 7:01 AM
To: Brandon Long
Cc: Arnt Gulbrandsen; [email-masked]
Subject: Re: [imapext] [IMAP] APPEND Command Usage

Sent from my iPhone

On 30 Oct 2014, at 22:01, Brandon Long <[email-masked]<mailto:[email-masked]>> wrote:
Sure, though you have to hit the limit first in that case.  I'm fine with that, especially since we disabled LITERAL+ so that we could respond to APPEND directly with a NO without having to eat the overly large message or drop the connection.

Brandon

On Thu, Oct 30, 2014 at 2:53 PM, Arnt Gulbrandsen <[email-masked]<mailto:[email-masked]>> wrote:
Another alternative would be a new response code, like LIMIT, but specifically for messages and with a named size.

Arnt

_______________________________________________
imapext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/imapext

---

From: Jan Kundrát <[email-masked]>
Date: Sat, 01 Nov 2014 02:07:30 +0100

On Saturday, 1 November 2014 01:37:15 CEST, Jayantheesh S B wrote:
> I have created a short document “IMAP APPENDLIMIT extension” , 
> which proposes the CAPABILITY based solution for the APPEND 
> command usage issue.

I tend to think that using QUOTA for this would be a bit more intuitive, 
but CAPABILITY will of cousre work as well. I don't think there's much 
real-world need for per-mailbox APPEND size limits.

> capability    =/ "APPENDLIMIT=" size-param
> 
> A decimal number indicating the fixed maximum message size in bytes
> that the server will accept. The syntax of the parameter is as
> follows, using the augmented BNF notation of [RFC 822]:
> 
> size-param = [1*DIGIT]

You could probably use a nz-number from RFC3501 here. Also, you put the 
grammar within square brackets which mean that this is an optional 
production, and therefore you allow a capability named just "APPENDLIMIT=". 
Is that what you mean? If so, how should a client interpret that?

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/