On Mon, 6 Jan 2003, Richard Welty wrote:
> some cautions about DNSBL usage:
[...much snipped...]
> 2) to that end, bl.spamcop.net has the pro that it is very quick and
> responsive. it has the con that it is very agressive,
True. It might be worth pointing out that if an IP appears in both
the spamcop list _and_ one of the technical open-relay or open-proxy
lists, then it's a good idea to refuse mail from it, even if you
wouldn't refuse it on one or the other kind of entry alone.
I presume that this _could_ be tested at RCPT TO time. What we're
currently doing in this area is rating them at RCPT TO time by adding
headers, and then testing those headers at DATA time. On the basis of
only a spamcop entry, or only a technical open-relay/proxy entry, they
get a penalty added to their spamassassin rating: but if _both_
circumstances apply, then they get rejected without bothering with
spamassassin.
On the other hand, we use the JANET mirror of MAPS to do outright
rejection at RCPT TO time - no messing about there. But one of the
shortcomings of MAPS is that although their RSS list is pretty good
about catching open one-hop _relays_ which have been abused for
spamming, we're missing something comparable for abused _proxies_
which now seem to represent a large volume of spam.
> 5) two good ones you left out:
>
> opm.blitzed.org -- open proxies (mostly insecure squid proxies
> and cacheflow servers)
See recent discussion on this list. We now reject mail from those
specific vehicles by testing $sender_ident at RCPT TO time, and if it
matches "CacheFlow Server" or "squid" they're out, without waiting for
blitzed or Osirusoft to catch up with them. It appears to be working
well, as a review of our rejection log indicates.
Oh, by the way, we do have
rfc1413_query_timeout = 10s
to cut down on the time spent hanging around for servers that don't
respond to identd requests.
best regards
