Dear Wiki user, You have subscribed to a wiki page or wiki category on "James Wiki" for change notification.
The following page has been changed by NoelBergman: http://wiki.apache.org/james/FastFail The comment on the change is: add rough proposal for generic fast-fail ------------------------------------------------------------------------------ DannyAngus ---- + -------- + + This is a proposal from Noel J. Bergman + + ---- + + Danny has some information on http://wiki.apache.org/james/FastFail for his proposal. That is one of several that have come up. + + Danny and I are largely in agreement on on having some form of handler for each of several kinds of event: + {{{ + - onConnect + - on<SMTP-COMMAND> + - onMessage + }}} + I'm not particularly married as to how it would be done, but I do have requirements: + + * fast + * flexible + * extensible + * configurable + + One possibility is doing something like: + {{{ + <handlerchain> + <handler class="org.apache.james.smtpserver.dnsrblhandler"> + <rbl>...</rbl> + </handler> + <handler class="org.apache.james.smtpserver.spamassassinhandler"> + ... config ... + </handler> + <handler class="com.devtech.james.smtpserver.somehandler" onConnection=false onMessage=false onCommand="HELP,AUTH"> + ... config ... + </handler> + <handler class="com.devtech.james.smtpserver.pipeline"> + <root> starting-processor </root> + <processor name=..." class="..."> + <mailet match="ClamAV" class="SMTPResponse"> + <code>554</code> + <notice>554 - delivery error: ClamAV reports that it detected {1} in message content.</notice> + </mailet> + </processor> + </processor name=..." class="..."> + ... + </processor> + </handler> + <handler class="org.apache.james.smtpserver.basehandler"> + ... config ... + </handler> + </handlerchain> + }}} + where the administrator simply liststhe handlers desired, along with their configuration. Internally, we inspect the handler to find out what events it handles. So we would have interfaces (incomplete here): + {{{ + interface ConnectionHandler ( + onConnection(Socket) + } + + interface CommandsHandler { + Map getCommands() + } + + interface CommandHandler { + onCommand(...) + } + + interface MessageHandler { + onMessage(...) + } + }}} + and each of the registered handlers would be inspected to see whether or not they implement an interface. For a ConnectionHandler or MessageHandler, it would be appended to the handler chain for that event. For a CommandsHandler instance, it would be queried for the Map, which would be merged into the master Map, such that the master Map would have a single chain for each supported operation. + + I have also illustrated here how to handle micromanagement of handler order. In the typical case, having to list each and every operation would make configuration difficult. + + Once this is implemented, the MessageHandler provides where we could plugin either special code, e.g., the hypothetical spamassassin handler, or generic code like my example with the pipeline (in-protocol processor) handler. A custom onMessage handler could support an new message management that would come along, such as in-line BSF scripts, jsieve, etc. + -------- +
