-----BEGIN PGP SIGNED MESSAGE-----
Well, *I* think it is a good idea. But how does remailer1 know that remailer2 is both a remailer and down?
By attempting a connection to the SMTP port and using the alternate if it fails?
This depends on a significant change in remailer features - existing remailers don't do message delivery, they pass remailed messages off to the local MTA (e.g, sendmail, Smail, whatever) and let it take care of delivery. Expecting remailers to handle queueing and delivery adds lots of code and complexity. (It also may piss off sysadmins who aren't remailer operators. Bogus or not, some institutions frown on attempting mail delivery manually or with non-standard programs.) Also, it's difficult to say when delivery has failed. Not every failure (where failure = not delivered in a reasonable time) results in a bounce message; if the sending remailer can't determine success or failure immediately, it will have to keep a database of the last few (hundred, probably) primary/alternate address pairs, and then extract the failed message from the bounce message, then reprocess with the alternate address. Yuck. I think the easiest way to do this would be for remailers to have a list of "unavailable remailers", and to process the primary/alternate choice immediately upon receipt/resending - but if we have a good way to provide the remailers with availability information, we've probably found a good way to provide it to users, too. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzKgyH3YhjZY3fMNAQHlkwP7Bj5D5PbC1H+x3XXqP3gdUTTL6eLMjt2d 6cmj/kr0nv88XwXkIttj7r4wSDRXSe8K4mpU4utNQ1l+RlArDzZLkiY/qleuRhGX yRplXo6eoNwSv24oBCIVwdu7r+gnlhVs4sU3tzkWD+deOQxVXffdPL0opZ1Cn8v6 qRmKmuOYFB8= =i/8j -----END PGP SIGNATURE-----