Hi Tony Boom, On Wednesday, May 18, 2005, you wrote: > Hello Stefan.
> --On 18 May 2005 19:28 +0300 you wrote about Re[8]: Threading?: >> Hmm. Good motto for IMAP client developers - if anything goes wrong, blame >> the server! Just a joke, > Not such a joke, I said exactly the same thing to Allie and Gary, in fact > my exact words were and I quote directly from my message to Allie... >> And his final verdict... To pass the buck. I can't see it myself because >> if it was my server stripping the headers then it would also happen when I >> used The Bat! surely? > However, the evidence that was presented to me was overwhelming and I had > to eat my words and concede defeat. A little more for you... I don't think IMAP was entirely to blame here, though maybe partially. The header that was incorrectly formatted was the one "generated" by Mulbery, the rest in the References header were correct iirc. This means Mulbery did correctly download/fetch those headers, it just messed up putting it's own ones in place after it was done. When I say "own ones", I'm talking about copying the message-id from the original email to the References and In-Reply-To fields on the reply. It's not difficult to read the data from the IMAP server (see msgid:[EMAIL PROTECTED] showing an example of me doing just that). So I see one of two possible things have happened in this case, and if you have a few, I'd like to investigate them with you (off list would probably be best) if you want. Possibility 1: Mulbery fetched the message-id header using the method I used in the above mentioned message (or something close to it). The imap server "messed" with the returned data, and stripped the < > off of the message-id. We know the messages had them in there originally, we can all go look at our archives. This would then mean Mulbery was not being very RFC compliant, and just "dumped" what it got back straight back out again. There is an RFC suggestion somewhere that says something along the lines of "be liberal in what you accept, and strict in what you send". Basically meaning, you can accept anything within a flexible bounds to the RFC, but follow the RFCs when sending stuff back out. This meaning, if the IMAP server /really/ did strip off the < > from the message-id, Mulbery *should* have put them back, as the are a MUST per RFC. Possibility 2: Mulbery fetched the headers, and tried parsing them itself, and didn't do it correctly. In either case, Mulbery *should* have handled the corrections. Just my personal opinion on it there. -- Jonathan Angliss <[EMAIL PROTECTED]>
pgp2NTOYEwPk6.pgp
Description: PGP signature
________________________________________________________ Current beta is (none) | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
