Hi Gary, On Friday, May 20, 2005, you wrote: >> 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.
> I have to disagree with you here Jonathan, RFC 3501 as you know, says... > A quoted string is a sequence of zero or more 7-bit characters, > excluding CR and LF, with double quote (<">) characters at each > end. > If his IMAP server fails to send this correctly, it means his server > is not RFC compliant. Sure, though I'm not sure what this has to do with the missing < > characters in the References header. Both < and > are 7 bit characters (iirc), and the data that is sent back in response is most likely to be returned in a literal format, which wouldn't use the " " in the results. > TB! or Mulberry can only be compliant with the RFC and not deviate > from it. It must assume that it is dealing with a compliant server. > It cannot and should not do otherwise. Sure, and if all clients/servers worked in RFC compliance, we would never have any of these issues. There are "hacks" to a lot of major IMAP server implementations to support buggy clients, and visa versa too. Check the IMAP fine tune menu in the account dialog, there is one right there for Courier :) Some of the time, and I've found this particularly true on RFC3501, interpretations of the docs can be different to each person. >> 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. > I would say this is programmer's saying or adage, as there is nothing of > this in the RFC as you know. Maybe i miss-worded that, "a suggestion when following RFCs", instead of "an RFC suggestion", that better? :) >> 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. > Now here is where I disagree with you. Yes, it is a must in the RFC, > but it is not up to the client to fix a broken server, and I believe > that is what you are asking above. You are asking a client to pick > up and make a non-compliant server compliant, to fix is > shortcomings. So, where does it end? Should a client fix any broken > IMAP server for whatever reason, e.g. broken attributes or commands. > One should only assume that any server is 100% compliant. IMO, that > is the only way to build a client. Everything else leads to > speculation, and isn't that why we have RFCs? Okay, maybe we'll look at this differently... The header that was broken was the one added by Mulbery. That means that Mulbery was the one that generated the non-RFC compliant header by not having the < > in the headers. Sure, if the IMAP server didn't return the data with the < > in the line in response to a fetch for the Message-ID header, the client should put them in it, the RFC says they MUST be there. But, that would mean the IMAP server was "processing" the data, which it really shouldn't be. When you tell it to look at the header lines, it should return the content of that header (including the header field itself) as it appears in the email (wrapping, bad content, whatever). While in general, I /hate/ the idea of client hacks to fix server problems, and visa versa (trust me, I've done plenty of both). Of course, without proper knowledge of what the Mulbery/server is really sending to each other, we're just speculating on what is happening. > I can only hope that TB! will be 100% compliant in its future development > and settle for no less. Only then will it be a true IMAP client. Sure, and it'll probably break when it hits a server that is slightly RFC incompliant, or a server implementation of the RFC specifications that doesn't meet the same understanding of the RFCs as RitLabs. I think the only person that really knows, and understands RFC3501 as it should be understood is Marc Crispin ;) We (I say we and mean the people on a project I work on) have come across many understandings of some stuff, and had many disputes about it which ultimately ended up being taken on the IMAP RFC list to be clarified by Mr Crispin :) -- Jonathan Angliss <[EMAIL PROTECTED]>
pgpg6fi3BsnvO.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/
