diff --git a/i2p2www/pages/site/about/performance/history.html b/i2p2www/pages/site/about/performance/history.html
index d919c51a..646f6440 100644
--- a/i2p2www/pages/site/about/performance/history.html
+++ b/i2p2www/pages/site/about/performance/history.html
@@ -140,7 +140,7 @@ message based, with the router providing delivery guarantees by garlic wrapping
 an "ACK" message in with the payload, so once the data gets to the target, the
 ACK message is forwarded back to us [through tunnels, of course]).
 {%- endtrans %}</p>
-<p>{% trans link='http://dev.i2p.net/pipermail/i2p/2004-March/000167.html' -%}
+<p>{% trans link='http://web.archive.org/web/20070607220008/http://dev.i2p.net/pipermail/i2p/2004-March/000167.html' -%}
 As I've <a href="{{ link }}">said</a>, having
 I2PTunnel (and the ministreaming lib) go this route was the best thing that
 could be done, but more efficient mechanisms are available.  When we rip out the
diff --git a/i2p2www/pages/site/docs/discussions/tunnel.html b/i2p2www/pages/site/docs/discussions/tunnel.html
index e8a3b5ce..bd8995b7 100644
--- a/i2p2www/pages/site/docs/discussions/tunnel.html
+++ b/i2p2www/pages/site/docs/discussions/tunnel.html
@@ -35,7 +35,7 @@ None of these are currently implemented.
 
 <p>These padding strategies can be used on a variety of levels, addressing the
 exposure of message size information to different adversaries.  After gathering
-and reviewing some <a href="http://dev.i2p.net/~jrandom/messageSizes/">statistics</a>
+and reviewing some <a href="http://web.archive.org/web/20050413140457/http://dev.i2p.net/~jrandom/messageSizes/">statistics</a>
 from the 0.4 network, as well as exploring the anonymity tradeoffs, we're starting
 with a fixed tunnel message size of 1024 bytes.  Within this however, the fragmented
 messages themselves are not padded by the tunnel at all (though for end to end