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. The list reaches me in any case. Bill -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
