Re: [Imap-protocol] Working around the evils of LITERAL+
Michael M Slusarz <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <20130326163025.Horde.rCiAnaUmvPUaLmL5tkpnSA1@bigworm.curecanti.org> |
Quoting Timo Sirainen <[email protected]>: > On 26.3.2013, at 23.26, Brandon Long <[email protected]> wrote: > >> with LITERAL+, the client would just issue an APPEND with two large >> a message. Our options were to just eat the data and say NO >> afterwards (great waste of bandwidth) or drop the connection. Some >> clients would just keep retrying to do the APPEND until they >> exhausted the upload bandwidth quota, or just cost the user a lot >> of money if they happened to be on a line that charged. > > You can answer NO immediately and then eat away the data. I don't > know if any clients will handle it though. Probably not. Especially if the client is pipelining the data with the LITERAL+ argument. Anyway, this is a known issue: http://tools.ietf.org/html/rfc4549#section-4.2.2.3 We explicitly disable LITERAL+ for our APPEND actions for precisely this reason - to capture NO responses before we send potentially large data payloads (although we compromise a bit and only disable LITERAL+ if the literal data is greater than 0.5 MB. No magic about that number - just a guess at the cost/benefit of wasted bandwidth vs. waiting for literal confirmation). I think you've already laid out the only 2 sane choices: either take the bandwidth hit to send the proper response or immediately drop the connection, albeit at the expense of making people think your software is "broken". For the former, you can issue a CLIENTBUG response code in the hopes that maybe a client author will see it and fix their APPEND usage. michael _______________________________________________ Imap-protocol mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol