Re: An alternative to remailer shutdowns
At 03:05 PM 5/21/96 -0500, you wrote:
To make it easy, how about a two part MIME message with the key and the PGP-encrypted message. The message text would be directions on opening it up, and breaking the "seal", which constitutes acceptance of the remailer terms...
Is that really any different than delivering the message rot-13? One of the reasons people object to getting anonymous email is spam; sending "You have mail; pick up message-id #2718281828 by midnight tonight!" encourages you to go to some effort to pick up the message, so you'll be even more annoyed if it's spam. Similarly, for hate-mail. PROPOSAL -------- On the other hand, a pickup system could reduce directed spam, if people generally don't pick up remailer pickups unless they recognize the messageid, leaving the remailer system to people who actually want to communicate with each other anonymously, which _had_ been one of the original goals of remailer systems. Protocol support requirements:? We could build in a fancy header, or we could just use the Subject: line, which many remailers know how to paste in anyway, and let the remailer do a messageid. Response mechanisms should probably be an email message to the remailer :: Deliver-Message: 2718281828 A secondary concern is handling multi-casts - should the remailer create one copy for each recipient (secure, easy, space-wasteful), or should it try to get fancy and keep the message for N recipients or D days? Two ways to implement the fancy version are to keep a flag that says not to delete the article upon receipt, while the normal behavior deletes it, or to use different keywords for picking up delete-after-pickup and shared messages. NEGATIVES --------- The big negatives with this approach are that it doesn't support PGP-encrypted messages, since they don't easily fit into one line, while they also encourage people to forget that the header of their message will be delivered insecurely. But it's probably close enough for non-anti-government work. Of course, it also doesn't do chaining; that either needs to be implemented by recognizing well-known remailers and forwarding directly instead of pickup, or by using a standard message format, so other remailers could do pickup. It's probably worth doing both, to support other remailer types transparently and to allow remailers to use pickups without having to be well-known. Adding automatic remailer registration is easy, but requires care to avoid spammers falsely registering victim@wherever.com as a remailer and then spamming. SPAM POSSIBILITIES ------------------ That still allows 1-line spams like Subject: <Expletive Deleted>! You <perjorative deleted><ethnic slur deleted>! or Subject: Our new Remail-Spam(tm) system lets you fit 1015 characters in a Subject: line, just like this one, so your whole message can fit through those anti-marketing filters! You can MAKE M0NEY REAL FAST building your downline - send e$1 of Bank Foo ecash to the top three addresses in the Cc: line but at least it cuts down on the annoyance level. It also supports messages like Subject: Secrets of the Scientologists for Sale! Pick up message for free sample and price list! Operate your own Thetan today! which permit direct-e-mail spams, or as some people prefer to call them, marketing opportunities. An interesting security/legality wrinkle is that if somebody is trying to multicast-publish unencrypted contraband data, it's sitting around in the mail-pickup spool, it can be seized by Bad Guys / courts / sheriffs / etc. As with most remailers, there's also a risk that outgoing unicast mail could be seized while in the spool, which is higher for a pickup system because the data may be in the spool longer. # Thanks; Bill # Bill Stewart, stewarts@ix.netcom.com, +1-415-442-2215 # goodtimes signature virus innoculation
Probably the best system is one that is in the middle.... that is say a message comes into a remailer targetting a user whom the remailer hasn't seen before, the remailer needs to make a decision as to whether to discard the message or deliver it. While the idea to either ROT13 the message or PGP it or somesuch sounds like a good one, it doesn't prevent spam-your-enemy's-mailbox attacks. Imagine 10,000,000 messages sent through remailers to your mailbhox, each ROT13'ed with a notice at the top stating "Wana read this? Un ROT13 it!" Very bad. However, what this is trying to do is quite honorable. Here's what I propose: Finger the target user and see if there's a universal token in his finger info (.plan file) that say looks like "::*ACCEPT ANONYMOUS EMAIL*::" or "::*REJECT ANONYMOUS EMAIL*::" or some such... If we can get all remailers to do this and respect finger info then there is no issue. One flaw in this is that some systems (my isp, dorsai, included) shut off the finger daemon for security reasons. In this case, the remailer should store the anonymous message on its hard drive for upto a week and send a notice message to the target asking them if they want to receive the email or not, and how to deal with future anonymous requests The remailer then has to keep a table of those recipients for whom finger fails. This is also an issue for shitty ISP's such as AOL or CI$ whom will not allow finger info because they don't run a cool unix service. :^) While this is going to eat up a bit of space on the remailer, space could be limited for the user, etc. If the space on the server runs out, what do you do? The remailer should still inform the target, but again a policy question rises - does the remailer send the message anyway, does it delete the message but inform the target that "Sorry dude, you had an anonymous email, but I had no room to store it and so I delted it. IF you don't want it delted the next time around, activate finger tags thusly, or send a reply to this message with "Accept Anonymous Email" or "Reject Anonymous Email" as the subject and I'll respect your wishes from now on"??? If a target's finger info does not fail but fails to produce a remailer accet/reject tag, there's a question of policy: does the remailer go ahead and send the message and adds a heading to the message informing the user how to set accept/reject in their finger info, or does it act as if the user's finger server is disabled? Another thought is that we could set up some universal remailer allow fingering service where the remailers can use some server somewhere or a list of servers somewhere to look up a user's email address and see if they are willing to receive anonymous email. Sort of like PGP key servers. Or we could have a DNS like service of email addresses between all remailers which should propagate their tables to each other of the exceptions and whether or not they wish to receive anonymous email... This setup also allows a potential anonymous person to see whether or not their target accepts anonymous messages before they bother writing a long rant to them about what a nice person they are, and what to shove where. :) This also solves the question or rather wishes of the mailing list or usenet group owners who may not wish to accept anonymous posts, such as alt.uptight.assholes.at.some.org but allows them to be posted on something like alt.whistleblowers, alt.sex-victims or whatever. :) Is this enough food for thought? ========================================================================== + ^ + | Ray Arachelian |FH| KAOS KERAUNOS KYBERNETOS |==/|\== \|/ |sunder@dorsai.org|UE|__Nothing_is_true,_all_is_permitted!_|=/\|/\= <--+-->| --------------- |CC|What part of 'Congress shall make no |=\/|\/= /|\ | Just Say |KD|law abridging the freedom of speech' |==\|/== + v + | "No" to the NSA!|TA| do you not understand? |======= ===================http://www.dorsai.org/~sunder/========================= Obscenity laws are the crutches of inarticulate motherfuckers-Fuck the CDA
participants (2)
-
Bill Stewart -
Ray Arachelian