15 Dec
2006
15 Dec
'06
8:27 a.m.
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
player.
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[1] 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.
Alistair
[1] AOL wasn't the only one, but it was the most complained about one.