Hi, If we could add a configuration parameter to be able to turn on and off the return of extension data that would be good. I have lots of trial users with Lotus Notes clients so I need to find a solution.
BTW. I did loads of changes and updates to FetchCommand.java and SimpleMessageAttributes.java in the old implementation to get it to work. Cheers, Martin -----Original Message----- From: Robert Burrell Donkin [mailto:[email protected]] Sent: 18 May 2009 08:24 To: James Developers List Subject: Re: IMAP FETCH BODYSTRUCTURE problem On Sun, May 17, 2009 at 4:18 PM, Martin.Bergljung <[email protected]> wrote: > Hi, > > > > I started to test the new IMAP Protocol with Lotus Notes > > (wants MIME parsing on the server side compared to Outlook and > Thunderbird > > that downloads the complete MIME and does it on the client side) > > and got into some problems with FETCH BODYSTRUCTURE. > > > > If I for example have a plain text message and execute a command like > "A9 FETCH 3 (RFC822.HEADER BODYSTRUCTURE)" then > > the bodystructure response looks something like this: > > > > * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" ("charset" "utf-8") NIL NIL > "7BIT" 1257 37 NIL NIL ("en-us") NIL) RFC822.HEADER {868} this looks right to me > ... > > > > This does not work with Lotus Notes, it things this response is > incorrect. > > The old IMAP implementation that I am using will respond as follows: > > > > * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" ("charset" "utf-8") NIL NIL > "7BIT" 1257 1) RFC822.HEADER {868} this looks wrong to me > ... > > > > And Lotus Notes is fine with this response. the lotus client is broken: <blockquote cite='http://www.faqs.org/rfcs/rfc3501.html'> Client implementations that do a BODYSTRUCTURE fetch MUST be prepared to accept such extension data. </blockquote> > Looks like there is some extra stuff in the response for the new > implementation: ... NIL NIL ("en-us") NIL ... this extension data is specified in RFC3501. the current IMAP implementation does quite a full job, more than many servers. this stuff is tricky to parse and isn't very useful so most servers don't bother sending and clients don't bother parsing. i don't know of any way for an IMAP server to work out what the client application is. the server has to send a hello including this information. it seems to be assumed by the specification that servers will often be buggy whilst clients will always be correct. the converse is usually the base :-/ AIUI the usual approach taken is to start adding configuration parameters which tell a server to deviate from the specification. any better ideas would be appreciated :-) > Note. It returns 1 for the number of lines in message but it works > anyway. the old implementation is broken and crashs some client versions with this behaviour - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
