james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Questions on the Mail and MailRepository interfaces
Date Wed, 16 May 2007 14:49:19 GMT
Hi,

On 5/16/07, Stefano Bagnara <apache@bago.org> wrote:
> 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.

ACK. I'll go for a single binary stream per message for now. We can
revisit that decision later if we want to look at better supporting
IMAP and webmail scenarios.

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

See the notes on email gateways in the SMTP specs.

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

The possibility of such intermediate transformation is the very reason
why for example S/MIME defines the canonicalization rules to avoid
problems with a potentially mangled message format. I'm not too
familiar how well this works in practice, i.e. is the only safe
alternative really to preserve the exact message source.

BR,

Jukka Zitting

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