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