Subject: Re: [imapext] IMAP message size limits

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 24 Jul 2012 12:02:36 +0000

------ Original Message ------
From: "Alexey Melnikov" <[email-masked]>
>Hi Adrien,
>
>On 24 Jul 2012, at 02:21, "Adrien W. de Croy" <[email-masked]> wrote:
>
>>------ Original Message ------
>>From: "Lyndon Nerenberg" <[email-masked]>
>>>On 2012-07-23, at 17:26 PM, Adrien W. de Croy wrote:
>>>
>>>
>>>>
>>>>In fact the 32 bit limit is only a comment in the BNF, I can't find it anywhere else.
>>>>
>>>
>>>
>>>Comments in the BNF are sometimes used to outline restrictions on the protocol. These 'comments' have equal standing with the BNF itself.
>>>
>>>32-bits is core to the protocol, and isn't going to change.
>>>

>>Forever is a long time.

>>Messages continue to get bigger and bigger.  Links get faster.  
>>People use mail for more things.

>>32 bits is not a requirement of the protocol itself.  Moses didn't 
>>come down from the mountain with a bit of stone that said "thou shalt 
>>not make emails larger than 4GB".

>>It was an implementation decision that polluted the protocol.  I'm 
>>sure 4GB seemed like an inconceivably enormous message size back in 
>>the early 80's.  It's still enormous, but not inconceivable now.
>
>Actually I believe it improved interoperability at the time. 

I can believe it.  I guess some people wanted to use 16 bit for some of 
these things at the time.

>>FWIW, we already support 64 bit sizes.  So if anyone sends a > 4GB 
>>message to a WinGate IMAP mailbox, it will go in, and the size will 
>>be reported correctly.  I guess the clients will barf on that if they 
>>don't support > 32 bit sizes.

>>So actually, it already did change.

>>What's the alternative you suggest?

>>a) we should for eternity reject any message > 4GB destined for IMAP?
>>b) advertise a CAPABILITY of 64BIT or something, and "hide" big 
>>messages from small clients?
>
>Do something like that. Use ENABLE 64BIT to let clients see all 
>messages.
>
>And I hope we are talking about message sizes (+ possibly quotas) and 
>nothing else at this time...

I can only really think of a use case for message sizes and quotas.  

  But creating another number type could be a pain in the neck.

Another idea may be to report size in a separate attribute if it's over 
4GB.

E.g. report something like

RFC822.SIZE 0 RFC822.SIZE64 5000000000

then "small" clients would still see the message, but only part of it 
(or none).

Hiding the message would be a pain, since you'd need to adjust msgnos

Adrien

>
>>c) make IMAP5 64 bit by default...
>>d) do nothing and wait.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Jul 2012 21:57:05 +0100

>>>> On 2012-07-23, at 17:26 PM, Adrien W. de Croy wrote:
 (snip)
>  
>> 
>>>  
>>> FWIW, we already support 64 bit sizes.  So if anyone sends a > 4GB message to a WinGate IMAP mailbox, it will go in, and the size will be reported correctly.  I guess the clients will barf on that if they don't support > 32 bit sizes.
>>>  
>>> b) advertise a CAPABILITY of 64BIT or something, and "hide" big messages from small clients?
>> 
>> Do something like that. Use ENABLE 64BIT to let clients see all messages.
>> 
>> And I hope we are talking about message sizes (+ possibly quotas) and nothing else at this time...
>  

I think extending existing "number" and "nz-number" would be easier. However the impact of the change still need to be studied, maybe changing some more specific ABNF productions would be better. We only want literal sizes and values returned in FETCH to change.

>  
> Another idea may be to report size in a separate attribute if it's over 4GB.
>  
> RFC822.SIZE 0

Probably better to return non 0 size.

> RFC822.SIZE64 5000000000
>  
> then "small" clients would still see the message, but only part of it (or none).

This might be Ok. But use of ENABLE would be required for the server to start sending these.

> Hiding the message would be a pain, since you'd need to adjust msgnos

Yes, that is true.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 24 Jul 2012 23:01:24 +0200

> This might be Ok. But use of ENABLE would be required for the server to

Why?

We've been through this in the context of EAI. Hide mail or do your best?

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Jul 2012 22:07:55 +0100

>> This might be Ok. But use of ENABLE would be required for the server to

Because IMAP servers are not supposed to send unsolicited FETCH items clients don't know how to parse.

> 
> We've been through this in the context of EAI. Hide mail or do your best

Well, maybe. It is not exactly the same case, the message is a valid RFC 5322 message, it is just long ;)