OK, there are many enthusiastic people out there willing to contribute to
James project, so I'm wondering if there is need for more, but still...
My name is Alexander Botov and I'm undergraduate student studying computer
science in Technical University of Sofia, Bulgaria. I've been using James in
production environments during my part time job and I'm impressed by the
mailet/matcher framework, which gives tremendous amount of flexibility for
processing messages. I have extensive background with writing matchers/mailets
and I'm well grounded with the existing ones which come with the official
distribution of James. Generally I'm interested in contribution towards
fast-fail proposal. If James has that feature, this will be major step forward
for the whole project in terms of getting better performance. Danny, I saw
your reply for the fast-fail and I have few comments on it and eventual
proposal. (Sorry for the top-post, this was just an introduction)
> Although the policy isn't written down it is clear from looking at
> James' code that this change will have to be implemented such that the
> protocol handlers are re-desinged in a modular way, and in a manner
> sugested by an OO analysis of the general process of handling
> protocols of this class. (ascii stateful request/response over tcp/ip)
> There are one or two options here, and one part of the task is to try
> to merge everyones requirements and arrive at an approach which gains
> the consensus of the group. The next part is to design some kind of
> simple API (and implement it in James) which will allow "rules" to be
> developed and applied declaratively through configuration, in keeping
> with the way the rest of James functionality is defined. This will
> involve identifying the set of data which the server should make
> available to the rules.
> The third and final part is to then implement some of the required
> rules and release it for testing by the community.
I think that we can follow mailet/matcher approach for handling input during
the SMTP session. Actually it can be simpler - without mailets and with just
one processor. If matcher returns *true*, the action associated with it
(either *accept* or *reject*) will be performed and the processing for
particular SMTP command will terminate. If all matchers return *false* there
should be default matcher which should match all input and does default action
(this is applied per single SMTP command). I will illustrate this with sample
config example:
<smtp-processor>
<!-- Sender based checks. -->
<matcher class="SenderCheck">
<command> MAIL FROM </command>
<action> accept </action>
<code> 220 </code>
<description> ... </description>
</matcher>
<matcher class="All">
<command> MAIL FROM </command>
<action> reject </action>
<code> 550 </code>
<description> ... </description>
</matcher>
<!-- Relay ? . -->
<matcher class="RelayCheck">
<command> RCPT TO </command>
<action> accept </action>
<code> 220 </code>
<description> ... </description>
</matcher>
<!-- Recipient based checks. -->
<matcher class="LocalLookup">
<command> RCPT TO </command>
<action> accept </action>
<code> 220 </code>
<description> ... </description>
</matcher>
<matcher class="LDAPLookup">
<command> RCPT TO </command>
<action> accept </action>
<code> 220 </code>
<description> ... </description>
</matcher>
<matcher class="All">
<command> RCPT TO </command>
<action> reject </action>
<code> 550 </code>
<description> ... </description>
</matcher>
</smtp-processor>
There should be additional checks for the destination peer (RBL lookups, DNS
PTR lookups etc ...) as well.
This proposal is written from scratch, and it surely has gaps or incorrect
points. Even it is applicable, I don't know if it can be implemented without
taking big resource or making big change on the existing James architecture.
Either way I will be very glad if someone has comments on this (if looks like
crap for you don't hesitate to say it ;-)).
Thanks
-- Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
