[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Don't Kill the Messenger--A New Slant on Remailers

[email protected] (Timothy C. May) wrote:

>(I was out of town most of the past few days, when the debate about this
>"Modest Proposal" happened. In reading the messages in the thread, I see a
>lot of the issues mentione that we talked about several years ago--not that
>this is a sin to talk about issues more than once--and that led to the
>creation of "message pools" and groups like "alt.anonymous.messages". But
>some new ideas are emerging. And I have a new idea for a remailer, so this
>is turning out to be a fruitful topic! Too bad the topic has already died,
>At 4:36 PM 10/18/95, Hal wrote:
>>Eli Brandt <[email protected]> writes:
>>>If you
>>>split the message into shadows, you avoid having anyone in this
>>I think splitting the message would be OK, but then the question is who
>>is responsible for reassembling it?  If there were a "reassembly
>>server" which took such messages, assembled them, and forwarded them,
>>then we would be right back where we started from.  If the end user is
>>responsible for reassembly, then that is tantamount to voluntarily
>>agreeing to receive anonymous messages, and that is no problem.  The
>>complaints we get are virtually 100% from people who didn't want to
>>receive such messages, or see them posted.  And of course anonymous news
>>postings via shadows would also have the reassembly problem.
>Hal succinctly describes the conceptual flaws in many of these schemes to
>replace the "last remailer" with something else: it usually turns out that
>such replacements either don't work (forging headers) or merely shift the
>problem to another agent.
>The most practical short term approach is for any remailer operator feeling
>some heat to do what Hal does with his Caltech remailer: remail to a site
>less likely to cause problems. For example, bounce all messages through a
>Netherlands remailer. (Even if the NL remailers are ultimately shut down,
>using them accomplishes the practical purpose of removing the heat from
>one's self...of course, they might feel the same way and lob the message
>back to U.S. remailers!)
>(Leading to the "Dining Buck Passers Problem," where a message never gets
>delivered because all remailers are passing the buck by lobbing the message
>to other remailers...."Charlie on the MTA.")

There could be a risk based messgae market here.  That is what the Futures 
market is about speculation and hedging (buging and selling risk). What is
a risky message in one country may be acceptable in another.

>But I think I have a longer term solution, one that involves a change in
>thinking about the differences between the _originator_ of a message and
>the mere _messenger_.
>The notion is to much more explicitly separate the functions of the
>"messenger" or "deliverer" from the "originator" or "sender." Granted, this
>is already done in the sense that a piece of e-mail goes through many
>hands. For example, Hal's message that I am responding to here has this in
>the header blocks, showing some of the "couriers" or "messengers":
>Return-Path: [email protected]
>Received: from relay3.UU.NET (relay3.UU.NET []) by you.got.net
>(8.6.9/8.6.9) with ESMTP id KAA08536 for <[email protected]>; Wed, 18 Oct 1995
>10:47:24 -0700
>Received: from toad.com by relay3.UU.NET with SMTP
        >id QQzlzw04926; Wed, 18 Oct 1995 13:06:48 -0400
>Received: by toad.com id AA06207; Wed, 18 Oct 95 09:38:06 PDT
>Received: from nova.unix.portal.com by toad.com id AA06198; Wed, 18 Oct 95
>09:38:02 PDT
>Received: from jobe.shell.portal.com (jobe.shell.portal.com [])
>by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id JAA01733 for
><[email protected]>; Wed, 18 Oct 1995 09:36:59 -0700
>Received: ([email protected]) by jobe.shell.portal.com (8.6.11/8.6.5) id
>JAA17879; Wed, 18 Oct 1995 09:36:58 -0700
>Date: Wed, 18 Oct 1995 09:36:58 -0700
>From: Hal <[email protected]>
>Now, by convention, we don't treat the _intermediate_ steps in the same way
>that we treat the "From: Hal <[email protected]>" step. So, why do
>many treat _remailers_ as originators?
>Mostly, it's education. People get a message from "[email protected]"
>and they are trained to think this is the sender. Or, they are trained to
>think they can send a message back to this site, or to "[email protected]"
>complaining abou the mail they received and expecting that something will
>be done to make it stop. But trying to educate people that a remailer is
>not the same as a sender is likely to be a long and disappointing process.
>A better approach is needed.
>I believe that by changing the nature of remailers and making them much
>more explicitly like messengers, couriers, and delivery services, that we
>can win the public relations battle. There may still be legal challenges,
>but at least the semantics will not be so confusing. Just as Willis Ware
>made the point to Michael Froomkin about the confusing and misleading
>semantics of "escrow," I believe the same is true of the confusing and
>misleading semantics of "remailer." Perhaps we should just change the name
>from "remailer" (or "mix") to "Message Delivery Services." Perhaps some of
>you can think of a shorter and catchier term that still makes the messenger
>role clear.
>(I hang out on the Cyberial mailing list for cyberspace law discussions, so
>I am well aware that any change such as I am suggesting must also be tested
>as a legal strategy, and that conceptual ideas may not hold water, legally.
>I won't address legal issues here, at least not now.)
>The idea is to make it much more explicit that a remailer is merely
>_delivering_ a message. Few people hold their local postal carrier
>responsible for delivering a letter containing "bad material," be they
>threats, hate speech, unwanted pornography, etc. Likewise, package delivery
>services are generally not held responsible. And telephone answering
>services are not treated as the authors of, say, threatening messages, when
>they pass on messages such as:
>"Tim, you received a call at 4:15 p.m. saying that if continue with your
>project to collect reports of NSA visits to software companies that some
>guys dressed in blue suits will try to run you down in your parking lot."
>In these cases, we don't kill the messenger. We don't even sanction the
>messenger. And it's more than just that we treat the messenger as being
>ignorant of the contents, as the telephone message service example shows:
>there are several examples I can think of immediately in which harmful or
>hateful speech is relayed to someone with no expectation that the relayer
>will face sanctions.
>This is much more than the oft-cited doctrine of "common carrier" status,
>where the government (it is claimed) grants to the phone company certain
>rights and responsibilities with the proviso that it will not hold them
>liable for the _content_ of phone calls. (I'm not sure if Federal Express
>is treated as a "common carrier," but I'm fairly certain they are not held
>liable for various evils delivered in sealed packages, with certain obvious
>exceptions involving cooperation with law enforcement.)
>I'm not a lawyer, but I believe the law recognizes (and has for a long
>time) that the messenger of bad or harmful news, or mail, etc., is not to
>be held liable. There are oft-debated examples involving a newspaper
>editor's responsibility not to "relay" libelous material, and so forth, but
>these are not cases of mere couriers or messengers.
>(Counterpoint: And yet couriers who knowingly transport drugs of course
>face sanctions. This is a case where the possession (and hence transport)
>itself is illegal. This involves scienter--awareness--of what is being
>transported, in a way that delivery of an encrypted message clearly could
>not. Or even unencrypted messages, if the messenger could make a plausible
>claim that he does not look at or screen messages. Lots of issues to
>A MAIL DELIVERY SERVICE (don't we already have them? yes, but....)
>So, how would this work?
>With remailers, even more steps need to be taken to make it absolutely
>clear that the delivered message is not _from_ the last Internet site that
>shows up in the "From:" field. More than just disclaimers are needed.
>One approach is for a _notification-based_ system. To wit:
>"You have a piece of mail awaiting at our mail delivery service. The
>originator is unknown. The title of the message is "Tentacles of Medusa
>Must Die!" You may retrieve this message by replying to this notification
>with the word "Yes" anywhere in the Subject field. This message will be
>kept for 60 days and then deleted."
>The idea being to more carefully distinguish between mere messengers and
>the "From:" field (not that "From:" establishes origin, as we all know from
>the whole point of remailers, but most people associate "From:" with an
>actual originator, wherein lies the problem).
>It would also lessen complaints from people who suddenly find unwanted mail
>arriving anonymously. People would have to make at least some token effort
>to "accept delivery."
>Similarities to "general delivery" mail delivery are obvious, as are
>similarities to fee-based mail forwarding services and "Mailboxes Etc."
>(By the way, and not to digress again, but I see systems like this as the
>likely future of mail. Some scheme where a user chooses to accept or reject
>delivery--as with packages delivered which one can refuse delivery on--is
>needed to solve several problems: mailbombs, unwanted illegal material
>arriving, the sheer flood of mail, etc. And with people moving around,
>changing companies, wanting anonymity, etc., such mail service sites will
>be a natural fit. Having them add filtering services, a la MailWeir, is one
>obvious service.)
>This could be implemented as a new type of remailer. This could also
>integrate with paid delivery systems, a la digital postage. (I can imagine
>some people demanding to be paid some small amount to receive a
>message....this is not feasible with the current "free delivery" model, but
>a lot of things are not possible with "free delivery." But I digress.)
>I'll quit for now. Lots of issues.
>"Don't kill the messenger."
>--Tim May

I like the Mail Delerery Service idea combined with user selectable

I would also like to see the merging of different message transmission
technology using gateways.  We have gateways... Fidonet to/from internet,
email to newsgroup, and Telegram to (snail) mail.  Would it not be
beneficial to add other gateways such as email to snail mail, email
to fax, fax to email, snail mail to email, and CB to email.

Remailers are in place in the RF world.  They are called repeaters or
transponders.  They perform the function of taking a weak signal and
boost it's power so that a larger group of receivers can pick up the
signal.  Ham radio has (vhf ?) repeaters in metropolitan areas.  Satellites
use transponders allowing the signal to be sent from horizon to horizon.
(this already has potential problems.  Hughes is comming out with a
product called DirectPC. I believe it allows you would transmit over a slow
modem but receive high data rates from a satellite.  I guess if you just look
at or edit some crypto source code from your shell account, it would be exported
as far as the satellite horizon as a byproduct of being sent to your display).

Does it not make sense for some kind of listening post to be set up to
take messages sent via Satellite, Ham radio, or CB and either place them
in a newsgroup or an archive site or a mail delivery service?  Transmitting
your anonymous e-mail by CB would be kind of nice.

Some of these RF modes are highly regulated. I believe that Hams
already have packet radio but cannot encrypt data and are accountable
for all the data being sent on their transmitter.  CB seems less regulated
, perhaps because of it's limited power and range. (this would change
with an internet repeater.)

I don't know about satellite regulation, but recall some CNN broadcast out
of Bagdad with a portable transmitter during Desert Storm.  Perhaps that kind
of equipment will be cheap and available in the future.  Is public access
limited to cable?

-Tom Rollins <[email protected]>