You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Anagha Mudigonda <an...@yahoo.com> on 2005/06/11 00:27:51 UTC
James FastFail thoughts
Hi,
I have been actively following the Fast fail design
discussions. I was wondering it may be necessary to
configure rule as the following:
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
We not only need session state but some kinda rule
engine if need to support the above feature.
Also I was thinking if the JAMES could be redesigned
to have common framework for IN-PROTOCOL(a.k.a Fast
Fail) or PIPELINE.
In configuration an extra parameter would be there to
indicate the type:
IN-PROTOCOL / PIPELINE. The Pipeline option routed
over Mailet API whereas a new architecture defined for
IN-PROTOCOL.
Anagha Mudigonda
Fast fail Enthusiast
Graduate Student
Polytechnic University
Newyork
__________________________________
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/online.html
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: James FastFail thoughts
Posted by Anagha Mudigonda <an...@yahoo.com>.
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" <no...@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
RE: James FastFail thoughts
Posted by "Noel J. Bergman" <no...@devtech.com>.
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