Sorry for reworking the Subject: line and doubly sorry for only
joining the discussion now. I have been, urm, archiving most of my
mail for the last month! so catching up is a slow process.
> On Wed, 19 Nov 1997, Evan Leibovitch wrote:
>
> > Philip, would it be difficult to implent config options of, say:
> > relay_reject_slow
> > host_reject_slow
>
> Remember that while you are sitting there dribbling out stuff slowly,
> you are tieing up *your* resources as well. You are keeping an SMTP
> connection open, thus reducing the number available for everyone else
> (if you have a limit set), and you have a process running which is
> taking up real and virtual memory and other process resources.
Philip, you may recall that we discussed something similar almost
exactly a year ago! (if you wish to search your own archives, the
Subject line was [Another "wouldn't it be nice" :-)] and the
original Message-Id: <E0xck8e-00069h-00@???>
In that message I suggested having a set of parameters that measure
the rate at which privelaged and non-privelaged (in broad strokes
one could probably use the "inside-nets" or "inside-domains" as a
guideline) could deliver mail.
Should a site exceed the initially set threshold, an incremental
backoff scheme could apply. Instead of accepting connections
_slowly_ Exim could simply refuse the connection, each time
incrememnting the amount of time it will refuse connections before
accepting the next.
The remote site would then backoff (trying backup MXs which
unfortunately would have to go through the same process) until it
had exhausted all MXs and eventually would back off completely until
it's own retry-time had been reached. By that stage, once again,my
Exim might be ready to accept a few connections.
I'm not sure how easy this would be to implement. It might
certainly add quite a bit to the DB but it *would* have the effect
of really pissing the SPAMMing site.
Obviously there are complications and there may be a need to add
overrides on a per-host or per-domain basis to allow outside domains
that are simply high volume mailers access into the network.
Another really neat option would be to limit the number of
Envelope-To: headers permissable to prevent mass-mailings in a
single SMTP session (or does this already exist - so many new
features - I really ought to read spec.txt from header to footer
again some day :-)
Come to think of it, the number of Envelope-To:'s would have to be
counted to measure the "rate" of mail delivery in the top
discussion. Not just the SMTP connect rate....
I hope I haven't missed this particular discussion elsewhere. If
so, please accept my apologies (and point me at the discussion!! :-)
Cheers
Kuyper
--
/ Kuyper Hoffman / Vox:+27.21.658.8718 O/H GMT+0200 /
\ Kuyper@??? \
/___________________________/ FAX:+27.21.683.4695 24h FAX /
\ SysAdmin Manager UUNET Internet Africa PO Box 44633 \
/ http://kave.iafrica.com/kuyper Claremont 7735 South Africa /
\______________________________________________________________\
--
*** Exim information can be found at
http://www.exim.org/ ***
