Re: Handling servers that don't wait on their retries

Hi Stephen,

This method you use would certainly partly handle the problem.  I think 
however one drawback of your method is that if there are a significant number 
of users sending mails from one server to another, your method might start 
refusing connections when in fact there is only a larger number of mails 
coming at one point in time.  For example, if a lot of users from one 
university send a lot of mails to users at another university, your method 
may kick in and refuse the connections.  I realise the situation is not 
particularly likely, but still possible.  This is where I would see an 
advantage of the method I have proposed, in that such a situation would be 
better handled, imho.

OK, one could also argue about a spammer sending his 5h17 to multiple 
receivers on one server.  In that specific case it's difficult to see which 
method would do the job better unless we know beforehand the exact method the 
spammer is using.  

And just to note, I'm now away for five days and not reading my mails, so 
don't be angry when I don't answer immediately.

regards from an ex Briso in Vienna ;-)
Ian


On Thursday 26 February 2009 06:30, Stephen Carr wrote:
> Dear Ian
>
> I think I solved this problem by setting the ClientConn and ClientRate in
> access file
>
> I see instances of hundreds of connections from a site in a few minutes
> but they are rejected eg
>
> sendmail [13785]: ruleset=check_relay, arg1=[201.15.201.113],
> arg2=201.15.201.113, relay=[201.15.201.113], reject=421 4.3.2 Connection
> rate limit exceeded.
>
> before the are handled by relaydelay.
>
> Regards
> Stephen Carr
>