MBOX-Line: From dave at cridland.net  Fri Mar 29 01:58:40 2013
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Working around the evils of LITERAL+
In-Reply-To: <515490A1.3070301@psaux.com>
References: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
	<5152E3E6.40506@aj.jp.nec.com> <1364388724.13923.97.camel@innu>
	<CABa8R6vv_fupAVX6bv018L9j-uW=YdW5wJ+oACrd3W_WVJq9Ow@mail.gmail.com>
	<CAKHUCzyfA2ZnDn3hXQt=DCj5O4y_fRSaW6ocDLMd1VpDWEn6zQ@mail.gmail.com>
	<4F401469-14A2-48FA-A6F7-B667A52E46C4@orthanc.ca>
	<515490A1.3070301@psaux.com>
Message-ID: <CAKHUCzyaOxXSd6RQevG-AyeMp-TxSW4MNpbSshNqPXhY9NPhTg@mail.gmail.com>

On 28 Mar 2013 18:52, "Tim Showalter" <tjs@psaux.com> wrote:
>
> 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.
>

Right, but to no damage. I think the best pattern is:

1) Send an tagged(?) NO, with an ALERT, explaining to the user what's
happening.

2) Send an untagged BYE, with the same message.

3) Terminate the connection. I suspect a partial shutdown might help get
the message through in some cases, but I'm not sure it's worth the pain.

Finally, you want to trigger this behaviour only for abusive cases -
multi-megabyte messages you'd have to reject anyway, not over 50k, however
desirable that might be.

By all that's holy - that is, RFC 3501 - the error will get to the user
and/or developer. At the least the constant failure will cause some users
to contact the developer. The weight of the Google Gorilla should be
sufficient to get the client fixed.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130329/a258ee88/attachment.html>
