Re: [Imap-protocol] Working around the evils of LITERAL+

Tim Showalter <[email protected]>
Newsgroups gmane.mail.imap.general
Message-ID <[email protected]>
On 3/27/13 7:35 PM, Lyndon Nerenberg wrote:

>> I'm hesitant to suggest it, but is it worth sending BYE and dropping the connection? It's sailing just within the lines of the specification, I think.
>
> I think this is perfectly valid behaviour, and well within the spec.  A smart server might choose whether the eat-and-continue vs. bye-and-punt based on the size of the proposed literal+, but punting is entirely valid.

I would recommend against this, or at least advise caution.  A lot of 
clients, particularly mobile phone clients of a couple years ago, are 
both stupid and single-minded.  Hanging up is going to be treated as an 
obvious temporary failure and they will retry.

We (my former employer) had somebody with like 80k messages in their 
"Sent" folder at one point because our SEARCH was broken, couldn't find 
the Message-ID, and the client really, really, really wanted to make 
sure it had been added.

That said, BYE is compliant in my opinion; I just don't expect it to help.

> And while the "nibble at the data slowly" idea is eeevily enticing, it's going to wreak havoc with the battery on my mobile, which is almost guaranteed to be running the most brain-dead IMAP client on the planet.  (Servers factoring in aggregate data link speed in their eat-vs-bye calculations will score many karma points in my book.)

The cleverness of this is appealing but it can't be worth the debugging 
cost.

I'm all in favor of advertising the limit, and recommending that 
LITERAL+ be used exclusively to replace quoted-strings for short uses. 
I don't think there's a good workaround otherwise.

Tim

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.