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

On Tue, 18 Jun 2002, Philip Hazel wrote:

> On Mon, 17 Jun 2002, Dave C. wrote:
>
> > > ... then drops the connection. That's all it can do. True "blocking" has
> > > to happen before the connection gets to Exim, that is, in a router or in
> > > the host's TCP/IP stack, or using TCPWrappers or similar.
> >
> > Currently, there is no way to do this based on a dnsbl lookup in exim4
> > (that I can tell).
> >
> > How hard would it be to add an "acl_smtp_call" ?
>
> Easy enough, but it doesn't really help. The connection still has to be
> made and passed to Exim before it could run such an ACL. This is the
> same effect as host_reject_connection.

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

> > Currently, hosts listed in an dnsbl called from acp_rcpt, have the
> > opportunity to send a whole ton of RCPT TO's, each one getting a 5xx.
> > This takes up lots of resources.
>
> 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
code to DNSBL-listed hosts. In fact, it would be nice to have this
facility built right into the deny or require like 'message =' is..
Perhaps 'code ='

> An alternative would be acl_smtp_mail, to operate for MAIL commands.
>
> When I implemented the ACLs, I deliberately implemented what I thought
> were the minimum possible number of them, to see how it worked out. Not
> providing them for connections and MAIL was intentional. I wanted to
> encourage people to reject RCPTs because that's the best way to
> discourage clients. Also, that is the point at which you can best
> implement exceptions such as "always allow mail to postmaster". If you
> reject earlier, you cannot allow these exceptions.

Is there a 'best' way to discourage clients? I'm not terribly interested
in making exceptions, I dont want spam at postmaster@ any more than at
any other address.

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

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. 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.

> I have put this on the Wish List, but I am still rather wary of
> implementing it because it will be easy for people to use
> inappropriately.

People will always find a way to use features inappropriately (refer to
recent thread where some misguided individual was trying to do routing
in a system filter based on the headers) - Is that a good reason to
limit the flexibility of exim for those that do know what they are
doing?

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.

> > Perhaps that above would help cut this down. It could have a sanity
> > delay of 5s or so, just to prevent such a host from repeatedly
> > connecting too frequently.
>
> The existing ratelimiting on RCPTS could have a similar effect. Does it
> use more resources to have one process rejecting RCPTS very, very
> slowly, or instead to reject connections (or MAIL) and have the client
> keep calling, thus requiring the repeated setup of a new connection and
> a new process? I would not be surprised to find the former is "cheaper".

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. I wonder what the best way to implement a way to have a
trigger for 'if we're not going to accept any mail from thist host,
generate a summary log line instead' (eg, 'rejected 1234 RCPT's from
x.x.x.x')

> Anybody else have views on this?
>
>

--