Milter-greylist

Hi,

In <20090706132156.GF28641@...>
  "Re: [milter-greylist] [RFC] implementing taRgrey" on Mon, 6 Jul 2009 13:21:56 +0000,
  Emmanuel Dreyfus <manu@...> wrote:

> On Mon, Jul 06, 2009 at 09:20:44PM +0900, Kouhei Sutou wrote:
>> I want to use tarpitting as a condition.
> 
> That does not make sense for milter-greylist ACL, as a negative
> result cause ACL processing to stop there.

It seems that I omitted needed information. Sorry.

milter-greylist needs to keep a SMTP client information
whether it passed tarpitting before. Its behavior is similar
to greylisting.

Greylisting:

  The 1st try:
    client-X                 milter-greylist
               - connect ->
                             marks client-X as pending.
               <- reject -

  The 2nd try:
    client-X                 milter-greylist
              - connect ->
                             checks client-X whether it is in
                             the pending clients.
        <- accept client-X -
          by auto-whitelist

Tarpitting (as I am proposing):

 case1:
  The 1st try:
    client-X                 milter-greylist
               - connect ->
                             checks client-X whether it had
                             been tarpitted. -> NO
               <- tarpit -
           (still connected)
         - the next command ->
                             puts client-X into auto-whitelist.

  The 2nd try:
    client-X                 milter-greylist
              - connect ->
                             checks client-X whether it is in
                             the auto-whitelist.
        <- accept client-X -
          by auto-whitelist

 case2:
  The 1st try:
    client-X                 milter-greylist
               - connect ->
                             checks client-X whether it had
                             been tarpitted. -> NO
               <- tarpit -
           (disconnected)
                 - abort ->
                             puts client-X into greylist.

  The 2nd try:
    client-X                 milter-greylist
              - connect ->
                             checks client-X whether it had
                             been tarpitted. -> YES
                             checks client-X whether it is in
                             the greylist. -> YES
        <- accept client-X -
          by auto-whitelist
          because client-X
          passes greylisting.
          (This is the 2nd try
           of client-X)

The key point of the above examples, tarpitting is used as a
pre-condition whether we use greylisting or not. Tarpitting
isn't used as a stand-alone anti-spam technique. Using
tarpitting as a pre-condition, we can decrease false
negatives. (A SMTP client can be accepted if it passes
either tarpitting or greylisting, not both of them.)


This is the reason why I want to use tarpitting as a
condition. Should I create a new ACL class instead of
'tarpit' clause for it? Could you here your comment?

> That does not make sense for milter-greylist ACL, as a negative
> result cause ACL processing to stop there.

In 'The 2nd try' cases, we can use a negative result because
milter-greylist knows 'client-X' was tarpitted before.
Does this make sense?

>> We can't append another clauses after 'tarpit' clause. Is it
>> acceptable behavior?
> 
> I think that what we need here is a new ACL class. I have been thinking
> about it for a while: We have whitelist, greylist and blacklist, all of
> them stop ACL evualuation on match.
> 
> We need a continue ACL, that allows action clause to be fired whithout
> having to stop ACL evaluation there:
> 
> racl whitelist addr 127.0.0.0/8
> racl whitelist domain example.net
> racl continue tarpit 65s
> # if tarpit failed the client is not there anymore
> racl greylist delay 15m

Thanks for your new idea.
But I want to use 'greylist' if the client was failed
by tarpitting before... It's negative condition.


Thanks,
--
kou