a nice point to why we should have protocols that are secure by design, and are developed to protect privacy from the gitgo <br><br>a
 user connecting to the network with unsecure settings, that is using 
unsecure protocols and encryption methods that are easily cracked is a 
security risk, and shouldn't not be welcome on the network. They pose a 
risk of being an intermediary node transferring data between the 
Egyptian user attempting to relay information from a repressive 
government which could help with identifying a source. <br>
<br>this is one of those areas where enforcement is a must. <br><br><div class="gmail_quote">On Wed, Aug 3, 2011 at 3:47 AM,  <span dir="ltr"><<a href="mailto:bertagaz@ptitcanardnoir.org">bertagaz@ptitcanardnoir.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, Aug 03, 2011 at 11:37:58AM +0800, Sandy Harris wrote:<br>
> On Wed, Jul 20, 2011 at 2:53 AM, Tony Godshall <<a href="mailto:togo@of.net">togo@of.net</a>> wrote:<br>
><br>
> > Any downside to letting your adversary know what domains you are<br>
> > emailing to?  Well, the mice probably don't want the octopus know that<br>
> > they are emailing via @<a href="http://octopusnotsogreat.org" target="_blank">octopusnotsogreat.org</a>?  But then again SMTP<br>
> > itself is not encrypted either...<br>
><br>
> There is an opportunistic SSL-based encryption option for SMTP.<br>
> <a href="http://tools.ietf.org/html/rfc3207" target="_blank">http://tools.ietf.org/html/rfc3207</a><br>
<br>
</div>Sure, but as always with SSL, this is completely efficient only if you are<br>
able to first verify the certificate... This is still better than nothing<br>
but isn't a complete protection.<br>
<br>
AFAIK a monkeysphere implementation for SMTP is being worked on. This<br>
won't completely address the issue but will certainly help.<br>
<div><div></div><div class="h5"><br>
> Any two servers with that set up will automatically encrypt all mail<br>
> transfers. If the Box runs a mail server, I'd say enabling that is a<br>
> no-brainer.<br>
><br>
> The only question is whether, when the other server does not support<br>
> it, the Box should proceed with unencrypted transfer, or bounce the<br>
> mail back to the user with some "cannot send securely" message,<br>
> or try some alternate routing method.<br>
><br>
> There's also "Using TLS with IMAP, POP3 and ACAP"<br>
> <a href="http://tools.ietf.org/html/rfc2595" target="_blank">http://tools.ietf.org/html/rfc2595</a><br>
><br>
> That covers the client-to-server transfer of mail. If the Box runs a<br>
> mail server, that's another obvious requirement.<br>
><br>
> _______________________________________________<br>
> Freedombox-discuss mailing list<br>
> <a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>
> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a><br>
<br>
_______________________________________________<br>
Freedombox-discuss mailing list<br>
<a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a></div></div></blockquote></div><br><br clear="all">
<br>-- <br>Thank you for your time<br>~Nathan<br><a href="mailto:nathan1465@gmail.com" target="_blank">nathan1465@gmail.com</a><br><br>