Re: Three kinds of IMAP extensions
Jayantheesh S B <[email protected]> Tue, 20 Oct 2015 15:18:44 +0000
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <[email protected]> |
Hi Adrien, Please find the response inline. Regards, Jay -----Original Message----- From: Adrien de Croy [mailto:[email protected]] Sent: Monday, October 19, 2015 5:18 PM To: Jayantheesh S B; [email protected]; [email protected]; 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). 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 protected]> To: "[email protected]" <[email protected]>; "[email protected]" <[email protected]>; "Alexey Melnikov" <[email protected]> Sent: 20/10/2015 5:15:45 a.m. Subject: Re: [imapext] Three kinds of IMAP extensions >Hi Arnt, > >Please find the response inline. > >Regards, >Jay >-----Original Message----- >From: imapext [mailto:[email protected]] On Behalf Of >[email protected] >Sent: Monday, October 19, 2015 11:45 AM >To: [email protected]; 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 > >_______________________________________________ >imapext mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/imapext > >_______________________________________________ >imapext mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/imapext _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext