I just committed a small refactoring on your last code, let me know if
this make sense.
I think we should remove every reference to "Junk" from concrete
implementation and keep the "action" knowledge for the Abstract class.
I also think we should better rename it AbstractFastFailHandler because
we'll probably use this for real fastfail operations (junkscore is
mostly for this goal). Otherwise something like AbstractJunkHandler.
Maybe we should simply return SMTP code, DSN code and a description and
then use the same description for junk logging or SMTP reply.
My idea is that in future for this specific handler we should use
something more specific than the CommandHandler. I would prefer to only
return "PASS", "PERMERROR", "TEMPERROR" as the result of the "match"
operation and then having a standard code that know how to reply a
PERMERROR to an RCPT command or how to reply a TEMPERROR to a given MAIL
command, and so on.
Maybe we should see this fastfail handlers as plugins to the standard
MailCmdHandler/RcptCmdHandler... and maybe this could be a first step to
model the "Common Services" Noel referred on the mailet-api list.
Stefano
Norman Maurer wrote:
Im not 100 % sure if im happy with this.. Any suggestions ?
I thought about to add an interface which handlers must implement if
they want to support JunkScore creation.. But after i did some coding i
changed it back.. The main problem is that i don't want to add a new
method to the SMTPSession interface.. So i need to store these stuff in
the state maps and retrieve it later again. So if i want to add such an
interface i need to store the stuff anyway in the state map cause
otherwise we will get problems with synchronize..
Any ideas are welcome ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
