Jeffrey Stedfast writes: [ ... ]
> When parsing a uid-set, you could do something creative like setting a > mode bit on the message files whos uids are encountered when parsing the > uid-set (this wouldn't use *any* memory or disk space). Once you > complete the parsing of the uid-set, you could scan the directory and > set whatever flags were requested in the next token on any message with > that particular bit set (probably a +x bit). > > Yes, this idea hasn't been completely thought out. You'd still have to > consider another client trying to set flags on an intersecting set of > messages (or even a non-intersecting set really...or maybe even multiple > clients trying to change flags at all). > > Perhaps you could lock the files or something as a solution, I don't > know. > > Maybe you can make it so only a single client can have READ-WRITE access > to the folder at a time, this'd solve the multiple client thing. If I do something like that, I'll be flamed for the next ten years. Plenty of people are dumping mbox in favor of maildirs precisely because they cannot have concurrent access, of any kind. Concurrent read-write access is important for many people. [ ... ] > > Okay, so what if 1 client has READ-WRITE access and we have multiple > clients (that can only get READ-ONLY access) requesting info and also > using uid-sets? Okay, so perhaps one client can set u+x bit, another > client can set the g+x bit and you can set the o+x bit for a third This is the most atrocious proposal I've ever heard anyone make. [ ... ] > Disclaimer: my +x idea may not be the perfect or ideal solution, there > will always be a race condition; but I think it's a prime example of > "thinking out of the box". This is also rather disgusting. You're thinking waaaay out of the box, here. [ ... ] > This is really less about you fixing a "bug" to make Evolution work than > it is for you to fix your software to be better. Whether you fix the bug The same argument can also be used to show that it is better not to assume that servers will accept commands of unlimited size. See? >> 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. > > Good for you. I would argue that it's not true - had you 0 knowledge of > the limitations of imap servers - it is doubtful that you would have > limited your commands to 1k since rfc2060 says to do no such thing. Yes, I would. The first time I read RFC 2060 it was perfectly clear to me that I'd be fooling myself if I were to expect servers to handle infinitely-sized commands. This aspect of RFC 2060's poor design was blatantly obvious right from the beginning. Perhaps I would not've picked 1k as a limit, perhaps I would've picked 2k or 4k, but I would've definitely capped the spigot on my IMAP client's output. >> 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. > > I bet you also read rfc822 and it was "patently clear, right from the > beginning", that email messages would never be longer than 4k. Oh wait, > there are messages thrown around *all* the time that are >4k. I also read rfc821, which placed limits on the maximum size of each text line. Since individual lines could be up to a thousand bytes each, a 4k assumption on the maximum size of an e-mail message would've been impossible. Furthermore, handling an E-mail message is completely different than writing a protocol parser or a generator, and this is a bogus comparison. > (okay, I'm sure you didn't read rfc822 and really think that, I was just > poking fun. In a few years, a multi-megabyte token will be considered > tiny - I just replaced my 6.4 gig drive that died with an 80 gig drive, > and I thought 6.4 gig was huge! how will I ever fill 80gigs!?!?) In a few years, I would hope that a more sane revision to RFC 2060, which addresses all the holes in RFC 2060. Sadly, this is not going to happen in Crispin's next draft, which I've read. It fixes some of the most egregious foul-ups, but completely fails to address some of these issues. I have toyed with the idea of just going forward with drafting a complete replacement for IMAP, that actually tries to achieve some sanity. I could easily graft an alternative, but a functionally equivalent, parser into Courier-IMAP, and have both available as a transition mechanism. I even wrote up a few notes that I may still have someplace around here. However, the conclusion that I've reached was that this would not be a viable project without at least some client support (and this was the original motivation for me to go ahead and write up the previously mentioned IMAP client of mine). This is now on a back burner. > What if someone were to implement a server that didn't allow tokens to > be more than say 20 bytes? What then? I would then like to know what they are smoking. > By your mode of thinking, this is > perfectly acceptable. After all, I believe that all the defined IMAP > protocol tokens would fit within a 20 byte buffer, so wouldn't that be > just fine and dandy? You can even pack a small uid-set into 20 bytes... > > Even your superb client couldn't handle this server implementation... This is not my argument. Nice straw-man. >> a time, thus imposing no actual upper limit on the size of the overall IMAP >> command[2]. > > It's surely better than a single 8k buffer that the entire command must > squeeze into, but it's hardly acceptable IMHO. Here's the bottom line: if there were specific max limits defined, I'd accept them. If there aren't any, I'll use my judgement to establish reasonable limits. That's it. >> > you impose limitations, then you are not compliant with the >> > specification IMHO. >> >> Go bitch to Crispin. > > Should I also use this argument next time someone complains about > Evolution's imap implementation? Sure! You won't get any arguments from me. > We have worked around so many bugs in a variety of IMAP implementations, > the code is riddled with comments like this one from just yesterday: > > /* This is a kludge around a bug in Exchange > * 5.5 that sometimes claims multiple messages > * have the same UID. See bug #17694 for > * details. > */ > > Here's a log of the type of transaction that this works around: > > -------------------- > sending : A00052 UID FETCH 262763:* (FLAGS RFC822.SIZE) > received: * 9 FETCH (FLAGS (\Recent) RFC822.SIZE 2065 UID 262766) > received: * 10 FETCH (FLAGS (\Recent) RFC822.SIZE 2065 UID 262766) > received: * 11 FETCH (FLAGS (\Recent) RFC822.SIZE 2565 UID 262768) > received: * 12 FETCH (FLAGS (\Recent) RFC822.SIZE 1877 UID 262770) > received: A00052 OK FETCH completed. > -------------------- > > Isn't that just beautiful? ;-) You don't need to tell me this. I'm well aware of Microsoft's proficiency in writing mail client and server software. I would be more than happy to offer corresponding examples of garbage coming out of Microsoft's IMAP clients, but, face it, it's just a waste of time rehashing this. >> 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]. > > > *sigh* I give up. I was hoping that I could at least convince you to > rethink your implementation to try and find ways of increasing the > limitation of token sizes that you accept if not going the whole 9 yards > and implementing it with no limitation. I believe that limiting token sizes to 16 kilobytes is a very reasonable. I don't think that any IMAP client has any business hatching anything anywhere close that it. > Let me apologize for any feelings I may have hurt (it was definitely not > my intention to do so). But *please*, do consider an implementation that > doesn't limit clients to token sizes. This request is impossible to accomodate simultaneously with the non-negotiable requirement to prevent denial-of-service attacks. The only way to implement something like this is to allow unlimited resource usage by the IMAP server process. I don't find this acceptable. > It's just that having to "guess" what the max allowable token size is on > a server is never a Good Thing (tm). While you are probably right that I agree. But, once again, this is a fault in RFC 2060. Accepting that, you have to use your judgement to estimate the "safe zone". > minimizing token sizes to 1k on the client-side will float most > anywhere, you can never ever be 100% certain of that. And if you go and I agree, but as the saying goes: shit happens. There is no perfect solution to this predicament. The best thing to do is for IMAP client to avoid sending huge commands to the server, and for IMAP server to set generous fixed upper limits on incoming IMAP commands. I believe that a single 16Kb token size limit, with no fixed upper limit on the overall size of a single IMAP command, is generous enough. -- Sam _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
