On Sun, 7 Mar 1999, Peter Gervai wrote:
> > There is an "address collector" program that works with a dictionary
> > of username appends the domain and uses RCPT TO to collect what it
> > thinks are valid email addresses.
> [...]
>
> A nice fella notified me that my domain is hardcoded in such a program,
> and I checked that it really does that: tries loads of rcpt to:'s.
>
> This made me ask whether there is a limit on max number of RCPT TO: in
> one session?
There is recipients_max and recipients_max_reject.
> And anyway, could I put a trigger to block the address when someone
> repeatedly tries to flood me with invalid rcpt to:'s?
This was suggested, and it would be possible to do something like
. Write a log line or mail postmaster if there are more than n bad
RCPT commands in one transaction, or connection.
However, I see several problems with this.
(1) Doing it per connection might cause problems in the case of a
mailing list that has a bad address at your domain (account cancelled,
for example) when you have been down and come back and the mailing
list host sends you a large number of backed up messages all down one
connection - each with one bad address.
(2) Doing it per SMTP transaction (i.e. per message) is trivially
circumvented, either by the remote machine sending
MAIL FROM:<>
RCPT TO:<xxx>
RSET
MAIL FROM:<>
RCPT TO:<yyy>
RSET
... etc
or even making separate SMTP connections for each address.
(3) Doing it per host - which would require the overhead of storing
the information in some kind of hints database - has the same problem
as (1), though I suppose maybe the way round that is to count
*different* bad addresses, and the rate at which they appear.
So, the only thing I can think of is some hints data storing the rate of
bad addresses received from a given host (x bad addresses per hour), and
a list of bad addresses. This would not be a trivial addition, and since
bad addresses arrive all the time in the normal course of events, the
database of bad addresses from each host could get quite big on busy
systems. Updating it every time there's a bad address introduces another
interlock between Exim processes, which might affect performance.
I think another approach is needed.
One thing you can do already is to run a program that watches the Exim
log file, checking for entries of the form
1999-03-08 00:14:36 verify failed for SMTP recipient xxxx@xxxxx from
<xxxx@xxxx> H=xxxxxx [x.x.x.x]
If you do that, you can implement your own algorithms for determining
when you think there is a problem, and take whatever action you want to.
If anybody wants to write such a thing (sounds like a Perl script would
be the best) I'd be happy to include it in the Exim Contrib directory.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
