Re: [exim] Milter interface for Exim

John Jetmore schrieb:
> On Sat, 27 May 2006, W B Hacker wrote:
>
>> 'All of the above' - and a great deal more - have been built-in
>> to Exim for (some variable number) of years, so no identifiable
>> need.
>
> I support (and have had on my personal wishlist for a while now(*)) having
> a milter interface in Exim. There are a ton of products out there that
> use the milter protocol because it's the only filtering standard there is.
Yes, there are several things I'd like to try out, but wouldn't know how
to easily implement them using Exim-ACL. For example, I'd like to have
some rate-limiting, which should keep an average of mails/timeunit sent
by some IP, which should send alerts to the abuse-team whenever a known
IP of our internal networks shows a significant derivation. There are
milters out there that would be quite close, and even if I had to start
from scratch, milters are really easy to write, in C, C++, Python, Perl,
TCL or Java.....


However, the question isn't so much "should milter be available for
exim", but mor along the lines of "how to do it with ACL".

Solution 1:
define your milters in main-configuration and have each milter evaluated
before interpreting each ACL, to make the results available in that ACL.
If I understand it correctly, that would be close to the way sendmail
does it, but I have no sendmail-experience, I just read some
documentation. Basically, "$milter_result" would be availabe in the ACL
and contain "reject", "defer", etc.

Pro: close to sendmail
Con: if using several milters, you wouldn't know which one caused the
$milter_result. Efficiency wouldn't be perfect, e.g. if I had "if
fast-to-evaluate-condition reject, if $long-running-milter-result=deny
reject", the milter would be evaluated first, though the other condition
might hit the message anyway...

Solution 2:
have some new ACL-statement (like "malware" or "spam") which could be
placed anywhere in the ACL, offering better performance (only evaluated
if actually necessary), different milters might be specified, e.g. after
rcpt-to only evaluate MilterA, after data evaluate MilterB, but I'm not
sure wheter that would be actually compatible to sendmails
implementation/behaviour.

Pro: Speed and flexibility
Con: would it break compatibility?

Solution 3:
Put it in String-expansion, e.g. "${milter{some-options}}".
Pro and con should be quite similar to solution 2.


--
CU,
Patrick.