Todd Lyons wrote:
> On Wed, Jul 14, 2010 at 10:28 AM, W B Hacker <wbh@???> wrote:
>> Marc Perkel wrote:
>>> Is there a variable that returns the number of seconds the connection
>>> has been open? I have a theory that virus spam bots send email a lot
>>> slower than normal and that I'd like to see if this is so.
>> 'When' we still accepted connections frmm them at all (scoring system vs RDNS &
>> dynamic-IP RBL's) we found the reverse to generally be so.
>> A delay of 13-15 seconds usually saw the greater part of them abandon and move
>> on, and extremely rare was the miscreant that would wait 30 seconds.
>
> You're talking about banner delay Bill,
No not at all. I don't DO banner delay. Never have.
We DID do delays at various phases of the smtp process. Sometimes mathematically
increasing ones (MAINDELAY * (x+y) as cumulative demerit scores grew.
Only a very few still trigger as rDNS fail et al brush off most of the
bad-actors they were designed for.
> whereas Marc was asking about
> the total time that a connection has been open. Short of some
> grepping and awking, I can't come up with any way to see that...
>
> ps aux | grep '/usr/sbin/exim' | egrep -v -- 'grep|-Mc' | awk '{print $9}'
>
> With a little massaging you could correlate that time since the
> process started to the hostname, but it sounds like a giant kludge
> that will be prone to error. I could be misreading it though.
>
It is easy enough (already logged 'near as dammit' with QT and DT, IF the system
is set to invoke a queue-run per arrival AND the queue and fs is fast).
But that is only for router/transports of sessions that run to *completion*.
That's also still a log parse.
.... and not exactly what Marc asked for anyway.
The actually pre-delivery *connection* time can be very close (check soem logs).
Or not.
Exim most certainly tracks session, if not conection, 'age' within each child
process - something of that sort would be used for clocking towards smtp time-out.
But Marc isn't likely to want to go into source code and find an internal
counter. Especially if, as I'd expect, it is resettable..
Nor I.
Given that TCP/IP and link speed can vary as much as they can - I get a 'close
enough' answer from log analysis.
Bill
