This is a reply to three emails... sry, just thought it best this way ;)
>
>On Tue, 23 Mar 2004, Edgar Lovecraft wrote:
>
> > I thought the entire idea for greylisting is that 'spamers do not
> > retry',
>
From Alan J. Flavell wrote:
>
> Not only...
>
????? what else then?
>
>On Tue, 23 Mar 2004, Edgar Lovecraft wrote:
>
> > so why do the Greylisting Docs suggest such a long period of time
> > before the accept??
>
From Alan J. Flavell wrote:
>
> RTFM - See http://projects.puremagic.com/greylisting/ under the
> subheading "Basic Configuration Parameters", where it says "The
> initial delay of 1 hour was picked for several reasons:".
>
From Dean Brooks wrote:
>
> The longer delay is more to prevent a spammer who sends multiple
> identical messages in a 20 minute period from triggering an automatic
> whitelisting. It's not perfect by any means, but a properly
> configured server should hopefully continue to retry even after the
> initial hour, and the hour delay will prevent multiple messages in a
> short period from being whitelisted inadvertantly.
>
From Alun wrote:
>
> I chose 1 hour fairly arbitrarily. It's likely that 15 minutes would do
> the job just as well at the moment, but we do need to ensure that it
> really hurts the spammers. You can get around greylisting by hitting a
> bunch of servers, then revisiting them some time later. I chose an hour
> because I want there to be a good chance that they've got listed in a
> DNSBL in the meantime.
>
I had read the manual, but it some time ago, and I had forgot that
they had that in there, oops ;)
however, after re-reading it again, I am still at my hang up point
as I was when I first RTFM for full implementation at my site because...
<qoute from the manual>
The data collected during testing showed that more than 99% of the
mail that was blocked with the tested setting of 1 hour would still
have been blocked with a delay setting of only 1 minute. However,
it is expected that as spammers become aware of this blocking method,
they will change their software to retry failed deliveries. At that
point, having a larger initial delay will definitely help, as it gives
time for other blocking methods to act. For this reason, it is suggested
that at least a one hour delay value be kept as a default, since spammers
will start adapting as soon as this method becomes known and starts being
used.
</qoute from the manual>
From Alan J. Flavell wrote:
>
> You might or might not agree with those reasons, but they seem at
> least plausible to me. I'm not criticising what Aber are doing - just
> taking a look to see if the resulting (small but unnecessary) network
> overheads could be reduced.
>
From Dean Brooks wrote:
>
> 2. Be prepared to deal with delays on incoming mail from new sources.
> For example, if you went to a website you forgot the password to
> and ask them to email it to you, it will take an hour to get it
> at a minimum.
>
> 3. Some spam will still get through, either because they retry or
> because they send another message to you an hour or so later.
>
> All in all, Greylisting is a good last resort, but it's really a
> desparate hack that works somewhat well if you dont mind the downsides.
>
I am not criticizing either, I am curious as to how others are using
this technique and still mulling it over in my head as to how I can
best use the idea to my advantage with the least amount of drawbacks.
For me, delaying email any longer than necessary is a huge drawback.
From Alun wrote:
>
> I've got another idea I'd like to try at some point - make the dead time
> dependent on the number of greylisted records outstanding against the
> incoming IP address. So, if you've only got one sender/recipient pair
> outstanding, you get delayed 10 minutes. If there are 1,000 of them,
> we ramp up your dead time. That ought to make the "hit & run & come back
> again" spammer fail too.
>
similar to the 'bad helo info == delay * something' approach,
interesting....
>
>On Tue, 23 Mar 2004, Edgar Lovecraft wrote:
>
> > Ah well, greylisting is a nice idea, I have just not figured out what a
> > good balance for its use would be yet, and I do not think that all
> > email should be greylisted "just because".
>
> I believe that Aber's got the balance right (after a few tweaks during
> the first week we ran it). Not all mail gets greylisted. With my
> implementation, around 7.5% of legitimate mail gets delayed. It's only
> the first mail you send to someone here that'll get delayed and then,
> only if they've never mailed you directly and you're coming from an IP
> address which hasn't delivered enough legitimate traffic to us to get
> itself whitelisted.
>
> Greylisting is the only anti-spam strategy that I've introduced in the
> past five years that has caused local users to comment on a sudden
> decrease in received spam. That's a good enough "just because" for me :-)
>
I have been kind of think of something along the lines of:
'bad IP DNS == greylist'
'bad HELO == greylist'
'looks like DUL == greylist'
This type of thing.
I suppose that 'greylisting' does not mean 'all connections all the time',
that is just the 'feeling' I take everytime I have RTFM.
Thanks for the replys, are there any other 'interesting' ideas that
people have in place?
Unfortunatly SPAM stomping needs many tools, some are just beter than
others, and I prefer to use the 'best match' for my situation.
Of course, if I did this just for me, it would be easy
(I don't know you, go away :)
--
--EAL--
