Philip Hazel wrote:
> On Wed, 17 Jan 2007, Jeremy Harris wrote:
>
>   
>> --- src/expand.c        (revision 1686)
>> +++ src.new/expand.c        (working copy)
>> @@ -463,6 +463,7 @@
>>    { "sender_rate_period",  vtype_stringptr,   &sender_rate_period },
>>    { "sender_rcvhost",      vtype_stringptr,   &sender_rcvhost },
>>    { "sender_verify_failure",vtype_stringptr,  &sender_verify_failure },
>> +  { "smtp_accept_count",   vtype_int,         &smtp_accept_count },
>>    { "smtp_active_hostname", vtype_stringptr,  &smtp_active_hostname },
>>    { "smtp_command",        vtype_stringptr,   &smtp_cmd_buffer },
>>    { "smtp_command_argument", vtype_stringptr, &smtp_cmd_argument },
>>     
>
> The reason I have always resisted doing this is that the value you will 
> get will be the value that the daemon had when it spun off the process 
> that is accepting the incoming message. If any substantial time has 
> passed since then (you are doing 1-second delays after the banner, or 
> you are now receiving the 100th message on this connection - each one 
> taking a few seconds because of content scanning, or whatever), the
> value may well be out-of-date, in either direction.
>
> Maybe for some purposes this doesn't matter. However, I would suggest a 
> more descriptive name such as
>
>   smtp_connection_count_at_start_of_connection
>   
> but that's rather long. Maybe smtp_count_at_connection_start might do.
>
> The *current* connection count is held only by the daemon process.
>   

Phil, I see your concern. However I think that disclaimer should be in 
the docs and that most people using this are looking for an 
approximation to deal with loading issues. So that if let's say the 
connection count spikes up to say 3000 connections then you could have 
an ACL that starts sending temp errors to IP addresses with bad RDNS or 
something like that.

What I've seen happen on one of my servers is that I might run a high 
connection count where someone is deliberately sucking up lots of 
connections but the load levels are still fairly low. Most of the 
conections coming from IPs with bad RDNS. So that's what the initial 
interest was for this.



-- 
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

Reply via email to