Re: Three kinds of IMAP extensions

"Adrien de Croy" <[email protected]> Mon, 19 Oct 2015 21:18:06 +0000
Newsgroups gmane.ietf.imapext
Message-ID <em36067aa6-f258-4fb7-b3ad-7b94a9adf072@bodybag>
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 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