1995-10-20 - Don’t Kill the Messenger–A New Slant on Remailers

Header Data

From: tcmay@got.net (Timothy C. May)
To: cypherpunks@toad.com
Message Hash: 65052b5f70504b7243408e127c65ff540532e48adc6f7122763ba0332b563ddb
Message ID: <acac7cd8430210046e54@[205.199.118.202]>
Reply To: N/A
UTC Datetime: 1995-10-20 06:22:26 UTC
Raw Date: Thu, 19 Oct 95 23:22:26 PDT

Raw message

From: tcmay@got.net (Timothy C. May)
Date: Thu, 19 Oct 95 23:22:26 PDT
To: cypherpunks@toad.com
Subject: Don't Kill the Messenger--A New Slant on Remailers
Message-ID: <acac7cd8430210046e54@[205.199.118.202]>
MIME-Version: 1.0
Content-Type: text/plain


(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,
apparently.)

At 4:36 PM 10/18/95, Hal wrote:
>Eli Brandt <eli@UX3.SP.CS.CMU.EDU> writes:
>
>>If you
>>split the message into shadows, you avoid having anyone in this
>>position.
>
>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.")


THE ROLE OF THE "MESSENGER"

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: owner-cypherpunks@toad.com
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by you.got.net
(8.6.9/8.6.9) with ESMTP id KAA08536 for <tcmay@got.net>; 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 [156.151.3.4])
by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id JAA01733 for
<cypherpunks@toad.com>; Wed, 18 Oct 1995 09:36:59 -0700
Received: (hfinney@localhost) 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 <hfinney@shell.portal.com>

Now, by convention, we don't treat the _intermediate_ steps in the same way
that we treat the "From: Hal <hfinney@shell.portal.com>" step. So, why do
many treat _remailers_ as originators?

Mostly, it's education. People get a message from "remailer@kremvax.org"
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 "root@kremvax.org"
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
discuss.)


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."
services.

(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

Views here are not the views of my Internet Service Provider or Government.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
Corralitos, CA              | knowledge, reputations, information markets,
Higher Power: 2^756839      | black markets, collapse of governments.
"National borders are just speed bumps on the information superhighway."







Thread