Subject: Re: [imapext] The IMAP APPENDLIMIT Extension

From: Pete Maclean <[email-masked]>
Date: Sat, 03 Jan 2015 08:11:00 -0500

Jay,

I have not said anything on APPENDLIMIT before but, reading your 
latest draft now, there are a few things I wonder about.  I don't 
think any of these necessarily requires any changes to the draft but 
some may merit additional consideration.

In section 5 you make reference to "the server's fixed maximum mail 
upload size".  What is the intended scope of said fixedness.  Should 
a client assume that a maximum upload size obtained in one session 
applies in a later session?  I think it should not.  Hardware or 
other changes at the server could surely lead to a maximum upload 
size changing over time.

How should a client behave if it obtains a maximum upload size for a 
given mailbox in a LIST command and then later in the same session it 
does a SELECT/EXAMINE for the same mailbox that quotes a different 
maximum upload size?  For that matter, is it valid for a server to 
return different maximum upload sizes in CAPABILITY responses within 
a single session?  In cases where a maximum upload size is dependent 
on a quota, it could make sense for these things to happen.

Surely it would be very valuable to include in this extension a means 
for a server to indicate that it does not accept APPENDs at all.  For 
IMAP servers fronting email archives, it is entirely reasonable for 
APPENDs to be unsupported.  In other cases, it seems reasonable for 
APPENDs to be disallowed for certain mailboxes (as, for example, in a 
proxy situation or when a mailbox reaches maximum capacity).  An easy 
way to deal with this would perhaps be to change the syntax to allow 
an append limit of 0 with the meaning, not that zero-length messages 
may be APPENDed (something that my checks show that many servers 
disallow anyway), but that APPENDs are not allowed period.  This 
could avoid a lot of trouble, I believe.

Pete Maclean

At 05:12 PM 12/19/2014, Jayantheesh S B wrote:
>Hi All,
>
>Please find the next version of the draft attached with all the 
>review comments addressed.
>
>If you have any comments/suggestions in the attached version, kindly share it.
>
>Regards,
>Jay
>
>_______________________________________________
>imapext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/imapext

---

From: Jan Kundrát <[email-masked]>
Date: Sun, 04 Jan 2015 00:25:30 +0100

On Saturday, 3 January 2015 14:11:00 CEST, Pete Maclean wrote:
> Surely it would be very valuable to include in this extension a 
> means for a server to indicate that it does not accept APPENDs 
> at all.

That's IMHO what the ACL extension is for -- the "i" right defined in 
RFC4314.

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 04 Jan 2015 18:17:41 +0000

Hi Pete,

On 03/01/2015 13:11, Pete Maclean wrote:
> upload size".  What is the intended scope of said fixedness. Should a 
> client assume that a maximum upload size obtained in one session 
> applies in a later session?  I think it should not.
I don't think this matters, because the limit would be always advertised 
in CAPABILITY response and/or on SELECT anyway.
> Hardware or other changes at the server could surely lead to a maximum 
> upload size changing over time.
>
> return different maximum upload sizes in CAPABILITY responses within a 
> single session?  In cases where a maximum upload size is dependent on 
> a quota, it could make sense for these things to happen.
Yes, it is probably sensible to allow for that.
> for a server to indicate that it does not accept APPENDs at all.
APPENDLIMIT=0?
> For IMAP servers fronting email archives, it is entirely reasonable 
> for APPENDs to be unsupported.  In other cases, it seems reasonable 
> for APPENDs to be disallowed for certain mailboxes (as, for example, 
> in a proxy situation or when a mailbox reaches maximum capacity).  An 
> easy way to deal with this would perhaps be to change the syntax to 
> allow an append limit of 0 with the meaning, not that zero-length 
> messages may be APPENDed (something that my checks show that many 
> servers disallow anyway), but that APPENDs are not allowed period.  
> This could avoid a lot of trouble, I believe.
Yes, I think this is a good idea.

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 04 Jan 2015 14:23:50 -0500

Hi Jan,

> That's IMHO what the ACL extension is for -- the "i" right defined in

Tru,e but I think we need to distinguish between what is "allowed" (ACL) vs 
what the size limit is (APPENDLIMIT). As others have noted, the limit may 
well reach zero because of some quota on the mailbox. I don't think that 
the ACL should depend on the the available quota in that case (i.e., the 
"i" right would remain set because if messages were deleted, APPENDs would 
be OK).

So I think APPENDLIMIT=0 should be a valid response (though I think Pete's 
example of a "read-only" email archive would be better served via removing 
the "i" ACL right).

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 4 Jan 2015 20:25:09 +0100

Allowed, but with a zero quota... Does any of you really care about 
supporting that case?

Arnt

---

From: Jan Kundrát <[email-masked]>
Date: Mon, 05 Jan 2015 14:51:59 +0100

On Sunday, 4 January 2015 20:23:50 CEST, Cyrus Daboo wrote:
> Tru,e but I think we need to distinguish between what is 
> "allowed" (ACL) vs what the size limit is (APPENDLIMIT). As 
> others have noted, the limit may well reach zero because of some 
> quota on the mailbox. I don't think that the ACL should depend 
> on the the available quota in that case (i.e., the "i" right 
> would remain set because if messages were deleted, APPENDs would 
> be OK).

I do not think that the per-mailbox APPENDLIMIT should take quotas into 
account at all. If you send an * OK [APPENDLIMIT 10] at a time your quota 
is almost exhausted, then you have to have a channel to asynchronously 
update that information when space gets freed. This means unsolicited * OK 
[APPENDLIMIT ...] on selected mailboxes, something pretty ugly already. How 
do you propose to pass this information for non-selected mailboxes where 
the client has already asked in STATUS or LIST-STATUS?

Seriously, if this switches from a rarely changing limit which is valid for 
at least the duration of the IMAP session, then you have to invent a 
syncing mechanism. That starts to get a bit complex soon enough.

With kind regards,
Jan

---

From: Pete Maclean <[email-masked]>
Date: Mon, 05 Jan 2015 09:00:51 -0500

Jan,

Thank you for pointing that out.  While I have 
looked at the RFC, I am not well up on ACL 
commands having never had reason to support them 
in my server.  I see an account's right to use 
APPEND as a different matter from a server's 
ability to allow APPENDs though (the former is, 
as it were, subjective while the latter is 
objective) and I still think it would be valuable 
for servers to have an ability to indicate that 
APPENDs are not acceptable.  Of course this does 
mean that the interaction of the two must be 
defined but I think that should be easy and, I 
hope, obvious in that nothing a server says about 
its willingness to accept APPENDs should be taken 
as any indication that that overrides a user's 
rights.  After all, we are not suggesting that a 
server should inhibit its sending of APPENDLIMIT 
data to clients operating without the "i" right.

Pete Maclean

At 06:25 PM 1/3/2015, Jan Kundrát wrote:
>On Saturday, 3 January 2015 14:11:00 CEST, Pete 
>Maclean wrote: > Surely it would be very 
>valuable to include in this extension a > means 
>for a server to indicate that it does not accept 
>APPENDs > at all. That's IMHO what the ACL 
>extension is for -- the "i" right defined in 
>RFC4314. With kind regards, Jan -- TrojitÃ¡, a 
>fast Qt IMAP e-mail client -- 
>http://trojita.flaska.net/ 
>imapext mailing list [email-masked] 
>https://www.ietf.org/mailman/listinfo/imapext </x-flowed>

---

From: Jayantheesh S B <[email-masked]>
Date: Mon, 5 Jan 2015 17:50:27 +0000

Hi Pete,

Thanks for your review comments. 

Please find my comments inline. 

Regards,
Jay

-----Original Message-----
From: Pete Maclean [mailto:[email-masked]] 
Sent: Saturday, January 03, 2015 8:11 AM
To: Jayantheesh S B; [email-masked]'
Subject: Re: [imapext] The IMAP APPENDLIMIT Extension

Jay,

I have not said anything on APPENDLIMIT before but, reading your latest draft now, there are a few things I wonder about.  I don't think any of these necessarily requires any changes to the draft but some may merit additional consideration.

In section 5 you make reference to "the server's fixed maximum mail upload size".  What is the intended scope of said fixedness.  Should a client assume that a maximum upload size obtained in one session applies in a later session?  I think it should not.  Hardware or other changes at the server could surely lead to a maximum upload size changing over time.

[Jay] Upload size obtained using SELECT/EXAMINE always overrides the CAPABILITY response. So, maximum upload size obtained in one session does not apply for another session.

How should a client behave if it obtains a maximum upload size for a given mailbox in a LIST command and then later in the same session it does a SELECT/EXAMINE for the same mailbox that quotes a different maximum upload size?  For that matter, is it valid for a server to return different maximum upload sizes in CAPABILITY responses within a single session?  In cases where a maximum upload size is dependent on a quota, it could make sense for these things to happen.

Surely it would be very valuable to include in this extension a means for a server to indicate that it does not accept APPENDs at all.  For IMAP servers fronting email archives, it is entirely reasonable for APPENDs to be unsupported.  In other cases, it seems reasonable for APPENDs to be disallowed for certain mailboxes (as, for example, in a proxy situation or when a mailbox reaches maximum capacity).  An easy way to deal with this would perhaps be to change the syntax to allow an append limit of 0 with the meaning, not that zero-length messages may be APPENDed (something that my checks show that many servers disallow anyway), but that APPENDs are not allowed period.  This could avoid a lot of trouble, I believe.

[Jay] This is the good idea. I will change the next version of the draft to accept the APPENDLIMIT=0, indicates the server will not accept any APPEND command due to size restriction.

Pete Maclean

At 05:12 PM 12/19/2014, Jayantheesh S B wrote:
>Hi All,
>
>Please find the next version of the draft attached with all the review 
>comments addressed.
>

---

From: Jayantheesh S B <[email-masked]>
Date: Wed, 21 Jan 2015 22:37:39 +0000

Hi All,

Please find the next version of the draft updated with APPENDLIMIT=0 case addressed.

Share comments in this version to make the final version of draft.

Regards,
Jay

-----Original Message-----
From: Jayantheesh S B [mailto:[email-masked]] 
Sent: Monday, January 05, 2015 12:50 PM
To: Pete Maclean; [email-masked]'
Subject: Re: [imapext] The IMAP APPENDLIMIT Extension

Hi Pete,

Regards,
Jay

-----Original Message-----
From: Pete Maclean [mailto:[email-masked]]
Sent: Saturday, January 03, 2015 8:11 AM
To: Jayantheesh S B; [email-masked]'
Subject: Re: [imapext] The IMAP APPENDLIMIT Extension

Jay,

Pete Maclean