Slightly OT: Greylisting success or failure stories?

[Les Mikesell]

On Thu, 2005-02-03 at 15:28, David Hoffman wrote:
> On Thu, 03 Feb 2005 16:09:07 -0500,
> replies-lists-redhat at listmail.innovate.net
> <replies-lists-redhat at listmail.innovate.net> wrote:
> > as someone who has had responsibility for large, time-sensitive,
> > mailings, i think that greylisting is bad. it pushes a high resource
> > cost back on the (legit) sender. while it may reduce the amount of spam
> > you get, it basically doesn't change the spammer's costs. also, since
> > they are dealing with percentages, that the one message to you doesn't
> > get delivered does little in terms of their effectiveness.
> >
> > i have found that using dnsbl to block acceptance from dynamic
> > ipaddress assignments and open relays, along with a well-tuned
> > spamassassin implementation basically rids my mailboxes of spam. in the
> > end i get max 1 untagged spam delivered to my mailbox per day -- for an
> > e-mail address that has been in public use for about 10 years.
> >
> 
> Thank you --- whoever you are (unnamed account), for your comments.
> 
> I do agree that with time sensitive situations greylisting could
> certainly be problematic.

Greylisting has been discussed extensively on the Mimedefang list (since
it includes mechanisms to implement it).  The big value in greylisting
currently is that most spam sources don't bother to retry.  That is,
a tmpfail for unknown sources effectively blocks spam while imposing
only the same kind of delay that a technical problem might have for
legitimate senders.  The key to having minimal impact on normal mail
is to never tmpfail any sender (host) that is known to retry. 

-- 
  Les Mikesell
    les at futuresource.com