On Wed, Dec 05, 2001 at 12:55:10PM +0000, Drav Sloan wrote:
> Matthew Byng-Maddick wrote:
> > 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...
There is a reason for doing a relay test, yes. Just not within the SMTP
dialogue.
> > 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
Right. In which case you can run continual relay probes, rather than every
time they connect. And accepting the probes can be part of your AUP.
> 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
Sure.
> 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.
Yes. Most of the sensible databases differentiate between the types of
open relays.
> > 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
That's not necessarily true.
> 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.
I'd do *only* that, and completely asynchronously with respect to the SMTP
dialogue. After all, you're not required to accept SMTP to emit it. Even
under the Demon AUP.
> > 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'.
I'm pointing out an example of where someone who did the tests got it
seriously wrong. The point, as I tried to explain to sharun, in another
post, is that there are multiple ways of relaying, and the blacklists
you're trying to avoid will test all of them, and what you actually
want to do is run your tests and compile your own database offline, not
during connections.
> > 4) you will waste enormous amounts of bandwidth.
> Not if the values are cached.
OK. So how is your cacheing policy going to work? after all, they may have
fixed a relay, or the boss has gone on holiday and doesn't want to change
the laptop configuration and suddenly they're an open relay again.
> > 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 :)
Sure. What I'm saying, though is that my mailer doesn't initially "trust"
someone who sends it mail. It therefore issues a 450 every time they
connect until a certain amount of time (dependent on various things) has
elapsed since they did the first connect. Then it will pass them through
to the real mailer.
> > 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.
Right. That's not what I'm saying. If I'm running my delayware, and you
try and do your relay test to me, your relay test is completely inconclusive,
because the delay stage happens before the relay test. So all you get is a
450. This doesn't help you in the slightest.
> 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.
I would do it outside the mail dialogue.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
