Milter-greylist

Hi,

Thanks for your comment.

In <20090705142730.GA22288@...>
  "Re: [milter-greylist] [RFC] implementing taRgrey" on Sun, 5 Jul 2009 14:27:30 +0000,
  Emmanuel Dreyfus <manu@...> wrote:

> 
> On Sun, Jul 05, 2009 at 09:21:12PM +0900, Kouhei Sutou wrote:
>> (1) Adding 'targrey' action.
>> e.g.: racl targrey CONDITIONS ... sleep 65s
> (...)
>> Pros.: Easy to read.
>> Cons.: New action.
> 
> And the new action be difficult to integrate with existing ACL.
> 
>> (2) Adding 'tarpit' ACL clause.
>> e.g.: racl greylist CONDITIONS ... not tarpit 65s
> 
> That one seems nicer, but could be imporved a bit.

OK. I'll use ACL clause not action.
We agree on configuration syntax, doesn't it?

I'll start to talk about implementation. It's the next stage. :)

>                                                    Milter-greylist
> actually has two kind of clauses in its ACL:
> - condtionnal clauses, such as rcpt /@evilsapmmer\.com$/
> - action clauses, with will always evalute to true. eg: msdg "go ayay"
> 
> IMO, tarpit fall in the latter category, since there is no conditionnal
> testing to perform: if the remote host fails the tarpit, it hangs up
> before the delay, and the ACL evaluation stops here because the connexion
> is closed.

I want to use tarpitting as a condition.

I want to use greylisting only if tarpitting IS
failed. Because a SMTP client that passes tarpitting may not
be spam-bot. spam-bot will not wait a long time because it
wants to send many spams. It doesn't want to wait a long
time.

I don't want to apply greylisting to spam-bot to reduce
false positives if a SMTP client isn't spam-bot.


I want to use tarpitting as a condition because of the above
reason but 'tarpit' clause behaves like action clause as you
write.

We can't use other conditions after 'tarpit' clause. We need
to wait the next milter event to detect the connection is
closed.

It's a limitation of both of libmilter and MTAs (Sendmail
and Postfix). Implementations of them can't detect the
connection is closed while a milter event is
processing. Connection closing is detected in their event
loop. We need to return a milter event response to cycle
their event loop.


Pass case:
  a SMTP client     milter
         RCPT TO -> ...
                    tarpitting
                 <- response
            DATA -> detect tarpitting is passed!

Failure case:
  a SMTP client     milter
         RCPT TO -> ...
                    tarpitting
   <disconnect>     ...
 (not detected yet) ...
 (not detected yet) tarpitting
    detected!    <- response
           abort -> detect tarpitting is failed!

We can't append another clauses after 'tarpit' clause. Is it
acceptable behavior?


> On the implementation: conditionnal clauses have been refactored some
> time ago to use function pointers so tht less code is duplicated.
> Check for acl_clause_rec in acl.c. Unfortunately, action clauses
> are still in the ancient world, with a lot of duplicated code.
> 
> You can choose to either add a quick hack to support the tarpit clause,
> or refactor action clauses to use the same scheme as conditionnal clauses.
> Choose the quick hack if you don't feel confortable with the code.

Thanks for the information!

I can choose both of them. :-)
If I choose the refactoring way, I'll send a patch for it
before send a patch for 'tarpit'.


Thanks,
--
kou