An alternative to remailer shutdowns

[Bill Stewart]

>>>Remailers on the attack points (first in chain, last in chain) simply MUST
>>>be disposable as tissue.  They must be run as anonymously as possible,
....
>>	Why the first in chain? If the anti-traffic-analysis provisions are
>>working properly, it should be impossible to prove that a given first remailer
>>was the first remailer for any particular message. [....] entrapment 

>Likewise, I don't see why the first address in the chain is vulnerable, as 
>long as the message subsequently passes through at least one trustworthy 
>remailer, and probably  a temporary output address.  

There are two major problems, which have different impacts
- protecting the users from corrupt remailers, and
- protecting the remailers from spamming or entrapping users

To protect users from corrupt remailers, you not only have to pass through
at least one trustworthy remailer, you have to encrypt the message for
each remailer in the chain so that any corrupt remailers can't read it
at least until it's been through the trustworthy remailer.

Protecting remailers from users depends on the threat.  If the government
wanted to claim that all the remailers were part of a Conspiracy to
Distribute Laundered Narcoterrorist Tax Evasion Paraphrenalia, 
first-in-chain remailers become vulnerable,
since the Postal Inspectors can send entrapment material to them
and document where it comes out, though the path between first and egress
can't always be documented, depending on how the remailers handle mail.
On the other hand, if the Church of Spam tries to frame remailers
by posting their own Secret Documents, they can only target the
terminal remailers and as far back as they can subpoena,
because they'd otherwise have to admit that they posted it.

There's been some discussion of delivering outgoing mail by
sending it through systems that don't add Received: headers;
it may make sense for non-root-owned remailers to do this
using telnet to port 25 instead of their local sendmail,
to prevent local logging and prevent their sendmail from
adding its own information.  Some sendmails try to detect forgery,
but systems that aren't even configured to do Receive: probably don't.

 Bill
#					Thanks;  Bill
# Bill Stewart, stewarts at ix.netcom.com, +1-415-442-2215
# goodtimes signature virus innoculation