On 5/16/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Jukka Zitting wrote:
> On 5/16/07, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
