james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anagha Mudigonda <anaghamudigo...@yahoo.com>
Subject RE: James FastFail thoughts
Date Sun, 12 Jun 2005 15:38:06 GMT
Noel,

I like the design you proposed for the protocol
handler framework so that Fast fail is a mere
extension to it. Moreover the rest of protocols can be
rewritten around the new framework. Here is my design
proposal very much on the lines on yours and Danny's.
Please review and let me know your feedback.

A typical command response protocol sequence

client>  command [argument]
james> response code and description
client>  command [argument]
james> response code
client>  message and message terminator
james> response code


At a high level, command response protocol handler can
two states – RECEIVE_COMMAND_STATE,
RECEIVE_MESSAGE_STATE.


Breaking the steps of in-protocol handling:
1. Parse the command and create command object
2. Validate the arguments and respond back upon
failure
4. If all necessary validations pass, respond back
success
5. If Message is expected, read the message till
termination
6. Validate the message content and generate response
upon failure
6. If all the message validations passed, generate
accept for delivery message
7. Hand over the mail to spooler for further
processing in the pipeline

I came up with a set of 5 framework classes (can be
placed under a new package org.apache.james.protocol.*
or org.apache.james.common.protocol.*)

//For eg: SMTPHandler
Public interface ProtocolHandler
{
  CommandHandler getCommandHandler(String
commandString);
  Validator[] getConnectionValidators();
  SessionState getSessionState();
}

//for eg: SMTPSessionState
Public interface Session state
{
  boolean isCommandAllowed(String cmdStr); //is this
command allowed
  boolean isCommandValidationRequired(String cmdStr);
// for short circuiting any necessary validations
  boolean isMessageValidationRequired(String cmdStr);
// for short circuiting any necessary validations

  void setCommandStatus(String command, boolean
status);
  int getState(); //COMMAND_STATE, MESSAGE_STATE
  CommandHandler currentCommandHandler(); // handling
message associate with the command
  reset(); //reset state
}

//MAILCommandHandler, RCPTCommandHandler and
DATACommandHandler and so on
Public interface CommandHandler
{
  Response onCommand();
  Response onMessage(InputStream in);
  Void registerCommandValidator(Validator
cmdValidator);
  Void registerMessageValidator(Validator
msgValidator);
}

//for eg: SuspectRemoteAddressResponse
Public interface Response
{
  String getCode();
  String getExtendedCode();
  String getDescription();
}

//Validator classes 
public interface Validator
{
  Response validate(); //returns null if successful,
else fails with response object
  Void configure(..)
  getType(); //validators for Connection, Command,
Message
}



I have tried to arrive at a configuration (still looks
messy). I need help to refine this part
<Protocol name=SMTP
class="org.apache.james.smtp.SMTPProtocolFactory">

<sessionState
class="org.apache.james.smtp.SessionState">
<ConnectionValidator class=”myConnectionValidator”>
  <response code=220 type=”default” >Welcome
message</response>
   config..
</connectionValidator>

<command name="MAIL"
class=”org.apache.james.smtp.MailCommand”>
  <response code=2xx type=”default” onCommand=”yes”
onMessage=”No”>..</response>
  <commandValidator class="RecepientValidator">
    <response ..> </response>
     config..
  </commandValidator>
  <commandValidator class="UserQuotoValidator">
    <response ..> </response>
     config..
  </commandValidator>
</command>


<command name="DATA"
class==”org.apache.james.smtp.DataCommand”>
  <response code=2xx type=”default” onCommand=”yes”
onMessage=”No”>..</response>
  <response code=2xx type=”default” onCommand=”No”
onMessage=”Yes”>..</response>

  <commandValidator class="RecepientValidator">
    <response ..> </response>
     config..
  </commandValidator>
  <commandValidator class="UserQuotoValidator">
    <response ..> </response>
     config..
  </commandValidator>

  <MessageValidator class=" SpamAssasinHandler">
    <response ..> </response>
     config..
  </MessageHandler>
  <MessageValidator class="your custom handlers">
    <response ..> </response>
     config..
  </MessageHandler>
</command>


Questions:
Can we leverage in some way code written for mailet
through some kinda adapters?
Not sure what parameter to pass to configure method in
validator. Is it ok to pass XML configuaration string?

--anagha.


--- "Noel J. Bergman" <noel@devtech.com> wrote:

> Anagha Mudigonda wrote:
> 
> > If MAIL FROM validation passed SPF then no need to
> Validate RCPT TO
> > If MAIL FROM, RCPT TO Passed then no need to
> validate DATA
> 
> Well, I'm not so sure about those rules, but that's
> separate from how one
> might do them.
> 
> > We not only need session state but some kinda rule
> > engine if need to support the above feature.
> 
> I'd consider that status information, and allow the
> handlers to decide
> whether or not to short-circuit.  It would be quite
> bad were someone to say,
> "Oh, I've verified the sender, so I needn't bother
> with the RCPT TO
> handlers" when the address still needs to be
> validated (and possibly mapped)
> to know if we handle will accept it or not.
> 
> The proposal I put forth wasn't just fast-fail, but
> pluggable in-protocol
> handler packages.  In fact, as I envision it, the
> "base" package would
> include the default onMessage handler that knows how
> to post a message into
> the spool.  That makes even that mechanism
> pluggable.
> 
> 	--- Noel
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail:
> server-dev-help@james.apache.org
> 
> 


Asatoma Satgamaya (Lead me From falsehood to truth)
Tamasoma Jyotirgamaya (From darkness to light)
Mryutorma Amrutangamaya (From death to immortality)

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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