Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-21.txt

From: [email-masked]
Date: Mon, 23 Nov 2020 07:31:25 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF.

        Title           : Internet Message Access Protocol (IMAP) - Version 4rev2
        Authors         : Alexey Melnikov
                          Barry Leiba
	Filename        : draft-ietf-extra-imap4rev2-21.txt
	Pages           : 163
	Date            : 2020-11-23

Abstract:
   The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
   allows a client to access and manipulate electronic mail messages on
   a server.  IMAP4rev2 permits manipulation of mailboxes (remote
   message folders) in a way that is functionally equivalent to local
   folders.  IMAP4rev2 also provides the capability for an offline
   client to resynchronize with the server.

   IMAP4rev2 includes operations for creating, deleting, and renaming
   mailboxes, checking for new messages, permanently removing messages,
   setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing,
   searching, and selective fetching of message attributes, texts, and
   portions thereof.  Messages in IMAP4rev2 are accessed by the use of
   numbers.  These numbers are either message sequence numbers or unique
   identifiers.

   IMAP4rev2 does not specify a means of posting mail; this function is
   handled by a mail submission protocol such as the one specified in
   RFC 6409.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21
https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-21

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Nov 2020 15:39:26 +0000

> https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-21

This version adds support for 63bit body part and message sizes.

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 23 Nov 2020 17:45:26 +0200

> This version adds support for 63bit body part and message sizes.

Hiding large messages from rev1 sounds a bit bad. Better would be to replace the message with some template body, which could either explain that this message is too large for the client or simply be an empty body and let the user figure it out themselves.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 23 Nov 2020 17:05:18 +0100

Imo a server that supports r1 cannot support a maximum size larger 
than... 2G? 4G? Which should be plenty for the moment. Senders cannot 
trust receivers to accept even 100M today, so supporting twenty times 
that is fine for a while.

Practically speaking, all that r2 does is 
change the syntax, so that a too-large literal is too large instead of 
being a syntax error.

Arnt

---

From: Ken Murchison <[email-masked]>
Date: Mon, 23 Nov 2020 11:21:46 -0500

> Hiding large messages from rev1 sounds a bit bad. Better would be to replace the message with some template body, which could either explain that this message is too large for the client or simply…

Presumably a message that exceeds the 32-bit limit contains one or more 
attachments that pushes it over the limit.  Perhaps the server could 
synthesize a message for IMAPrev1 clients that replaces large 
attachments with message/external-body parts.

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 23 Nov 2020 18:36:00 +0200

On 23. Nov 2020, at 18.21, Ken Murchison <[email-masked]> wrote:
> Presumably a message that exceeds the 32-bit limit contains one or more attachments that pushes it over the limit.  Perhaps the server could synthesize a message for IMAPrev1 clients that replaces large attachments with message/external-body parts.

My suggestion would be to just leave this implementation-defined, rather than recommending anything specific.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Nov 2020 16:45:40 +0000

On 23/11/2020 16:36, Timo Sirainen wrote:

> On 23. Nov 2020, at 18.21, Ken Murchison <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
>>
>>> On 23. Nov 2020, at 17.39, Alexey Melnikov 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>> On 23/11/2020 15:31, [email-masked] 
>>>> <mailto:[email-masked]> wrote:
>>>>
>>>>> <https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/>
>>>>>
>>> Hiding large messages from rev1 sounds a bit bad. Better would be to 
>>> replace the message with some template body, which could either 
>>> explain that this message is too large for the client or simply be 
>>> an empty body and let the user figure it out themselves.
>>
>>
>> Presumably a message that exceeds the 32-bit limit contains one or 
>> more attachments that pushes it over the limit.  Perhaps the server 
>> could synthesize a message for IMAPrev1 clients that replaces large 
> My suggestion would be to just leave this implementation-defined, 
> rather than recommending anything specific.

Are there choices that we should advise against? Maybe message truncation?

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 25 Nov 2020 14:50:36 +0100

> Are there choices that we should advise against? Maybe message truncation?

IMO: "Note that the syntaxes for SMTP/LMTP, IMAP4rev1 and IMAP4rev2 all 
have different ranges for message size. Implementers are advised to 
restrict their software's suported range to conform to all relevant 
protocols, and to fail gracefully in case a message is too large."

(SMTP's limit is.... hm.... 10²⁰ bytes, or about 10⁵⁰⁰, or maybe ∞. Wow.)

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 25 Nov 2020 14:47:41 +0100

> On 23. Nov 2020, at 17.45, Alexey Melnikov <[email-masked]> wrote:
> 
>> On 23. Nov 2020, at 18.21, Ken Murchison <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>>> On 23. Nov 2020, at 17.39, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> On 23/11/2020 15:31, [email-masked] <mailto:[email-masked]> wrote:
>>>>> 
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ <https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/>
>>>>>> 
>>>>>> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21 <https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21>
>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21 <https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21>
>>>>>> 
>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-21 <https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-21>

I don't really have an opinion on this. I think even message truncation might be acceptable in some situations.