Author: rransom Date: 2011-03-29 21:17:33 +0000 (Tue, 29 Mar 2011) New Revision: 24503

Modified: website/trunk/docs/en/faq.wml website/trunk/eff/en/tor-legal-faq.wml website/trunk/getinvolved/en/volunteer.wml Log: Update mailing list archive links

Modified: website/trunk/docs/en/faq.wml =================================================================== --- website/trunk/docs/en/faq.wml 2011-03-29 21:17:16 UTC (rev 24502) +++ website/trunk/docs/en/faq.wml 2011-03-29 21:17:33 UTC (rev 24503) @@ -1307,7 +1307,7 @@ <li>If you're running a fast relay, meaning you have many TLS connections open, you are probably losing a lot of memory to OpenSSL's internal buffers (38KB+ per socket). We've patched OpenSSL to <a - href="http://archives.seul.org/or/dev/Jun-2008/msg00001.html%22%3Erelease + href="https://lists.torproject.org/pipermail/tor-dev/2008-June/001519.html%22%3Ere... unused buffer memory more aggressively</a>. If you update to OpenSSL 1.0.0-beta5, Tor's build process will automatically recognize and use this feature.</li>

Modified: website/trunk/eff/en/tor-legal-faq.wml =================================================================== --- website/trunk/eff/en/tor-legal-faq.wml 2011-03-29 21:17:16 UTC (rev 24502) +++ website/trunk/eff/en/tor-legal-faq.wml 2011-03-29 21:17:33 UTC (rev 24503) @@ -146,7 +146,7 @@ and help set a clear legal precedent establishing that merely running a node does not create copyright liability for either node operators or their bandwidth providers. If you want to be the EFF's test case, -<a href="http://archives.seul.org/or/talk/Oct-2005/msg00208.html">read +<a href="https://lists.torproject.org/pipermail/tor-talk/2005-October/016301.html">read more here</a>.</p>

<a id="ExitSnooping"></a>

Modified: website/trunk/getinvolved/en/volunteer.wml =================================================================== --- website/trunk/getinvolved/en/volunteer.wml 2011-03-29 21:17:16 UTC (rev 24502) +++ website/trunk/getinvolved/en/volunteer.wml 2011-03-29 21:17:33 UTC (rev 24503) @@ -724,8 +724,8 @@ addresses and algorithms for gathering and blocking them. See <a href="<blog>bridge-distribution-strategies">our blog post on the topic</a> as an overview, and then look at <a - href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html%22%3ERoger%27s - or-dev post</a> from December for more recent thoughts &mdash; lots of + href="https://lists.torproject.org/pipermail/tor-dev/2009-December/000666.html%22%... + or-dev post</a> from December 2009 for more recent thoughts &mdash; lots of design work remains.</p> <p>If you want to get more into the guts of Tor itself (C), a more minor problem we should address is that current Tors can only listen on a single