Since many servers (should) nowadays be running inside a VM, simply dumping out due to being an a virtual environment isn't enough of a check. Servers are the lucrative hosts for zombies due to their always-on, high-bandwidth, high-horsepower nature. To dump them simply for being a virtual server will cut out a portion of this zombie base. As noted in the paper, other methods would be much more meaningful. However, one mentioned (of including a self-address in the list for verification), wouldn't be on my list. Even if it was a web-based email, it would still require utilizing one (or some) of the bots to auto-check the "personal" email address for verification, which would throw a control password into the mix, and provide a means of compromise. Not good. Other alternative would be to check it with some control center, which could be traced back to, another fail.
Perhaps the easiest way would be to register a few (if not all) directly-accessible bots (not behind a firewall or the like) as targets. For every batch of spam sent, from every server, one email would be addressed to <randomgarbage>@<infectedcomputerip> (so to speak) and have a C&C message verify across the bot-whispernet that such an email was received, and have that determine if the machine is being filtered/blocked/redirected. It isn't flawless, but will give the herder an idea of which machines are pointlessly infected.
As for the "act as a honeypot" to disable a zombie suggestion above, I would assume you have the technical know-how to remove such a bot if you know how to "act as a honeypot" in the first place. Or am I just giving too much credit?
Either way, if the bot is unable to send spam for whatever reason, I'd probably just flip it into "keylog and send me juicy info" status anyways.