discuss: Re: Review needed: Spam Filtering for Mail Exchangers (fwd)
Subject:
Re: Review needed: Spam Filtering for Mail Exchangers (fwd)
From:
Tor Slettnes ####@####.####
Date:
2 Jul 2004 21:50:40 -0000
Message-Id: <CB0AC597-CC71-11D8-BF76-0030656CF512@slett.net>
On Jul 2, 2004, at 02:18, Shuvam Misra wrote:
> I asked a friend, who is not a member of this list, to review the Spam
> Filtering HOWTO.
Good idea. Thanks!
> In fact it was with his feedback that we have
> implemented (Sendmail-based) spam filtering on our servers.
Sounds very interesting. Do you suppose your server configuration
might be useful in this document?
> ---------- Forwarded message ----------
> Date: Fri, 2 Jul 2004 16:55:32 +0800
> From: (Name Withheld)
> To: Shuvam Misra ####@####.####
> Subject: Re: Review needed: Spam Filtering for Mail Exchangers (fwd)
>
> Quite unobjectionable. Caller verification works. Timeouts are Ok, I
> am
> worried about race conditions if both sides are using it.
There is no race condition under normal circumstances. Such
verifications happen with a NULL sender ("MAIL FROM:<>"), and so the
host that is being asked to do the first verification, in turn, has no
sender to verify.
That is, of course, until you change the "sender=" option to this
feature - something that people normally only do for _recipient_
callout verification.
There _may_ be a race condition involved if a recipient host is
performing sender callout verification back to a MX that imposes
indiscriminate SMTP transaction delays. That's why the document
suggests 20 seconds for such delays - the default callout verification
timeout per command is 30 seconds.
> I am using all the options he has given, except for greylisting. A
> guaranteed 1 hour wait is not acceptable.
Hmm, this comment makes me think that greylisting is not explained
clearly enough.
The one hour wait happens only on the _first_ message for a given
sender/senderhost/recipient triplet. Thereafter, the triplet is added
to a whitelist, and future deliveries are not subject to delays.
I personally find this technique much more acceptable than some other
mechanisms that people use (DNSbls, requesting confirmation by the
sender, and some types of content filtering, to name a few). Unlike
these latter techniques, greylisting involves virtually ZERO false
positives - legitimate mail is always delivered. About 90% of
current-generation spam is blocked, at a very low cost to the server
CPU or network bandwidth.
More details on Evan Harris' web site:
http://projects.puremagic.com/greylisting/
