On Wed, Dec 05, 2001 at 12:18:24PM +0000, Drav Sloan wrote:
> Suresh Ramasubramanian wrote:
> > There are plenty of third party blocklists available for this - which can be
> > queried using exim.
> Of which I'd argue the majority are mostly useless/out of date/have
> very bad policies/will not listen to the public.
Yes. I agree with this.
> I also would agree with Sharun; I'd like to see the ability for exim
> to maintain it's own db of 'open relays' by verifying this at connection
> time from other hosts - (very much like the verify_recipients option).
Erm? You mean doing a callback to test for open relay? Are you completely
insane, or completely clueless? There are several reasons not to do this.
1) it is hostile to mailadmins who maintain clean machines.
2) you're assuming that a relay can be delivered straight away, or that
acceptance of responsibility for the message is an indication of that
machine being about to relay it.
3) you will probably get the tests wrong, think of the time when 127.0.0.1
hit the MAPS RSS, and loads of people started generating X-RBL-Warning
headers, which were (incorrectly) rejected by other people's mail
filters.
4) you will waste enormous amounts of bandwidth.
> Is there similar, has anyone heard of anyone managing to impliment this?
If you just delay messages[1] initially, and change the delay parameters
depending on what lists they are on, rather than outright rejecting them
things work a bit better. Often this means that other people complain
about the spam run and the machine gets pulled.
[1] by issuing a 450 in response to the RCPT TO:< line in the SMTP dialogue.
I've found this trick works extremely well...
of course,
5) you will have problems with anybody who implements such a system on their
mailserver, as you'll have to wait to be able to test it.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
