Hi Jonathan, On Fri, 20 May 2005 09:39:44 -0500 UTC (5/20/2005, 9:39 AM -0500 UTC my time), Jonathan Angliss wrote:
J> Sure, and if all clients/servers worked in RFC compliance, we would J> never have any of these issues. yes, just look at how many problematic email servers are out there floating around with this old basic protocol. J> There are "hacks" to a lot of major IMAP server implementations to J> support buggy clients, and visa versa too. One of the greatest non-compliant clients of all time are the earlier versions of Outlook. J> Check the IMAP fine tune menu in the account dialog, there is one right J> there for Courier :) exactly my point :) This is needed by TB!, yet is not needed by Mulberry when talking to a Courier server. No additional switches are needed, and personally, I gave up Courier years ago, moved to Binc, again with Maildir format.. Sam is a little too far out there at times for me :) J> Some of the time, and I've found this particularly true on RFC3501, J> interpretations of the docs can be different to each person. very true... it is a complex, difficult protocol >> 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? J> Okay, maybe we'll look at this differently... The header that was J> broken was the one added by Mulbery. That means that Mulbery was the J> one that generated the non-RFC compliant header by not having the < > J> in the headers. Sure, if the IMAP server didn't return the data with J> the < > in the line in response to a fetch for the Message-ID header, J> the client should put them in it, the RFC says they MUST be there. J> But, that would mean the IMAP server was "processing" the data, which J> it really shouldn't be. When you tell it to look at the header lines, J> it should return the content of that header (including the header J> field itself) as it appears in the email (wrapping, bad content, J> whatever). The answer lies with Tony, as he opened his logging capability when talking to his IMAP server and sent it off, showing the server side problem. Perhaps if he would send it off to you, off list, this might help. J> While in general, I /hate/ the idea of client hacks to fix server J> problems, and visa versa (trust me, I've done plenty of both). Of J> course, without proper knowledge of what the Mulbery/server is really J> sending to each other, we're just speculating on what is happening. exactly, agreed... as above, if Tony can send you his logs on this, off list. >> 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. J> Sure, and it'll probably break when it hits a server that is slightly J> RFC incompliant, or a server implementation of the RFC specifications J> that doesn't meet the same understanding of the RFCs as RitLabs. I J> think the only person that really knows, and understands RFC3501 as it J> should be understood is Marc Crispin ;) LOL... Mr. UW-IMAP with all that code bloat... probably so :) J> We (I say we and mean the people on a project I work on) have come across J> many understandings of some stuff, and had many disputes about it which J> ultimately ended up being taken on the IMAP RFC list to be clarified by J> Mr Crispin :) Yes, I know a few IMAP authors who subscribe to that list when problems arise in the implementation. I have seen this too <g> -- Gary ________________________________________________________ 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/
