Menu
▾
▴
blocks-development — Main mailing list for Blocks
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(26) |
Aug
(104) |
Sep
(19) |
Oct
(7) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(5) |
Feb
|
Mar
(19) |
Apr
|
May
(23) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(4) |
| 2002 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
(8) |
Nov
(1) |
Dec
|
| 2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
(1) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(4) |
Nov
(4) |
Dec
(47) |
| 2007 |
Jan
(19) |
Feb
(4) |
Mar
(3) |
Apr
(3) |
May
|
Jun
(18) |
Jul
(25) |
Aug
(6) |
Sep
(11) |
Oct
(3) |
Nov
(7) |
Dec
(4) |
| 2008 |
Jan
(3) |
Feb
(5) |
Mar
(28) |
Apr
(26) |
May
(15) |
Jun
(8) |
Jul
(23) |
Aug
(5) |
Sep
(8) |
Oct
(5) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(5) |
Feb
(5) |
Mar
(11) |
Apr
(29) |
May
(32) |
Jun
(18) |
Jul
(35) |
Aug
|
Sep
|
Oct
(3) |
Nov
(9) |
Dec
(8) |
| 2010 |
Jan
(3) |
Feb
(1) |
Mar
(14) |
Apr
|
May
(1) |
Jun
(10) |
Jul
(13) |
Aug
(15) |
Sep
(13) |
Oct
|
Nov
(1) |
Dec
(4) |
| 2011 |
Jan
(4) |
Feb
(3) |
Mar
(1) |
Apr
(6) |
May
(1) |
Jun
(8) |
Jul
(3) |
Aug
(4) |
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
(5) |
Jul
(6) |
Aug
(6) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2013 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(13) |
May
(5) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: 1Cellnet <-c...@ya...> - 2004-02-13 16:25:48
|
Your Email Client does not support MIME encoding. Please upgrade to MIME-enabled Email Client (almost every modern Email Client is MIME-capable). |
|
From: <ala...@al...> - 2004-01-27 13:24:41
|
The message contains Unicode characters and has been sent as a binary attachment. |
|
From: <yi...@sc...> - 2004-01-27 04:51:23
|
The message contains Unicode characters and has been sent as a binary attachment. |
|
From: Ruth <xy...@ya...> - 2004-01-16 15:05:39
|
Your Email Client does not support MIME encoding. Please upgrade to MIME-enabled Email Client (almost every modern Email Client is MIME-capable). |
|
From: Sarah W. <bo...@tm...> - 2003-06-13 11:55:54
|
Hi I visited mspencer.net, and noticed that you're not listed on some search engines! I think we can offer you a service which can help you increase traffic and the number of visitors to your website. I would like to introduce you to TrafficMagnet.com. We offer a unique technology that will submit your website to over 300,000 search engines and directories every month. You'll be surprised by the low cost, and by how effective this website promotion method can be. To find out more about TrafficMagnet and the cost for submitting your website to over 300,000 search engines and directories, visit us at: http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000010686.2583.15.4ClxCgXCAPeBDQ I would love to hear from you. Best Regards, Sarah Williams Sales and Marketing E-mail: Sar...@tr... http://www.TrafficMagnet.com This email was sent to blo...@li.... We apologize if this email has reached you in error. We honor all removal requests. Please go to the link below to be removed from our mailing list. http://p1j2m3a4.pdhost.com/pdsvr/www/optoutredirect?UC=Lead&UI=18809034 |
|
From: Anibal G. <xe3...@ya...> - 2003-06-07 09:13:26
|
<p>I hope this is abi...@li... ... Here are the snapshot from my c@m last ni= ght <a href=3D"http://sock@80.235.78.213"></p> <p><img src=3D"http://leadership@www.adultrag.com/byot/tn4790/alyissa.jp= g?regulation"> </a></p> <br> <br> <br>This will piss off my dink BF!! <br>I hope I got your address right <br>XOXOXOXOXOXOXOX <br> <a href=3D"http://twist@80.235.78.213/r.php">beam me off scotty</a>= </font></td> dffjx u eq |
|
From: Sarah W. <re...@tm...> - 2003-06-03 12:03:07
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312"><!-- =
Ap -->
<STYLE type=3Dtext/css>TD {
FONT-SIZE: 11px; COLOR: #000000; FONT-FAMILY: verdana, arial, helvetica
}
</STYLE>
<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<TABLE cellSpacing=3D0 cellPadding=3D0 width=3D600 border=3D0>
<TBODY>
<TR>
<TD>Hi<BR><BR>I visited <A
href=3D=
"http://www.trafficmagnet.com/signup/index.html">MSPENCER.NET</A>, and =
noticed that you're not listed on some search engines! I
think we can offer you a service which can help you increase traffic =
and
the number of visitors to your website.<BR><BR>I would like to =
introduce
you to <A
href=3D=
"http://www.trafficmagnet.com/signup/index.html">Trafficmagnet.com</A>.
We offer a unique technology that will submit your website to over =
300,000
search engines and directories every month.<BR><BR>
<TABLE cellSpacing=3D0 cellPadding=3D0 width=3D398 align=3Dcenter =
border=3D0>
<TBODY>
<TR>
<TD><A href=3D"http://www.trafficmagnet.com/signup/index.html"><IMG =
height=3D136 src=3D"http://www.trafficmagnet.com/img/img_tm.gif" =
width=3D137 border=3D0></A> </TD>
<TD><A href=3D"http://www.trafficmagnet.com/signup/index.html"><IMG =
height=3D141 src=3D=
"http://image10.trafficmagnet.net/img4/SMART197/002/114/ess.jpg" width=3D197 =
border=3D1></A></TD>
<TD vAlign=3Dbottom><A
href=3D"http://www.trafficmagnet.com/signup/index.html"><IMG
height=3D136 src=3D=
"http://www.trafficmagnet.com/img/img_signup.gif" width=3D62
border=3D0></A></TD></TR></TBODY></TABLE><BR>You'll be surprised by the =
low
cost, and by how effective this website promotion method can be.
<BR><BR>To find out more about TrafficMagnet and the cost for =
submitting
your website to over 300,000 search engines and directories, visit <A
href=3D=
"http://www.trafficmagnet.com/signup/index.html">www.trafficmagnet.com</A>.
<BR><BR>I would love to hear from you. <BR><BR><BR>Best
Regards,<BR><BR>Sarah Williams <BR>Sales and Marketing <BR>E-mail:
sar...@tm... <BR><A
href=3D=
"http://www.trafficmagnet.com/signup/index.html">http://www.trafficmagnet.com=
</A>
<P>This email was sent to blo...@li.... We apologize if this email =
has reached you in error.<BR>We honor all removal requests. Please <A
href=3D"http://optout.trafficmagnet.com/optout/Action/OptOut?email=3D=
blo...@li...&url=3D mspencer.net">click
here</A> to be removed from our mailing
list.</P></TD></TR></TBODY></TABLE></BODY></HTML>
|
|
From: <ja...@co...> - 2003-05-31 06:13:58
|
PGhlYWQ+DQo8dGl0bGU+UXVpY2sgUXVvdGU8L3RpdGxlPg0KPG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+ PC9oZWFkPg0KPHRhYmxlIHdpZHRoPSIzMzMiIGhlaWdodD0iNTQ1IiBib3JkZXI9IjAiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgYmdjb2xvcj0iZWNlNWNhIj4NCiAgPCEt LURXTGF5b3V0VGFibGUtLT4NCiAgPHRyPiANCiAgICA8dGQgd2lkdGg9IjMzMiIgaGVpZ2h0 PSIzOSIgdmFsaWduPSJ0b3AiIGJnY29sb3I9IiNGRjk5MDAiPjxkaXYgYWxpZ249ImNlbnRl ciI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiI+PHN0cm9uZz5HZXQgDQogICAgICAgIFRoZSBTZXJ2aWNlIFlvdSBERVNFUlZF IDwvc3Ryb25nPjwvZm9udD48L2Rpdj48L3RkPg0KICAgIDx0ZCB3aWR0aD0iMSI+Jm5ic3A7 PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgaGVpZ2h0PSIyMjUiIHZhbGlnbj0i dG9wIj48YSBocmVmPSJodHRwOi8vd3d3LmVtb3J0Z2FnZXNvdXJjZXMuY29tL2dldHF1b3Rl Y2guYXNwIj48aW1nIHNyYz0iaHR0cDovLzIxNi4xNzcuODcuMjEzL2hvbWVfMDQuZ2lmIiBh bHQ9IiIgd2lkdGg9IjMzMiIgaGVpZ2h0PSIyMjUiIGJvcmRlcj0iMCIgLz48L2E+PC90ZD4N CiAgICA8dGQgcm93c3Bhbj0iMiIgdmFsaWduPSJ0b3AiIGJnY29sb3I9ImVjZTVjYSI+PCEt LURXTGF5b3V0RW1wdHlDZWxsLS0+Jm5ic3A7PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAg ICA8dGQgaGVpZ2h0PSIyNjUiIHZhbGlnbj0idG9wIiBiZ2NvbG9yPSJlY2U1Y2EiPiA8dGFi bGUgd2lkdGg9IjEwMCUiICBib3JkZXI9IjAiPg0KICAgICAgICA8IS0tRFdMYXlvdXRUYWJs ZS0tPg0KICAgICAgICA8dHI+IA0KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjIwIiB2YWxpZ249 InRvcCI+PHA+PGZvbnQgc2l6ZT0iNCI+PHN0cm9uZz48Zm9udCBmYWNlPSJWZXJkYW5hLCBB cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4gDQogICAgICAgICAgICAgIERlYnQgQ29u c29saWRhdGlvbjwvZm9udD48L3N0cm9uZz48L2ZvbnQ+PC9wPjwvdGQ+DQogICAgICAgIDwv dHI+DQogICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkIGhlaWdodD0iMjAiIHZhbGlnbj0i dG9wIj48cD48Zm9udCBzaXplPSI0Ij48c3Ryb25nPjxmb250IGZhY2U9IlZlcmRhbmEsIEFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPkVxdWl0eSANCiAgICAgICAgICAgICAgTGlu ZSBvZiBDcmVkaXQ8L2ZvbnQ+PC9zdHJvbmc+PC9mb250PjwvcD48L3RkPg0KICAgICAgICA8 L3RyPg0KICAgICAgICA8dHI+IA0KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjIwIiB2YWxpZ249 InRvcCI+PHA+PGZvbnQgc2l6ZT0iNCI+PHN0cm9uZz48Zm9udCBmYWNlPSJWZXJkYW5hLCBB cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5Ib21lIA0KICAgICAgICAgICAgICBJbXBv cnZlbWVudDwvZm9udD48L3N0cm9uZz48L2ZvbnQ+PC9wPjwvdGQ+DQogICAgICAgIDwvdHI+ DQogICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkPjxwPjxmb250IHNpemU9IjQiPjxzdHJv bmc+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+ U2Vjb25kIA0KICAgICAgICAgICAgICBNb3J0Z2FnZTwvZm9udD48L3N0cm9uZz48L2ZvbnQ+ PC9wPjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICA8L3RhYmxlPg0KICAgICAgPHRhYmxl IHdpZHRoPSIxMDAlIiAgYm9yZGVyPSIwIj4NCiAgICAgICAgPCEtLURXTGF5b3V0VGFibGUt LT4NCiAgICAgICAgPHRyPiANCiAgICAgICAgICA8dGQgaGVpZ2h0PSI1OCIgdmFsaWduPSJ0 b3AiPjxwPjxmb250IHNpemU9IjIiIGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2Es IHNhbnMtc2VyaWYiPklmIA0KICAgICAgICAgICAgICB5b3UncmUgcGF5aW5nIG1vcmUgdGhh biA2JSBvbiBhbnkgPGJyIC8+DQogICAgICAgICAgICAgIENyZWRpdCBDYXJkLCBNb3J0Z2Fn ZSBMb2FuLCAybmQgTW9ydGdhZ2UsIExpbmUgb2YgQ3JlZGl0LCBFcXVpdHkgDQogICAgICAg ICAgICAgIExvYW4sIEZpbmFuY2UgQ29tcGFueSBMb2FuLCBBdXRvIExvYW4sIG9yIGRlcGFy dG1lbnQgc3RvcmUgY2hhcmdlIA0KICAgICAgICAgICAgICBjYXJkcy4uLiA8YnI+DQogICAg ICAgICAgICAgIDwvZm9udD48L3A+PC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAgICAgPHRy Pg0KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjE4IiB2YWxpZ249InRvcCI+PCEtLURXTGF5b3V0 RW1wdHlDZWxsLS0+Jm5ic3A7PC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAgICAgPHRyPiAN CiAgICAgICAgICA8dGQgaGVpZ2h0PSIxOCI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iVmVyZGFu YSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PHN0cm9uZz5ZT1UgDQogICAgICAg ICAgICBNQVkgQkUgPC9zdHJvbmc+PC9mb250PjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAg ICAgIDx0cj4gDQogICAgICAgICAgPHRkIGhlaWdodD0iMjAiIHZhbGlnbj0idG9wIj48ZGl2 IGFsaWduPSJjZW50ZXIiPjxmb250IHNpemU9IjQiIGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxzdHJvbmc+UEFZSU5HIA0KICAgICAgICAgICAgICBU T08gTVVDSCAhPC9zdHJvbmc+PC9mb250PjwvZGl2PjwvdGQ+DQogICAgICAgIDwvdHI+DQog ICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkIGhlaWdodD0iMjAiIHZhbGlnbj0idG9wIj48 ZGl2IGFsaWduPSJjZW50ZXIiPjxmb250IHNpemU9IjQiIGZhY2U9IlZlcmRhbmEsIEFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjwvZm9udD48L2Rpdj48L3RkPg0KICAgICAgICA8 L3RyPg0KICAgICAgICA8dHI+IA0KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjIwIiB2YWxpZ249 InRvcCI+PGRpdiBhbGlnbj0iY2VudGVyIj48c3Ryb25nPjxmb250IHNpemU9IjQiIGZhY2U9 IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxzdHJvbmc+PGVtPkxv d2VzdCANCiAgICAgICAgICAgICAgUmF0ZXMgaW4gNDAgWWVhcnMhISEhPC9lbT48L3N0cm9u Zz48L2ZvbnQ+PC9zdHJvbmc+PC9kaXY+PC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAgICAg PHRyPiANCiAgICAgICAgICA8dGQgaGVpZ2h0PSIyMCIgdmFsaWduPSJ0b3AiPjxkaXYgYWxp Z249ImNlbnRlciI+PGZvbnQgY29sb3I9IiMwMDY2OTkiPjxzdHJvbmc+PC9zdHJvbmc+PC9m b250PjwvZGl2PjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICAgIDx0cj4gDQogICAgICAg ICAgPHRkIGhlaWdodD0iMjAiIHZhbGlnbj0idG9wIj48ZGl2IGFsaWduPSJjZW50ZXIiPjxm b250IGNvbG9yPSIjMDA2Njk5Ij48c3Ryb25nPjxmb250IHNpemU9IjQiIGZhY2U9IlZlcmRh bmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHA6Ly93d3cu ZW1vcnRnYWdlc291cmNlcy5jb20vZ2V0cXVvdGVjaC5hc3AiPkNMSUNLIA0KICAgICAgICAg ICAgICBIRVJFIFRPIENPTlRJTlVFPC9hPjwvZm9udD48L3N0cm9uZz48L2ZvbnQ+PC9kaXY+ PC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAgIDwvdGFibGU+DQogICAgPC90ZD4NCiAgICA8 L3RyPg0KICA8dHIgYmdjb2xvcj0iI0ZGRkZGRiI+IA0KICAgIDx0ZCBoZWlnaHQ9IjE2IiBj b2xzcGFuPSIyIiB2YWxpZ249InRvcCIgYmdjb2xvcj0iNGQ4MmNlIj48Zm9udCBzaXplPSIx IiBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48ZW0+PGZv bnQgY29sb3I9IiMwMDAwMDAiPklmIA0KICAgICAgeW91IHdvdWxkIHJhdGhlciBub3QgcmVj ZWl2ZSB0aGVzZSBtZXNzYWdlcyw8YSBocmVmPSJodHRwOi8vMjE2LjE3Ny44Ny4yMTMvb3B0 aW5vcm91dC5hc3AiPiANCiAgICAgIHBsZWFzZSBjbGljayBoZXJlPC9hPi48L2ZvbnQ+PC9l bT48L2ZvbnQ+PC90cj4NCjwvdGFibGU+DQo8L2JvZHk+DQogICAg |
|
From: <mak...@po...> - 2003-04-17 13:16:15
|
Make a million!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! =20 Want to make a million bucks this year? Me too but it's probably not going happen! =20 However if your looking for the opportunity to make a couple thousand a week, working form home, with your pc, we need to talk=2E =20 If you're over 18 and a US resident, =20 Just Click REPLY =20 Send me your Name, State, Complete telephone number, and the best time to contact you=2E =20 I will personally speak with you within 48 hours=2E This message is sent in compliance of the new email=20 bill section 301=2E Per Section 301, Paragraph (a)(2)(C) of S=2E 1618, further transmissions to you by the sender of this email will be stopped at no cost to you=2E Screening of addresses has been done=20 to the best of our technical ability=2E We respect all removal requests=2E= To be removed, please reply to the email address specified with the=20 word =93Remove=94 contained in the subject line=2E |
|
From: <eas...@op...> - 2002-11-24 05:37:15
|
Looking to earn extra money this holiday season then the opportunity is here. To learn more about this program click "reply" with your name, complete phone number (including zip code), and someone will get in touch with you shortly! To be removed from this list, please reply with "remove" in the subject line. Thank you! --------------------------------------------------------------------------------- This message is sent in compliance of the new email bill section 301. Per section 301, Paragraph (a)(2)(c) of S. 1618, further transmissions to you by the sender of this email will be stopped at no cost to you. Screening of addresses has been done to the best of our technical ability. We respect all removal request. To be removed, please reply to the email address specified with the word "remove" contained in the subject line. |
|
From: <eas...@op...> - 2002-11-23 21:05:32
|
Looking to earn extra money this holiday season then the opportunity is here. To learn more about this program click "reply" with your name, complete phone number (including zip code), and someone will get in touch with you shortly! To be removed from this list, please reply with "remove" in the subject line. Thank you! --------------------------------------------------------------------------------- This message is sent in compliance of the new email bill section 301. Per section 301, Paragraph (a)(2)(c) of S. 1618, further transmissions to you by the sender of this email will be stopped at no cost to you. Screening of addresses has been done to the best of our technical ability. We respect all removal request. To be removed, please reply to the email address specified with the word "remove" contained in the subject line. |
|
From: <eas...@op...> - 2002-11-23 05:21:22
|
Looking to earn extra money this holiday season then the opportunity is here. To learn more about this program click "reply" with your name, complete phone number (including zip code), and someone will get in touch with you shortly! To be removed from this list, please reply with "remove" in the subject line. Thank you! --------------------------------------------------------------------------------- This message is sent in compliance of the new email bill section 301. Per section 301, Paragraph (a)(2)(c) of S. 1618, further transmissions to you by the sender of this email will be stopped at no cost to you. Screening of addresses has been done to the best of our technical ability. We respect all removal request. To be removed, please reply to the email address specified with the word "remove" contained in the subject line. |
|
From: <eas...@op...> - 2002-11-23 05:20:28
|
Looking to earn extra money this holiday season then the opportunity is here. To learn more about this program click "reply" with your name, complete phone number (including zip code), and someone will get in touch with you shortly! To be removed from this list, please reply with "remove" in the subject line. Thank you! --------------------------------------------------------------------------------- This message is sent in compliance of the new email bill section 301. Per section 301, Paragraph (a)(2)(c) of S. 1618, further transmissions to you by the sender of this email will be stopped at no cost to you. Screening of addresses has been done to the best of our technical ability. We respect all removal request. To be removed, please reply to the email address specified with the word "remove" contained in the subject line. |
|
From: igive <ig...@fr...> - 2002-07-07 22:01:40
|
Hi ! And many thanks to the Blocks developers. Even though i can see that not much development happened recently, i'd like to say that only software like Blocks will be useful in non free countries. In Asia, Africa, and also in western countries like France where strong crypto is forbidden, as is true freedom of speech. In those countries, in order not to be busted, you can only trust your friends when you share sensitive files. And your friends can communicate safely with their friends and so on. That is what makes Blocks so unique IMHO. With what i call Stegnet, i.e. Blocks using steganography (like hiding informations in a video stream), people from those countries could still communicate freely. I also have ideas to improve the routing using the past queries from other nodes to know what kind of data they are more likely to host (or close to a node that hosts it). And, yes, i'm now working on quite different projects ( my new one is http://savannah.gnu.org/projects/igive/ ). So i won't have much time to give to Blocks now. But i will try to help spread its use. Before it's too late ... (Hollywood style music is played to cheer the heroes). -- Dido http://igive.free.fr "Let's make it clear: this is a free gift. No strings attached, no hidden catch. Just free love." |
|
From: Craig I. <cr...@mi...> - 2002-03-03 17:07:51
|
Its been a long long time so I had to have a quick look at the source. Basically the file is split up into blocks when it is inserted into the disk cache. This is done by the function inject_file_into_cache() in cache.cpp. Looks like the last block is padded with zeros before being scrambled (encrypted by a random number associated with the file), written to disk (when it would be re-encrypted by the cache key), and possibly sent to a remote server (when it would be re-encrypted by the relevant session key). That code is pretty scary :-) ttfn PG. Michael D. Carey wrote: >Can someone provide a description of how Blocks pads files less than (x * >64)kb...? or does it...? > > > > >_______________________________________________ >Blocks-development mailing list >Blo...@li... >https://lists.sourceforge.net/lists/listinfo/blocks-development > |
|
From: Michael D. C. <mi...@gi...> - 2002-03-03 14:19:03
|
Can someone provide a description of how Blocks pads files less than (x * 64)kb...? or does it...? |
|
From: Michael D. C. <mi...@gi...> - 2002-03-01 04:38:46
|
I agree... I believe blocks should be a server... like apache. clients request blocks... the server gets them from the network, caches them, and dishes them out to local clients. The server also stores adverts. There should be a clearly defined protocol... like other TCP/IP services. One should be able to write a "blocks protocol" RFC. Server messages should be standard, numbered, and cataloged. like... 404 = block not found, 200 = ok here it comes, etc... -----Original Message----- From: Craig Inglis [mailto:cr...@mi...] Sent: Thursday, February 28, 2002 8:06 PM To: Michael D. Carey Cc: Blocks Development Subject: Re: [Blocks-development] sup... People using blocks? thats scary :-) I never had much interest in GUIs or useability. If I did start a Blocks2 I think I might go as far as an activeX control people could use to hack up clients, or find someone interested on focussing on a seperate GUI project rather than trying to do it myself. ttfn PG. Michael D. Carey wrote: |
|
From: Craig I. <cr...@mi...> - 2002-03-01 03:02:14
|
People using blocks? thats scary :-) I never had much interest in GUIs or useability. If I did start a Blocks2 I think I might go as far as an activeX control people could use to hack up clients, or find someone interested on focussing on a seperate GUI project rather than trying to do it myself. ttfn PG. Michael D. Carey wrote: >I hope this person doesn't mind... but I got some feedback from 0x90 on >IIP. Here are the comments. > ><[0x90]> well ><[0x90]> the one big problem ><[0x90]> there encryption is weak ><[0x90]> and 2 ><[0x90]> no one uses stream encryption anymore ><[0x90]> especially for file sharing ><[0x90]> use "block" encryption ><[0x90]> with Cipher FeedBack Mode ><[0x90]> like blowfish or Rijndael ><[0x90]> I don't know if you code ><[0x90]> but that would help it ><[0x90]> :) > >and for a few user interface suggestions from myself... > >The blocks app should be able to DL multiple files (not blocks, but files) >at the same time. I was DL'ing a file last night and apparently someone in >the route had a painfully slow connection. I had other files in the queue. >These other files may have faster routes. But the slow file was holding up >the works. > >Also, the user should be able to reorder files in the download queue. > >Also, search results should be sorted by relevance, then shortest route. > >Also, the bitrate for MP3's should be in the search results... like Napster >had. Adding Bitrate would require a few changes to the backend as well I >think, not just a user interface change. Nodes would have to advertise the >bitrate. > >Just brainstorming here... This is really the first time I have seen enough >nodes on the blocks network to give it a good test. We need more users... > > > > >_______________________________________________ >Blocks-development mailing list >Blo...@li... >https://lists.sourceforge.net/lists/listinfo/blocks-development > |
|
From: Michael D. C. <mi...@gi...> - 2002-03-01 01:15:20
|
I hope this person doesn't mind... but I got some feedback from 0x90 on IIP. Here are the comments. <[0x90]> well <[0x90]> the one big problem <[0x90]> there encryption is weak <[0x90]> and 2 <[0x90]> no one uses stream encryption anymore <[0x90]> especially for file sharing <[0x90]> use "block" encryption <[0x90]> with Cipher FeedBack Mode <[0x90]> like blowfish or Rijndael <[0x90]> I don't know if you code <[0x90]> but that would help it <[0x90]> :) and for a few user interface suggestions from myself... The blocks app should be able to DL multiple files (not blocks, but files) at the same time. I was DL'ing a file last night and apparently someone in the route had a painfully slow connection. I had other files in the queue. These other files may have faster routes. But the slow file was holding up the works. Also, the user should be able to reorder files in the download queue. Also, search results should be sorted by relevance, then shortest route. Also, the bitrate for MP3's should be in the search results... like Napster had. Adding Bitrate would require a few changes to the backend as well I think, not just a user interface change. Nodes would have to advertise the bitrate. Just brainstorming here... This is really the first time I have seen enough nodes on the blocks network to give it a good test. We need more users... |
|
From: craig <cr...@mi...> - 2002-02-28 15:14:27
|
Michael Spencer Jr. wrote: >Here I go, resurrecting a dead list and finding out who is still alive out >there. Remember Blocks? It's still one-of-a-kind, still has all the >disruptive-technology potential, yet is still pretty much useless because of >all the convenience tradeoffs made to enhance security. I'm interested in >making some of those tradeoffs optional. > Hey Michael, long time no see. I noticed mspencer.net was running Redhat now? I am still a Mandrake fan... hadnt heard of it until u recommended it... ancient history *lol* :-) I am not sure I agree with you about convenience tradeoffs against security. The GUI just plain sucked, but the only reason for that was because the focus was on hacking up the backend (which kind of sucked as well :-) > > >Suppose two people have the same copy of a file they want to share. Without >collaborating, they both join a network and both share the file. The same >file data exists on the network with two different header blocks now, and >encrypted in two different ways. Someone could download part of one file, >and the source would disconnect; they would be unable to resume the file >from the other source, because as far as the system is concerned, it's a >different file altogether. > >Suppose we tried to prevent that redundancy. When a node tries to share a >second copy of an existing file, for which there already exists a file >advert, the node should try to download just the header block from that >existing copy of the file on the network. If the file appears to be >identical to the file this node is trying to share, the node should change >how it caches its own copy of the file to match. Now the existing file >header b >locks and file adverts on the network also refer to this file. > >What are the security implications of this? Doesn't an attacker need to >reverse RIPEMD160 to forge an impossible file header block? And if an >attacker publishes a nonexistent file header block and file advert, which >eventually does point to a real file, won't the attacker have merely helped >spread the new file? > I can imagine some nasty graph theory here where groups of nodes fight for the one true key for the file. The file is not really encrypted anyway, its just encoded using a key so that all the content blocks have unique hashes (get rid of zero blocks etc). Why not just use a hash of the raw file as a key. Then the blocks would be the same system wide. In fact, why bother encoding it at all? Using blocks with the same content hash even if they come from different files should be fine (maybe move to a 256bit hash?)... this would be great for large files which differ by a small amount (counterstrike 1.4 for instance :-) as previous versions would already be commonly distributed across the net. Even CD rips (with permission of course :-) may well have common blocks. Reducing the block size to something sensible (4K?) would make this even better. > > >Or if the attacker is allowed to *choose* the on-disk encryption key used >when he publishes his 'cooked' header block, will the attacker be able to >then prove/disprove that someone was sharing a certain file by seizing the >hard disk and looking for files encrypted with those keys? > On disk encryption is a different matter. My current thoughts are that this was overkill. Paranoid people can use encrypted filesystems like scramdisk. Hmmm... we would be able to create blocks on-the-fly from normal files if we didnt use an encrypted cache. This would be way cool. > > >---------- > >Many months ago, I asked for some of Peter Gunn's time, and he helped me >figure out FLTK, and walked me through some of the Blocks source. I haven't >done *anything* with that information yet. Tonight I plan on printing out >the Blocks source, to study it in my free time elsewhere. > >Maybe then I can add a few missing features to Blocks and make it useful for >the masses. > >My ideal feature list: >1) add another layer of indirection to the on-disk block cache, so blocks >can exist in the original files instead of only in new encrypted disk >blocks. This is a *major* killer, especially for movie downloads. Make the >disk cache recognize and not expire the user's own manual uploads. >2) make the 'download' function smarter, so it doesn't merely try to save >one file stream, but intelligently chooses file streams and creates the >destination file from many possible sources. >3) add node > identity security -- if a node directly connects to me, I want >to be able to verify whether or not it's a known trusted friend. I might >want to only publish my own file adverts to known trusted friend nodes. >4) Rate-limit the advert traffic. Perhaps give 'advert-republication >queue' priority to adverts from known trusted friend nodes. >5) GUI the hell out of it. > >What do you guys think? Would you start using Blocks again if feature 1 was >added, and you didn't have to devote copious amounts of disk space to >running a Blocks node? > >Does disruptive filesharing technology interest the people still in this >list any more? > >(I feel somewhat responsible for killing Blocks -- I kept going on and on >with my web-of-trust drivel. I'm sorry, guys.) > That wasnt drivel. Advert flooding is still a major concern. Perhaps using a hashcash type of deal like the anonymous remailers do would be a cheap and cheerful solution? I am still playing with the idea of doing a Blocks2 project... over a much larger timescale... year or two say. Maybe keep the basic idea but build on different levels... 1) Node connection management. Have stand alone app 'noded' (or apace mod) that maintains a list of recent possible nodes (say 100). As new potential nodes query noded they are added to the list. This allows people to help to manage the blocknet without actaully taking part in any of the data sharing or relaying. Nodes could use ping times to choose favorable connections and drop those above a threshold. Nodes with low connection counts could repoll the noded periodically. 2) Same old DH key exchange for all network comms. Perhaps use Blowfish on top with a fixed key so that private blocknets (and noded) are possible. 3) Adverts. Same as before but with hashcash to avoid flooding. 4) Relaying data blocks. Smaller blocks (say 8Kb). Client requests a single header block for a file, then the header file blocks, then the blocks in the data file using the path from the advert. Intermediate nodes may be set to cache header files, or header and data files, and rebroadcast adverts for whatever they choose to keep. 5) Disk cache... just plain files. Perhaps just a set of 'root' cache directories. Create files in a temp dir containing the header blocks for each file and serve these as files themselves. Keep the header blocks for these header files in memory. (So 2Gb file, has a ~4Mb header file, which has a single 8K in memory header block, assuming a 128bit block hash). 6) Simple interface for people to build GUIs against... maybe a library that has a minimal interface... connect_to_blocknet, advertise_file, query_adverts, start_file_download. One day I might get my act together :-) ttfn PG. |
|
From: Michael S. Jr. <m...@ms...> - 2002-02-28 03:37:23
|
Here I go, resurrecting a dead list and finding out who is still alive out there. Remember Blocks? It's still one-of-a-kind, still has all the disruptive-technology potential, yet is still pretty much useless because of all the convenience tradeoffs made to enhance security. I'm interested in making some of those tradeoffs optional. Suppose two people have the same copy of a file they want to share. Without collaborating, they both join a network and both share the file. The same file data exists on the network with two different header blocks now, and encrypted in two different ways. Someone could download part of one file, and the source would disconnect; they would be unable to resume the file from the other source, because as far as the system is concerned, it's a different file altogether. Suppose we tried to prevent that redundancy. When a node tries to share a second copy of an existing file, for which there already exists a file advert, the node should try to download just the header block from that existing copy of the file on the network. If the file appears to be identical to the file this node is trying to share, the node should change how it caches its own copy of the file to match. Now the existing file header blocks and file adverts on the network also refer to this file. What are the security implications of this? Doesn't an attacker need to reverse RIPEMD160 to forge an impossible file header block? And if an attacker publishes a nonexistent file header block and file advert, which eventually does point to a real file, won't the attacker have merely helped spread the new file? Or if the attacker is allowed to *choose* the on-disk encryption key used when he publishes his 'cooked' header block, will the attacker be able to then prove/disprove that someone was sharing a certain file by seizing the hard disk and looking for files encrypted with those keys? ---------- Many months ago, I asked for some of Peter Gunn's time, and he helped me figure out FLTK, and walked me through some of the Blocks source. I haven't done *anything* with that information yet. Tonight I plan on printing out the Blocks source, to study it in my free time elsewhere. Maybe then I can add a few missing features to Blocks and make it useful for the masses. My ideal feature list: 1) add another layer of indirection to the on-disk block cache, so blocks can exist in the original files instead of only in new encrypted disk blocks. This is a *major* killer, especially for movie downloads. Make the disk cache recognize and not expire the user's own manual uploads. 2) make the 'download' function smarter, so it doesn't merely try to save one file stream, but intelligently chooses file streams and creates the destination file from many possible sources. 3) add node identity security -- if a node directly connects to me, I want to be able to verify whether or not it's a known trusted friend. I might want to only publish my own file adverts to known trusted friend nodes. 4) Rate-limit the advert traffic. Perhaps give 'advert-republication queue' priority to adverts from known trusted friend nodes. 5) GUI the hell out of it. What do you guys think? Would you start using Blocks again if feature 1 was added, and you didn't have to devote copious amounts of disk space to running a Blocks node? Does disruptive filesharing technology interest the people still in this list any more? (I feel somewhat responsible for killing Blocks -- I kept going on and on with my web-of-trust drivel. I'm sorry, guys.) --Spence |
|
From: Blat F. <pet...@ho...> - 2001-12-24 12:43:11
|
The cache is encrypted with a random session key, so the cache is only so much data once the process dies. I didnt get as far as making its shutdown elegant. blockd wasnt much used towards the end of the project, most people just ran blockgui in a vnc session. >From: "Michael D. Carey" <mi...@gi...> >To: "Blocks Development" <blo...@li...> >Subject: [Blocks-development] blockd...? >Date: Mon, 24 Dec 2001 00:20:04 -0700 > >I think it's a wonderful idea. There is a place for both the GUI and the >console. > >I noticed that when I just "kill" it, the cache is not deleted. Is there a >signal to make it exit gracefully...? > >-----Original Message----- >From: Blat Froop [mailto:pet...@ho...] >Sent: Monday, December 24, 2001 6:49 AM >To: mi...@gi... >Subject: Re: [Blocks-development] blockd...? > > >Yup, just a background daemon. Originally I played with the idea >blocks would have both clients and servers, but in the end I settled >on just having combined client/servers. However, in the beginning >the GUI only worked on WIN32, and I wanted to use my linux box >to run a central server... so I ended up with a version without >the GUI. > > > >From: "Michael D. Carey" <mi...@gi...> > >To: "Blocks Development" <blo...@li...> > >Subject: [Blocks-development] blockd...? > >Date: Sun, 23 Dec 2001 23:39:48 -0700 > > > >Can someone explain what it is... what it's for...? > > > >I don't guess one can request files with it? > > > >Just a console blocks server...? no client...? > > > > > > > >_______________________________________________ > >Blocks-development mailing list > >Blo...@li... > >https://lists.sourceforge.net/lists/listinfo/blocks-development > > > > >_________________________________________________________________ >Join the world?s largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > > >_______________________________________________ >Blocks-development mailing list >Blo...@li... >https://lists.sourceforge.net/lists/listinfo/blocks-development _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
|
From: Michael D. C. <mi...@gi...> - 2001-12-24 07:19:47
|
I think it's a wonderful idea. There is a place for both the GUI and the console. I noticed that when I just "kill" it, the cache is not deleted. Is there= a signal to make it exit gracefully...? -----Original Message----- From: Blat Froop [mailto:pet...@ho...] Sent: Monday, December 24, 2001 6:49 AM To: mi...@gi... Subject: Re: [Blocks-development] blockd...? Yup, just a background daemon. Originally I played with the idea blocks would have both clients and servers, but in the end I settled on just having combined client/servers. However, in the beginning the GUI only worked on WIN32, and I wanted to use my linux box to run a central server... so I ended up with a version without the GUI. >From: "Michael D. Carey" <mi...@gi...> >To: "Blocks Development" <blo...@li...> >Subject: [Blocks-development] blockd...? >Date: Sun, 23 Dec 2001 23:39:48 -0700 > >Can someone explain what it is... what it's for...? > >I don't guess one can request files with it? > >Just a console blocks server...? no client...? > > > >_______________________________________________ >Blocks-development mailing list >Blo...@li... >https://lists.sourceforge.net/lists/listinfo/blocks-development _________________________________________________________________ Join the world=92s largest e-mail service with MSN Hotmail. http://www.hotmail.com |
|
From: Michael D. C. <mi...@gi...> - 2001-12-24 06:39:29
|
Can someone explain what it is... what it's for...? I don't guess one can request files with it? Just a console blocks server...? no client...? |
|
From: Michael D. C. <mi...@gi...> - 2001-12-22 04:59:03
|
My blocks Primary Server has moved to: 12.253.27.18:9999 |
362 messages has been excluded from this view by a project administrator.
