Re: Thoughts on MixMinion archives

[Len Sassaman <rabbi@quickie.net>]

On 23 Apr 2002, Nick Mathewson wrote:

> Sorry -- I was suggesting that, if we got stuff right this time, we
> might make future systems backwards compatible with type III... not that
> we should keep types I and II alive forever.

Gotcha. Bram Cohen and I have discussed this a bit, with regard to the TLS
transport layer stuff. I'll write up what we came up with shortly.

Big things that Type IV remailers should do is: allow remailers to be
compensated for the messages they process, and be far more tolerant of
short-lived nodes.

You can check the cypherpunks archives for some ideas I had on a postage
stamp system that could also be used in conjunction with a system allowing
for independent user verification of remailer reliability and message
delivery. I'll go into this in more detail as well, if anyone is
interested.

>  [...]
> > > Sorry about the confusion--what you describe is the intended behavior of
> > > a SMTP delivery module.  The idea is to make all delivery methods into
> > > isolated modulres, to make the security of the core easier to examine.
> >
> > Okay, so this is a Mixminion specific architecture issue, which I don't
> > have to worry about.
>
> Well, it touches the spec a little too.  The idea is to have a notion of
> "payload type" in the spec, so that experimental extensions can be
> isolated from the spec proper.
>
> The spec will need to say things of the form, "When you receive a
> message of type SMTP, you need to extract an email address like this and
> a message body like that, and send them along via SMTP--either via an
> MTA or manually."

Okay, so we're actually saying the same things and just not realizing it.
Good. :)

>  [...]
> > Agreed. This also brings up the sticky question of extensibility. Ideally,
> > we'll permit no extensions that would fragment the anonymity set. However,
> > if we don't specify a method for specifying additional features/
> > capabilities, they will happen ad-hoc.
>
> Indeed.  Also, extensibility allows us to phase new delivery and
> forwarding strategies into the system _without_ breaking backwards
> compatibility.
>
> There's no way we can prevent people from wilfully adding stupid
> extensions to the system.  We should just practice good design
> ourselves, make sure that our design docs explain how to do so, and
> encourage others to follow along.  I bet that anybody with enough hubris
> to ignore our advice has enough hubris to hack an incompatible, ad-hoc
> extension mechanism onto our code anyway. :)

Agreed.