<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yiv0225427225"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div class="yiv0225427225" id="yiv0225427225yui_3_16_0_8_1413608224903_4" style=""><span class="yiv0225427225" id="yiv0225427225yui_3_16_0_8_1413608224903_11" style="">Hi Bjarni,</span></div>What is the novel part of your SMTorP design that allows users of insecure email to "gradually, opportunistically" improve their security wrt hiding their metadata? It looks to me like your users would need to exchange onion addys out-of-band, or else take the risk that comes with exchanging over an insecure connection. Well, I guess they could also leverage GPG if they've already done a key exchange. But anyway,
that's the same with Cables so I'm not seeing any scaling benefits that would deliver more privacy more easily to a greater number of users. (And you already listed one drawback, which is that you have to develop some kind of safeguard to keep users from mixing normal and onion addys in the same message.)<br><br>Btw-- did you look at Cables before you started working on SMTorP? If so, what was it lacking? If not, what is it lacking?<br><br clear="none">Thanks,<br clear="none"><div class="qtdSeparateBR"><br><br></div><div class="yiv0225427225yqt7017246518" id="yiv0225427225yqtfd23970">Jonathan<br clear="none"></div></div></div></div></div></body></html>