Hi Gary, On Friday, May 20, 2005, you wrote: > 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. RFC3501 isn't "that" old... I think it's dated 2003, but the one it supercedes is dated 1996, still not "that" old. 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. Indeed... several common open source imap servers still have options to support such :) 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. I think this had something to do with the APPEND command, but I don't remember exactly... not sure why it'd be needed, unless they were expecting a result set back that they get from other servers, but not courier, and the option toggles a research of the drafts/whatever folder. [..] >>> 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. [..] > 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. Sure, but I think the point I made still stands, not withstanding the log from the server to see what was going on :) ie, if the server sends a message-id without the < > around it, Mulbery should send it WITH them... RFC2822 requires it. [..] J>> I think the only person that really knows, and understands RFC3501 J>> as it should be understood is Marc Crispin ;) > LOL... Mr. UW-IMAP with all that code bloat... probably so :) Aye, that is one beast, and unusually programmed... not entirely sure what the goals were in some of the things he did (like being allowed to read /etc/passwd from the IMAP server). -- Jonathan Angliss <[EMAIL PROTECTED]>
pgpLfghUhMlUU.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/
