Remailer Unreliability

[Greg Broiles <greg@ideath.goldenbear.com>]

-----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-----