Hi Danny, > > My own idea config would look like: > > <smtpHandler> > <!-- Sender based checks. --> > <commandHandler class="Mail"> > <!-- Handle MAIL --> > <command>MAIL</command> > <!-- MAIL expects FROM --> > <commandHandler class="MailFrom"> > <command>FROM</command> > <!-- process a rule --> > <rule class="SenderCheck"> > <!-- if message matches use this response --> > <code>5xx</code> > <description>foo-barred</description> > </rule> > <accept-rule class="accept"> > <!-- if message isn't matched by any rules use this "special" rule > to accept --> > <code>220</code> > <description>OK</description> > </accept-rule> > </commandHandler> > </commandHandler> > </smtpHandler> >
I like your proposal for fastfail, very much in line with my own thoughts. I only have minor comments. As far as I can see we need another class to grasp state information in a consistent way. This is needed if the CommandHandlers action depends on earlier commands having been executed. My best example of this is that "MAIL FROM" might not be allowed unless STARTLS has been executed. Maybe all we need are attributes being passed to each CommandHandler. Also in your example: <commandHandler class="Mail"> do you envision that "Mail" is a user-defined class? I would certainly prefer this as I envision an implementation where I would delegate the fastfail decissions to a policy-daemon that might be running outside James (like reuse of existing postfix policy-daemons). If "Mail" is not a user-defined class such an approach (while still doable) leads to a pretty cumbersome configuration. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax: +45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer <at> tietoenator.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
