james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [IMAP] MessageResult += Content
Date Mon, 05 Nov 2007 08:52:31 GMT
On Nov 4, 2007 11:21 PM, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Nov 2, 2007 7:22 PM, Robert Burrell Donkin
> > <robertburrelldonkin@gmail.com> wrote:
> >> On Nov 2, 2007 12:34 AM, Stefano Bagnara <apache@bago.org> wrote:
> >>> Robert Burrell Donkin ha scritto:
> >>>>> I'm not sure I understand the size in octect. You write a StringBuffer,
> >>>>> so it is an unicode string, how can you calculate the real octects
if
> >>>>> you don't know the charset/encoding that will be used when the buffer
> >>>>> will be written out?
> >>>> the content must be prior encoded into US-ASCII. probably should be
javadoc'd.
> >>> At least SMTP supports 8bitmime feature and binary encoding. Do you mean
> >>> that we'll have to re-encode that messages in order to store them using
> >>> the MailboxManager API ?
> >> this is an output API: the input API is a different matter
> >>
> >> IMHO the MailboxAPI should be liberal in what it accepts but precise
> >> in what it outputs
> >
> > there is a fundemantal conflict between the needs of a system that
> > just wants to store a MimeMessage quickly and then retrieve it a small
> > number of times with absolute fidelity at some future time, and the
> > needs of protocols that need to read that data quickly many times.
>
> Right. Something we should care about is also RFC compliance.

+1

> To keep
> SMTP compliance we should make sure that a message is not normalized or
> "fixed" before it is relayed (as an example).

i've add this example to
http://wiki.apache.org/james/BackendMailboxAPI but it would be great
if other SMTP requirements could be added

> IIRC SMTP tell us that we can reject an invalid message but we can't fix
> it and relay it. So we can normalize/fix it/be liberal only if we keep
> the result for ourselves, but we need a way to "relay" the original message.

ok

> Maybe we should simply avoid using this mailbox stuff also for spooling
> and keep the spooling very "stream/buffer" oriented while
> parsing/normalizing/fixing when storing to the mailboxes.

i'm not sure that the MailboxAPI is right to fix or normalise at all.
all that the backend can do is to convert all isolated CRs and LFs to
CRLFs. my reading of RFC822 is that the responsibility to fix line
endings is at the transport boundary. this makes sense to me: only at
that boundary can the incoming encoding be correctly understood.

ATM the MailboxAPI corrects line endings. IMHO this is wrong and
should be changed.

> This for sure
> is a performance leak as while spooling we often have mailets looking up
> message content/structure/headers. Maybe the "liberal" parsed version
> during spooling can simply be cached and only stored when the message is
> delivered to the mailbox. Or maybe we should keep the stream/buffers in
> the spool and then lazily create a structured representation of the
> message as soon as a parsing is needed and only use the parsed version
> once the message is altered (let's still rememeber that adding the
> Received header on top of the message should be done without altering
> anything else in the message by a relaying server).

either of these options sounds acceptable to me

- robert

---------------------------------------------------------------------
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