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: Questions on the Mail and MailRepository interfaces
Date Wed, 16 May 2007 21:49:27 GMT
On 5/16/07, Stefano Bagnara <apache@bago.org> wrote:
> Jukka Zitting wrote:
> > On 5/16/07, Stefano Bagnara <apache@bago.org> wrote:
> >> 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.
>
> ok!

hold on a minute - i think we might be being just a little too hasty!

noel, peter, danny and myself were talking through some advanced SEDA
based architectures that will cluster well. jukka's exploding mail
idea fits very well into this.

> >> > 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.
>
> Please note that a gateway is a very special use case: smtp spec define
> a gateway an SMTP server that is a brindge between 2 different transport
> layers.
>
> SMTP relaying was the scenario I referred and it is not related to
> gateways. Here are some interesting quotes from rfc2821:
>
>    --
>    In general, a relay SMTP SHOULD assume that
>    the message content it has received is valid and, assuming that the
>    envelope permits doing so, relay it without inspecting that content.
>
>    --
>    As discussed in section 2.4.1, a relay SMTP has no need to inspect or
>    act upon the headers or body of the message data and MUST NOT do so
>    except to add its own "Received:" header (section 4.4) and,
>    optionally, to attempt to detect looping in the mail system (see
>    section 6.2).
>
>    --
>    The following changes to a message being processed MAY be applied
>    when necessary by an originating SMTP server, or one used as the
>    target of SMTP as an initial posting protocol:
>    -  Addition of a message-id field when none appears
>    -  Addition of a date, time or time zone when none appears
>    -  Correction of addresses to proper FQDN format
>    The less information the server has about the client, the less likely
>    these changes are to be correct and the more caution and conservatism
>    should be applied when considering whether or not to perform fixes
>    and how.  These changes MUST NOT be applied by an SMTP server that
>    provides an intermediate relay function.
>
>    --
>    An Internet mail program MUST NOT change a Received: line that was
>    previously added to the message header.  SMTP servers MUST prepend
>    Received lines to messages; they MUST NOT change the order of
>    existing lines or insert Received lines in any other location.

designing a complete mail (not just email) storage solution around
relaying IMHO doesn't really make much sense. however, it is a very
useful extreme border case.

there are various ways that various types of mail can enter the
system. the consensus was that it's best for the least possible amount
of processing to be done initially (perhaps even just writing a
temporary file and then writing the data to the permanent store using
another thread)

the first stage storage should just store the raw mail and basic
meta-data about that mail. this should include some audit trail
information about the original of the mail. (note mail here, not
email.)

later stages of processing could then explode the mail on demand. this
would mean parsing the data and attaching the contents. the original
data would still be available.

- 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