March 1993 - cypherpunks-legacy

REMAIL: "Stealth" Remailers
by edgar＠spectrx.Saigon.COM 28 Mar '93

28 Mar '93

-----BEGIN PGP SIGNED MESSAGE----- In the wake of the forced demise of penet.fi, Dave del Torto said: >>> The anonymous service at anon.penet.fi has been closed down. This is a dark day indeed. The forces of Repression are upon us yet again. OK, where do we set up the next one? I guess the solution here is to have a floating set of difficult-to-detect anon remailers and switch between them regularly. I have an idea for making remailers more difficult to find. This applies only to systems where the remailer operator owns the system, such as at wimsey.com. (But a "system" can be just a PC/XT with hard disk and modem - maybe under $1000). Where the remailer operator controls the system, it's easy to "forge" net headers. The problem is that once you send mail, other systems are going to add "Received:" lines to the net headers that point back to you. I don't know how to stop this once the mail leaves your control. But it should be possible to add -extra- "Received:" headers, indicating you received the message from some system "behind" you. Should the "net police" trace an "offensive" message back to you, you can point to the added net headers and say, "Oh, but this came from -him-, not -me-; -I'm- just an innocent forwarder (not remailer) of this message. That SOB down at the end there must be running one of those infernal remailers; Go get him!!" By the way, these phony added headers should all have -real- system names. It's fairly easy to trace messages along the "mainline" internet, because those are all "hard-wired" leased lines. But there's another class of system called UUCP which sends and receives messages over the - -switched- network (ordinary dialup telephone lines). Many of the mainline systems accept UUCP accounts, so UUCP systems usually have the same internet connectivity as the mainline systems for E-mail. (They can't do FTP and Telnet). Furthermore, UUCP systems can allow other systems UUCP accounts, creating long chains over the dial-up net. Furthermore, a UUCP system can be set up with a minimal investment in hardware. A single hardware system can be -many- different UUCP "systems" by just dialing into different UUCP "accounts". A good strategy is to accept mail for remailing at one well-publicized UUCP address, but -never- use that same account for -sending- remailed mail. Just use one of several -other- UUCP accounts for that, adding phony "From:" and "Received:" net headers as explained above. Be generous in accepting UUCP accounts from other systems; don't take too much trouble verifying the registration info they give you. Once they've been on a while, start using their names in the phony "Received:" headers you generate. Well, I'm not an expert on either the net or the "Waffle" software used to run small UUCP systems (like this one). But perhaps the above ideas will prove useful to those of you who are. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBK7RidN4nNf3ah8DHAQG1/AP/dphEH+j0pou/jZ86PhQEffyVyzcHBm0A lwEnJFhX7RXx3l4RNlhv9dTRwQwaQPiaZ7qfWhdtqIsWwBSD39krfv7RwZDVI6Rs nuzE67BvLljl4N1rEqUdW/ln3gFvUBo/ud+b3DBFJFZEOMRPJFFkE5hux5RBxG+N wk3X28rUUM8= =BVPy -----END PGP SIGNATURE----- -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

3 2

Penet.fi replacement up
by Dan McGuirk 28 Mar '93

28 Mar '93

I just wanted to let everyone know that another penet.fi-style anonymous service has been set up. It works the same as anon.penet.fi did for anonymous mail, but it only allows anonymous posting to about ten newsgroups. For information, send a message to "anonymus+info(a)charcoal.com" (yes, anonymous should be misspelled).

1 0

alt.hackers post
by Eric Hughes 28 Mar '93

28 Mar '93

Here's the other one Eric ----------------------------------------------------------------------------- From: hughes(a)soda.berkeley.edu (Eric Hughes) Newsgroups: alt.hackers Subject: a new feature of the remailer Message-ID: <HUGHES.92Oct9095848(a)soda.berkeley.edu> Date: 9 Oct 92 13:58:48 GMT Distribution: alt Organization: /accounts/hughes/.organization Lines: 191 Here is the third in the series of articles on the remailer. Remember, these are meant to be fairly tutorial. Eric ----------------------------------------------------------------------------- There's a new feature in the remailing software. Some people can't add arbitrary header fields because of mailer or gateway restrictions. This restricts them from using the remailer. I have added a facility to allow new header fields to be pasted onto the end of a header when the mail arrives. This effectively happens before processing by the remailer software. These new fields exist during transit in the message body, where they remain untouched. Only after the message is delivered to my account does this operator take effect. Syntax: If the first line of the body is the two characters "::", then the following lines are appended to the header, up to the next blank line. Here's how it works. First of all, here's my new .maildelivery file: ------- cut here ------- # # field pattern action/ string # result (quote included spaces) # Request-Remailing-To "" pipe R "perl remailer/remail.perl" Request-Remailing-To "" file R remailer/archive * "" pipe R "/usr/local/lib/mh/rcvtty -biff" * "" pipe ? "perl remailer/incoming.header.perl" ------- cut here ------- Comments are indicated by #. The Request-Remailing-To lines have been there. The second of the makes an archive for debugging purposes. It will go eventually. The third field, "*", indicates all fields, it runs 'rcvtty' on my mail; this replaces the function of biff, since mail is getting piped to slocal now, disabling biff. The last line is the important one. It says "If the mail hasn't been delivered by now, run the incoming header rewrite script on it. If that doesn't work, continue trying to deliver it." Now here's the trick. slocal has no way of taking the output of the rewrite and continuing to process it. (It should. It would make this whole job easy.) So in order to continue processing, you need to redeliver the mail. You could invoke sendmail and mail it back to yourself, but that would mangle the existing header. So the thing to do is to recursively invoke slocal from within the perl script. Here's the perl script to do all this: ------- cut here ------- # First read in the whole header. # We check for the Second-Pass: line to detect infinite loops. while (<>) { last if /^$/ ; exit 1 if /^Second-Pass:/ ; $header .= $_ ; } # We have just read the last line in the header. # Now we check to see if there is a pasting operator. if ( ( $_ = <> ) && /^::$/ ) { while (<>) { last if /^$/ ; $header .= $_ ; } } else { # There is either an empty body or no pasting operator # Thus exit with a return code of 1 to indicate that # the mail has not been delivered. exit 1 ; } # There was a header pasting operator. # So we open 'slocal' as a pipe, effectively redelivering the mail # back to ourselves. #open( OUTPUT, ">foo" ) ; open( OUTPUT, "| /usr/local/lib/mh/slocal -user hughes" ) ; select( OUTPUT ) ; # print a "From " line to satisfy slocal @weekdays = ( "Sun","Mon","Tue","Wed","Thu","Fri", "Sat" ) ; @months = ( "Jan","Feb","Mar","Apr","May", "Jun","Jul","Aug","Sep","Oct","Nov","Dec" ) ; ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime ; printf "From hughes %s %s ", @weekdays[ $wday ], @months[ $mon ] ; printf "%2d %02d:%02d:%02d 19%d\n", $mday, $hour, $min, $sec, $year ; # Now just print out the message print $header ; print "Second-Pass:\n" ; print "\n" ; while (<>) { } continue { print ; } ------- cut here ------- Here's how the perl script works. The first loop reads lines from the existing header. When it sees a blank line (regexp /^$/) it terminates the loop. If it sees a field "Second-Pass", it knows it has filtered this message before and exits with a return code indicating that the mail has not been delivered. The variable $header is appended with the current header line. $header contains the whole header when the loop terminates. Properly speaking, the Second-Pass test is not necessary to detect infinite loops. Since the pasting operator gets removed during the rewrite, the script won't return an exit status of 0 more times than the pasting operator appears. But should something get screwed up, such as a different module adding pasting commands (how? I don't know), the Second-Pass test should prevent infinite recursion. The next statement reads another line from the input file. This line is the first line of the message body. If this line is the pasting operator, then header lines are accumulated in $header as before until a blank line. The difference is that these header lines are being read from the body of the message. If there is no pasting operator, the script exits undelivered. At this point we now have to redeliver the message back to ourselves. We first open slocal as the output pipe. The next section is a kludge. It turns out that slocal strips off the out-of-band "From " (no colon) line that the mail delivery system uses. In other words, the message which slocal pipes into its pipes is not identical to the message it itself received. This means that slocal cannot be directly recursed. What this section does is to create a "From " line to make slocal happy. It calls localtime() and then formats those numbers into the proper form. It turns out that slocal will deliver this mail without the "From " line, even to /usr/spool/mail, but it doesn't do so properly. On my system, in added some delimiters which I think I've tracked down to the 'mtstailor' file, namely mmdelivery1 and mmdelivery2. Since these are not null on my system, there's some garbage added which screws up separation of the spool file into messages. Adding a "From " line fixes that. This misbehavior may not be so surprising, considering that slocal was "meant" to be invoked only in a .forward file. Now we print the variable $header which contains the whole header, including newlines. Using a single string removes the need for an array. We added the Second-Pass line and a blank line for the end of the header. The final loop prints out the rest of the message body. There is another way to proceed to get the same functionality. One could write a filter to translate the first occurrence only of \n\n::\n into \n. We could then pass the message through this filter before slocal saw it. And for now, that would do the same thing. But suppose we want more that one rewrite rule active? Then you would only be able to apply each rewrite rule exactly once in fixed order. You want to be able to rewrite a message and then apply all the rewrite rules again. At least one other rewrite rule is planned: automatic decryption. Since decrypting a message will completely change the body, and since some of the header fields may need to be hidden, you have to be able to decrypt the body and then paste on header lines. But since you need to indicate an encrypted body by a header line (well, not really, but it's more reliable), and since some people can't add these header lines, you need to paste lines before encryption as well. Thus the rewrite rules need to be applied asyncronously and hence I'm using a fairly complex slocal scheme to do a simple filter. Eventually I hope to write an equivalent to slocal which knows about message rewrites and simple filters, but that's for later. ----------------------------------------------------------------------------- To follow this project (and others soon to be started), send mail to cypherpunks-request(a)toad.com and I'll add you to the mailing list. Eric

1 0

alt.hackers post
by Eric Hughes 28 Mar '93

28 Mar '93

Rusty Babani forwarded me my hackers postings from six months ago. Thanks! Here they are (in two messages). Eric ----------------------------------------------------------------------------- From: hughes(a)soda.berkeley.edu (Eric Hughes) Newsgroups: alt.hackers Subject: Remailer that will run on a user account Date: 25 Sep 92 16:17:25 GMT Distribution: alt Organization: /accounts/hughes/.organization Lines: 347 What follows are a couple of postings to the recently formed cypherpunks mailing list. They are tutorial in form because the list is not entirely hackers. Enjoy and deploy. Eric ============================================================================= How to Make an Automated Remailer in Your Copious Spare Time with Easy to Find and Inexpensive Software Tools You May Have Lying Around. <reprinted from Popular Cryptography, September 1992. Used with permission> The basic remailer illustrates how to hook in automated software processing into the Unix mail system. Here are the basic elements. 1. .forward 2. slocal and .maildelivery 3. remail.perl 4. /usr/lib/sendmail -------------------------------------------- 1. .forward Unix mail provides a way to have accounts on many different machines but to receive all your mail in one place. That facility is the .forward file, which resides in the home directory. The file is one line long and contains the email address to which the mail will be forwarded. But the .forward file has another mode of operation. If the string begins with the pipe character '|', the mail will be piped through the program listed. Enclose the string with double quotes if you need spaces included. Here is my .forward file: "| /usr/local/lib/mh/slocal -user hughes" Thus all my mail gets processed by the slocal program, described next. I don't know where the man page for .forward is. Perhaps someone could provide a reference. --------- 2. slocal and .maildelivery The software system MH contains a bunch of useful tools for handling mail, only one of which we need. For details on MH, do 'man mh'. MH has a nice little mail hook processor called slocal. Its docs can be found by 'man mhook'. slocal can conditionally perform operations on mail messages and consider them either delivered or not. It allows multiple operations on individual mail messages. slocal reads the file .maildelivery when it starts up for instructions. Here is my .maildelivery file: # # field pattern action/ string # result (quote included spaces) # Request-Remailing-To "" pipe R "perl remail.perl" Request-Remailing-To "" file R archive.remailer The various pieces of the .maildelivery file are fully documented in the man page. I'll just explain what mine does. Each line describes one operation to be performed on each incoming mail message. Fields are separated by whitespace, so if you need to include spaces, use quotes. The first field, labelled field, is the mail header field to look for. slocal can selectively process on any header line. If the header line does not exist, then the mail does not match this line and no operation is performed. If the header line does exist, processing continues. The second field, pattern, is a text string to match with the contents of that header line, i.e. with everything after the colon. In my case, I put the empty string in, which matches everything. You need the pair of quotes to have a placeholder for the field contents. The next field, action, tells what to do with the message. 'pipe' sends the message to the standard input of the named program. 'file' appends the message to an archive or log file. A useful pipe command for testing is "tee foo", which makes a copy of the message in file foo, but does not append, so that you get an exact copy of what slocal is going to pass to your pipe. This allows testing of the pipe program without sending yourself mail all the time. The next field, result, tells what to do with the message after processing. I am currently using R for Regardless to indicate that this action should always be performed no matter what. The code R indicates that the mail should be considered not delivered after processing; thus slocal writes the mail back into my local spool and I see it as normal. Later, after I'm sick of looking at all the forwarded mail, I'll change this code to A, meaning if the processing succeeds, then the mail is considered delivered. The archive file will always remain R. The last field, string, is the parameter to the action. It is a file name or program. Use quotes to include spaces. The name of my mail processor is "perl remail.perl", which is to run the perl script remail.perl on the mail. The .maildelivery file is also the place to put encryption hooks to automatically decrypt the bodies of messages. More on that in a future version. --------- 3. remail.perl Perl is a wonderful language for doing all sorts of useful work like processing mail headers. Do 'man perl' for details, or get the O'Reilly book and really learn how to use it. The perl script, in summary, strips off the mail headers, saving the Subject: line, rewrites a new header, and appends the body of the previous message. Here is the script: --------- cut here --------- while (<>) { last if /^$/ ; $subject = $_ if /^Subject:/ ; if (/^Request-Remailing-To:/) { chop ; s/^.*:// ; $addressee = $_ ; } } #open( OUTPUT, ">foo" ) || die "Cannot open 'foo'." ; open( OUTPUT, "| /usr/lib/sendmail " . $addressee ) ; select( OUTPUT ) ; print "To:" . $addressee . "\n" ; print "From: nobody\n" ; print $subject ; print "Remailed-By: Eric Hughes <hughes(a)soda.berkeley.edu>\n" ; print "\n" ; while (<>) { } continue { print ; } --------- cut here --------- Here is a summary of the operation. To really understand this, you'll have to learn perl. The while loop processes standard input. 'last' terminates the loop as soon as a blank line is seen. A blank line separates the header from the body. The subject line, if seen, sets the subject variable to the whole subject line. The Request- header line has its final newline removed, the contents up to the colon substituted into nonexistence, and saves the rest in the addressee variable. Next the pipe to sendmail is opened and its output is selected so that all print commands will go to the pipe. There is a comment for a different output channel to the file foo which can be commented in for testing. Next the remailed header is constructed out of print statements. Lastly the rest of the standard input is passed through unmodified to the output channel. The while loop terminates when there is no more input. --------- 4. sendmail sendmail is the backend mailer; it expects complete mail messages and does not usually generate any line itself except for the first "From" (with no colon) line. Any header you construct will thus get passed through mostly unmodified. Hence you can put in any "From:" line you want and any other header info, such as my "Remailed-By:" line. sendmail expects the name of the addressee on its command line, otherwise it puts an "Apparently-To:" line in the header. Any mail processor which remails should probably go through sendmail, although it would also be possible to talk to an SMTP port directly, were you so motivated. MH also has some remailing programs; see 'man mhook'. --------- A few words for tinkerers. -- You can always send mail to yourself. Especially after you've done one kind of mail processing and want to pass the mail through the filters again. -- When getting started, create an empty .maildelivery file first and then get your .forward file working. Test it by sending messages to yourself. If you're not getting them, they are going into the bit bucket. All your other mail will as well, in this case, so if you can't afford to lose mail, do it right the first time or work on a spare account. -- Any mail slocal does not process will get delivered as normal. Running a remailer will not interfere with your other work. -- Remember to use quote marks. -- You don't need to be a sysadmin to run this kind of remailer. There is nothing, however, to prevent a sysadmin from running this sofware under an alias. The sysadmin is also a 'trusted user' to sendmail and can get rid of pesky "From"-no-colon lines. -- Perl has a random function which could be used to automatically choose various "From:" lines from a database. Remember to include yeltsy(a)kremvax.rus. -- postnews or inews could be substituted for sendmail. Different header lines would have to be created. Such a service could run in parallel with a remailer. You too can now repost to alt.sex.bondage! Enjoy. And watch for interesting improvements like encryption. Eric ============================================================================= The hopping remailer is finished. I wrote it this morning. The change to make a hopping remailer is very easy. Here's the new perl script: --------- cut here --------- while (<>) { last if /^$/ ; $subject = $_ if /^Subject:/ ; if (/^Request-Remailing-To:/) { chop ; s/^.*:// ; $addressee = $_ ; } } #open( OUTPUT, ">foo" ) || die "Cannot open 'foo'." ; open( OUTPUT, "| /usr/lib/sendmail " . $addressee ) ; select( OUTPUT ) ; print "To:" . $addressee . "\n" ; print "From: nobody\n" ; print $subject ; print "Remailed-By: Eric Hughes <hughes(a)soda.berkeley.edu>\n" ; # # check to see if there are header lines in the body to collapse # into the full header. # if ( $_ = <> ) { if (/^##$/) { # do nothing if the pasting token appears # the rest of the body will be directly appended # this allows for extra header lines to be added } else { # normal line print "\n" ; print $_ ; } } else { # empty body exit ; } while (<>) { } continue { print ; } --------- cut here --------- Short explanation. The 'print "\n" ;' line was moved inside the new if statement. The if statement reads a line of the body and stops the script if there is no body. The line read is tested to see if it contains the two characters "##" alone on the line. "##" is the ANSI C token pasting operator. If there is no pasting, a blank line is printed to mark the end of the header and the first line of the body is printed. If there is pasting, then the conditional does nothing, which has the effect that the body is appended directly onto the end of the header, allowing you to add more header lines after the header is rewritten. Here is a sample message that I sent myself after the new script was installed: --------- cut here --------- To: hughes Subject: multiple hops Request-Remailing-To: hughes ## X-Hop: 1 Request-Remailing-To: hughes ## X-Hop: 2 Request-Remailing-To: hughes ## X-Hop: 3 This is a test message of multiple hops. Eric --------- cut here --------- I received four pieces of mail after sending this to myself. The first was the actual letter, which is still delivering normally and not being filtered. The next two were the first and second remailings; they had X-Hop: 1 and 2. The last message was the final one, had X-Hop: 3 in its header and was delivered normally. At each stage, the header got rewritten and a new Request-Remailing-To: line inserted. When that mail got delivered, it was again rewritten, with a new remailing request. This process is extensible up to the 50K or so practical limitatation on mail size. Note that this system is not at all secure by itself. But if each message body were encrypted first, and the message first decrypted before the header re-write took place, the routing instructions as a whole would be hidden from prying eyes. That's the next project. Eric ============================================================================= To be on the cyhperpunks mailing list, mail to cypherpunks-request(a)toad.com I'll put you on. Eric

1 0

ANON: Mark anon. posts a
by Hal 28 Mar '93

28 Mar '93

-----BEGIN PGP SIGNED MESSAGE----- I sent mail to Cypherpunks on this a couple of days ago, but it never appeared. There is a problem with the notion that all "anonymous" remailers and news-posting services should label their messages as anonymous so that users can decide whether to read them or not. This approach abandons one of the strongest arguments in favor of anonymous remailers, which is that the net is inherently an anonymous environment. Especially as more public access Unix systems, BBS systems, and so on become part of the net, we are going to see less and less of the strict controls on identity which were possible when the net was restricted to a few government labs and large universities. The level of anarchy will inevitably increase as larger numbers of people acquire net access. Unless massive and universal authentication efforts are undertaken, it is going to be more and more the case that you will know little about the true identity of a poster. Because of this, those who object to having to read the words of an "anonymous" poster are taking an untenable position. They are already reading words of people about whom they know no more than they would about an anonymous poster. And the argument that "non-anonymous" posters are subject to a form of discipline not available to anonymous posters - messages to the system operator - is clearly falsified by the existance of many sysops who care nothing about complaints. As more and more people run their own machines with net access, these cases will only increase. In short, we anonymous remailer operators have every right to be part of the net. We introduce no more problems than are already happening and will continue to occur as the net grows and becomes more universal. The resistance we've seen is from old-time sysops who are unable to adjust to a changing network environment. Rather than placating obsolete beliefs about network identity by agreeing to mark our messages with the scarlett letter A for anonymity, by accepting that we deserve to be in a ghetto set aside for inferior posts, I feel that we should challenge the net with messages that blur the distinction between anonymous and authenticated posts. The sooner people realize that there is no line that divides the clean from the unclean, the sooner anonymity will be widely accepted on the net. Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK7S2oqgTA69YIUw3AQEfagP8DlzINcvUDn7jc351S+hHTBz5NtB3RbRC l+0rgltFcn6QxWaE0GsWFcOa6RcPOe1DOTlwiJejiT6MbnfuDopbUoS98bCiIzLE 0Q2ZVhtsfLs5zFdUj08bRzzU7zyuzSmNoSsCx01O6OiGZB/zs0PEnx/0XqRtXFD2 RM1YTCPIF7Y= =0zw5 -----END PGP SIGNATURE-----

2 1

ANON: real-person newsgroups
by Marc.Ringuette＠GS80.SP.CS.CMU.EDU 28 Mar '93

28 Mar '93

Hal Finney (I think) writes, > the net is inherently an anonymous environment. > ...The sooner people realize that there is > no line that divides the clean from the unclean, the sooner anonymity will > be widely accepted on the net. But there _is_ a line, and people will likely want to draw it. It's true that currently there aren't any security guarantees to prevent a person from pretending to be someone else, but there will be. PEM certificates will distinguish between real people and personas. A public-key-authenticated "real person newsgroup" can be implemented. This raises the possibility that most newsgroups will transition to real-person-only status. This will cramp the style of those of us who wish to participate in the net using a persona. I think a major task ahead of us is to provide an alternative to "real people = good, personas = bad", and to put forward alternatives to "real person newsgroups" which are tolerable to most and more palatable to us. So what's the distinction we might wish to put forward instead of "real person"? "Paying customer", perhaps, or "respected reputation"? Yeah, that sounds good. Maybe it's time to set up some reputation based newsgroups, with a means of keeping track of who has been posting good stuff, and of filtering for credibility. -- Marc Ringuette (mnr(a)cs.cmu.edu)

2 1

Speaking of TEMPEST....
by David Heck 28 Mar '93

28 Mar '93

I was able to procure a tempest specced HP Laserjet + (model 2686 TA), used around a year ago and recently did a motherboard swap to upgrade the unit to 2mb of RAM...wasn't all that much to rip apart and put back together...even with all the damn machined-screws and shielding, the thing still emits a fair amount of noise, but no farther than the room it's in... I checked all my cables and system box and switched to shielded cables and cleaned up the the noise as best I could...interesting design and at least I would see the damn snoops...they'd have to be in my front yard to pick it up...anyone else hack any used TEMPEST stuff? David a.k.a. Unixorn

3 2

Re: ANON: Shutdown of Anon.penet.fi
by nobody＠alumni.cco.caltech.edu 28 Mar '93

28 Mar '93

It is fruitless to try to guess the identity of the famous network personality. You only tar innocent people. The truth will come out, more likely sooner than later. Nowhere, Man

1 0

Re: TEMPEST in a teapot
by ghoast＠gnu.ai.mit.edu 28 Mar '93

28 Mar '93

> > ----- Begin Included Message ----- > > It is speculated that poorly protected systems can > be effectively monitored up to the order of one kilometer from the target > equipment. > > ----- End Included Message ----- > > The "readability" of the relatively high energy sweeps in a standard CRT monitor > is well known. Any idea of similar effects on LCD screens ? The energy involved > would be orders of magnitude less, just for starters. Also, since the whole screen > is effectively oscillating, I'm not sure that there is any 'raster' sweep per se > going on here at all. This could be a factor for the truly paranoid :-) using > portables with LCD screens. > > > Pete Carpenter pete(a)cirrus.com > I've been told that the CRT is not what is generating the signals at all, rather that it is the CPU, and that having an LCD screen won't save you, strength of signal reduced or otherwise.

2 1

REMAIL: Anon. remailers
by wixer!pacoid＠cactus.org 28 Mar '93

28 Mar '93

One alternative would be to use the technology within its own narrative.. If IP providers and other sysops are *annoyed* that an anonymous remailer passes "untraceable" email, why not have a remailer that passes email with a trail of encrypted SASE ?? That way, the identity of the person posting is preserved, albeit not the physical location.. pxn. pacoid(a)wixer.cactus.org

1 0