Keith Matthews <keith_msweeney.demon.co.uk> writes:

> On Sun, 9 Dec 2001 20:02:31 -0600 Phil Howard <Phil Howard <phil-postfix-usersipal.net>> wrote:
>
> [snip]
>
> > Maybe it needs to be the same project, i.e. work them together.
>
> > If there is a common live database that has the record of all the recent
> > mail (right up to the newest from any connection) then multiple connections
> > won't be able to introduce greater mail throughput. So in addition to
> > checking "should I stall this connection for a while" when the first
> > attempt to inject mail is made, make that same check again after the
> > first time period expires, in case another connection has succeeded in
> > sending through some mail.
>
> Having deleted your initial post a thought came too me (slow as usual
> !). While not quite the same thing, some FTP deamons have code to
> limit the amount a bandwidth a given remote host can use. Might be
> some ideas and techniques there to help.
>
> One worth looking at is vsftpd (freshmeat knows about it).
>

This can already be archieved on may OS'es using various
approaches. On linux (2.2+) you can use network schdulers to slice up
available bandwidth. In addition to adjusting badnwidth available for
SMTP, adjusting bandwidth available for ICMP makes for a handy and
quick trick to get rid of quite a few DoS'es and if you ever get
caugth being an open relay it limits damage (suddenly your 8Mbit
DSL-line is only churning SMTP at 50kbit).

cheers,
Alexander

-- 
Alexander Hoogerhuis
FYI: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
#include <stdstuff.h>
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]