Nigel Metheringham wrote...
> I wonder if limiting the number of incoming messages per SMTP session
> will have the effect you want - you would expect whatever mail
> injection tool is being used would just start another session and
> continue with scarcely any delay.
I understand what you're saying - and this certainly isn't expected to be
a long-term solution - we just want to make life a little more difficult
for this particular spammer (and possibly others using the same software)
while we come up with something better. In addition to this, it seems to
fill a gap in the flexibility offered by all Exim's configuration options.
Since a 421 reply code is given once the limit is reached, this might also
be useful to make a remote host with a heavy backlog of mail for your
system back off for a bit.
> My own approach to the problem was to have a log processor which
> processed the exim logs on the fly and rate limited on modem IP
> addresses - it actually dropped information about spamming IPs and
> message ids into a local database which was consulted by the system
> filter.
> Use of this would normally pick up all but the first few messages of a
> spam run.
That's an interesting solution - I hadn't considered using the system
filter to enforce a limit in that way. Thanks for the input.
Rate-limiting (as you're suggesting) is my next task :) I may be able to
use the smtp_accept_max_per_connection option in applying the limits
somehow, if Philip feels it's acceptable. By this, I mean that I can
tweak the values of recipients_max and smtp_accept_max_per_connection to
limit the total number of recipients that can be given per connection. I
can also use the smtp_accept_max_per_host option to limit concurrent
connections from each IP. If I can then come up with another option, say
smtp_accept_max_rate_per_host which limits the frequency of connections
per IP, I have complete control over the rate of relay through or delivery
to my host from each IP :) I got distracted from this today, but I plan
to look at the implementation of sender_verify_max_retry_rate for ideas.
What I may try to do to enforce the limit is add a mini-teergrube
somewhere, rather than totally blocking connections for a time.
