On 09/05/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > In a REAL SMTP environment I think we need to allow custom behaviour in > reply to the "RCPT TO" (recipient not local, relay not allowed) and in reply > to the "DATA" commands (this is spam, mail too big, no virus please, other > content filters).
My proposal addresses this. > The latter could be addressed with the pre-processor (but please find a > solution to my question: what happen if the preprocessor splits the mail?) > but the rcpt reply not. My proposal would have any rule in any command handler of any protocol capable of returning a hard or soft fail response with a custom message generated in response to the exact mode of failure, by the rule that judged the command to fail. > For the "RCPT TO:" stuff I think we should add a specific handler, but I > would hardcode the management of this handler and leave for later the > automatic extensibility for each command! Why? If we simply refactor the doXYZ() methods into ProtocolCommand.execute(String command, Object state) we get the architecture. I did HELO, EHLO & RCPT TO last night. > Can you point to other situations in the SMTP session that needs > extensibility at deploy time? To add extended commands per ESMTP without having to modify the core SMTP commands. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
