Marc Perkel wrote:
> Not that it is by itself but when combined with other conditions it is
> very effective. My theory is that after the message is sent by the virus
> sending the quit just takes more time and bandwidth so the spambot just
> leaves the connection open on the server side.
>
> But - almost all of the connections that time out are spambots. So you
> can combine this with a number of other sins and have a very effective
> means of identifying spambots.
>
>
Maybe.
Possible circular logic here. You may have *caused* them to time-out.
To the extent you have already ID'ed a possible 'bot and sent a 'deny' or
'defer' to it, many of them lack the mechanism to understand or action
SMTP-time
rejections.
Their coder didn't provide for the situation encountered. Simpler and cheaper
for him to fire, forget, move on, not worry about what the victim had to say.
If instead they sit on the connection it may be out of pure confusion.
Most zombot masters want to hit as many targets in a day as they can do, so pay
more attention to not getting stuck than to RFC handshake compliance.
As little as a 3 second delay before sending your deny/defer/{whatever} sees
most such drop off here.
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/
