More precisely, Rustock-infected bots are no longer using TLS, a protocol that utilizes code encryption for safe e-mail dispatch. Understandably, spammers used TLS for encrypting their junk messages so that other network components found it increasingly difficult to scan e-mail traffic for spam.

Moreover, during the treatment of server e-mail, TLS includes a growing though small overhead to such treatment that joins mail servers, however, it influences the rate of spam dispatch too. It's never been lucid as to why the owners of Rustock imbibed this method though the reason may be associated with an apparent belief that it'll create difficulties for servers in separating the malicious traffic passing through them alternatively, spotting the C&C system that regulated their operations.

Figuratively, Rustock now uses TLS at a mean rate of 0.1%-0.2% of the entire spam, reaching the highest rate at 0.5%, in contrast with the 25% mean rate and the 77% peak level observed in March 2010.

But, the prime time occurred a few months back when Rustock sent a surging amount of spam while employing TLS encryption, thus setting about a vital new botnet behavior pattern.

Currently, Rustock has discarded this stage so that its e-mail junk can be delivered faster. Nonetheless, due to fewer potential spam targets, the botnet has raised its spam amount too.

State the security researchers that apparently Rustock controllers now understand that by utilizing TLS there's hardly any benefit and so they've slowed down their delivery ability because of extra bandwidth as also processing overhead required when TLS is employed.

Meanwhile, Rustock was almost eradicated during November 2008 whilst a San Jose, California based ISP was taken down, yet it continued to survive as the botnet's operators managed to change the C&C servers whilst the ISP temporarily turned active prior to its ultimate closure. Incidentally, Rustock, during its 4 years of operation, has sent as many as 43bn spam mails/day and these numbers are continuously increasing.