On 26 September 2007, Bob Beck <[EMAIL PROTECTED]> wrote:
> > 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*
> 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
