Caskey, :) On Sat, 5 Apr 2003, Caskey Dickson wrote: >On Sat, Apr 05, 2003 at 11:17:29AM +0200, Andreas Aardal Hanssen wrote: >> On Sat, 5 Apr 2003, Daniel Brooks wrote: >> >I'm trying to move a farily large number of emails (thousands) up to the >> >server, and it's dying during the process. I'm using mozilla on the >> >client end, and it doesn't give any error messages (naturally :P). >> >Here's what I get from the server log when it happens: >> I'll do some testing this weekend to see if I can reproduce it. Binc >> definitely aborted, so there might be some unhandled exception around. >> If you are able to reproduce this error and find more info about it, >> please do post it and I'll see if we can track it down. >I'm reading through the append code in 1.1.3 and I notice that the code >strips '\r' from the uploaded content, is this the correct behavior? From >what I can tell, append data should be 'literal' and that has no restrictions >or conversions of the data. While this may not be sufficient to cause the >crash, it doesn't seem to be a good thing.
It strips CR from the data that is stored to disk, but that's just because qmail-local does the same when it stores messages, so instead of having some messages CRLF and some LF in the Maildir, they are all LF with APPEND's behavior. But I do not know of any requirement in Maildir to strip those CR's. A similar conversion is done in the mime parser, where it adds CR characters so the resulting mime when fetched is CRLF. When calculating the size of the message, this conversion routine is used so that any format stored in the Maildir will be converted to CRLF. This is perfectly good IMAP compliance, as long as the conversion is consistent from the client's view (fetching character 2-7 and 3-8 should not give jumpy off by ones obviously) :-). Now, :-) since converting from CRLF or LF to CRLF has some interesting side effects [*], it's hard to keep the size appended by the client in the stored message. Also, I can't see any requirement in the RFC that the size of the document appended be the same as that which is fetched.. but I see your point - it doesn't make much sense from the client's side for the server to change this size. I have no really big arguments for doing so other than that qmail-local does it too, but I don't think it's a show stopper to keep it in. :/ Andy [*] If a mime document (and whoa are there funky mime docs out there) contains this sequence: CR CR CR CR LF, how is this converted to CRLF? Obviously, this document does not qualify as MIME with regards to the RFCs that define MIME, but in IMAP we _must_ represent the document in true CRLF encoding (I checked with Marc Crispin about this specifically), and the GIGO rule (garbage in, garbage out) applies. Binc strips all CR from documents stored in the depository. If it sees an LF, it outputs CRLF. So the above sequence would be converted to CR LF only. From what I understand, this is an ok way to do things. -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | Nil desperandum
