At 02:07 AM 10/3/97 -0500, Jim Choate wrote:
For purposes of argument, we could say that a remailer throws away messages that violate usage policies.
Way too high for commercial use. Get it down to something like .01 and that would be workable I suspect (haven't done the math).
You may be confusing actual traffic, with valid customer traffic. (BTW - the 10% reject figure was totally pulled out of the air. Since there is no logging on a remailer, I'm just making an educated guess.) Almost all commercial sendmail implementations reject a large amount of traffic and call it "spam filtering". It's very effective, but the fact is that incoming mail traffic is blocked before any program such as a remailer can see the messages. Some of this is done by IP address, some is done through other methods. I'm merely suggesting that a commercial remailer will have similar policies. A remailer will also toss any email that is not addressed to a deliverable recipient. Apparently some people can't type. :) I'm not suggesting anything is happening here other than what occurs with an ISP and normal email. Or what usage polices claim are allowable. I'm merely pointing out that like any ISP, some mail is tossed.
Course this raises the issue of who pays for dumped mail on a commercial box. Should the customer pay since it was their action that instigated the drop? Or perhaps the remailer since they were selling a service which they didn't provide at their discretion?
For usage policies, I would think it is the originating user's fault. For middleman mail rejects, it is the middleman remailer's fault. For public key errors, it is the originating user's fault. For the cases mentioned, I wouldn't put the blame on the initial remailer.
Let's generalize a bit to see if we can get a clearer picture. .... Are there any other classes that you can think of that you might want to filter on?
You can sum it up by saying messages are tossed due to * Spam * Denial Of Service (DOS) attacks * typing errors
If I understand you the remailer would send outbound traffic to its input for distribution to your subscribers? I don't believe it would factor into the analysis at all if all the source destinations are the same. Outbound traffic from party A that went to party B would be important to track.
Giving an example that overly simplifies things... I think my idea here was that for some number of nyms, they would each receive an average of, say, five messages each day. All five messages would be addressed from the remailer and PGP encrypted. Four of the messages would be from real people trying to communicate with the owner of the nym. One would be a bogus message sent to confuse traffic analysis. All four real messages would come into the remailer encrypted to the remailer and addressed to the remailer. My thought was that fake outgoing messages to the nym would look identical to real messages, thereby helping obscure the "mix" just a little better. This helps hide the identity of the sender of the email that is headed to a nym. To define nym again, a nym is someone who has registered a real email address with the remailer. For instance, ravage@anon.efga.org might remail to ravage@ssz.com. So it would be possible for someone to send a message to remailer@anon.efga.org that would ultimately arrive at ravage@ssz.com, but the sender would have no idea of who the final destination of the email. The remailer keeps this info in an internal database (as it must) and is not available to anyone other than the remailer software. There would be no way, without traffic analysis, for a connection to be made between the sender and the recipient.
It has nothing to do with limiting speech so I doubt you'd have a 1st leg to stand on. Furthermore, the 1st doesn't guarantee the right to anonymity.
Having just spent a year and a half involved in a federal court case over the 1st amendment right to anonymity on the net, and winning, I'd have to disagree with you here. Our affidavit specifically mentioned remailers, among other things. -- Robert Costner Phone: (770) 512-8746 Electronic Frontiers Georgia mailto:pooh@efga.org http://www.efga.org/ run PGP 5.0 for my public key