1996-03-09 - Re: Remailer Security

Header Data

From: “E. ALLEN SMITH” <EALLENSMITH@ocelot.Rutgers.EDU>
To: jrochkin@cs.oberlin.edu
Message Hash: 3baa0f63797498dc29cbe56c9b1ffcb7fdf48cfe096731ead339cd9b252fdade
Message ID: <01I25746VK34AKTUGH@mbcl.rutgers.edu>
Reply To: N/A
UTC Datetime: 1996-03-09 23:31:06 UTC
Raw Date: Sun, 10 Mar 1996 07:31:06 +0800

Raw message

From: "E. ALLEN SMITH" <EALLENSMITH@ocelot.Rutgers.EDU>
Date: Sun, 10 Mar 1996 07:31:06 +0800
To: jrochkin@cs.oberlin.edu
Subject: Re: Remailer Security
Message-ID: <01I25746VK34AKTUGH@mbcl.rutgers.edu>
MIME-Version: 1.0
Content-Type: text/plain


From: jrochkin@cs.oberlin.edu (Jonathan Rochkind)

>Um, there's no reason why your remailer's account needs to be logged into
>interactively, is there?  Seems like remailer ops should disable login to
>remailer accounts, putting '*' into the password field in /etc/passwd, or
>however unix lets you disable login (I know it does).

	This depends on the setup at the remailer machine. If I'm operating
a remailer off of a rented account on a commercial machine, how am I going to
maintain the remailer when it crashes if I can't get into that account? This
would work to some degree if the machine in question had the remailer program
in a publically-accessible account, and all the remailer account was doing was
A. acting as a forwarding account and B. containing info like the private key
of the remailer. But it could still go wrong in a way such that you'd need to
get into the account (or have root access, which is equivalent from what I
know of the subject).
	-Allen





Thread