Norman Maurer wrote:
Hi Stefano,
i don't like most of your refactoring. See my reply to your commit..
More comments inline ..
Stefano Bagnara schrieb:
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.
Can you ellaborate ?
Imho a fastfail filter should simply say if it is matching or not (maybe
if the matched error is something permanent or temporary), and something
common should be used to decide whether to block or to add informations
to a junk score or anything else we could elaborate later.
What exactly you don't like? I simply moved common code from
specializations to the abstract class, not a big deal indeed.
Anyway, feel free to revert the code if you preferred the previous one.
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
This sounds like a good idea .. Maybe you can give a small example ?
I think I will have a better overview and it will be easier to
understand how to proceed once we refactored more classes to use this
pattern.
Then we should try to see what subset of SMTPSession is used by the
handlers and try to understand if it worth extracting a "fastfail
context" from SMTPSession, to make the most common use case of this "new
api" more user friendly.
But now it is probably too early to talk about this...
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
