Re: [exim] *Suspect* Re: Connection age feature?

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