SPAM (on list) was:Re: classiccmp list (sort of) help requested
A.MacDonald+classiccmp at slitesys.demon.co.uk
Fri Dec 15 10:27:02 CST 2006
Mike Loewen wrote:
>> It was noted in one of the trade publications I looked at that a very
>> effective check on SPAM was to confirm that the stream opened up to
>> you (on your port 25) actually did a "conversation" with the remote
> Something I've been experimenting with on one of my SMTP servers is
> "greylisting", as implemented in a sendmail milter:
> On my system, it blocks over 95% of SPAM delivery attempts. Most of
> the SPAMbots I've seen attempting to deliver a message don't wait around
> for a reply and simply disconnect when they get the temporary reject
> code. [...]
The problem, as mentioned in a few places online, is that it increases
the burden of sending a (legitimate) email as it spends more time on the
outgoing mail server being repeatedly sent -- I'm not aware of any
system where the rejection message is parsed and then used to insert the
correct retry delay. For the big boys this would massively increase the
amount of work their servers would have to do.
I experimented with greylisting on my servers which handle email for
clients. It worked *extremely* well, but I still had to turn it off
after about 3 days. We found that customers where failing to get email
from people at big ISPs because their systems would not retry the mails
(or didn't do enough retry attempts to pass the 1hr barrier.) Whilst
many people might feel that dropping all emails from AOL is a good
thing my customers didn't seem to agree ...
It might be possible to use in conjunction with other tools, or by
skipping it for the set of ISPs that can't/won't accept being
greylisted, but it really shouldn't be used at the primary filter level.
 AOL wasn't the only one, but it was the most complained about one.
More information about the cctalk