Re: [exim] Need a little unix help

Marc Perkel wrote:

*heavily trimmed*
>
>>>
>>>>Marc Perkel wrote:
>>>>>
>>>>>What I want to do is create a simple client/server application where
>>>>>clients running Exim can easily report IP addresses to the server.
>>>>>The server will accept the IP addresses and execute a command to add the IP
>>>>>address to a MySQL database and increment a counter. What I'm
>>>>>specifically doing is counting spam/ham based on IP address.

*trimmed* (questions / suggestions on methods)

>>>
>>>... what I want to do is give other people a simple
>>>way to send me IP addresses in real time. I dont want to give the direct
>>>access to my database and provide them with passwords and query strings.
>>>What I want to do is to have them do something simple like write a
>>>string to a port and I'll handle the processing on my end with something
>>>that listens on that port, gets the string, and runs the MySQL on my end.
>>>

*trimmed* (questions / suggestions on methods)

>>>I
>>>think I have the server side of it working. Still testing. So what I
>>>need now is an easy way for Exim to open a port and send a string to it.
>>>Right now the best I have is running netcat (nc) but would like
>>>something cleaner.
>>>

*trimmed* (questions / suggestions on methods)

>
> I'm not looking for the load of sending whole messages. Those who will
> be feeding it will be hand chosen by me ans will be given a secret host
> and port to send it to and it will be set up to only accept from
> specific hosts. But - I want to make it so that anyone can read it and
> use it to filter spam. If this is sucessful then I hope some big service
> will take it over and other people will do it right. I'm good at
> starting things because I think outside the box. But once I get it going
> then other can improve it and do it right.
>

Marc,

To the extent that you have a tool that can dynamically, in near-real-time, keep
a "recent bad behaviour by-IP" <brown?>list, yes, I think it IS 'out of the box'
and worth looking into. For one thing, it need not necessarily have to make
off-box callouts. For another, the IP's could be exported to a firewall, further
reducing Exim load.

I'm still interested in that, so please don't give it up.

At the point it becomes less 'near real time', less fequently updated/purged,
less local, has a longer time-to-live, and moves toward yet-another-RBL, I think
it is neither new, nor out-of-the box, and is already well-covered, particularly
if you are basing otherwise 'cheap' IP gonging on the result of otherwise
'expensive' SpamAssassin scoring.

SA already has white/black autolisting tools and there are perhaps a hundred
RBL's already. Typically fewer than 5 are sufficiently accurate, current, AND
broadly useful to justify the bother of checking against. Each sysadmin has his
own favorites.

There still may be new value to your approach at the RBL end of the spectrum,
but it is not clear to me.

A potential application that could benefit is blocking a zombie that connects,
then tries to send a dozen or so messages to our valid domains, but to all or
mostly machine-generated invalid recipients.

By incrementing an acl_c variable instead of an acl_m variable at each recipient
verification failure, then multiplying that value by 'n' seconds for a "delay =
", the rapid ramp-up in delay can cause impatient zombies to abandon the
connection, often by the 2d or 3rd message in each assault.

This approach is 'cheap' only if one can afford to hold open a lot of IP
connections and Exim process children, but it at least avoids an 'expensive' SA
call.

OTOH, it has no 'memory', the process repeats - twice more on average - before
the free-range-rude are off to hit another target - returning anywhere from
hours to days later when the whole dance repeats.

Your approach *could perhaps* 'cache' that errant behavior and put such a caller
into the penalty box right away on each succesive assault.

Permanently blocking the IP is of less value to me, as these are often transient
bad-actors amongst otherwise-OK players.

Thoughts?

Bill