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 21:44:07 GMT
robert burrell donkin 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.
> 
> IMAP is *VERY* sensitive about malformed messages: a MIME message
> *MUST* be well formed. it's all too easy to crash modern IMAP clients
> with malformed emails.

I know this, but we have to make sure we know how the original mail
looked like because in SMTP relaying we need this.
Then we may want to do any operation for IMAP, but this must not be a
limit of the JCR repository. (IMO).

> one approach would be to take advantage of the typing available in
> JCRs to help the server understand mail. malformed MIME could
> gracefully degrade to RFC822 and malformed RFC882 to a general mail
> type.

I think we should also be sure we don't loose time parsing a message if
we don't need to parse it. If I use JAMES as a relay only mail server I
don't want to waste resources by parsing every message.

>> 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.
> 
> it's important to be able to get the raw as well as the processed

+1

> it's good being able to have smooth access to a parsed set of
> addresses but the raw header also needs to be preserved

+1

>> > 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.
> 
> i really like this idea :-)
> 
> there is no need to wait until the first client with SEDA: exploding
> would just another task to execute
> 
> IMAP is write rarely and read regularly. unless MIME messages are
> parsed and stored as separate parts, performance will be very poor in
> normal operation.

Once the message is in an IMAP folder imho there is no problem in
translating it from rawmessage to structured/parsed message.

The important fact is that in SMTP relay we need to store messages and
to retrieve them as simple streams: a 1GB message should be streamed
reading a writing without using more than 1MB memory and without having
to parse it.

> but again, the key is to be able to access the original, raw data when
> needed

Is this important also when the message is already in an IMAP repository
and we don't need to relay it to another SMTP server? Or in this case a
reconstructed message would suffice?

Stefano


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