In article
[...] Let's say there is a method to quickly and easily verify the continuing existance (or lack thereof) of a remailer. When a remailer receives a request to send a message to another remailer, it can quickly check to see if that remailer is in operation. [...]
But how would this be done? The first way that comes to my mind is spooling the message in a queue of some sort, sending a "ping" message to the next remailer in the chain, and waiting x minutes for a response. If a response does arrive within x minutes, that remailer is considered alive. But what is the value of x? It can't be too short - the remailer might be on a slow link. For example, I have a remailer running on my machine, which is connected via uucp. The turnaround time of a "ping" message would vary from about 35 minutes to upwards of 13 hours (I don't connect at all from 0855 to 2205 EDT). But the longer the delay, the slower the whole chain runs. If one popular remailer goes down, all messages routed to it would be delayed at least x minutes, which is better than the bit bucket - but with x being, say, 1440 (one day) the delay would not be trival. There also might be security issues with the spooling of the messages. I just wrote a couple extra perl programs for the remailer that do part of the above. I'll try to put them on soda, called "morpheus-remailer-hack" or something similiar. They add another header (called "Request-Safe-Remailing-To for now - please send better suggestions!) that acts just like R-R-To: but spools the message and sends out a email ping, then waits to send the actual message until it gets the "ok" message back. It's slow and ugly, but it seems to work (it works with itself, anyway ;-) There's probably lots of locally-dependant stuff in it (like the MESSAGE_ID and VISIBLE_NAME enviroment variables, etc) that will need to be fixed. The big problem with it at this point is that it's useless - there isn't any code to deal with the "no response" condition. A simple script ran from the crontab could check timestamps in the spool area and do something if they were more than x minutes old - but _WHAT_ should it do? Maybe a better idea would be to add a Recipt-Requested header instead of doing the email ping, which would have the receiving remailer send back an "ok", but continue with delivery.. Then the sending remailer could delete the spooled message, otherwise if it didn't get an ok it would try again at another site. Better or worse? -- morpheus@entropy.linet.org Non serviam! Support your local police for a more efficient police state.