1994-08-06 - Re: RemailerNet

Header Data

From: jdd@aiki.demon.co.uk (Jim Dixon)
To: adam@bwh.harvard.edu
Message Hash: e8bbc05829529a06f130b9c9133a10c1ef54cf460909da814718918a176d355f
Message ID: <4094@aiki.demon.co.uk>
Reply To: N/A
UTC Datetime: 1994-08-06 19:02:45 UTC
Raw Date: Sat, 6 Aug 94 12:02:45 PDT

Raw message

From: jdd@aiki.demon.co.uk (Jim Dixon)
Date: Sat, 6 Aug 94 12:02:45 PDT
To: adam@bwh.harvard.edu
Subject: Re:  RemailerNet
Message-ID: <4094@aiki.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


In message <199408061739.NAA05213@bwh.harvard.edu> Adam Shostack writes:
> | If you are using unmodified Internet hardware and TCP/IP as the underlying
> | transport system, then your point of entry into a remailer network
> | definitely knows which machine is originating a message and the point
> | of exit definitely knows where it is going.
> 
> 	IP is not reliable & trustworthy.  It it was, RFC931 ident
> servers would be useful. ;)  Theres source routing to make packets
> appear to come from someplace else, and there is outright forgery,
> which has limits, but can work quite well.

My "if you are using unmodified ..." clause shows that I understand this.

You can send from a very large network and forge your TCP/IP or
(more difficult) Ethernet source address.  But I can sit on the same
network, build a table relating TCP/IP to ethernet (or whatever)
addresses, and filter out messages that should not be there.  There
are commerical packages that do this sort of thing.

Basically, this is a different topic.  One problem is designing a
generic software package and set of protocols that will allow you
to route mail anonymously.  This is a general problem.	The hacking
of specific networks is a different, if related, problem.

--
Jim Dixon





Thread