From: dlv@bwalk.dm.com (Dr.Dimitri Vulis KOTM)
Date: Wed, 2 Oct 1996 10:23:07 +0800
To: cypherpunks@toad.com
Subject: Re: Making Remailers Widespread [REMAILERS]
In-Reply-To: <199609300728.AAA17384@netcomsv.netcom.com>
Message-ID: <a2R5uD3w165w@bwalk.dm.com>
MIME-Version: 1.0
Content-Type: text/plain


Bill Stewart <stewarts@ix.netcom.com> writes:

> At 09:37 AM 9/29/96 EDT, you wrote:
> >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 th
> >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. :-
> 
> Getting more complex, but it might be workable.

Unfortunately, making a system more reliable and available sometimes
entails additional cost in terms of complexity and redundancy.

> >> sender-blocking list 
> ...
> >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.
> 
> You obviously can't source-block a determined spammer, but you can
> slow down some spam attacks, especially if they're one individual 
> using his/her regular account.  It's no panacaea, but it helps.
> Also, if you source-block based on patterns anywhere in the header,
> you can catch less capable email forgers.

If you don't see why I think it's wrong to pretend to be able to do
something you can't do, then I probably can't explain it to you.

Try asking your parents or your priest or something. :-)

> >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.
> 
> That'd work.  It's clunky, but there's no avoiding clunkiness
> for this sort of thing, and it does preserve privacy.

I think it'll be pretty efficient, though.

> 
> >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.
> 
> postmaster@domain is (ostensibly) guaranteed to exist.
> The Internic database is an interesting alternative, but for this
> I suspect postmaster is good enough.  There's also the problem
> that for many domains, where smallcompany.com is virtual on an ISP,
> the Internic database will generally list someone at the ISP,
> who probably has no interest in the issue, rather than someone
> responsible for making decisions about smallcompany.com

That's a very good point: I retract the InterNIC siggestion.

Also it's possible for someone to be reached at a certain address, but not
be able to e-mail from that address. So here's the new improved version:

Scenario 1. Alice used to be a student at nursery.edu, reachable as
alice@nursery.edu. She can no longer log in there, but her e-mail is
forwarded to alice@work.com. Alice doesn't wish to receive anonymous
e-mail via her edu account unless it includes a reply block.

Alice tells one of the 'bots maintaining the blocking lists that she
wants alice@nursery.edu blocked. She should be able to make this
request via a WWW form or by e-mailing a 'bot from alice@work.com.

The 'bot sends a cookie to alice@nursery.edu, which is forwarded to
alice@work.com. Alice sends back the cookie to confirm.

(To prevent an obvious attack, the 'bot shouldn't send more than one
cookie to a given address in a 24-hour period. Perhaps one of the
flags should be 'don't send cookies unless the request is e-mailed
from the account.)

Scenario 2: root@bwalk.dm.com wants to add *@bwalk.dm.com to the
blocking list. (Not likely. :-). Again, the request is submitted
to one of the 'bots via a WWW form or by e-mail. Seeing that the
address contains a wildcard, the 'bot sends a cookie to
postmaster@bwalk.dm.com. Presumably whoever reads postmaster
mailbox is authorized to send back the cookie and to confirm
the wildcard block.

> >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.
> 
> For destination blocking, I agree that users should be able to 
> block their own stuff as automagically as possible.

I think it's fair to assume that whoever demonstrates his ability to
receive postmaster's mail by returning a cookie sent to postmaster has
the authority to block receivers in that domain.

I.e. there needs to be a way for postmaster@toad.com to say:
block cypherpunks@toad.com, but send the cookie to postmaster@toad.com,
not cypherpunks@toad.com.

I think it's fair to assume that whoever gets a cookie sent to an
address has the authority to block that address: that takes care of
the .forward scenario I described.
> For source blocking, most of the need is for spams and abusers
> that have been tracked down (or identify themselves in their postings),
> and that takes human thought.  In particular, spammers are unlikely
> to block themselves from the remailers (:-), but forgers may try to block
> legitimate users.
> 
> >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
> 
> Interesting.  I suspect the state of the art would be to collect
> the bits with a disclaimer that there isn't any code to interpret them :-),
> but it does let you build a blocking database that's usable as capabilities
> grow.
> Any suggestions for flags besides block/allow one-way, block/allow two-way,
> and max-size?  I'm thinking of doing a remailer that instead of sending
> you a message, it sends you a retrieval cookie and lets you send it back
> to collect the message; blocking that would be another flag.

I just came up with another one above. :-) I think reserving 32 bits should
be enough for future expansion, or 64 to be really generous with disk space.

> 
> The other kind of blocking that needs adding is blocking by
> words in message bodies - the spammer that caused me to shut down
> my remailer and not bring it back up was posting hate messages
> with somebody else's name and email signed at the bottom.  
> It only took one or two to generate a flood of flames to the victim,
> and my current remailer couldn't block any followups.
> Also, since the spammer wasn't generating the flames himself,
> his spam slipped under the remailer's spam counter, just as
> hipcrime's did.  This sort of blocking also lets you block
> things like the hipcrime spam and MAKE MONEY FAST.
> But it's a much more sensitive problem - anybody who can add things
> to the body-checking list can start doing real censorship,
> and it's probably best to leave that to individual operators to block,
> or at least to turn on by hand rather than default.
> 


I agree that each operator should be able to block what goes out of
his remailer based on strings being contained in the body. However
having some Cabal force this filtering automatically on all remailer
operators is a very bad idea, even if the operators consent to it.
In the scenario you described above, was the victim's address encrypted
in the reply block, or was it in cleartext? If it was in cleartext, then
it's little different from Peter Vorobiev forging garbage in my name
and Timmy May (fart) quoting it as someting I really said.

(Some time ago Vorobiev forged Usenet articles from my wife's seldom used
account on another machine claiming that we split up. Dave Hayes actually
asked me over the phone if it's true. There are strange people out there.)


I'm not claiming to have all the solutions - this is merely a way to
block recepients without taking up too much of operator's time.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps