[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SMTP service (was: Reply blocks and tagging protection: a thirdvariant)
On Tue, 9 Apr 2002, Zooko wrote:
>
> Roger wrote:
> >
> > Which leads to the issue of putting destination information in the payload
> > vs the header. I'm still not convinced by George's statement that it
> > should go in the payload. First off, it seems hard to put destination
> > info in the payload of a reply block: I just don't know how it could work
> > with our encryption system. The guy using your reply block should not be
> > able to learn (parts of) your delivery info, eg by keeping transport_type
> > but changing email_address, in order to learn transport_type.
>
> I have been using a whole different paradigm about this. I think of the basic
> mix net operation as being a messaging service between two computers where
> *both* of them are *required* to be running mixminion nodes locally.
>
> Then I think of the SMTP stuff (in, out, or both, whether nymserver or anonymous)
> as being a service that a mixminion node can offer to the world. "Send me your
> e-mail and I'll poke it through the mixnet for you.".
>
Indeed I had this model in mind as well. The constrain I was working with
all this time was that the people benefiting should be running special
software while others should not. Therefore it seemed natural to me that
the final recipient of SURBS runs a server that understand MixMinion.
Note however that the final recipient does not need to act as a mix or be
known to anyone else in the system.
I accept that in some cases this is not possible (since people might be
off-line) and therefore we need a pull rather than push mechanism for
final delivery. I do not think it is wise to assume that Email will
satisfy us. In particular if email is allowed we allow MixMinion to be
used to perform Mail Bombing. Maybe something else would be more
appropriate.
What about the following: The mix sends a notification by email (or
other) that a message is waiting, and the client can then choose to go and
download it.
The above still seems a bit ad-hoc and I would really be more pleased if
we could find a way of having some hops providing storage services,
independently from any particular transport mechanism (as modules) so that
the functionality can be implemented on the layers above MixMinion (in the
same way as the mail gateways for the forward delivery). We can use the 40
bytes of addressing to tell the final mix what is expected from it.
Yours,
George