wasm-demo/demo/ermis-f/imap-protocol/cur/1600095048.22682.mbox:2,S

57 lines
2.4 KiB
Plaintext

MBOX-Line: From t-chiba at aj.jp.nec.com Wed Mar 27 05:19:50 2013
To: imap-protocol@u.washington.edu
From: Takeshi Chiba <t-chiba@aj.jp.nec.com>
Date: Fri Jun 8 12:34:50 2018
Subject: [Imap-protocol] Working around the evils of LITERAL+
In-Reply-To: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
References: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
Message-ID: <5152E3E6.40506@aj.jp.nec.com>
It seems like not general problem but gmail :-)
(There are many special clients for gmail such as gmail filesystem)
If I were gmail developper, eat the data *slowly*.
C: tag APPEND INBOX {1000000+}
S: tag NO quota limit exceeded
C: From: foo@bar.baz.com
S: From: BAD unknown command
C: To: imap-protocol@u.washington.edu
S: To: BAD unknown command
C: Subject: i-node
(server detect bad client by several invalid command, so sleep 10 seconds)
S: Subject: BAD unknown command
C: Date: ...
(sleep 10 seconds)
S: Date: BAD unknown command
...
--
Takeshi Chiba
(2013/03/27 6:26), Brandon Long wrote:
> More than a year ago, we (Gmail) disabled LITERAL+ on our servers.
>
> This was because of some unfortunate combination of factors. For one, we have a maximum message size on our server, with no real way to make that available to
> IMAP (maybe via GETQUOTA, but if no clients check it, that's not that useful). For two, we have an inbound bandwidth quota to protect against both broken
> clients and attempts to use Gmail IMAP as a storage system.
>
> So, if a user attempted to draft a message larger than our limit (35MB), 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.
>
> So, we disabled LITERAL+... but now I watch some UTF-8 SEARCH commands that have N literals in them, each requiring a server response, its just kind of evil.
>
> I guess we could have the server learn that a user is using a bad client and disable LITERAL+ automatically, anyone have any other ideas?
>
> Brandon
>
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
>