From: Rod Whitworth (glistenwitworx.com)
Date: Thu Mar 03 2005 - 06:26:44 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Thu, 03 Mar 2005 11:27:23 +0100, Lionel Bouton wrote:

>Greg A. Woods wrote the following on 03.03.2005 09:37 :

>>[ On Tuesday, March 1, 2005 at 00:53:17 (+0100), Lionel Bouton wrote: ]
>>
>>
>>>Subject: Re: Blocking mail from=<>
>>>
>>>Thanks for all of us poor stupid souls coding various greylisting policy
>>>services...
>>>
>>>
>>
>>You're wasting other people's time to solve a problem that you have many
>>other better alternatives to solve.
>>
>>
>>

>Has anyone said that greylisting is the holy grail? Personnaly I start
>with the most safe Postfix UCE controls then hand it to greylisting,
>then to RBLs and finally DSPAM does the delivery.
>I don't think you have 'alternatives' for SPAM filtering, you have a set
>of tools you can choose from but none of them is good enough to be used
>alone.

>>Either accept the mail when it's offered in as efficient a manner as
>>possible (and then either deliver it as addressed or quarantine it); or
>>reject it outright right away.
>>
>>
>>

>The problem is the amount of quarantine (or tagged messages) you
>generate, the amount of CPU/disk space needed to filter the SPAM, the
>time the users must spent searching for FP. Greylisting takes away a
>good chunk of this, even after UCE controls. For admins using RBLs
>before greylisting it either:
>- stops the message
>- delays it enough to allow the RBLs to kick in
>often enough to make them happy with it.

>>Anything else, especially what has been inappropriately called
>>"greylisting",
>>

>Agreed, but the name is here :-/

>> is an unnecessary abuse of the SMTP protocol and is a
>>continual ongoing waste of everyone's time and resources.
>>
>>

>Don't think so, the amount of time a server saves processing messages
>that only greylisting can temporarily refuse far outweight the time
>needed to process the occasional messages that have to be processed
>twice. Sure this time is shared by the sender and the receiver and you
>can argue that it is an "abuse" of the protocol.
>But lets talk about what happens in reality. When I started SQLgrey one
>of my goals was minimising this "waste of time" with auto-whitelisting.
>For the 2 'efficiency' reports I already have :
>- one has more than 99% (ie : less than 1 legit mail out of 100 is
>delayed) after one month of SQLgrey learning,
>- another is at 96% after one week.

>So as far as I can tell this "waste of time" is marginal.

Same for me. In my case greylisting is done at my OpenBSD firewall which also tarpits blacklisted spammers.
Both functions are done by the lightweight smtpd look-alike that only gets to see blacklisted and unknown
senders. It runs on an old P75 and really loafs no matter how much mail is happening. The CPU is 98+ % idle
whenever I look and that box is also running an ntpd and named caching server for a busy little network.

I sometimes see a whole swatch of potential messages for a real address and they never get to the mailbox because
they are worm attacks (viral emails) and never knock twice.

Come to think of it, since the greylisting has been running no user has had a viral email arrive. That alone is
enough to keep me running it. The worm authors will no doubt eventually do something about it if they realsie
what is happening. Meantime it does a good job at doing what it is supposed to.

Watch a spammer being stuck there for about 6 minutes with packet size negotiated to 1 char payload and after all
the effort he gets a 450 and the mail is stuck in his queue. Love it! and zero load on the MTA machine.

>Best regards,

>Lionel.

/Rod/

From the land "down under": Australia.
Do we look <umop apisdn> from up over?

Rod/

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]