I wonder if the source of remailer unreliability could be further
tracked down by providing a "publish" bit under the encryption at each
layer. If the bit is set, the remailer publishes, on its own web site
the incoming message, the decrypted message, and the outgoing message.
If the bit is not set, the message is relayed privately as usual. The
publishing could be delayed for a period of time if desired.
Examining the web sites of the remailers will show where a published
message was lost or corrupted in transit. It will exit one remailer and
never enter the next - or enter it corrupted.
If identical messages sent with the publish bit on and off have different
long-term reliability statistics, it means the adversary has broken the
encryption, and can read the publish bit (and only corrupt messages that
are not publicly visible).
Note that merely flipping any data bit in a packet containing an email
message in transit will suffice to cause it to be discarded, since PGP
will report that it has been corrupted. (This would require hacking
the TCP checksum to avoid TCP error correction.) SMTP mailer logs on
such systems should also be scrutinized for indications that e.g. a
TCP connection was "reset" in the middle of receiving a message. It
would be worth recording full packet traces to and from some remailers
and looking for interesting activities such as TCP attacks or altered
data packets.
John
