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

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.


Jukka Zitting

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

View raw message