Don't Kill the Messenger--A New Slant on Remailers
(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."
To add some background, here are two recent complaints which I received. They give some of the flavor of what people object to:
Please do not allow any more anonymous postings from your site to the Technical Writer's list. I don't see any reason we should waste time on messages from people we cannot respond to. One of the rules of the list is that MOST discussions are conducted "offline," with the list strictly reserved for topics of Technical Writers' interest. Anonymous postings do not allow this to proceed.
I am angered when I see the message "THE PORTAL SYSTEM DOES NOT CONDONE OR APPROVE OF THE CONTENTS OF THIS POSTING." I think this is irresponsible net behavior. It is liable to cause you service trouble when your site is inevitably spammed by angry EMailers and newsgroup readers from all over the world.
Dear Sir,
I recently received some mail through "anonymous-remailer@shell.portal.com" from a sick person that probably has (had) problems with the way I behave, and says he (or she?) means that my live has to be terminated. I do NOT approve of these kind of messages, and I also do not approve of your service to make these kinds of threads possible. I demand that you take action to trace and stop these massages, and I will make it my business to have these kinds of services banned from the Internet.
yours sincerely, <...>
These messages show that most people are unfamiliar with the notion of anonymous remailers. Their first exposure to the idea is when they get some objectionable anonymous mail. So to the extent that the problem is to be solved by education, we would have a very long row to hoe. Fortunately, the vast majority of such complaints can be dealt with by blocking the addresses of the people complaining from receiving future anonymous mail. This almost always satisfies people. The idea of making people ask to receive anonymous mail is interesting. It would not seem to apply to newsgroups and/or mailing lists, but for individuals it might work. The remailer would have to be able to distinguish between "end users" and other remailers in order to know whether it was just one step in a chain or the last step. (We can't depend on the sender to tell us that since it is abusive or harrassing mail which will cause the problems, and senders of such mail would presumably have incentive to get it delivered.) It would require somewhat greater resources on the part of the remailer to hold the messages. I would guess from experience that a large fraction of the messages would never be picked up, although my perceptions may be biased since I only see bounced, poorly formatted, or complained-about mail, and these categories probably have a larger fraction of messages from clueless and obnoxious people. But certainly the messed-up messages I do see are mostly flames, "guess who's", and similar worthless junk. I hope there are some pearls going through that I never see, but that is just a matter of faith. Hal
Timothy C. May writes:
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":
This is an interesting notion, but one I don't think is quite right. The anonymous remailer is not merely a courier. It actively modifies the message envelope by removing any indication of its origin. The main issue in Hal's quoted complaints are that the receiver isn't able to contact the sender. This fact is a direct result of the action of the remailer. Consider what would happen if a remailer were set up that *didn't* remove the "From:" data. Anonymizing remailer operators could attempt to limit complaints by forwarding everything through the non-anonymizer to make it the last link. Who do you think would get the complaints? The last anonymizer.
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."
I had a similar idea that I mentioned to Hal in a private message. How about a POP server that authenticates with crypto, and accepts and holds email addressed to the keyid of a PGP key? You send email to 4466A801@keymail.com it holds them for 30 days (or whatever) and discards them. When I connect to the server to retrieve my mail, it asks for my public key, encrypts a random challenge with it, and I tell it the decrypted version. Having proved that I can read messages encrypted to the key, it delivers messages addressed to the hash of the key. It might also allow me to configure an address where notifications of new messages should be sent. It's an interesting twist on the anon.penet.fi system, since you needn't bother tracking all the nym/email mappings, and *can't* give CoS any incriminating information.
Scott Brickner wrote: | I had a similar idea that I mentioned to Hal in a private message. How | about a POP server that authenticates with crypto, and accepts and | holds email addressed to the keyid of a PGP key? You send email to | 4466A801@keymail.com it holds them for 30 days (or whatever) and | discards them. When I connect to the server to retrieve my mail, it | asks for my public key, encrypts a random challenge with it, and I tell | it the decrypted version. Having proved that I can read messages | encrypted to the key, it delivers messages addressed to the hash of the | key. It might also allow me to configure an address where | notifications of new messages should be sent. Who cares if you can read messages encrypted to the key or not? Let everyone connect and download whatever messages they want to see. They're encrypted, after all. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
Adam Shostack writes:
Who cares if you can read messages encrypted to the key or not? Let everyone connect and download whatever messages they want to see. They're encrypted, after all.
Two reasons. One, it cuts down on traffic. Why bother to waste the server's bandwidth on something the client can't read anyway. The only possible reason someone could be asking for the data is because they're trying to compromise the key or do traffic analysis. Why help bad guys? Second, there's no reason the messages need to be encrypted. The server can accept messages addressed to *any* string of eight hex digits, and doesn't care about the content. The server needn't limit the kinds of encryption used in the actual message. It only cares that the recipient is "really" (in some sense) the right reciever. The original mental prompt for the idea came from the discussion of the "key-is-the-person" model. I was trying to devise a scenario where it was possible to know of an entity only through his key, and came up with this. I also included the idea that messages signed by the key would be forwarded by the server after being pseudonymized to the keyid. That way, the user could participate in mailing lists purely identified by the key.
participants (4)
-
Adam Shostack -
Hal -
Scott Brickner -
tcmay＠got.net