Kouhei Sutou | 5 Jul 2009 11:57
Favicon
Gravatar

[PATCH] typos in acl_add_autowhite() [1 Attachment]

<*>[Attachment(s) from Kouhei Sutou included below]

Hi,

I found typos in acl_add_autowhite(). It seems that they are
produced by copy & paste.

Thanks,
--
kou

<*>Attachment(s) from Kouhei Sutou:

<*> 1 of 1 File(s)
http://groups.yahoo.com/group/milter-greylist/attachments/folder/494001708/item/list 
  <*> milter-greylist-autowhite-typo.diff

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/milter-greylist/join
    (Yahoo! ID required)
(Continue reading)

Kouhei Sutou | 5 Jul 2009 14:21
Favicon
Gravatar

[RFC] implementing taRgrey

Hi,

I want to implement taRgrey into milter-greylist. I want to
hear comments about how should I implement it.

= Background

taRgrey is an anti-spam technique based on greylisting and
tarpitting:
  http://k2net.hakuba.jp/targrey/index.en.html

taRgrey's main purpose is decreasing false positives with
low maintenance cost. Decreasing false positives is more
important rather than increasing false negatives because
false negative mails can be detected content-based filter
(e.g. SpamAssassin) but false positive mails can't be
rescued easily. So taRgrey is valuable.

= About taRgrey

taRgrey don't apply greylisting until a SMTP client seems a
spammer. taRgrey uses S25R and tarpitting to decide a SMTP
client is a spammer. A SMTP client is treated as non-spammer
if it passes one of S25R, tarpitting and greylisting. It
decreases false positives.

S25R: It's an anti-spam technique that detects spam-bots
      with SMTP client's FQDN and 7 regular expressions:
        http://www.gabacho-net.jp/en/anti-spam/

(Continue reading)

Emmanuel Dreyfus | 5 Jul 2009 16:27
X-Face
Picon

Re: [RFC] implementing taRgrey

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. Milter-greylist
actually has two kind of clauses in its ACL:
- condtionnal clauses, such as rcpt / <at> 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.

Therefore, you can just drop the 'not' and add a tarpit action clause
to the ACL. It can be used both in racl and dacl, while we are there.

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.

(Continue reading)

Emmanuel Dreyfus | 5 Jul 2009 16:29
X-Face
Picon

Re: [PATCH] typos in acl_add_autowhite()

On Sun, Jul 05, 2009 at 06:57:23PM +0900, Kouhei Sutou wrote:
> I found typos in acl_add_autowhite(). It seems that they are
> produced by copy & paste.

Yes it was. i fixed it in CVS.

-- 
Emmanuel Dreyfus
manu@...

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/milter-greylist/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:milter-greylist-digest@... 
    mailto:milter-greylist-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    milter-greylist-unsubscribe@...
(Continue reading)

Kouhei Sutou | 6 Jul 2009 14:20
Favicon
Gravatar

Re: [RFC] implementing taRgrey

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:
(Continue reading)

Emmanuel Dreyfus | 6 Jul 2009 15:21
X-Face
Picon

Re: [RFC] implementing taRgrey

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.

> 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

--

-- 
Emmanuel Dreyfus
manu@...

------------------------------------

Yahoo! Groups Links

(Continue reading)

Adam Katz | 7 Jul 2009 01:23

Re: [RFC] implementing taRgrey

I've actually been eying tarpits for a while now, specifically leaders
like MailChannels (which some high-volume colleagues of mine use, plus
an award from the MIT Spam Conference).  Their product is actually
very similar to what could be added to milter-greylist with the
implementation of a tarpit command.

I wouldn't actually be surprised if tarpitting was in almost every way
better than greylisting; I'd strongly consider reconfiguring my
servers use tarpitting over greylisting in every case (perhaps with a
10s grey-time on Windows desktop OS "servers" before the tarpit).

The sendmail configuration option "greet_pause" is a basic form of
tarpitting with astounding affect.  See the testimonial at
http://www.acme.com/mail_filtering/sendmail_config.html#greet_pause
and data at http://mailchannels.com/images/drop-off.png

One important implementation note:  if the connecting server drops the
connection but then comes back later, the tarpit clock should have
been counting from that first connection.  (Otherwise, some
noncompliant servers might never deliver mail.)

One more note on tarpitting:  the full-on implementation is actually
that of a connection throttle; traffic is let through very very
slowly.  The idea of pausing often accomplishes the same thing, but
it's easily interpreted as a lost connection.  A good tarpit
implementation would actually have variable dynamic throttle rates (or
at least several bandwidth thresholds), and no tarpit mechanism should
throttle longer than 300-500 seconds (see above linked image).

As to taRgrey, it appears to bring two concepts to the table:  the
(Continue reading)

Kouhei Sutou | 7 Jul 2009 10:02
Favicon
Gravatar

Re: [RFC] implementing taRgrey

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
(Continue reading)

Kouhei Sutou | 7 Jul 2009 10:23
Favicon
Gravatar

Re: [RFC] implementing taRgrey

Hi,

In <4A52878B.3030209@...>
  "Re: [milter-greylist] [RFC] implementing taRgrey" on Mon, 06 Jul 2009 19:23:55 -0400,
  Adam Katz <yegsa-yahoo@...> wrote:

> One important implementation note: if the connecting server drops the
> connection but then comes back later, the tarpit clock should have
> been counting from that first connection. (Otherwise, some
> noncompliant servers might never deliver mail.)

I want to rescue the servers by greylisting not tarpitting.

> After reading a bit on S25C, I'm quite dubious. No concrete data on
> false-positives is presented and the whitelist is MASSIVE.

Yes. S25R has some false positives. We need a whitelist when
we use S25R.

We can use S25R with greylisting to maintain our whitelist
automatically.

Here is a configuration to use S25R in milter-greylist:

  extendedregex
  racl greylist domain /^\[.+\]$/ msg "S25R rule 0"
  racl greylist domain /^[^.]*[0-9][^0-9.]+[0-9].*\./ msg "S25R rule 1"
  racl greylist domain /^[^.]*[0-9][0-9][0-9][0-9][0-9]/ msg "S25R rule 2"
  racl greylist domain /^([^.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]/ msg "S25R rule 3"
  racl greylist domain /^[^.]*[0-9]\.[^.]*[0-9]-[0-9]/ msg "S25R rule 4"
(Continue reading)

Bob Friesenhahn | 7 Jul 2009 16:59
Picon
Picon
Gravatar

Re: [RFC] implementing taRgrey

On Mon, 6 Jul 2009, Adam Katz wrote:
>
> One more note on tarpitting:  the full-on implementation is actually
> that of a connection throttle; traffic is let through very very
> slowly.  The idea of pausing often accomplishes the same thing, but
> it's easily interpreted as a lost connection.  A good tarpit
> implementation would actually have variable dynamic throttle rates (or
> at least several bandwidth thresholds), and no tarpit mechanism should
> throttle longer than 300-500 seconds (see above linked image).

It seems like this makes your server susceptible to DOS.  It also 
assumes that the bots are implemented well and will sever slow 
connections.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/milter-greylist/

<*> Your email settings:
    Individual Email | Traditional

(Continue reading)


Gmane