explore different message delivery models

[david415]

The spam problem is not inherent to mix networks. It is an optional design trade off. There are many other different trade offs we can make.

Also, let it be known, Yawning's current implementation of the katzenpost Provider doesn't have to be used for "e-mail" style messaging nor does it have a spam problem inherently: RecipientIDLength = 64.

[moba]

While spam is not a "special" problem of mixnets per se, any system that you deploy these days has to take spam and denial of service attacks into account. Regardless of use case. That's just the sad reality. You can't expect mixnets to be a viable alternative to systems that rely on IP reputation for many things, for example. If I can authenticate to my provider, and then easily flood the network without anyone able to identify the flooder, it is simply not going to work.

I argue that the reason we even have spam is that it wasn't considered to be part of the protocol design of email. If we make it easy for recipients to identify or drop bad traffic on their end, regardless of "message delivery model", the whole incentive scheme on why you would want to spam in the first place changes, and you can avoid spam up front. The thinking that "this can be dealt with later on application layer" is exactly what brought us spam in the first place.

[david415]

Firstly, it is clear we disagree. I regard this ticket as having no consequence at the moment since it's tagged as "future research" and will not be worked on any time soon.

Secondly, I shall not attempt to defend my position here because I regard it as self-evident that the spam problem is not inherent to mix networks, nor is it inherent in a practical deployeable system.

Thirdly, let's not conflate denial of service with spam. These are two very different problems and may have little to do with each other depending on system design.

When I created this ticket I was thinking of systems such as agl's pond which may be regarded by you as "not practical". These kinds of messaging systems are in fact very practical however they do not "replace e-mail"... nor should they attempt to do so... nor was I positing that they should. This ticket is about exploring other delivery models such as Petmail and Pond. If you don't want to consider these alternatives then that's your decision but it SHOULD NOT stifle intellectual progress in these directions.

@warner has written an interesting blog post about possible designs for the Petmail system:

http://www.lothar.com/blog/53-petmail-delivery/