On 26 September 2007, Bob Beck  wrote:

quoted text
> >     Oh, I'm not saying it doesn't work.  What I'm saying is,

> > greylisting is trivial to bypass, and some spammers have figured

> > that out.  Amazingly, most of them still haven't, which is why it

> > still works in a significant number of cases.

> >

>

>       greylisting does what it does. It delays the initial email for

> 30 minutes or more. what you do with that 30 minutes will decide on

> how effective it is for you.

>

>       In that 30 minutes)

[...]

    Ok, brain dump:
    That's an interesting idea, a lot of slow operations could be

offloaded to those 30 minutes.  Your greyscanner script does DNS checks

on the envelope.  A lot more could be done, should the script have

access to the body.  I think it's legal to reply with 4xx (that is,

simulate a queue error) to the final "." . That could be used to gather

and inspect the data; basically do at greylisting time what Postfix does

with the "after-queue filters".
    I suppose gathering everything would be prohibitive though, and

against the entire philosophy of greylisting.  Which brings me to a

different approach: use a "pre-queue filter" instead of spamd (which is

what I'm doing now).  Now, the problem with pre-queue filters is they

can take too long to scan a message.  Thus, the better mouse trap: a

pre-queue filter, which can send feedback to smapd, and use spamd's

database to keep some state across messages.  I need to ponder on that

some more.
>       spamd is designed to get the low hanging fruit. It is *NOT*

quoted text
> designed to stop all possible spam, forever. attempting to do so there

> is wrong. Spamd is a *tool* - it's good for what it's good for -

> stopping stuff that is easily identifiable in the smtp dialogue. It is

> not intended for other things.

    We are in violent agreement here...
    Regards,
    Liviu Daia
--

Dr. Liviu Daia                                  http://www.imar.ro/~daia