Without quoting the entire message, I think I better solution, in terms of ease to implement as well as conserving bandwidth would be to have a sophisticated remailer script-language.

For instance, the script language could tell the remailer to check if a site is on-line (perhaps within certain GMT hours or dates) and use the next site if not available, or to randomly choose from a list of sites the active ones, etc.

Aye, there lies the rub. How exactly does one determine if a site is active or generate a current list of active sites? It is not enough to ping the site or even to successfulyl deliver mail to it: the fact that something is alive and running sendmail does not make it a remailer. Likewise, a remailer cannot select an alternate site on behalf of the user if the routing is chosen by the user, as each "envelope" is encrypted specifically for a given remailer. I suppose one could develop client software that built several redundant "envelopes" for alternate mailers, but that would get out of hand pretty quickly, both in terms of the effort of generating a secure message and in term of the size of a message. Scripting is useful (hell, the ::Request-Remailing lines are effectively a script) but not until there is data to operate on.

Maybe even have it work with a data haven? Mail the message to a data haven and send another message to a remailer chain to pull the message from the data haven and post the data (not flaws in this: don't want remailers getting files from people's accounts and posting them to usenet etc.).

Not a bad idea, actually. -- Kevin