Jeffrey Stedfast writes: > On Fri, 2002-01-11 at 17:28, Adrian Hosey wrote: >> On 11 Jan 2002, Jeffrey Stedfast wrote: >> : >> : The UID STORE command was setting the \Deleted flag on a very large set >> : of messages. This is a perfectly valid operation. >> >> It's technically legal, but it's not wise to try and do it all with one >> command. Your example of a large non-contiguous set of UIDs can be broken >> into multiple smaller UID STOREs. "Be conservative in what you send." > > Granted we will have to do this anyway, but it is still broken behavior > for courier-imapd to impose token size limits.
Actually, what's really broken here is RFC 2060. IMAP is a fundamentally broken protocol that fails to take into account the harsh realities of the world at large. As someone else already noted, the UW-IMAP server imposes a fixed limit on the size of the entire IMAP command (it just fgets() the next command off the wire, and chews it up). Now, when the author of RFC 2060 cannot himself write an implementation that strictly adheres to his own write-up, to the letter, what does that tell you?[1] >> Dynamically growing buffers is fine, but there still needs to be a >> limit. > > The only limit that you need is the "system is out of resources" limit. Congratulations: a single hostile user is now able to completely DOS the box out of its resources. The following question is not really meant to be confrontational, but: have you ever written a server -- for a relatively complicated protocol -- that is designed to be publicly accessible? > You could, as an option, write a generic token interface that could > optionally save token data to disk if it was larger than a size you > wanted to store in memory. With or without an upper limit on the size of the token? If without any limit, then a single hostile user can now fill your entire server's disk. Wonderful. And if you do impose an upper limit on the token size, when spooled to disk, then you failed to satisfy your own initial requirements of strict adherence to RFC 2060. >> To do otherwise invites denial of service. > > Not if you do it right. I'm curious. Please explain how to do this "right": by that meaning properly implementing RFC 2060, up to your own standards, while preventing DOS attacks. No matter how you turn things around, if you actually think things through you will have no choice but agree that you have to impose maximum limits on these kinds of things, so the original "bug", as you stated, is a red herring. Let me make a wild guess: the IMAP client in Evolution will happily spew forth infinitely-sized IMAP commands; people are bitching because Evolution goes tits-up on huge folders because of this; and you want everyone else to fix this for you? Well, it just so happens that I'm writing this message using my own IMAP client. As a side note it's never going to see the light of day because I'll rewrite it from scratch, when I have some free time -- but the point is that it will happily handle these kinds of large folders situations without choking. It doesn't matter whether it's the UW-IMAP server ot the Courier-IMAP server it's talking to. And that's not necessarily becuase I happen to have some casual knowledge of their innards. It's because from reading RFC 2060 it was always patently clear from me, right from the very beginning, that expecting to fire multi-megabyte tokens at the IMAP server, and expecting that to work in real life, is sheer folly. Putting my client hat on, I feel confident that I'm in the safe zone if I limiting my whole commands to less than a 1,000 bytes. So, in a similar situation, my IMAP client will simply issue multiple commands to go through the entire message list, a couple of hundred messages at a time, and do what it needs to do. And, as a side note, when I put my server hat on, I conclude that I should be safe limiting tokens to 16K bytes, and parsing IMAP commands one token at a time, thus imposing no actual upper limit on the size of the overall IMAP command[2]. > Just because other servers impose limits doesn't mean you should. If the > IMAP specification does not impose limits, then neither should you. If The IMAP specification is fundamentally broken. And this is not the only broken part, BTW. Actual implementations have to make judgement calls like this. Thinking rationally about it you have no choice but come to that conclusion. Anything else is sheer folly. > you impose limitations, then you are not compliant with the > specification IMHO. Go bitch to Crispin. >> A quick look at the UWash imapd code and >> it looks like that limits the size of the _entire_ command buffer to >> 8K. Have you tried your large STORE operation against a UWash server? >> Maybe it works, maybe I'm reading the code wrong. > > No, you are right. But again, just because someone else does it doesn't > make it right. Prediction: you explain to Crispin the fact that Evolution will choke on large UW-IMAP folders, and what the reason is, and he'll tell you that you're full of crap[3]. -- Sam [1] It's a hypothetical question. [2] Well, certain constructs do need to be parsed into memory. The solution is to forcibly ulimit yourself down to something reasonable, and it'll probably take an hour, or so, at average bandwidth, to fill up your data segment. If that's what you want to do, it's your rope to hang yourself onto. [3] Mentally pondering the situation of Crispin telling someone that they are full of crap for wanting to implement his specification, verbatim, should be even more beneficial than yoga, for your mental health. Especially if you are inclined to agree with his conclusion, when under normal circumstances you think that he's full of it. _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
