Re: Making Remailers Widespread [REMAILERS]
There have been several good replies - thanks!
Doing two-way remailers would be better, but that's still a hard problem, and I don't want to widely deploy shoddy two-way-remailers.
Unfortunately, one-way remailers have much fewer uses than two-way remailers, any many of these uses are abusive.
I agree, it's a problem; the return address seems to reduce abuse. But one-way remailers can be used to simulate many of the uses of two-way, especially with message-pool return methods (e.g. alt.anonymous.messages.) Doing two-way remailers well is hard - most of the methods around are ok for passive attacks, but may not resist subpoenas, rubber-hose, or crackers. It's especially hard if you want the remailer to be a no-brainer to install and operate, rather than one that requires expert support. Snow's one-shot reply block method is interesting, whether you do a public-key or secret-key approach (if you do public key, you obviously use the public half for the part that stays at the remailer.) It has the real advantage that compromising the remailer doesn't give you the reply information for past or current messages, so you can only compromise one message at a time, which is a big win over the one-key-per-remailer reply blocks. I think I like it. On the other hand, there are a host of potential problems: - Chaining is probably more difficult, at least return-chaining. - Individual True Believer remailer operators would usually resist cooperating with authorities to decrypt the reply block, but ad-hoc remailer operators who are just running a remailer because they haven't turned off the default feature that came with their Web Server will probably reveal the key, especially for Politically Incorrect material (definition depends on their individual politics, of course.) - A web form interface, filled out from a web anonymizer, doesn't give you a useful return address, so spammers can still abuse it. - You have to decide how much persistence to use for the reply block. One-shots are more secure, but aren't helpful for replies to web postings or other multiple-recipient communication, but timeouts have their own problems.
- A centralized block list (e.g. http://www.remailer.net/block.txt) which all of the form-based remailers could load and reference would allow non-picky operators not to have to handle it themselves A single centralized point of failure is bad. Maybe 4 or 5 redundant ones. A blocking request sent to one will be replicated in the other automatically.
Good point. A bit tough to implement in a no-brainer out-of-the-box remailer; you gain a bit by having the block list point to an address that's really a round-robin DNS spinner of some sort, but that still leaves you with centralization.
[centralized blocking list; handshake with cookies ] - this is a bit messier for mailing lists, but we can ignore...
We can't quite ignore... In the scheme you've just described, someone can enter a blocking request via a Web page and give a submission request for some mailing list, and the cookie will be e-mailed to the mailing list.
Yeah. This makes it easy to block anonymous remailer input to (say) the cypherpunks mailing list, since _any_ mailing list user can block. Putting a never-block list at the blocking server is a possibility, and would require some announced policy for implementing it.
- special-case for "postmaster", who may want to block all of foo.domain instead of just postmaster@foo.domain - special-special-case for postmasters of big sites, e.g. aol, netcom who we may want to ignore?
I don't think it's a good idea to suport blocking receivers in an entire domain, like *@aol.com. Just say it's not supported.
Blocking an entire domain like *@aol.com is mostly bad. Blocking an entire domain like *@myconsultingfirm.com is fine. Deciding the boundary between the two is, um, amusing :-) I'd probably set it such that ISPs don't get blocked, but non-ISPs do, though that might change if the administrator of aol.com asks five million users to submit individual blocking request. I suppose this means there's a volume question here :-) Having a don't-block list that individuals can subscribe to would help.
- A sender-blocking list is harder, and may still take human attention I don't think it's a good idea to support sender blocking at all.
There are some spammers you'd like to stop quickly when a Spam Event is happening. There are broken email gateways that may need blocking. There are known abusers you might want stopped. And there are folks like president@whitehouse.gov who can be presumed to be forgeries :-) A sender-blocking list administered by the Remailer Cabal* would be a reasonable default for no-brainer remailers, and obviously it should be possible for remailer-admins to override or ignore if they want.
Would the receiver blocking list be available to everyone to view? That sounds like a violation of privacy. Someone suggested on this list that (assuming that the entires are addresses that match exactly, not regular expressions), one can store hashes of addresses.
That's worth doing, or at least thinking about seriously. The most interesting regular expressions are *@domain (which you can handle by keeping separate block lists for domains and full addresses (or a merged list that the using remailer checks both)) and *@*.domain and user@*.domain - e.g. alice@mailserver17.big-isp.com, which would successfully deliver mail to alice@big-isp.com. Perhaps the system needs to keep two hashes - hash(alice),hash(big-isp.com) and check subsets of the domain name? This is creeping featurism, but it may be the right way to go to set a good precedent. One unfortunate result of only using hashed names and not readable names is that it doesn't help the current remailer operators, since their existing code doesn't work that way. Keeping the file of real names encrypted and only distributing it to the Remailer Cabal seems leaky at best :-) - I'd expect to see it remailed to some public place just on principle. snow wrote:
Off the top of my head, the biggest problem is that you can't send email to a web site (page). You can easily send it to a procmail program at a web site, though, which can take care of doing the right thing with it. Mark M.'s pointer to netcat is especially relevant for this. Netcat can be used pretty easily to fetch URLs (e.g. echo "GET /foobar.html HTTP/1.0" | nc www.webserver.com 80).
[*The existence of the Remailer Cabal, viewed by some as a shadowy subversive conspiracy, and by others as Dedicated Public Servants has been repeatedly denied by anyone in a position to know. :-) ] # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto
Bill Stewart <stewarts@ix.netcom.com> writes:
Unfortunately, one-way remailers have much fewer uses than two-way remailers any many of these uses are abusive.
I agree, it's a problem; the return address seems to reduce abuse.
It's not only a question of traceability... Most "useful" uses of Julf's remailer involved scenarios like someone posting anonymously to a public forum and soliciting replies, or someone contacting another party anonymously and wanting to receive a reply. It was pretty easy for two anonmous parties to establish a dialog. An optional reachable return address (even if the sender can't be traced back and be punished for abuse) makes the system so much more useful for things other than anonymous farting.
- A centralized block list (e.g. http://www.remailer.net/block.txt) which all of the form-based remailers could load and reference would allow non-picky operators not to have to handle it themselves A single centralized point of failure is bad. Maybe 4 or 5 redundant ones. A blocking request sent to one will be replicated in the other automatically
Good point. A bit tough to implement in a no-brainer out-of-the-box remailer you gain a bit by having the block list point to an address that's really a round-robin DNS spinner of some sort, but that still leaves you with centralization.
How about: maintain a list of trusted blocking-list sites (comparable to the list of remailers used for chaining) and when it comes the time to update the local copy of the blocking list, ask a random one on the list; if it's down, ask another random one on the list. There may even be more than one list. :-)
- special-case for "postmaster", who may want to block all of foo.domain instead of just postmaster@foo.domain - special-special-case for postmasters of big sites, e.g. aol, net who we may want to ignore?
I don't think it's a good idea to suport blocking receivers in an entire domain, like *@aol.com. Just say it's not supported.
Blocking an entire domain like *@aol.com is mostly bad. Blocking an entire domain like *@myconsultingfirm.com is fine.
I think it's also bad, but I suppose the market wants it, so I'm showing below how this can be done.
- A sender-blocking list is harder, and may still take human attention I don't think it's a good idea to support sender blocking at all.
There are some spammers you'd like to stop quickly when a Spam Event is happening. There are broken email gateways that may need blocking. There are known abusers you might want stopped. And there are folks like president@whitehouse.gov who can be presumed to be forgeries :-) A sender-blocking list administered by the Remailer Cabal* would be a reasonable default for no-brainer remailers, and obviously it should be possible for remailer-admins to override or ignore if they want.
With most ISP's it's trivial to forge one's From: header in SMTP. Switching to another dime-a-dozen throwaway account is also trivial. Just admit that you can't block senders, and don't pretend that you can - false pretenses destroy one's credibility. Timmy the pathological liar posted a rant a few weeks ago on how "remailer operators can't be choose" - usually he's full of shit, but that time he had a point - he must have plagiarized it.
Would the receiver blocking list be available to everyone to view? That sounds like a violation of privacy. Someone suggested on this list that (assuming that the entires are addresses that match exactly, not regular expressions), one can store hashes of addresses.
That's worth doing, or at least thinking about seriously. The most interesting regular expressions are *@domain (which you can handle by keeping separate block lists for domains and full addresses (or a merged list that the using remailer checks both)) and *@*.domain and user@*.domain - e.g. alice@mailserver17.big-isp.com, which would successfully deliver mail to alice@big-isp.com. Perhaps the system needs to keep two hashes - hash(alice),hash(big-isp.com) and check subsets of the domain name? This is creeping featurism, but it may be the right way to go to set a good precedent.
I think I see a way to accomplish this without too much trouble. When an e-mail is directed at u@c4.c3.c2...c1, the code that checks for blocking will search for the following records in the blocking list: u@c4.c3.c2...c1 (exact match) *@c4.c3.c2...c1 (replace user by *) u@*.c3.c2...c1 (replace leftmost .-separated piece of domain by *) *@*.c3.c2...c1 (both) and repeat until there are only 2 components left in the domain name. E.g., if a message is addressed to dlv@under.bwalk.dm.com, the blocking code would compute hashes of the following strings and check for each one's presence in the blocked list: dlv@under.bwalk.dm.com *@under.bwalk.dm.com dlv@*.bwalk.dm.com *@*.bwalk.dm.com dlv@*.dm.com *@*.dm.com and here we stop. This shouldn't take much more CPU time than the blocking code in Lance Cotrell's mixmaster that I just looked at, which loops though all blocking patterns and checks if each one matches. Now, the question is, who would be allowed to add records containing '*' to the blocking list using the cookie protocol? I suggest that it be one of the contacts listed in Internic's database. E.g. joe@some.place.com can add himself to the blocking list using the cookie protocol. If joe tries to add *@*.place.com to the blocking list, the 'bot looks at Internic's database and sees only jim and jeff listed for place.com, so it refuses. On the other hand, jim@some.place.com can add *@*.place.com, joe@*.place.com, etc, because Internet says he's the admin for place.com. Thus a blocking record for cypherpunks@toad.com could be added by anyone listed in toad.com's Internic entry. There's no need for any Remailer Cabal [tinc] to maintain blocking lists. One other suggestion: instead of storing one bit of information (the address is on the list or not), why not have several flag bits. E.g., the blocking list could contain records similar to: hash - e.g. 160-bit SHA flags - e.g. reserve 32 bits If the list is sorted by hash, then using binary search to check whether a value is in it is very fast (much faster than matching wildcards). But at the same time you can retrieve the flags word, which could be used, e.g., to say that an address doesn't wish to block all inciming anonymous e-mail, but only e-mail that appears not to contain a reply block, or whatever other preferences can be stuffed into 32 bits. E.g., one could use 2 or 3 bits to specify the maximum size of a message to be delivered to addresses matching this pattern: 000 for no limit, and nnn for nnn*4K bytes.
One unfortunate result of only using hashed names and not readable names is that it doesn't help the current remailer operators, since their existing code doesn't work that way.
This seems like a straightforward replacement for a small piece of code in Lance Cotrell's mixmaster (which remains to be written, of course :-). It's probably not hard to plug the same code into other remailers if they're well-written. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
Mr. Stewart said:
I agree, it's a problem; the return address seems to reduce abuse. But one-way remailers can be used to simulate many of the uses of two-way, especially with message-pool return methods (e.g. alt.anonymous.messages.) Doing two-way remailers well is hard - most of the methods around are ok for passive attacks, but may not resist subpoenas, rubber-hose, or crackers. It's especially hard if you want the remailer to be a no-brainer to install and operate, rather than one that requires expert support. Snow's one-shot reply block method is interesting, whether you do a public-key or secret-key approach (if you do public key, you obviously use the public half for the part that stays at the remailer.) It has the real advantage that compromising the remailer doesn't give you the reply information for past or current messages, so you can only compromise one message at a time, which is a big win over the one-key-per-remailer reply blocks. I think I like it. On the other hand, there are a host of potential problems: - Chaining is probably more difficult, at least return-chaining.
Each reply refers to the remailer before it. The originating web site hands the originator a key and a pseudo-random ID. The originator can check check back on a regular basis to see if a reply came back in. That way there is no "final trail" and the reciepent can view the page thru something like www.anonymizer.com.
- Individual True Believer remailer operators would usually resist cooperating with authorities to decrypt the reply block, but ad-hoc remailer operators who are just running a remailer because they haven't turned off the default feature that came with their Web Server will probably reveal the key, especially for Politically Incorrect material (definition depends on their individual politics, of course.)
Set a time limit on replies (say 5 days) and after the 5 days, the reply is deleted by the server. That way the casual user would have to hack the code to _keep_ the addresses on hand, and the censors would have to get back thru the entire chain in 5 days, and they don't know the entire chain to begin with. If you can get the web server spread out internationally, that ain't gonna happen.
- A web form interface, filled out from a web anonymizer, doesn't give you a useful return address, so spammers can still abuse it.
If you inert the *this is an anonymous email* automaticaly, this won't matter as much. Commercial spammers will have to put a commercial access point (phone, fax, email address) in their message and people who are just harassing others will get deleted pretty quick. Spam itself will be cut back as you only allow <x> number of addresses per message, and set it up so that you enter the addresses on a seperate page from the message. That way to hit 2 or 3 hundered email addresses you have to enter the message 100 times. Ok, so cut and paste 100 times, but if the spammer has a brain (I know, but there may be one or two) they are going get the spam out. How about this (It is a little complicated, so it may not work) Alice wants to send email to Bob, so she hit's sameers anonmymizer site to go to a random remailer web site. At this site she enters Bobs email address on one page, and on the next enters her message. This message could even be encrypted, assuming that Bob knows what to do with it. Hit send. The webremailer software hands Alice a temporary (10 day expire time) ID and key/passphrase. The webremailer selects the next mailer in the chain, encrypts the message, writes the public key and encrypted message to disk (with date stamp), and forwards the email (encrypted message + key) to the next remailer. The second (and each succeeding remailer in the chain) simply re-writes the headers and writes a keyid/previous-remailer pair file (with date stamp) to file. (maybe even keep a single database file with this info in it, a single file might not get written to disk as often (maybe) and with constant would be marginally harder to "recover" old addresses from than multiple hard files (or would it?) and then sends the mail on. If we can use the "puts" feature, we really don't need much in the way of headers right? Anyway the last remailer in the chain writes a simple web page with the keyid of the keypair, and simply sends the key and an address to the receipent so that 1) the final "message" is still not the email, only a notice that email is waiting, for instance http://www.encodex.com/anonmail/id0x4556/ The reciepient then goes to the site (or doesn't if they don't want email) they can use www.anonymizer.com if they wish, and they enter their key when prompted. The encrypted file is then decrypted and sent to them. At this point, the encryption is more to prevent the "prying eyes" than TLA level snooping, so it has to be good, but it doesn't have to be 2000 bit RSA type stuff. That can be done at the message level. Return messages would include the keyid of the sent message, and would retrace the same hops. At the original end, a simple web page is written and a "you have a reply to your anonymous message at http://www.encodex.com /anonmail/id0x99a4/ Holes? Petro, Christopher C. petro@suba.com <prefered for any non-list stuff> snow@smoke.suba.com
participants (3)
-
Bill Stewart -
dlv＠bwalk.dm.com -
snow