Autor: W B Hacker Data: A: exim users Assumpte: Re: [exim] Connection age feature?
Marc Perkel wrote: >
> On 7/14/2010 10:20 PM, W B Hacker wrote:
>> Marc Perkel wrote:
>>
>>> On 7/14/2010 11:41 AM, Graeme Fowler wrote:
>>>
>>>> On Wed, 2010-07-14 at 09:02 -0700, Marc Perkel wrote:
>>>>
>>>>
>>>>> Is there a variable that returns the number of seconds the connection
>>>>> has been open?
>>>>>
>>>>>
>>>> No.
>>>>
>>>> However in the connect ACL you could set a connection variable to hold
>>>> the value of $tod_epoch (or one of the variants) and then check against
>>>> that when the connection is closed.
>>>>
>>>> Note that this is unlikely to be reliable, because all manner of things
>>>> could cause the connection to be open for a long time - and at least 50%
>>>> of those reasons are at your end.
>>>>
>>>> Graeme
>>>>
>>>>
>>> It works. And most everything that takes more than 30 seconds to reach
>>> the data acl is spam (that not a large message and when load levels are
>>> normal) It does seem to be somewhat useful in detecting spam in
>>> combination with other factors.
>>>
>>>
>>>
>> Interesting.
>>
>> Maybe.
>>
>> *Why* does it take so long?
>>
>> Are your own content-scanning delays a significant contributor, perhaps?
>>
>> NB: *Excluding* any penalty delays WE impose, but *including* SA and ClamAV,
>> even spam is generally handled here in sub two seconds end to end, so....
>>
>> 'Curious'
>>
>> Bill
>>
>>
>>
>
> No - not my content scanning because I do it before Spam Assassin or
> Clam.
ACK - but I'd meant inclusive of those players - eg: overall time consumed at
your end....and on the expectation that the spammier it is the longer the scan
is likely to take.
So the question remains - is the delay the far-end's 'tactic' - or just a byproduct.
And I also exclude large messages. A Windows virus infected spam > bot doesn't send out spam one at a time. They connect to several servers
> at once and they are pumping spam as fast as the connection can handle
> it.
Agree so far...
Thus it takes longer to deliver a message than usual.
That reason is still To be Determined.
As computing and networking stuff goes, an smtp session - or many such at once -
is/are relatively trivial users of machine (or link) resources - even if
something other than a fast, compiled binary is doing the do.
MY point was that a Winbox that has become infected with one parasite may well
be infected with MANY. While a zombie pumping smtp spam might come nowhere near
bringing the machine to a crawl, some of those others are far heavier resource hogs.
All supposition, of course - and your metric may have merit.
But I remain sceptical that it is a deliberate tactic on the part of the zombot
master.
Seems to go way too much against their pressing need for speed..
>
> How to use this information is tricky. One thing someone could do is to
> conditionally grey list based on this. What I'm doing is adding a point
> if there are also other spam indicators like bad helo, dynamic ip space,
> etc.
Incorrect HELO is all too common. Originating in dynamic IP *space* , OTOH,
could pass here IF the provider's upstream has registered all the right DNS
creds, as 'some' do for SME clients, AND it is NOT found in a SORBS Dynamic IP RBL.
Fairly rare combo, that. Most reject on rDNS fail, after which I of course no
longer have further details.
>
> BTW Bill, you have my servers black listed.
>
Some of them. Sometimes.
Reject message may state '... blacklisted', but it might just be the DDFD acl.
