On 26 September 2007, Bob Beck <beck@bofh.cns.ualberta.ca> 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.

quoted text
>       spamd is designed to get the low hanging fruit. It is *NOT*
> 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