Keith Moore followed upe:
Maybe the spammers are trying to deal with greylisting?
For that matter, I wonder if legitimate senders are trying to deal with
greylisting also. Maybe there are poor implementations of greylisting that
block legitimate traffic too often. Maybe there are some large-volume senders
that don't want to deal with having greylisted mail in their queues any longer
than necessary. If retrying after a few seconds works on some greylists, it's
not surprising that some senders would start doing it.
So anonymous bad guys hurt receivers, receiver invent ways to throttle
the abuse using methods that forces SMTP compliancy, anonymous good
guys must also comply and must also follow the throttle invention. Bad
guys finds a loop hole around the throttling invention. Receivers
find and close the bad guy loop hole unbeknowst to them that they are
also closing the loophole also used by the good guys.
Serendipitously, the receiver finds there is a intentionally delay
used by good guys and its built into the software they are using and
discovers that this delay pattern is also exhibited by bad guys,
leading to a reasonable conclusion that all prior thinking was
incorrect and that the good and bad are using the same type of
software with the intentional delays. The good uses it inefficiently
for good bulk mail intentions and the bad uses its inefficiently for
the same bad bulk spam reasons and to get around greylist rejections.
The receivers are now stuck in a conundrum and catch-22 situation in
dealing with this situation that is only solvable by reducing the idle
CPU waste time by dropping all clients after the 1st transaction
attempt is completed - the good and bad.
I will be showing after I get more daily stats, but yesterday I
enabled the new option to reduce the QUIT time idle time from 5 to 1
min and I already saw a 60% reduction in lost CPU idle time waste.