james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin.Bergljung" <Martin.Berglj...@opsera.com>
Subject RE: IMAP FETCH BODYSTRUCTURE problem
Date Mon, 18 May 2009 08:30:02 GMT
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:robertburrelldonkin@gmail.com] 
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
<Martin.Bergljung@opsera.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message