SMTP service (was: Reply blocks and tagging protection: a third variant)

[Zooko <zooko@zooko.com>]

 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.".

From this perspective, it seems clear to me that SMTP addresses are completely 
unknown to the Mix Core code and get delivered (via the payload) to "SMTP 
extension modules" which interpret and act on them.  Maybe there are some 
drawbacks to this separation of concerns that I'm not seeing?

Anyway, it kind of seems like George is also envisioning a similar separation 
but that Roger is thinking of SMTP and Mix being more integrated.  Let's talk 
this out.

Regards,

Zooko