Subject: [imapext] Three kinds of IMAP extensions

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 17 Oct 2015 10:39:31 +0100

At risk of sounding like a broken record, we have three kinds of 
(non-proprietery) IMAP extensions:

1. Ones like CONDSTORE, which most readers know to be worthwhile, in 
CONDSTORE's case because so many people have felt the pain of FETCH 1:* 
FLAGS.

2. Ones like COMPRESS=DEFLATE, whose RFC says "implementing this is dead 
simple and you'll cut your traffic by two thirds" (no, that's not a direct 
quote).

3. Ones that go unused.

Please, IMAPAPND authors and anyone else, if your document doesn't solve a 
well-known pain point like CONDSTORE, make an attempt to argue like C=D. 
Make it seem as if the value of the implementation exceeds the effort to 
implement. And don't explain the value on this list, make it clear to the 
reader of the RFC itself. And doubleplusplease don't mistake a good 
intention for a valuable effect (as IMAPAPND does as far as I can see).

Arnt

---

From: Bron Gondwana <[email-masked]>
Date: Sun, 18 Oct 2015 21:26:51 +1100

On Sat, Oct 17, 2015, at 20:39, Arnt Gulbrandsen wrote:
> At risk of sounding like a broken record, we have three kinds of (non-
> proprietery) IMAP extensions:
>
>    CONDSTORE's case because so many people have felt the pain of FETCH
>    1:* FLAGS.
>
> 2. Ones like COMPRESS=DEFLATE, whose RFC says "implementing this is
>    dead simple and you'll cut your traffic by two thirds" (no, that's
>    not a direct quote).
>
> 3. Ones that go unused.
>
> Please, IMAPAPND authors and anyone else, if your document doesn't
> solve a well-known pain point like CONDSTORE, make an attempt to argue
> like C=D. Make it seem as if the value of the implementation exceeds
> the effort to implement. And don't explain the value on this list,
> make it clear to the reader of the RFC itself. And doubleplusplease
> don't mistake a good intention for a valuable effect (as IMAPAPND does
> as far as I can see).

+1, despite my ideas of suggestions like LIST-RETURN-MYRIGHTS and LIST-RETURN-METADATA, which are probably not such big pain points that people care.

The main things that I think have proven value that need to be RFCed soon are THRID / MSGID (the main point of debate is whether to mandate that they are exactly compatible with GMail's 63 bit integer format, or whether the are more general opaque blobs a-la UIDL from pop3)

And also some form of uniqueid support for folder, so you can detect them after they've been moved, though if you have MSGID and it's really immutable, that becomes heaps less bad, because you can just fetch all the contents of the new folder (FETCH 1:* (UID FLAGS MSGID MODSEQ)) and you've got everything you need - just incref the MSGID records before you decref them for the folder which went away. 

Some form of cross folder sort/search would probably be popular too.  The fastmail XCONVMULTISORT is probably not quite the right interface, but it's not totally awful either.

Bron.

-- 
  Bron Gondwana
  [email-masked]

---

From: Bron Gondwana <[email-masked]>
Date: Sun, 18 Oct 2015 21:38:01 +1100

> +1, despite my ideas of suggestions like LIST-RETURN-MYRIGHTS and LIST-RETURN-METADATA, which are probably not such big pain points that people care.

Looks like this btw:

. LIST "" * RETURN (MYRIGHTS METADATA ("/shared/vendor/cmu/cyrus-imapd/uniqueid"))
* LIST (\HasChildren) "." INBOX
* MYRIGHTS INBOX lrswipkxtecdn
* METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/uniqueid" "567d9ea54215e1e9")
* LIST (\HasNoChildren) "." INBOX.AICSA
* MYRIGHTS INBOX.AICSA lrswipkxtecdn
* METADATA INBOX.AICSA ("/shared/vendor/cmu/cyrus-imapd/uniqueid" "5598faa4-2e37-4f70-8954-48b525b4fc40")
* LIST (\HasChildren \Archive) "." INBOX.Archive
* MYRIGHTS INBOX.Archive lrswipkxtecdn
* METADATA INBOX.Archive ("/shared/vendor/cmu/cyrus-imapd/uniqueid" "210306ee-5833-456b-bede-6d04757128b3")
* LIST (\HasNoChildren) "." INBOX.Archive.2003
* MYRIGHTS INBOX.Archive.2003 lrswipkxtecdn
* METADATA INBOX.Archive.2003 ("/shared/vendor/cmu/cyrus-imapd/uniqueid" "be9d732f-087a-49d6-85ca-3e5961824c49")
* LIST (\HasNoChildren) "." INBOX.Archive.2004
* MYRIGHTS INBOX.Archive.2004 lrswipkxtecdn
* METADATA INBOX.Archive.2004 ("/shared/vendor/cmu/cyrus-imapd/uniqueid" "88471efa-f778-44ab-95f7-3197cfefddf5")

[...]

. list (METADATA (DEPTH infinity)) "" INBOX RETURN (METADATA ("/shared"))
* LIST (\HasChildren) "." INBOX
* METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/uniqueid" "567d9ea54215e1e9" "/shared/vendor/cmu/cyrus-imapd/synccrcs" "1618741296 4185168140" "/shared/vendor/cmu/cyrus-imapd/squat" NIL "/shared/vendor/cmu/cyrus-imapd/size" "589174618" "/shared/vendor/cmu/cyrus-imapd/sieve" NIL "/shared/vendor/cmu/cyrus-imapd/sharedseen" "false" "/shared/vendor/cmu/cyrus-imapd/pop3showafter" NIL "/shared/vendor/cmu/cyrus-imapd/pop3newuidl" "true" "/shared/vendor/cmu/cyrus-imapd/partition" "default" "/shared/vendor/cmu/cyrus-imapd/news2mail" NIL "/shared/vendor/cmu/cyrus-imapd/lastupdate" "18-Oct-2015 05:34:20 -0400" "/shared/vendor/cmu/cyrus-imapd/lastpop" "18-Sep-2014 20:49:24 -0400" "/shared/vendor/cmu/cyrus-imapd/expire" NIL "/shared/vendor/cmu/cyrus-imapd/duplicatedeliver" "false" "/shared/vendor/cmu/cyrus-imapd/annotsize" "837079" "/shared/thread" NIL "/shared/specialuse" NIL "/shared/sort" NIL "/shared/comment" NIL "/shared/checkperiod" NIL "/shared/check" NIL "/shared" NIL)
. OK Completed (0.000 secs 69 calls)

-- 
  Bron Gondwana
  [email-masked]

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 18 Oct 2015 20:59:12 +0000

I agree

we need to take into account the cost also of complications to other 
extensions.

At the moment for us appendlimit looks to have negative value overall, 
and we don't plan to implement.

Adrien

------ Original Message ------
From: "Arnt Gulbrandsen" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 17/10/2015 10:39:31 p.m.
Subject: [imapext] Three kinds of IMAP extensions

>dead simple and you'll cut your traffic by two thirds" (no, that's not 
>a direct quote).
>
>3. Ones that go unused.
>
>the effort to implement. And don't explain the value on this list, make 
>it clear to the reader of the RFC itself. And doubleplusplease don't 
>mistake a good intention for a valuable effect (as IMAPAPND does as far 
>as I can see).
>
>Arnt
>
>_______________________________________________
>imapext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/imapext

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 18 Oct 2015 22:30:09 +0100

Hi Bron,

> On 18 Oct 2015, at 11:38, Bron Gondwana <[email-masked]> wrote:
> 

Anything that avoids extra rountrips on client start is a good thing on my book. In our client we prefer to issue a single LIST with all options needed. So I am in favour of documenting this.

---

From: Stu Brandt <[email-masked]>
Date: Sun, 18 Oct 2015 19:54:50 -0400

To me, the value of APPENDLIMIT is clear -- It provides a way for a 
server to advertise its maximum upload size. Without it, a client is 
left to implement a try-and-see approach to uploading data, often to the 
detriment of the user, his/her mobile data plan, and the server's 
resources. It's the IMAP equivalent of today's ESTMP servers returning...
   250-SIZE [size]
...in response to EHLO

I'm curious if removal of section 3, cleanup of section 2 to remove 
handling in the per-mailbox limits case, and removal of the 3rd 
paragraph of section 4 would reduce the complications negative value 
described.

I'd hate to see this go nowhere because of its attempt to solve for 
*both* majority and minority cases.

- Stuart

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 19 Oct 2015 00:02:12 +0000

understood, although the situation for SMTP is entirely different.

With IMAP you're dealing with authenticated / trusted users.  We've had 
requests about quota, but no request to limit an individual message 
size.

Also APPEND is hardly ever used - only to copy to sent folder after you 
already submitted with SMTP (drafts folder doesn't really count does 
it?).  It would be better to solve the requirement to transmit the 
message twice in the first place (e.g. SUBMIT command).

It does not address the problem of what happens when a message is 
appended to an IMAP mailbox by something other than IMAP APPEND (e.g. 
the much more usual case, when the message came in by SMTP and is placed 
in the inbox).  Or is this intended to be a different case?  In which 
case how do we explain all this to server admins, which didn't even ask 
for it?  If someone sets the value too low they just create problems.  
Is there really that much pain associated with this?

Adrien

------ Original Message ------
From: "Stu Brandt" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 19/10/2015 12:54:50 p.m.
Subject: Re: [imapext] Three kinds of IMAP extensions

>left to implement a try-and-see approach to uploading data, often to 
>the detriment of the user, his/her mobile data plan, and the server's 
>>>not

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 Oct 2015 08:52:52 +0100

Hi Adrien,

> On 19 Oct 2015, at 01:02, Adrien de Croy <[email-masked]> wrote:
> 
> 
> With IMAP you're dealing with authenticated / trusted users.  We've had requests about quota, but no request to limit an individual message size.
> 
> Also APPEND is hardly ever used -

It is used less frequently than FETCH, but I generally disagree with this statement.

> only to copy to sent folder after you already submitted with SMTP (drafts folder doesn't really count does it?

Oh yes, it does count a lot. Look at what Thunderbird is doing. Also automatic saving of Notes in iOS.
> ).  It would be better to solve the requirement to transmit the message twice in the first place (e.g. SUBMIT command).
> 
> It does not address the problem of what happens when a message is appended to an IMAP mailbox by something other than IMAP APPEND (e.g. the much more usual case, when the message came in by SMTP and is placed in the inbox).  Or is this intended to be a different case?

It is different. It can frequently be controlled by the same setting, if the mailstore also implements LMTP or SMTP.

> In which case how do we explain all this to server admins, which didn't even ask for it?  If someone sets the value too low they just create problems.  Is there really that much pain associated with this?

Yes, especially for big providers.
>> To me, the value of APPENDLIMIT is clear -- It provides a way for a server to advertise its maximum upload size. Without it, a client is left to implement a try-and-see approach to uploading data, often to the detriment of the user, his/her mobile data plan, and the server's resources. It's the IMAP equivalent of today's ESTMP servers returning...
>>  250-SIZE [size]
>> ...in response to EHLO
>> 
>> I'm curious if removal of section 3, cleanup of section 2 to remove handling in the per-mailbox limits case, and removal of the 3rd paragraph of section 4 would reduce the complications negative value described.
>> 
>> I'd hate to see this go nowhere because of its attempt to solve for *both* majority and minority cases.
>> 
>> - Stuart
>>

---

From: [email-masked]
Date: Mon, 19 Oct 2015 17:44:56 +0200

The drafts folder does not count because nothing appended there is big 
enough to care about this extension.

The other folders... suppose you 
are an iphone client, and you are to send mail, and it is big and you 
care about that. What do you do, upload twice, once to port 587 
checking its limit and once to IMAP checking its limit? Or do you 
upload just to 587 and bcc yourself?

This extension must be very 
simple to understand and implement if it is to be worthwhile against 
such questions. I have no idea whether even the simplest is simple 
enough.

Arnt

---

From: Jayantheesh S B <[email-masked]>
Date: Mon, 19 Oct 2015 16:15:45 +0000

Hi Arnt,

Please find the response inline. 

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 19, 2015 11:45 AM
To: [email-masked]; Alexey Melnikov
Subject: Re: [imapext] Three kinds of IMAP extensions

The drafts folder does not count because nothing appended there is big enough to care about this extension.
[Jay] On a mobile client it is very easy and frequent to attach a video to a mail and save. 
We, as a mobile client, have observed many instances where user attach a big files (video most of the time) and save the mail to their Drafts folder.
In fact, this was our primary motive behind this proposal.
 
The other folders... suppose you
are an iphone client, and you are to send mail, and it is big and you care about that. What do you do, upload twice, once to port 587 checking its limit and once to IMAP checking its limit? Or do you upload just to 587 and bcc yourself?
[Jay]If I BCC myself, it will come to my Inbox. People expect it in their Sent folder.  

This extension must be very
simple to understand and implement if it is to be worthwhile against such questions. I have no idea whether even the simplest is simple enough.
[Jay] I feel that this extension solves the over data usage problem, especially in a mobile environment.
Arnt

---

From: Stu Brandt <[email-masked]>
Date: Mon, 19 Oct 2015 12:33:20 -0400

> enough to care about this extension.

Anything with photos or videos or other rich media/files in it runs the 
risk of being too large. Clients are increasingly doing incremental 
save-to-draft as users compose messages, so whatever the user composes 
ends up "in the cloud" within a few minutes.

>
> The other folders... suppose you are an iphone client, and you are to
> send mail, and it is big and you care about that. What do you do, upload
> twice, once to port 587 checking its limit and once to IMAP checking its
> limit? Or do you upload just to 587 and bcc yourself?

This is a different problem than what is being addressed by the draft, 
though I agree it's one that should be tackled by the group.

Somewhere in amongst SMTP BURL (rfc4468), IMAP Submit 
(https://www.ietf.org/archive/id/draft-kundrat-imap-submit-02.txt), and 
IMAP Catenate (rfc4469) seems to be some good concepts that will help 
address this other problem.

>
> This extension must be very simple to understand and implement if it is
> to be worthwhile against such questions. I have no idea whether even the
> simplest is simple enough.

For server dev, I'd think the simplest is to add 
"APPENDLIMIT=<your-servers-appendsize-limit>" where 
your-servers-appendsize-limit ideally comes from some existent limit 
configured in your server. This is what we implemented.

For client dev, I'd think the simplest is to look for "APPENDLIMIT=" 
capability and steer users away from trying to do operations that would 
require appending oversized messages -- "Your draft/note is too large to 
save" or "Sorry, that message is too large to copy from AccountA to 
AccountB. AccountB only accepts messages less than <appendlimit> bytes."

Perhaps I'm oversimplifying, though :)

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 19 Oct 2015 21:18:06 +0000

Hi Jay

in your experience is the limit based usually on a user's remaining 
quota, or some other administrative limit in the IMAP server?

Dealing with issues close to the remainder of a user's quota is very 
difficult, as at any moment a message can be put in their inbox which 
puts them over quota.  To get around race conditions you'd need to 
reserve space in the mailbox prior to appending.

If the other (some limit on APPEND size in the server) then does this 
interact with CATENATE?  I'm trying to get an understanding of what 
server operators are even trying to achieve by putting such limits in 
(other than increased support desk calls).

Happy to be wrong about all of this.

I guess it sounds like we should all be implementing CATENATE, and I 
personally am a big fan of SUBMIT over the alternative in LEMONADE.

In many cases BURL etc doesn't work.  Many users use completely 
different providers for IMAP vs SMTP.  There's no way for an SMTP server 
to know a priori whether to advertise support for BURL if it doesn't 
know if the IMAP server (which it doesn't know about yet) supports the 
necessary extensions to allow it.  SUBMIT is so much simpler IMO.  I 
would be very keen to progress Jan's SUBMIT draft.

Adrien

------ Original Message ------
From: "Jayantheesh S B" <[email-masked]>
To: "[email-masked]" <[email-masked]>; 
"[email-masked]" <[email-masked]>; "Alexey Melnikov" 
<[email-masked]>
Sent: 20/10/2015 5:15:45 a.m.
Subject: Re: [imapext] Three kinds of IMAP extensions

>We, as a mobile client, have observed many instances where user attach 
>a big files (video most of the time) and save the mail to their Drafts 
>folder.

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 19 Oct 2015 21:23:28 +0000

------ Original Message ------

>require appending oversized messages -- "Your draft/note is too large 
>to save" or "Sorry, that message is too large to copy from AccountA to 

I think the UX for this needs to be thought through a bit more.

I'm pretty sure if I had just been working on a huge email with 
attachments etc, and at the time I tried to save it it told me it was 
too big, I'd be pretty unhappy about it.  Substitute "your draft/note is 
too large to save" with "your provider sucks, get a new one".

Is the problem with me, or is the problem with the person that set the 
(IMO) too-small limit?  And what are they really trying to achieve?  
Keep my disk-usage down?  I could save a million tiny messages but not 
one big one?  It doesn't make much sense to me to limit this.

Adrien

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 20 Oct 2015 07:13:06 +0100

Stu Brandt writes:
> Anything with photos or videos or other rich media/files in it 
> runs the risk of being too large. Clients are increasingly doing 
> incremental save-to-draft as users compose messages, so whatever 
> the user composes ends up "in the cloud" within a few minutes.

Consider that.

Suppose you write a mail reader and want to save drafts every two minutes 
and support IMAPAPND. So you write a function:

  1. If the server supports IMAPAPND, and the draft message including
     attachments is within the mailbox' size limit, write it.
  2. Otherwise write the draft to the mailbox, but with references instead
     of the attachments. Perhaps a header field called 
"X-Myclient-Attachment:
     <local file name here>"

IMAPAPND has a limit, so you have to write step 2. The question you now 
have to consider is: why value does step 1 give you?

It gets worse. Suppose that your mail reader is on a mobile device with 
both WLAN and mobile data, and that in your target market many people may 
per gigabyte for mobile data, and that sending costs no money but eats the 
battery. So someone on your team suggests the following change:

  1. If on WLAN, set a high limit for how big messages can be.
  2. If on mobile data, set a lower limit.
  3. If server supports IMAPAPND, use its limit instead.
  4. If the draft message including attachments is within the mailbox' size
     limit, write it.
  5. Otherwise write the draft to the mailbox, but with references instead
     of the attachments. Perhaps a header field called 
"X-Myclient-Attachment:
     <local file name here>"

A third member asks: Why don't se skip step 3? What value does IMAPAPND 
bring us? And it's a really good question. You can change step 3 to be 
conditional, but the question remains.

IMAPAPND has to be simple enough to survive discussion of whether 
implementing and testing step 3 takes too much time.

> your-servers-appendsize-limit ideally comes from some existent 
> limit configured in your server. This is what we implemented.
>
> For client dev, I'd think the simplest is to look for 
> "APPENDLIMIT=" capability and steer users away from trying to do 
> operations that would require appending oversized messages -- 
> "Your draft/note is too large to save" or "Sorry, that message 
> is too large to copy from AccountA to AccountB. AccountB only 
> accepts messages less than <appendlimit> bytes."
>

I think you may be simplifying enough, but I'm not sure.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 20 Oct 2015 07:17:10 +0100

I typoed:
> It gets worse. Suppose that your mail reader is on a mobile 
> device with both WLAN and mobile data, and that in your target 
> market many people may per gigabyte for mobile data, and that 
> sending costs no money but eats the battery. So someone on your 
> team suggests the following change:
>

The test in step 4 should be "is within the selected limit". Sorry.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 20 Oct 2015 09:14:51 +0100

Jayantheesh S B writes:
> We, as a mobile client, have observed many instances where user 
> attach a big files (video most of the time) and save the mail to 
> their Drafts folder.

So what's the proper limit to avoid this, then? Since this limit is set at 
the server, it applies both to the battery-powered phone whose owner pays 
per byte when on mobile data, and for the mains-powered chromebook with a 
gigabit-plus 801.11ac Wave2 connection.

For clients who are willing to implement something to limit data usage, it 
sounds easier to add a limit based on the power/connection status than on a 
server configuration. For clients who aren't willing it really doesn't 
matter.

Arnt

---

From: Jayantheesh S B <[email-masked]>
Date: Tue, 20 Oct 2015 15:11:45 +0000

Hi Arnt,

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Arnt Gulbrandsen
Sent: Tuesday, October 20, 2015 4:15 AM
To: [email-masked]
Subject: Re: [imapext] Three kinds of IMAP extensions

> In fact, this was our primary motive behind this proposal.

So what's the proper limit to avoid this, then? Since this limit is set at the server, it applies both to the battery-powered phone whose owner pays per byte when on mobile data, and for the mains-powered chromebook with a gigabit-plus 801.11ac Wave2 connection.

For clients who are willing to implement something to limit data usage, it sounds easier to add a limit based on the power/connection status than on a server configuration. For clients who aren't willing it really doesn't matter.

[Jay] I feel that having a client side prevention check is not a better solution. It's not just about the mobile device's resources, here we are considering the server side resources too.
According to your input, we can even have a similar argument for ESMTP SIZE extension, where clients are not allowed to exceed a certain size irrespective of mobile or desktop environment.

Also if every client will add a limit of its own (based on its proprietary solution), it might not be a uniform behavior. 
For clients who are not willing to implement APPENDLIMIT, it's up to them to have their own solution. 

Arnt

---

From: Jayantheesh S B <[email-masked]>
Date: Tue, 20 Oct 2015 15:18:44 +0000

Hi Adrien,

Regards,
Jay
-----Original Message-----
From: Adrien de Croy [mailto:[email-masked]] 
Sent: Monday, October 19, 2015 5:18 PM
To: Jayantheesh S B; [email-masked]; [email-masked]; Alexey Melnikov
Subject: Re: [imapext] Three kinds of IMAP extensions

Hi Jay

in your experience is the limit based usually on a user's remaining quota, or some other administrative limit in the IMAP server?
[Jay] Limit is based on the administrative limit in the IMAP server. It's similar to ESMTP SIZE parameter.  
It is more like a guideline rather than a precise limit.
I feel that server doesn't have to do intensive calculation to get this value.

Dealing with issues close to the remainder of a user's quota is very difficult, as at any moment a message can be put in their inbox which puts them over quota.  To get around race conditions you'd need to reserve space in the mailbox prior to appending.

If the other (some limit on APPEND size in the server) then does this interact with CATENATE?  I'm trying to get an understanding of what server operators are even trying to achieve by putting such limits in (other than increased support desk calls).

I guess it sounds like we should all be implementing CATENATE, and I personally am a big fan of SUBMIT over the alternative in LEMONADE.

In many cases BURL etc doesn't work.  Many users use completely different providers for IMAP vs SMTP.  There's no way for an SMTP server to know a priori whether to advertise support for BURL if it doesn't know if the IMAP server (which it doesn't know about yet) supports the necessary extensions to allow it.  SUBMIT is so much simpler IMO.  I would be very keen to progress Jan's SUBMIT draft.

Adrien

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 20 Oct 2015 20:53:19 +0100

Jayantheesh S B writes:
> [Jay] I feel that having a client side prevention check is not 
> a better solution. It's not just about the mobile device's 
> resources, here we are considering the server side resources 
> too.

So you mean that APPENDing one large .zip file containing ten .mp3 files 
consumes more server resources than ten messages, each with one .mp3 file, 
and that the difference matters? That seems strange, can you elaborate?

Arnt

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 20 Oct 2015 20:26:01 +0000

------ Original Message ------

>
>[Jay] I feel that having a client side prevention check is not a better 
>solution. It's not just about the mobile device's resources, here we 
>are considering the server side resources too.
>According to your input, we can even have a similar argument for ESMTP 
>SIZE extension, where clients are not allowed to exceed a certain size 
>irrespective of mobile or desktop environment.
>
>
The SMTP argument is interesting.  In my experience, the size limit on 
SMTP is a nett negative.  Due to the nature of SMTP relaying, you can 
get a bounce at any stage in a delivery path due to a local configured 
max size being set too low.

For our mail, we don't even enforce a limit on incoming from untrusted 
sources except for a very few addresses which are processed by other 
systems which do have (unfortunately) limits.  Bouncing large mails only 
ever causes us (and our customers) pain and denies legitimate mail 
causing everyone extra work.  Spam just isn't that big.

Our real limits are set only by the amount of free disk space.  We don't 
care if people use their quota in 1 message or 1M.

And in IMAP it's an even narrower case. You're dealing with 
authenticated clients only, these are people with whom there is a 
pre-existing relationship.

Also the protocol itself limits message size to 32bits.  4GB is getting 
smaller all the time.

Last time I raised that particular issue the only response I got was 
that people shouldn't send such large mails, but that train is still 
approaching us stuck in our tunnel. Our server actually uses 64bit 
unsigned and generates numeric strings accordingly, client authors would 
be well advised to make the move to 64 bit sooner rather than later.

Adrien

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 22 Oct 2015 14:04:02 +0100

Narendra Bisht writes:
> What we mean here, essentially, is that having one limit at 
> server side is better than having the different clients having 
> different limits.

Hm.

I'm sitting in my office now, where there's a misconfiguration on one of 
the upstream connections, and because of that the internet connection is 
slower than it should be. I could get it fixed if I were to pick up the 
phone and spend some time listening to "your call is important, please hold 
the line". But I don't bother phoning, because I already have so much 
bandwidth that more doesn't matter.

Two months ago I was on a farm in southern Italy on vacation, reading mail 
on my phone. It was very nice, but the connection wasn't too fast and I 
paid per byte.

Can you explain to me as a user why it is better if two email readers 
behave in the same way regarding bandwidth?

> The motive is pretty simple and clear. We want to have a limit 
> that can act like a guideline for the client, so that the client 
> get rid of try-and-fail.

If you go back to the first message in this thread, you'll find the 
description of the three kinds of extensions. Consider the motive you just 
mentioned.

This document and its motive, is this like CONDSTORE? Lots of people 
understand it and think that it's effective at solving a problem they have?

Or is it like C=D? Implementing the spec is simple and the document 
explains the benefit?

I think neither, which leaves the third possibility: It will not be 
implemented.

> We understand that this might not be a very regular thing, but 
> it might not be a rare thing either.

Right, and the problem is solvable. It's just that your document doesn't 
explain what the problem is, why your solution works at all, or why it 
works well enough to be worth implementing. Because it doesn't, I think it 
will go unimplemented, and that is a problem. We already have many 
unimplemented IMAP extensions.

Arnt

---

From: Jayantheesh S B <[email-masked]>
Date: Fri, 23 Oct 2015 22:17:39 +0000

Hi Arnt,

There are few servers who has shown interest in implementing this draft.
So, I strongly feel, it won't get unimplemented.
 
The "Introduction" part of the draft conveys the problem pretty clearly.
Over last few months it has been reviewed through multiple iterations and review comments have been addressed.

We as a mobile client has faced this problem quite often.

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Arnt Gulbrandsen
Sent: Thursday, October 22, 2015 9:04 AM
To: [email-masked]
Subject: Re: [imapext] Three kinds of IMAP extensions

Narendra Bisht writes:
> What we mean here, essentially, is that having one limit at server 
> side is better than having the different clients having different 
> limits.

Hm.

I'm sitting in my office now, where there's a misconfiguration on one of the upstream connections, and because of that the internet connection is slower than it should be. I could get it fixed if I were to pick up the phone and spend some time listening to "your call is important, please hold the line". But I don't bother phoning, because I already have so much bandwidth that more doesn't matter.

Two months ago I was on a farm in southern Italy on vacation, reading mail on my phone. It was very nice, but the connection wasn't too fast and I paid per byte.

Can you explain to me as a user why it is better if two email readers behave in the same way regarding bandwidth?

> The motive is pretty simple and clear. We want to have a limit that 
> can act like a guideline for the client, so that the client get rid of 
> try-and-fail.

If you go back to the first message in this thread, you'll find the description of the three kinds of extensions. Consider the motive you just mentioned.

This document and its motive, is this like CONDSTORE? Lots of people understand it and think that it's effective at solving a problem they have?

Or is it like C=D? Implementing the spec is simple and the document explains the benefit?

I think neither, which leaves the third possibility: It will not be implemented.

> We understand that this might not be a very regular thing, but it 
> might not be a rare thing either.

Right, and the problem is solvable. It's just that your document doesn't explain what the problem is, why your solution works at all, or why it works well enough to be worth implementing. Because it doesn't, I think it will go unimplemented, and that is a problem. We already have many unimplemented IMAP extensions.

Arnt

---

From: Narendra Bisht <[email-masked]>
Date: Wed, 21 Oct 2015 20:50:37 +0000

What we mean here, essentially, is that having one limit at server side is better than having the different clients having different limits.

The motive is pretty simple and clear. We want to have a limit that can act like a guideline for the client, so that the client get rid of try-and-fail.

We understand that this might not be a very regular thing, but it might not be a rare thing either.

Thanks & Regards
- Naren

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]] 
Sent: Tuesday, October 20, 2015 3:53 PM
To: [email-masked]
Subject: Re: [imapext] Three kinds of IMAP extensions

Jayantheesh S B writes:
> [Jay] I feel that having a client side prevention check is not a 
> better solution. It's not just about the mobile device's resources, 
> here we are considering the server side resources too.

So you mean that APPENDing one large .zip file containing ten .mp3 files consumes more server resources than ten messages, each with one .mp3 file, and that the difference matters? That seems strange, can you elaborate?

Arnt