james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Questions on the Mail and MailRepository interfaces
Date Wed, 16 May 2007 14:22:53 GMT
Jukka Zitting ha scritto:
>> The MOST IMPORTANT thing at all is that if I store a message and I later
>> retrieve it every single space, every single header, everything is
>> exactly as I wrote it. Even if it was malformed.
> Is this a hard requirement? If yes, then I could just model the entire
> mime message as a normal nt:resource node, in which case the JCR
> repository would act just like an advanced file system with
> transactions and some search features.

As JAMES Server can be used as a relay server, the SMTP specification
tell us to not alter the messages (even if they are malformed). The only
thing we're allowed to to is *prepending* a "Received" header, and
converting from 8bit to 7bit if we support 8BITMIME.

I think SMTP relaying is a common use case for JAMES Server and one of
the main goals so we should keep this in high consideration.

> Personally I don't see the exact storage requirement as essential, as
> the mail specs explicitly allow all sorts of intermediate nodes to
> perform various types of reformattings on messages while in transit.
> Things should be fine as long as the original intended content is
> preserved.

Are you sure? I don't agree on this. Instead you break some signature
mechanism if you do that. My interpretation of the SMTP spec is not that
we can do what we want. Maybe other JAMES committers can share their
experience and knowledge on this.

>> To achieve performance we'll probably have to avoid parsing the mime
>> structure at all: we don't need this for most SMTP/POP3 operations. Some
>> IMAP operation needs this, but this should probably done on demand and
>> not when writing the message to the repository.
> One possible approach, at the expense of storing potentially redundant
> duplicate data, is that the original message source is stored as a
> verbatim binary stream and the message content is automatically
> "exploded" when the first client that actually needs to parse the
> message.

This is what we do now (MimeMessageWrapper does lazy parsing of
headers/body separately), but we never store the "parsed" version then.


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

View raw message