On Sun, Oct 05, 2014 at 12:50:40PM -0500, Tom Ritter wrote:
> Spam detection does not _have_ to rely on originating source, although
> obviously that's a large input to a spam detection system. The
Indeed, considering that future SPAM would be encrypted to the end
recipient, so spam assassination has to happen on the end system.
Defeats models that detect SPAM by the way it looks similar while
being delivered to a multitude of recipients.
> > All Tor-and PK-routing based systems have solved this by requiring
> > pubsub relationships, thus making SPAM at worst annoying, but
> > ineffective at its primary intent.
>
> I'm not clear what you mean here. In my mind, Tor is not set up as a
> publisher-subscriber relationship at all, but perhaps you mean
> something different.
Pond, the mail system you mentioned, uses Tor hidden services and requires
a subscription/authentication exchange before being able to mail.
> I feel like you've made an assertion: "it is impossible to implement
> metadata protection on top of SMTP..." but not supported it very
I started a discussion posing that question.. could it be it isn't
actually feasible..? Indeed from a scientific point of view quite
unlikely to be a provable statement.
> strongly. One, you talk only of Onion Routing - but that is merely
> one mechanism of metadata protection. There is also Broadcast
> Transmission, Mix Networks, and other more complicated systems like
I specifically asked about onion routing since I wish Bitmessage
good luck in finding a way to segment the broadcast space but I
doubt that approach to be viable over the existing SMTP system.
Mix networks have the disadvantage of requiring trust from their
users, correct? In a world where computing centers can receive a
knock on the door and servers be systematically, especially virtual
ones, tapped with memory scanning for private keys... I did not
intend to speak about that model.
I am thinking of an SMTP-based onion routing system where the SMTP
hosts act like relay nodes and the MUA creates the message encrypted
to all in-between relay hops. The optimization suggested by the
authors of PIR-Tor is applicable, but doesn't affect the challenge
of getting it to work with the existing SMTP federation.
I'm not saying that mixing and broadcast is scientifically absurd,
but sufficiently uninteresting within my personal judgement, so
I am asking specifically what I find interesting.
> PIR. Two: It is impossible to prove a negative, that something must
> not exist or not be possible. I think there are a multitude of
Luckily I'm not trying to prove it, just gathering some good thinking
on the topic.
> systems that have been designed or could be designed that would feed
> into this debate. If you want to make an assertion that something is
> impossible, I would expect a more descriptive exploration of the
> problem space, and attempting to address several potential ideas and
> why they do not work.
That's why I am glad you gave such an exhaustive reply.
Let's dig deeper into the problem space.
> I think it's entirely reasonable to say "I don't see a way this would
> work" - indeed there are some hard problems in the space, followed by
Sure, if we include post-SMTP systems I know that solutions are feasible
but I was very specifically wondering if the backwards compatibility
with SMTP's presumption that you can mail anyone anytime breaks the scheme
of onion routing approaches.
Thinking it through it seems to me a bit like a time bomb. You can start
using a new mailbox with a new public key and share these with your
contacts - but the moment any of your contacts gets her device p0wned by
a secret service or other malware deployer, your mailbox can be DoSsed
with epic amounts of SPAM and only the end node would have a vague chance
of distinguishing signal from noise.
Sure, this isn't a very scientific assertion, but to me it sounds like
doing Onion Routing on top of a network of SMTP servers is a very bad
idea.
--
http://youbroketheinternet.org
ircs://psyced.org/youbroketheinternet
_______________________________________________
Endymail mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/endymail
