Pay per use remailers and remailer reliability tracking.

[Steve Schear]

At 06:54 AM 12/21/2001 +0000, you wrote:
>Quoting Steve Schear <schear at lvcm.com>:
> >
> > I don't run a mixmaster because:
> >  - its not been easy to get running
> >  - it uses SMTP ports which are filtered on my AT&T cable system.  The
> > remailer reference lists need to include port number references so 
> users on
> > these "restricted" ISPs can participate.  Since the traffic is 
> encrypted it
> > might make sense for operators to choose port numbers used by P2P
> > applications which currently encrypt traffic (I believe Morpheus does).
> >  - it didn't run under Windows (until the other day)
>
>[admittedly, I'm very biased, since I have more of a network engineering/admin
>point of view than a normal end-user cypherpunk point of view]
>
>I'm wary of doing things which violate internet standards and generally
>complicate application design to support:
>1) Windows users trying to run servers

You must mean non-commercial users since substantial number, probably a 
majority of commercial servers run this crud.

>2) People running reliable servers on filtered networks (just get a tunnel
>if you really care)

Are there good free one's?


>I don't see there being a huge need for middleman/remix-only nodes.

Why?

>There is
>a huge need for well-configured, production-grade exit hosts with testicular
>fortitude and a bad attitude.

But these are likely to be the most difficult to find and persist.  I think 
its a bad idea to hinge remailer network improvements on the participation 
of deep pocket parties who need convincing that this is a ideological fight 
they should take on and risk their resources and public image upon.


>Things like the hotmail exit code are foiled these days by the "prove you
>are a real human or a turing-test-complete AI to open an account"

I'll look into this and report.


>Relying on services which are in violation of terms of service (running a
>remailing server on a consumer dialup or cablemodem with a no-servers
>policy, abusing stupid web email providers to take the heat) is not a
>good way for high-visibility, high-abuse postions of the network to
>operate, if reliability is key (as it is for non-abusive remailer users).

These restrictive ISP policies are almost always aimed at web hosting and 
mail and rarely against other ports or services (e.g., P2P) which are major 
driving forces for consumers purchasing broadband connections.  As for the 
judgement of whether something is wise I would love the remailer network to 
work as even as well as Gnutella or Freenet.


>Until there is evidence otherwise, I think 5-10 well-administered,
>professionally maintained remailers, run by reasonably well known
>organizations, with sufficient legal firepower to defend themselves,
>running a codebase which is as reliable as a standard MTA, with best-efforts
>spam and abuse prevention, would provide a better service to users than 100
>99% reliable remailers running on cablemodems which can be incapacitated
>by a single email to noc at home.net or blown power supply or whatever.

I see no need to follow only one path which might become a dead end.


>Simultaneously raise the bar in some ways (require better network,
>maintenance, etc.) but lower it in the ways which influence TCO for a
>professional organization (install and maintenance admin time).

I think architectures which lower the bar should be equally be 
explored.  Alternatives are the life blood of any business 
strategy.  Commitment to a single avenue increases risks.


>Provide a way to inject messages into the system without identifying the
>user as "member of the set of remailer users"; put up a web interface
>accessible via a quality anonymizing proxy, or pick up encrypted messages
>from USENET, or encourage dummy traffic from end users (put a nice web
>anonymizer and/or SSL web server with general-interest content right next
>to the remailer, ideally, for plausible deniability, and use JS or java or
>something so normal browsing sessions and remailer-interaction sessions are
>similar).

Excellent.


> > There needs to be an automated way to anonymously and securely 
> determine if
> > your messages have gotten stuck at a particular remailer.

If clients generate message digests for each link in the daisy chain then 
the Web interface to the remailers could enable automated checking whether 
a message was received and successfully processed by each 
remailer.  Provacy could be maintained by having the remailer response 
include all MDs for some client selected/fixed window.



>Given the level of latency and standard deviation for messages, I'm not
>sure if this would provide a reasonable level of quality of service, using
>today's remailer population.

Well certainly the few brave operators we currently have.

steve