[James Wiki] Update of "FastFail" by NoelBergman

[Apache Wiki <wi...@apache.org>]

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.
+ --------
+