james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Heath <m...@cycletime.com>
Subject Re: Wanted: Volunteers for Fast-Fail Proposal/Implementation
Date Mon, 09 May 2005 19:24:49 GMT
On Mon, 2005-05-09 at 10:09 +0100, Danny Angus wrote:

> 1/ it tries to force the mailet architecture into a role for which it
> isn;t suited
> 2/ it doesn't satisfy the requirement that the server be capable of
> terminating the conversation after any command which resolves to a
> predicted temprorary _or_ permamnent failure to deliver.
> I would propose an alternative architecture for James (not the mailet
> API yet) which looks like this..
> ----
> ProtocolHandler - parses commands per protocol spec.
> CommandHandler - matches command(s) and responds to the protocol
> handler with a response code & message.
> CommandRule - called by command handler to validate command, responds
> with a response code & message
> ----
> Configuration process assigns command handlers to protocol handlers,
> and assigns CommandRules to command handlers.
> ----
> In this way we build up functionality out of simple-to-develop &
> simple-to-deploy classes.
> This (IMHO);
> - matches the simplicity which has been one of mailet's strengths
> - is flexible and doesn't pre-judge individual requirements
> - meets the general requirement for fast-fail, minimising resource
> consumption by unwanted messages, and adherence to protocol RFC's
> - architecture can be applied to all protocols (not just smtp)
> - future proofs existing protocols by encapsulating commands such that
> commands can be modified, added to, reused etc. etc.

In spite of the fact that I brought up a similar idea to Noel's on the
list a while ago, I've changed my stance and have to agree with Danny.

I like Danny's above comments because they resonate really well with the
work I've been doing with MINA.  As I've thought about this problem, it
seams like a much better design to modularize the SMTP handler to
facilitate fast fails.  Trying to pull the mailet system in seams to be
opening a can of worms.


> I'd like to have a crack at this too, along the lines mentioned,
> because I believe that this will also give us an opportunity for ESMTP
> support to accept externally developed Extensions, and for Extensions
> to be deployed by configuration (declaratively).
> It would also provide a framework for releasing minimal compliant
> protocol handlers, such as IMAP and next-generation SMTP and adding to
> or replacing features of these with no impact on existing functions.

The MINA based SMTP handler I've developed already supports extensions
as Danny has described.  For examples, The STARTTLS command handler was
just plugged into the framework and didn't require modifying anything
else.  My current design still needs some additional extensions points
and improved manageability (like the ability to remove an extension
dynamically) but I think it's a step in the right direction.

Danny, I'm interested in your ideas and would like to take a look at
your architecture and see where I can make improvements to what I'm


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

View raw message