Hello everyone, I was pointed here by Hannes and Stephen -
some may remember me from IMPP, STRINT or recently IPEN.
As a side note please acknowledge the updated version
of http://youbroketheinternet.org/secure-email with
more reasonable information concerning Key Management
and a more accurate list of post-SMTP mailing systems,
in particular the ones using the Public-Key Routing
paradigm (Re: What are the problems?).
What I specifically want to talk about in this thread
is the "Onion Packaging?" in Dave's slides (number 9):
http://www.ietf.org/proceedings/90/slides/slides-90-saag-2.pdf
Onion routing works by letting the sender pack up the crypto
layers for each inbetween node up to the final recipient. If
SMTP were to allow that, it would re-introduce relaying which
used to be its favorite backdoor for SPAM.
The only way for an MDA to receive a message from somewhere,
decrypt it, then find out it needs to forward it to another MDA,
would be to have a large view of the social graph of users and
.. erm.. servers.. in order to know that if the message came
from eris it is probably safe to forward on to tolsun.
To me this sounds like a catastrophe waiting to happen since
SMTP by default has no trust architecture, thus any onion
routing would open up large windows of opportunity for spammers
since once the SPAM has arrived at destination, the recipient
can no longer figure out where it originated from - thus there
is no way of protecting yourself.
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.
If I'm not mistaken, it is impossible to implement metadata
protection on top of SMTP while also maintaining compatibility
to its subscription-free transmission model.
Any mistakes in my reasoning?
Best from Berlin,
CvL
--
http://youbroketheinternet.org
ircs://psyced.org/youbroketheinternet
_______________________________________________
Endymail mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/endymail
