Re: [Exim] Blocking incessant relay testers with Exim 4

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Philip Hazel
Date:  
À: Dave C.
CC: exim-users
Sujet: Re: [Exim] Blocking incessant relay testers with Exim 4
On Tue, 18 Jun 2002, Dave C. wrote:

> If you made more ACL's, a lot of the individual options like
> host_reject_connection could be obsoleted.


I don't think there are many, actually, though that is indeed one.

> > Ah, I see your point; host_reject_connection doesn't allow for dnslist
> > lookups.
>
> I beleive it currently sends an 4xx code, I'd really like to send a 5xx


No, it sends "554 SMTP service not available".

> Is there a 'best' way to discourage clients?


Experience in the past was that only 5xx to RCPTs discouraged some
clients. 5xx on connection or after MAIL or after DATA did not. I don't
know if the situation in general has changed recently.

> I actually sort of liked the exim3 way, where it would first reject the
> data, then the mail, then the rcpts.


Exim 3 developed into that baroque style as we discovered that rejects
after DATA and then after MAIL "didn't work". I threw it all away as
overkill bloat in Exim 4. (Besides, you can now choose between RCPT and
DATA for yourself.)

> Perhaps a way to cache information from the ACL's when a deny is issued,
> which can be referenced on a subsequent connection in other ACL's, would
> be useful.


More complication, more disc use, more interaction between processes,
leading to more contention and maybe bottlenecks. Those are the
arguments against that kind of thing. I'm not saying "never", or that
it's a bad thing, just that it will slow things down.

> Other counters/caches would be nice too. For instance,
> variables to count the number of commands received, the number of each,
> the number accepted, would all be nice to implement in an acl. In fact,
> with those, even the ratelimiting could be moved into an ACL, if a
> 'delay =' was added.


Exim is not designed to keep centralized information, so that its
processes don't have to interact with each other. Bodging something into
the existing design would probably not be very nice, and might well
perform lousily. For something fundamental like this, some entirely new
design is needed. I don't know what that is, but I feel in my bones that
this is in the nature of "big, fundamental, enhancement". I'm not able
to undertake such things just at the moment...

> People will always find a way to use features inappropriately


Oh, sure, and one has to take that risk. I did say I was "wary", not
"utterly opposed" :-)

> The ACL's are great, it would be nice to move more of the power and
> flexibility into them, removing a lot of hard-coded logic, and even
> reducing the need for it in the future.


I certainly always intended to review them after some operational
experience had been gained. So far we have almost 4 months. I think it's
worth letting Exim 4 setting a bit longer...

> Hrm. You do make a good point. Its just annoying to have thousands of
> entries in the log from hosts that we are never going to acccept any
> mail from.


If you can identify them, host_reject_connection is your friend. (Maybe
scan your logs for DNS list rejects and create a file of them? Not nice,
but it would work.)

Philip

--
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.