Besides, if you think about it, the spamming zombies aren't really that much of a distributed app...
I am not a spammer, and don't personally know anyone who is. The stuff below is based on several security articles I've read along with logical extrapolation. I'm not trying to provide a recipee for how to write a spam bot, and I'm not saying anything that isn't already commonly available to anyone with access to google and a few spare brain cells *grin*
GRC [grc.com] has a fascinating account of tracking down a ddos who was using similar zobmie bots. It includes some very good insigits into how these things work.
The comprimized PC (zombie) just logs in to some IRC channel whenever the internet is available and sends a mesage saying it's ready to accept a command. Commands are issued via sending specially worded messages. The zombie client would listen for commands sent to its nik as well as commands for all in the channel.
The controller application (probably logged in with channel operator status) provides filenames for the email text and the first chunk of addresses to the zombie would then download the message text file and first batch of addresses. At this point, the zombie will just happily send messages out as fast or slow as its programmed to, and will report back to the controller when the work package (address list) has been fully processed (There should be a certain amount of client autonomy to reduce overhead for the controller app). When the zombie reports back that the messages were sent, the controller will assign another mail list file with a chunk of N addresses and the process will continue until there's nothing more for it to do.
a simple perl script could take a master email list and slice it up into a bunch of files with N addresses each. When a zombie reports in that it needs another work block, the controller would respond with the name of the file with the next N addresses for it. The controller would keep track of what lists were assigned to where. When the zombies report back, they would tell the controller what file they last finished, and if they are ready for another. The conroller could be smart enough to keep track of what lists are outstanding. If foo-1000.txt is out with some zombie for more than N days, the conrtoller will assume the zombie has been cleaned/removed and will reallocate the package.
Now, change it from zombie to seti client and change email list to data blocks to process, and you have the basis for SETI. The big difference is that with spam, you would just need the email text and a simple list of addresses to send to, but with seti, you've got to figure out how to break up the data into meaningful chunks. Also, with SETI and other legitimate apps, you would have to be more aggressive about guarantees... and have ways that the data analysis would overlap so that you aren't taking the word of just one client on whether to call Agent Mulder *grin*.