Matthew Byng-Maddick wrote:
> > 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.
I hope not clueless, so people may argue otherwise. I would argue
the are reasons for doing this...
> 1) it is hostile to mailadmins who maintain clean machines.
The upsteam users are 'customers' and not 'the internet', a large
percentage run open relays against our AUP causing excessive amounts
of spam to be relays through our systems. The results we end up
with are our smarthosts ending up on 'Open Relay' dbs (even though
we are not the open-relays) and no longer can send mail to allsorts
of places. This is NOT acceptable and is also something we presently
have no power over.
> 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.
If the machine is sending mail to us, there is a good chance you can
connect back; if they are not responding the mail is 4xx'ed on
the envelope RCPT TO. Any that accepts are taken as 'okay' but a valid
return address is used which can be then used to manually add 'additions'
to this database.
> 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.
I'm not adding headers, I'm not using third party lists. I'm mainating
a db of people who 'Connect to me who are open relays'.
> 4) you will waste enormous amounts of bandwidth.
Not if the values are cached.
> 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.
I would be using 4xx series as stated above. These are customers
after all :)
> [1] by issuing a 450 in response to the RCPT TO:< line in the SMTP dialogue.
U huh.
> 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.
?? You mean it will have to verify you before it verifies itself? This
would be understandable. Once a host is verified the value of 'an okay'
box is put in the db, and future delivery is instananeous.
So; does anybody know any form of mechanism to be able to call external
functions to verify sending domains of received emails; are there any form
of 'command hooks' - like libperl with exim or similar? I'd be interested.
Regards,
D.
--
David Sloan - Senior Mail and News Systems Admin - Platform Management
Tel: +44 845 272 0666 Fax: +44 20 8371 1167 Email: dsloan@???
