[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REMAIL: problems
In article <[email protected]> Joe Thomas <src4src!imageek!access.digex.net!jthomas> writes:
> [...] 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?
--
[email protected] Non serviam!
Support your local police for a more efficient police state.