3.05.1978

Arpanet.


Mail-from: DEC-MARLBORO rcvd at 3-May-78 0955-PDT
Date: 1 May 1978 1233-EDT
From: THUERK at DEC-MARLBORO
Subject: ADRIAN@SRI-KL
To: DDAY at SRI-KL, DAY at SRI-KL, DEBOER at UCLA-CCN,
To: WASHDC at SRI-KL, LOGICON at USC-ISI, SDAC at USC-ISI,
To: DELDO at USC-ISI, DELEOT at USC-ISI, DELFINO at USC-ISI,
To: DENICOFF at USC-ISI, DESPAIN at USC-ISI, DEUTSCH at SRI-KL,
To: DEUTSCH at PARC-MAXC, EMY at CCA-TENEX, DIETER at USC-ISIB,
To: DINES at AMES-67, MERADCON at SRI-KL, EPG-SPEC at SRI-KA,
To: DIVELY at SRI-KL, DODD at USC-ISI, DONCHIN at USC-ISIC,
To: JED at LLL-COMP, DORIN at CCA-TENEX, NYU at SRI-KA,
To: DOUGHERTY at USC-ISI, PACOMJ6 at USC-ISI,
To: DEBBY at UCLA-SECURITY, BELL at SRI-KL, JHANNON at SRI-KA,
To: DUBOIS at USC-ISI, DUDA at SRI-KL, POH at USC-ISI,
To: LES at SU-AI, EAST at BBN-TENEX, DEASTMAN at USC-ECL,
To: EBISU at I4-TENEX, NAC at USC-ISIE, ECONOMIDIS at I4-TENEX,
To: WALSH at SRI-KL, GEDWARDS at SRI-KL, WEDWARDS at USC-ISI,
To: NUSC at SRI-KL, RM at SU-AI, ELKIND at PARC-MAXC,
To: ELLENBY at PARC-MAXC, ELLIS at PARC-MAXC, ELLIS at USC-ISIB,
To: ENGELBART at SRI-KL, ENGELMORE at SUMEX-AIM,
To: ENGLISH at PARC-MAXC, ERNST at I4-TENEX,
To: ESTRIN at MIT-MULTICS, EYRES at USC-ISIC,
To: FAGAN at SUMEX-AIM, FALCONER at SRI-KL,
To: DUF at UCLA-SECURITY, FARBER at RAND-UNIX, PMF at SU-AI,
To: HALFF at USC-ISI, RJF at MIT-MC, FEIERBACH at I4-TENEX,
To: FEIGENBAUM at USC-ISI, FEINLER at SRI-KL,
To: FELDMAN at SUMEX-AIM, FELDMAN at SRI-KL, FERNBACH at LLL-COMP,
To: FERRARA at RADC-MULTICS, FERRETTI at SRI-KA,
To: FIALA at PARC-MAXC, FICKAS at USC-ISIC, AFIELD at I4-TENEX,
To: FIKES at PARC-MAXC, REF at SU-AI, FINK at MIT-MULTICS,
To: FINKEL at USC-ISIB, FINN at USC-ISIB, AFGWC at BBN-TENEX,
To: FLINT at SRI-KL, WALSH at SRI-KL, DRXAN at SRI-KA,
To: FOX at SRI-KL, FRANCESCHINI at MIT-MULTICS,
To: SAI at USC-ISIC, FREDRICKSON at RAND-RCC, ETAC at BBN-TENEXB,
To: FREYLING at BBN-TENEXE, FRIEDLAND at SUMEX-AIM,
To: FRIENDSHUH at SUMEX-AIM, FRITSCH at LLL-COMP, ME at SU-AI,
To: FURST at BBN-TENEXB, FUSS at LLL-COMP, OP-FYE at USC-ISIB,
To: SCHILL at USC-ISIC, GAGLIARDI at USC-ISIC,
To: GAINES at RAND-UNIX, GALLENSON at USC-ISIB,
To: GAMBLE at BBN-TENEXE, GAMMILL at RAND-UNIX,
To: GANAN at USC-ISI, GARCIA at SUMEX-AIM,
To: GARDNER at SUMEX-AIM, MCCUTCHEN at SRI-KL,
To: GARDNER at MIT-MULTICS, GARLICK at SRI-KL,
To: GARVEY at SRI-KL, GAUTHIER at USC-ISIB,
To: USGS-LIA at BBN-TENEX, GEMOETS at I4-TENEX,
To: GERHART at USC-ISIB, GERLA at USC-ISIE, GERLACH at I4-TENEX,
To: GERMAN at HARV-10, GERPHEIDE at SRI-KA, DANG at SRI-KL,
To: GESCHKE at PARC-MAXC, GIBBONS at CMU-10A,
To: GIFFORD.COMPSYS at MIT-MULTICS, JGILBERT at BBN-TENEXB,
To: SGILBERT at BBN-TENEXB, SDAC at USC-ISI,
To: GILLOGLY at RAND-UNIX, STEVE at RAND-UNIX,
To: GLEASON at SRI-KL, JAG;BIN(1525) at UCLA-CCN,
To: GOLD at LL-11, GOLDBERG at USC-ISIB, GOLDGERG at SRI-KL,
To: GROBSTEIN at SRI-KL, GOLDSTEIN at BBN-TENEXB,
To: DARPM-NW at BBN-TENEXB, GOODENOUGH at USC-ISIB,
To: GEOFF at SRI-KL, GOODRICH at I4-TENEX, GOODWIN at USC-ISI,
To: GOVINSKY at SRI-KL, DEAN at I4-TENEX, TEG at MIT-MULTICS,
To: CCG at SU-AI, EPG-SPEC at SRI-KA, GRISS at USC-ECL,
To: BJG at RAND-UNIX, MCCUTCHEN at SRI-KL, GROBSTEIN at SRI-KL,
To: MOBAH at I4-TENEX, GUSTAFSON at USC-ISIB, GUTHARY at SRI-KL,
To: GUTTAG at USC-ISIB, GUYTON at RAND-RCC,
To: ETAC-AD at BBN-TENEXB, HAGMANN at USC-ECL, HALE at I4-TENEX,
To: HALFF at USC-ISI, DEHALL at MIT-MULTICS,
To: HAMPEL at LLL-COMP, HANNAH at USC-ISI,
To: NORSAR-TIP at USC-ISIC, SCRL at USC-ISI, HAPPY at SRI-KL,
To: HARDY at SRI-KL, IMPACT at SRI-KL, KLH at SRI-KL,
To: J33PAC at USC-ISI, HARRISON at SRI-KL, WALSH at SRI-KL,
To: DRCPM-FF at BBN-TENEXB, HART at AMES-67, HART at SRI-KL,
To: HATHAWAY at AMES-67, AFWL at I4-TENEX, BHR at RAND-UNIX,
To: RICK at RAND-UNIX, DEBE at USC-ISIB, HEARN at USC-ECL,
To: HEATH at UCLA-ATS, HEITMEYER at BBN-TENEX, ADTA at SRI-KA,
To: HENDRIX at SRI-KL, CH47M at BBN-TENEXB, HILLIER at SRI-KL,
To: HISS at I4-TENEX, ASLAB at USC-ISIC, HOLG at USC-ISIB,
To: HOLLINGWORTH at USC-ISIB, HOLLOWAY at HARV-10,
To: HOLMES at SRI-KL, HOLSWORTH at SRI-KA, HOLT at LLL-COMP,
To: HOLTHAM at LL, DHOLZMAN at RAND-UNIX, HOPPER at USC-ISIC,
To: HOROWITZ at USC-ISIB, VSC at USC-ISI, HOWARD at LLL-COMP,
To: HOWARD at USC-ISI, PURDUE at USC-ISI, HUBER at RAND-RCC,
To: HUNER at RADC-MULTICS, HUTSON at AMES-67, IMUS at USC-ISI,
To: JACOBS at USC-ISIE, JACOBS at BBN-TENEXB,
To: JACQUES at BBN-TENEXB, JARVIS at PARC-MAXC,
To: JEFFERS at PARC-MAXC, JENKINS at PARC-MAXC,
To: JENSEN at SRI-KA, JIRAK at SUMEX-AIM, NICKIE at SRI-KL,
To: JOHNSON at SUMEX-AIM, JONES at SRI-KL, JONES at LLL-COMP,
To: JONES at I4-TENEX, RLJ at MIT-MC, JURAK at USC-ECL,
To: KAHLER at SUMEX-AIM, MWK at SU-AI, KAINE at USC-ISIB,
To: KALTGRAD at UCLA-ATS, MARK at UCLA-SECURITY, RAK at SU-AI,
To: KASTNER at USC-ISIB, KATT at USC-ISIB,
To: UCLA-MNC at USC-ISI, ALAN at PARC-MAXC, KEENAN at USC-ISI,
To: KEHL at UCLA-CCN, KELLEY at SRI-KL, BANANA at I4-TENEX,
To: KELLOGG at USC-ISI, DDI at USC-ISI, KEMERY at SRI-KL,
To: KEMMERER at UCLA-ATS, PARVIZ at UCLA-ATS, KING at SUMEX-AIM,
To: KIRSTEIN at USC-ISI, SDC at UCLA-SECURITY,
To: KLEINROCK at USC-ISI, KLEMBA at SRI-KL, CSK at USC-ISI,
To: KNIGHT at SRI-KL, KNOX at USC-ISI, KODA at USC-ISIB,
To: KODANI at AMES-67, KOOIJ at USC-ISI, KREMERS at SRI-KL,
To: BELL at SRI-KL, KUNZELMAN at SRI-KL, PROJX at SRI-KL,
To: LAMPSON at PARC-MAXC, SDL at RAND-UNIX, JOJO at SRI-KL,
To: SDC at USC-ISI, NELC3030 at USC-ISI,
To: LEDERBERG at SUMEX-AIM, LEDUC at SRI-KL, JSLEE at USC-ECL,
To: JACOBS at USC-ISIE, WREN at USC-ISIB, LEMONS at USC-ISIB,
To: LEUNG at SRI-KL, J33PAC at USC-ISI, LEVIN at USC-ISIB,
To: LEVINTHAL at SUMEX-AIM, LICHTENBERGER at I4-TENEX,
To: LICHTENSTEIN at USC-ISI, LIDDLE at PARC-MAXC,
To: LIEB at USC-ISIB, LIEBERMAN at SRI-KL, STANL at USC-ISIE,
To: LIERE at I4-TENEX, DOCB at USC-ISIC, LINDSAY at SRI-KL,
To: LINEBARGER at AMES-67, LIPKIS at USC-ECL, SLES at USC-ISI,
To: LIS at SRI-KL, LONDON at USC-ISIB, J33PAC at USC-ISI,
To: LOPER at SRI-KA, LOUVIGNY at SRI-KL, LOVELACE at USC-ISIB,
To: LUCANIC at SRI-KL, LUCAS at USC-ISIB, DCL at SU-AI,
To: LUDLAM at UCLA-CCN, YNGVAR at SRI-KA, LYNCH at SRI-KL,
To: LYNN at USC-ISIB, MABREY at SRI-KL, MACKAY at AMES-67,
To: MADER at USC-ISIB, MAGILL at SRI-KL, KMAHONEY at BBN-TENEX,
To: MANN at USC-ISIB, ZM at SU-AI, MANNING at USC-ISI,
To: MANTIPLY at I4-TENEX, MARIN at I4-TENEX, SCRL at USC-ISI,
To: HARALD at SRI-KA, GLORIA-JEAN at UCLA-CCN, MARTIN at USC-ISIC,
To: WMARTIN at USC-ISI, GRM at RAND-UNIX, MASINTER at USC-ISI,
To: MASON at USC-ISIB, MATHIS at SRI-KL, MAYNARD at USC-ISIC,
To: MCBREARTY at SRI-KL, MCCALL at SRI-KA, MCCARTHY at SU-AI,
To: MCCLELLAND at USC-ISI, DORIS at RAND-UNIX, MCCLURG at SRI-KL,
To: JOHN at I4-TENEX, MCCREIGHT at PARC-MAXC, MCCRUMB at USC-ISI,
To: DRXTE at SRI-KA
cc: BPM at SU-AI

MCKINLEY@USC-ISIB
MMCM@SRI-KL
OT-ITS@SRI-KA
BELL@SRI-KL
MEADE@SRI-KL
MARTIN@USC-ISI
MERRILL@BBN-TENEX
METCALFE@PARC-MAXC
JMETZGER@USC-ISIB
MICHAEL@USC-ISIC
CMILLER@SUMEX-AIM
MILLER@USC-ISI
SCI@USC-ISI
MILLER@USC-ISIC
MITCHELL@PARC-MAXC
MITCHELL@USC-ISI
MITCHELL@SUMEX-AIM
MLM@SU-AI
JPDG@TENEXB
MOORE@USC-ISIB
WMORE@USC-ISIB
JAM@SU-AI
MORAN@PARC-MAXC
ROZ@SU-AI
MORGAN@USC-ISIB
MORRIS@PARC-MAXC
MORRIS@I4-TENEX
OT-ITS@SRI-KA
LISA@USC-ISIB
MOSHER@SRI-KL
MULHERN@USC-ISI
MUNTZ;BIN(1529)@UCLA-CCN
MYERS@USC-ISIC
MYERS@RAND-RCC
DRCPM-FF-FO@BBN-TENEXB
NAGEL@USC-ISIB
NAPKE@SRI-KL
NARDI@SRI-KL
NAYLOR@USC-ISIE
LOU@USC-ISIE
NESBIT@RAND-RCC
NEUMANN@SRI-KA
NEVATIA@USC-ECL
NEWBY@USC-ISI
NEWEKK@SRI-KA
NIELSON@SRI-KL
NLL@SUMEX-AIM
NILSSON@SRI-KL
NITZAN@SRI-KL
NOEL@USC-ISIC
NORMAN@PARC-MAXC
NORTON@SRI-KL
JOAN@USC-ISIB
NOURSE@SUMEX-AIM
PDG@SRI-KL
OMALLEY@SRI-KA
OCKEN@USC-ISIC
OESTREICHER@USC-ISIB
OGDEN@SRI-KA
OKINAKA@USC-ISIE
OLSON@I4-TENEX
ORNSTEIN@PARC-MAXC
PANKO@SRI-KL
TED@SU-AI
PARK@SRI-KL
PBARAN@USC-ISI
PARKER@USC-ISIB
PEARCE@USC-ISI
PEPIN@USC-ECL
PERKINS@USC-ISIB
PETERS@SRI-KL
AMPETERSON@USC-ISI
ASLAB@USC-ISIC
EPG-SPEC@SRI-KA
PEZDIRTZ@LLL-COMP
CHARLIE@I4-TENEX
UCLA-DOC@USC-ISI
WPHILLIPS@USC-ISI
PIERCY@MOFFETT-ARC
PINE@SRI-KL
PIPES@I4-TENEX
PIRTLE@SRI-KL
POGGIO@USC-ISIC
POH@USC-ISI
POOL@BBN-TENEX
POPEK@USC-ISI
POSTEL@USC-ISIB
POWER@SRI-KL
PRICE@USC-ECL
RANDALL@USC-ISIB
RANDALL@SRI-KA
RAPHAEL@SRI-KL
RAPP@RAND-RCC
RASMUSSEN@USC-ISIC
RATTNER@SRI-KL
RAY@ILL-NTX
FNWC@I4-TENEX
BRL@SRI-KL
RETZ@SRI-KL
SKIP@USC-ISIB
RICHARDSON@USC-ISIB
RICHES@USC-ECL
GWEN@USC-ECL
OP-RIEDEL@USC-ISIB
RIES@LLL-COMP
RINDFLEISCH@SUMEX-AIM
OP-ROBBINS@USC-ISIB
ROBINSON@SRI-KL
JROBINSON@SRI-KL
RODRIQUEZ@SRI-KL
MARTIN@USC-ISI
ROM@USC-ISIC
ROMIEZ@I4-TENEX
ROSE@USC-ISI
ROSEN@SRI-KL
BARBARA@I4-TENEX
ROTHENBERG@USC-ISIB
RUBIN@SRI-KL
JBR@SU-AI
RUBINSTEIN@BBN-TENEXD
RUDY@USC-ECL
RUGGERI@SRI-KA
RULIFSON@PARC-MAXC
DALE@USC-ISIB
SACERDOTI@SRI-KL
SAGALOWICZ@SRI-KL
ALS@SU-AI
SANTONI@USC-ISIC
SATTERTHWAITE@PARC-MAXC
SAWCHUK@USC-ECL
CPF-CC@USC-ISI
SCHELONKA@USC-ISI
SCHILL@USC-ISIC
SCHILLING@USC-ISI
SCHULZ@SUMEX-AIM
SCOTT@SUMEX-AIM
CPF-CC@USC-ISI
OP-SEATON@USC-ISIB
SENNE@LL
NORM@RAND-UNIX
AFWL@14-TENEX
SHEPPARD@LL-ASG
SHERWIN@USC-ISI
SHERWOOD@SRI-KL
SHORT@SRI-KL
SHORTLIFE@SUMEX-AIM
SHOSHANI@BBN-TENEX
MARTIN@USC-ISI
UCLA-NMC@USC-ISIE
SDL@USC-ISIC
SKOCYPEC@USC-ISI
SLES@USC-ISI
SLOTTOW@UCLA-CCN
NOAA@14-TENEX
SMALL@USC-ISI
DAVESMITH@PARC-MAXC
DSMITH@RAND-UNIX
SMITH@SUMEX-AIM
SMITH@USC-ECL
MARCIE@I4-TENEX
USARSGEUR@USC-ISI
LOGICON@USC-ISI
EPA@SRI-KL
SONDEREGGER@USC-ISIB
SPEER@LL
AMICON-RN@USC-ISI
SPROULL@PARC-MAXC
PROJX@SRI-KL
STEF@SRI-KA
STEFIK@SUMEX-AIM
STEPHENS@SRI-KA
CFD@I4-TENEX
STOCKHAM@SRI-KA
STOTZ@USC-ISIB
ALLEN@UCLA-SECURITY
STOUTE@MIT-ML
STRADLING@SRI-KL
STROLLO@PARC-MAXC
UCLA-0638@UCLA-CCN
CRT@SRI-KA
SUNSHINE@RAND-UNIX
SUTHERLAND@SRI-KL
SUTHERLAND@RAND-UNIX
SUTHERLAND@PARC-MAXC
SUTTON@USC-ISIC
SWEER@SUMEX-AIM
TAFT@PARC-MAXC
TAYLOR@USC-ISIB
TAYLOR@PARC-MAXC
TAYNAI@SUMEX-AIM
TEITELMAN@PARC-MAXC
TENENBAUM@SRI-KL
GREEP@RAND-UNIX
TERRY@SUMEX-AIM
TESLER@PARC-MAXC
THACKER@PARC-MAXC
PWT@RAND-UNIX
TIPPIT@USC-ISIE
TOBAGI@USC-ISIE
TOGNETTI@SUMEX-AIM
TORRES@SRI-KL
TOWNLEY@HARV-10
ELINA@UCLA-ATS
TUCKER@SUMEX-AIM
TUGENDER@USC-ISIB
LLLSRG@MIT-MC
UNCAPHER@USC-ISIB
NOSC@SRI-KL
UNTULIS@SRI-KL
MIKE@UCLA-SECURITY
AARDVARK@UCLA-ATS
UZGALIS;BIN(0836)@UCLA-CCN
VANGOETHEM@UCLA-CCN
VANMIEROP@USC-ISIB
VANNOUHUYS@SRI-KL
VEIZADES@SUMEX-AIM
VESECKY@USC-ISI
AV@MIT-DMS
VICTOR@USC-ISIC
VIDAL@UCLA-SECURITY
OP-VILAIN@USC-ISIB
RV@RAND-UNIX
SDL@USC-ISIC
VOLPE@SRI-KL
VONNEGUT@I4-TENEX
VU@SRI-KL
WACTLAR@CMU-10A
WAGNER@USC-ISI
WAHRMAN@RAND-UNIX
WALDINGER@SRI-KL
WALKER@UCLA-SECURITY
WALKER@SRI-KL
WALLACE@PARC-MAXC
EVE@UCLA-SECURITY
LOGICON@USC-ISI
DON@RAND-UNIX
WATSON@USC-ISIC
WEIDEL@USC-ECL
WEINBERG@SRI-KL
JLW@MIT-AI
LAUREN@UCLA-SECURITY
WEISSMAN@I4-TENEX
WELLS@USC-ISIC
GERSH@USC-ISI
WETHEREL@LLL-COMP
RWW@SU-AI
SCRL@USC-ISI
TWHELLER@SRI-KA
MABREY@SRI-KL
WHITE@PARC-MAXC
WHITE@SUMEX-AIM
WIEDERHOLD@SUMEX-AIM
WILBER@SRI-KL
EPG-SPEC@SRI-KA
WILCOX@SUMEX-AIM
WILCZYNSKI@USC-ISIB
WILE@USC-ISIB
OP-WILLIAMS@USC-ISIB
WILSON@USC-ISIB
TW@SU-AI
SCI@USC-ISI
WISNIEWSKI@RAND-UNIX
WOLF@SRI-KL
PAT@SU-AI
NELC3030@USC-ISI
WYATT@HARV-10
LEO@USC-ISIB
YEH@LLL-COMP
YONKE@USC-ISIB
YOUNGBERG@SRI-KA
ZEGERS@SRI-KL
ZOLOTOW@SRI-KL
ZOSEL@LLL-COMP
DIGITAL WILL BE GIVING A PRODUCT PRESENTATION OF THE NEWEST MEMBERS OF THE
DECSYSTEM-20 FAMILY; THE DECSYSTEM-2020, 2020T, 2060, AND 2060T. THE
DECSYSTEM-20 FAMILY OF COMPUTERS HAS EVOLVED FROM THE TENEX OPERATING SYSTEM
AND THE DECSYSTEM-10
COMPUTER ARCHITECTURE. BOTH THE DECSYSTEM-2060T
AND 2020T OFFER FULL ARPANET SUPPORT UNDER THE TOPS-20 OPERATING SYSTEM.
THE DECSYSTEM-2060 IS AN UPWARD EXTENSION OF THE CURRENT DECSYSTEM 2040
AND 2050 FAMILY. THE DECSYSTEM-2020 IS A NEW LOW END MEMBER OF THE
DECSYSTEM-20 FAMILY AND FULLY SOFTWARE COMPATIBLE WITH ALL OF THE OTHER
DECSYSTEM-20 MODELS.

WE INVITE YOU TO COME SEE THE 2020 AND HEAR ABOUT THE DECSYSTEM-20 FAMILY
AT THE TWO PRODUCT PRESENTATIONS WE WILL BE GIVING IN CALIFORNIA THIS
MONTH. THE LOCATIONS WILL BE:

TUESDAY, MAY 9, 1978 - 2 PM
HYATT HOUSE (NEAR THE L.A. AIRPORT)
LOS ANGELES, CA

THURSDAY, MAY 11, 1978 - 2 PM
DUNFEY’S ROYAL COACH
SAN MATEO, CA
(4 MILES SOUTH OF S.F. AIRPORT AT BAYSHORE, RT 101 AND RT 92)

A 2020 WILL BE THERE FOR YOU TO VIEW. ALSO TERMINALS ON-LINE TO OTHER
DECSYSTEM-20 SYSTEMS THROUGH THE ARPANET. IF YOU ARE UNABLE TO ATTEND,
PLEASE FEEL FREE TO CONTACT THE NEAREST DEC OFFICE
FOR MORE INFORMATION ABOUT THE EXCITING DECSYSTEM-20 FAMILY.

Ops, ecco quello che è considerato il primo messaggio di spam nella storia della rete.

Il “colpevole” è stato identificato, dato che questa email, primogenita nella stirpe dello spam, era talmente naif da lasciare in chiaro l’indirizzo da cui proveniva il messaggio, riconducibile a Gary Thuerk, della divisione marketing di DEC, il quale ha avuto la brillante idea di spedire lo stesso messaggio pubblicitario a 393 utenti di Arpanet. Eh, già, DEC aveva appena integrato il supporto per Arpanet nei nel sistema operativo TOPS-20 su DEC-20.

In realtà, a spedire l’email dall’account di Thuerk fu un ingegnere di DEC, Carl Gartley, ma poco conta.

Piccolo dettaglio. Il programma utilizzato per spedire le email, SNDMSG, poteva accettare solo 320 indirizzi, il resto finì nel corpo dell’email. Eh, beh, non sapevano ancora dell’esistenza della funzionalità “Address File” che avrebbe consentito loro di spedire tutti i messaggi senza alcun problema.

Pazienza, quelli non arrivati vennero rispediti con solerzia.

E che problema c’è? Thuerk aveva anche avvertito il suo capo che ci sarebbe stata un po’ di maretta fra i destinatari, ma non poteva immaginare le reazioni. Tanto meno quella di Stallman che, pur non avendo ricevuto l’email in questione, prima chiosò:


10-MAY-78 23:20:30-PDT,2250;000000000001
Mail-from: MIT-AI rcvd at 7-MAY-78 2316-PDT
Date: 8 MAY 1978 0213-EDT
From: RMS at MIT-AI (Richard M. Stallman)
Subject: MSGGROUP# 697 Some Thoughts about advertising
To: stefferud at USC-ISI
Redistributed-To: [ISI]Mailing.List;154:
Redistributed-By: STEFFERUD (connected to MSGGROUP)
Redistributed-Date: 8 MAY 1978

1) I didn’t receive the DEC message, but I can’t imagine I would have been bothered if I have. I get tons of uninteresting mail, and system announcements about babies born, etc. At least a demo MIGHT have been interesting.

2) The amount of harm done by any of the cited “unfair” things the net has been used for is clearly very small. And if they have found any people any jobs, clearly they have done good. If I had a job to offer, I would offer it to my friends first. Is this “evil”? Must I advertise in a paper in every city in the US with population over 50,000 and then go to all of them to interview, all in the name of fairness? Some people, I am afraid, would think so. Such a great insistence on fairness would destort everyone’s lives and do much more harm than good. So I state unashamedly that I am in favor of seeing jobs offered via whatever.

3) It has just been suggested that we impose someone’s standards on us because otherwise he MIGHT do so. Well, if you feel that those standards are right and necessary, go right ahead and support them. But if you disagree with them, as I do, why hand your opponents the victory on a silver platter? By the suggested reasoning, we should always follow the political views that we don’t believe in, and especially those of terrorists, in anticipation of their attempts to impose them on us. If those who think that the job offers are bad are going to try to prevent them, then those of us who think they are unrepugnant should uphold our views. Besides, I doubt that anyone can successfully force a site from outside to impose censorship, if the people there don’t fundamentally agree with the desirability of it.

4) Would a dating service for people on the net be “frowned upon” by DCA? I hope not. But even if it is, don’t let that stop you from notifying me via net mail if you start one.

Ma poi…


10-MAY-78 23:20:30-PDT,685;000000000001
Mail-from: MIT-AI rcvd at 9-MAY-78 1528-PDT
Date: 9 MAY 1978 1827-EDT
From: RMS at MIT-AI (Richard M. Stallman)
Subject: MSGGROUP# 698 DEC message [VERY TASTY!]
To: Stefferud at USC-ISI
CC: Geoff at SRI-KL
Redistributed-To: [ISI]Mailing.List;154:
Redistributed-By: STEFFERUD (connected to MSGGROUP)
Redistributed-Date: 9 MAY 1978

Well, Geoff forwarded me a copy of the DEC message, and I eat my words. I sure would have minded it! Nobody should be allowed to send a message with a header that long, no matter what it is about.

Forward this if you feel like it.

LOL!

Se vuoi approfondire, fai un salto da Brad Templeton.

Se la sicurezza del vostro blog vi sta a cuore come la copertina che alberga mattina e sera sul vostro divano, vi consiglio di dare un’occhiata a questa lista di plugin messa a punto da Specky boy.

Si tratta di plugin dedicati alla sicurezza in senso lato, dalla protezione dei dati, agli strumenti contro lo spam, alle login sicure.

Io mi sono limitato a tradurla liberamente. Buona lettura.

1. WordPress Database Backup (http://www.ilfilosofo.com/blog/wp-db-backup/)

URL: http://www.ilfilosofo.com/blog/wp-db-backup/
Description: Questo plugin fa proprio ciò che il nome lascia intendere, esegue il backup dell’intera installazione di WordPress. Dovrebbe essere uno dei primi plugin da installare appena create il vostro blog. Vi consente di eseguire i backup copiandoli sul vostro disco rigido, su un server o anche tramite email. Che si tratti di un plugin riottoso, un hacker (o voi stessi) a far crashare WP, WP Database Backup riporterà tutto a come avrebbe dovuto essere (prima del danno). Mi piace pensare a questo plugin come a un “WP , recupero del sistema.

2. Semisecure Login (http://jamesmallen.net)

URL: http://jamesmallen.net/2007/09/16/semisecure-login/
Description: Semisecure incrementa la sicurezza della componente di Login di WP, utilizzando una crittazione lato client delle password in MD5 (vabbé, MD5 è un hash…). Affinché la criptazione possa venire eseguita è necessario che che il navigatore supporti JavaScript. Quando il supporto JavaScript non è disponibile, la password viene trasmessa in chiaro (come succede normalmente), ma l’autenticazione procede senza alcun ostacolo.

3. AskApache Password Protect (http://www.askapache.com)

URL: http://www.askapache.com/wordpress/htaccess-password-protect.html
Description: Questo plugin renderà più sicuro l’accesso alla console di amministrazione di WP tramite l’utilizzo di htaccess per la gestione delle password, impedendo agli indesiderati bot l’ingresso al vostro sito.

4. Force SSL (http://almosteffortless.com/)

URL: http://almosteffortless.com/wordpress/force-ssl/
Description: Se avete un certificato SSL, il plugin Force SSLFor forzerà le connessioni su HTTPS per garantire una migliore sicurezza. Ciò è utile per coloro che vogliono assicurare un maggiore livello di sicurezza per la veicolazione dei contenuti al navigatore.

5. WP Security Scan (http://wordpress.org/extend/plugins)

URL: http://wordpress.org/extend/plugins/wp-security-scan/
Description: Adoro questo plugin, che scandisce il vostr osito alla ricerca di problemi di sicurezza e controlla password, permessi sui file e messa in sicurezza del database, nascondendo anche la versione di WP e proteggendo/rendendo sicuro l’admin di WP. Mi rende anche un po’ paranoico.

6. Secure Files (http://wordpress.org/extend/plugins)

URL: http://wordpress.org/extend/plugins/secure-files/#post-271
Description: Questo plugin vi consente di caricare e scaricare file al di fuori della document root del vostro sito web, per motivi di sicurezza. Quando viene utilizzato insieme a un plugin che richiede all’utente di essere loggato per poter leggere le pagine del vostro sito, potete limitare i donwload agli utenti loggati.

7. WP-SpamFree (http://www.hybrid6.com/)

URL: http://www.hybrid6.com/webgeek/plugins/wp-spamfree
Description: Ho sentito parlare parecchio di questo plugin prima di provarlo e si dice che sia meglio di Akismet. In tutta onestà, non ho mai notato molta differenza (ho 500 messaggi di spam al giorno, in questo periodo) fra i due. Penso sia solo una questione di scelta dell’utente. Speravo ci fosse invece un modo per fermare gli spammer.

8. BackUpWordPress (http://wordpress.designpraxis.at)

URL: http://wordpress.designpraxis.at/plugins/backupwordpress/
Description: Quasi identico al primo plugin, solo non altrettanto semplice. La lista di funzionalità è lunga ed è indicata per un WP Pro. Alcune funzionalità: backup del database, inclusi i file caricati, i plugin, etc; notifica via email dei nuovi backup; backup lanciabili manualmente, possibilità di pianificare i backup, di eseguire restore, importazioni scaglionate di SQL; prosecuzione in background dei backup non terminati; Supporto lingue. (E questo solo per la modalità Easy, aspettate di vedere quella avanzata).

9. Anonymous Wordpress Plugin Updates (http://f00f.de/)

URL: http://f00f.de/blog/2007/10/02/plugin-anonymous-wordpress-plugin-updates.html
Description: Anonimizza il sistema di controllo degli aggiornamenti dei plugin, una nuova funzionalità introdotta in WordPress 2.3. Il plugin impedisce a WordPress di inviare una lista di plugin attivi, l’url del blog e la versione di WordPress. Ideale per gli amministratori consapevoli delle implicazioni relative alla privacy di una installazione WordPress.

10. Replace WP-Version (http://wordpress.org/extend/plugins/)

URL: http://wordpress.org/extend/plugins/replace-wp-version/#post-2859
Description: (Abbiamo tutti letto del problema di sicurezza derivato dal mostrare la propria versione di WP, questo plugin lo risolve). Se state utilizzando una versione più vecchia di WordPress, chiunque può vedere i sorgenti per capire quali attacchi possono funzionare contro il vostro blog. Questo plugin rimpiazza l’informazione relativa alla versione di WP con una stringa casuale per le versioni < 2.4 e la elimina per le versioni > 2.4.

[Via The Fucking Shit]

Vediamo un po´…

Ieri sera ho messo l´eeepc sul comodino, configurato Pidgin con i miei account ICQ, MSN, Jabber, ho installato e configurato Skype 2, installato e configurato Amarok.

Poi, cosa ho fatto? Ho chiamato Wolly e abbiamo chiacchierato su Skype, guardandoci alla luce di una abat jour grazie alla webcam dell´eeepc.

Mentre eravamo in video conferenza, ho messo un po´ di musica classica in streaming da Last.fm, tramite Amarok, mentre con Firefox davo un´occhiata ai miei feed su Bloglines, seguendo nel contempo le facezie che passavano su Twitter.

Nel frattempo, Nikto si macinava il sito di Wolly per scovare qualche security risk .

Dopo un´ora di chiacchiere, rigorosamente in batteria e in wireless, la batteria riportava 1:50 di autonomia rimanente. Ci credo poco, ma tant´é…

Alla fine, ho salutato Wolly, lasciato Nikto a macinare, sprimacciato i cuscini e mi sono messo beatamente a dormire, soddisfatto di queste prime prove.

In pratica, ho fatto tutto quello che faccio di solito con il mio Asus A7Jc, solo con 3,5 Kg. in meno e molti meno pollici.

Come ci si giostra con un 7´´? Giudicate voi…

Ah, ovviamente questo post é stato scritto dall´eeepc. Ovviamente.

Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN), è un protocollo leggero che consente alle applicazioni di scoprire la presenza e la tipologia di NAT e firewall (frapposti, ndt) tra loro e l’Internet pubblica. Fornisce inoltre alle applicazioni la capacità di determinare gli indirizzi pubblici del Protocollo Internet (IP) loro allocati dal NAT. STUN funziona con molti tipi di NAT e non richiede da parte loro alcun tipo di comportamento speciale. In forza di ciò, consente a un’ampia gamma di applicazioni di funzionare attraverso l’infrastruttura NAT (pre)esistente.

E’ con l’abstract della RFC 3489 che riprendiamo in mano il filo del discorso intrapreso nella prima parte di questa lunga digressione, focalizzando fin da ora quale sia lo scopo pratico per il quale viene utilizzato il protocollo STUN (RFC 3489): consentire alle applicazioni che facciano uso di pacchetti UDP (STANDARD 00006) l’attraversamento di firewall e NAT (Network Address Translation - RFC 3022). Non si pensi, però, che STUN sia la soluzione a qualsiasi problema incontrato da un’applicazioni che sia segregata da un firewall o da un NAT. Tutt’altro, come viene ben evidenziato dal primo paragrafo della RFC 3489:

Questo protocollo non è una panacea per i problemi associati al NAT. Non consente connessioni TCP (STANDARD 00001) in entrata attraverso il NAT. Permette l’attraversamento del NAT in entrata per i pacchetti UDP, ma solo attraverso un sotto insieme dei (diversi ndt) tipi di NAT esistenti. In particolare, STUN non consente pacchetti UDP in entrata attraverso NAT simmetrici (definiti in seguito), comuni nelle grandi aziende. Le procedure di scoperata adottate da STUN sono basate sulle assunzioni (derivate, ndt) dal modo in cui NAT tratta UDP; queste assunzioni possono risultare non valide nella pratica nel momento in cui vengono introdotti nuove periferiche NAT. STUN non funziona quando viene utilizzato per ottenere un indirizzo (utile a, ndt.) comunicare con un nodo che sia dietro lo stesso NAT. STUN non funziona quando il server STUN non è nello stesso reame di indirizzi comuni condivisi. Per una discussione più completa discussione dei limiti di STUN, vedere la Sezione 14.

Tutto il discorso ruota quindi intorno al gioco di “invisibilità” introdotto dal NAT, specialmente quello simmetrico, come risulta evidente dalla definizione di quest’ultimo data nella prima parte di questo post:

Symmetric: Un Symmetric NAT è qualcosa di “unico”: come nel full nat, una connessione originata da una IP/PORTA interna verso un IP/PORTA esterna avrà una mappatura IP/PORTA pubblica sull’interfaccia esterna del router. La differenza risiede nella destinazione e nella “dinamicità” del mapping: ogni volta che o l’IP o la PORTA di destinazione cambiano, verrà utilizzato un mapping diverso sull’interfaccia esterna del router, ovvero una differente combinazione IP/PORTA pubblica. In più, solo l’host esterno che riceve un pacchetto può replicare con un pacchetto UDP verso l’host con indirizzo privato. Questa è una configurazione tipica di una rete aziendale.

E’ un po’ come il gioco della talpa in cui i pacchetti in uscita da un client dietro NAT simmetrico escono di volta in volta da una buca diversa, anche se si tratta sempre della stessa comunicazione, dello stesso soggetto emittente. In questo scenario, il NAT non è in grado di informare gli estremi di una comunicazione dei reali indirizzi e porte assunti da ognuno di questi nel corso di una stessa comunicazione, associazioni dinamiche e mutevoli. E sebbene siano state proposte linee guida per l’implementazione di protocolli NAT safe (RFC 3235), alcune fra le applicazioni più comuni non sono in grado di funzionare all’interno di un NAT. Perché diamo insieme un’occhiata ad alcuni passi della RFC 3235:

Con il NAPT (Network Address Port Translation, ndt), sia gli (indirizzi, ndt) IP che le porte di partenza e di arrivo (di un circuito di dati, ndt) (per TCP e UDP) vengono potenzialmente alterate dal gateway. Stante ciò, le applicazioni che passano solo l’informazione relativa al numero della porta (utilizzata per la connessione a un altro client o server, ndt) funzioneranno con il NAT di base, ma non con il NAPT.

E’ la differenza fra il NAT di base e il NAPT a giocare un ruolo fondamentale. Nel primo, viene alterato dal gateway (solitamente il firewall) unicamente l’IP con cui il client interno viene presentato sulla rete pubblica, mentre con il secondo viene modificato anche il numero di porta utilizzato per la connessione. Ed è sotto questa tipologia, il NAPT, che ricade il NAT simmetrico. Quali sono le tipologie di applicazioni che sono più inclini a non funzionare all’interno di un NAT simmetrico?

• Applicazioni Peer To Peer. Questo tipo di servizi vedono gli estremi di una connessione coinvolti in una rete in cui i client sono nello stesso tempo server. Per ciò che ci interessa ai fini di questa discussione, la differenza fra un client e un server può essere esemplificata nel seguente schema:
  • Un client genera una connessione verso l’esterno. Non si attende di ricevere una connessione originata dall’esteno a lui diretta;
  • Un server attende una connessione originata dall’esterno, alla quale rispondere. Un server, quindi, rimane in ascolto (binding) su una tupla IP/PORTA, che sarà il punto di arrivo di una connessione iniziata da un client.

  In questo scenario, in cui il client è anche server, un NAT simmetrico che prevede una mappatura dinamica degli IP e delle porte ostacola la raggiungibilità univoca dei servizi: dietro al NAT potrebbero esservi una moltitudine di client che di volta in volta assumono la tupla IP/PORTA del client/server i cui servizi si vorrebbe raggiungere;

• Applicazioni che richiedono l’utilizzo del protocollo IPSec (Internet Protocol Security, RFC 2401) in modalità end-to-end. I presupposti per cui non può essere utilizzato IPSec quando uno dei due estremi della connessione è all’interno di un NAT sono simili, come viene evidenziato nella RFC 2709, dedicata all’implementazione di IPSec in modalità tunnel combinata con il NAT :
  • Le applicazioni che incorporano informazioni inerenti al reame (di indirizzi privati, ndt) nel payload richiederanno un application level gateway (ALG), affinché il payload abbia senso in entrambe i reami. Tuttavia, le applicazioni che richiedono l’ausilio di un ALG per il routing non possono conseguire una sicurezza end-to-end a livello di applicazione.

Torniamo alla RFC 3235, per capire il perché di questa limitazione:

Le applicazioni dovrebbero, quando possibile, usare dei nomi a dominio pienamente qualificati (FQDN, ndt), piuttosto che gli indirizzi IP, quando fanno riferimento a punti finali (gli estremi di una comunicazione, ndt) IP. Applications should, where possible, use fully qualified domain names. Quando gli estremi sono posti su lati diversi di un gateway NAT, agli indirizzi privati non deve essere consentito di raggiungere l’altro estremo (della connessione, ndt).

Una ragione per questa limitazione viene fornita dalla stessa RFC 3235:

Ad aggravare ulteriormente il problema è la possibilità che vi siano indirizzi duplicati fra i due reami. Se un server offre un collegamento contenente un indirizzi IP privato, tipo 192.168.1.10, la pagina referenziata (si sta facendo riferimento, come esempio, a un server web che offra collegamenti a pagine poste su macchine all’interno del suo reame di indirizzi privati, ndt.) la pagina referenziata può risolvere a un sistema sulla rete locale sul quale si trova il browser (che evidentemente si trova su un altro spazio di indirizzi privati, ndt), ma questo sarebbe un server completamente differente. La confusione che ne risulterebbe per gli utenti finale sarebbe significativa. Le sessioni che coinvolgono implementazioni multiple del NAT (nell’esempio il server web è su una reta in NAT, il client su una diversa rete in NAT), sarebbero eccezionalmente vulnerabili a problemi di riutilizzo di indirizzi di questo tipo.

Per capire intuitivamente il problema, diamo un’occhiata al seguente diagramma: Notato qualcosa? In effetti le due reti private hanno, possono avere, la stessa classe di indirizzi, anche lo stesso subnetting, il che porta a uno spiacevole equivoco nel routing dei pacchetti. Se il client .5 della prima rete (quella più in alto nello schema) richiede al web server 192.168.1.10 della rete più in basso una pagina che si trova su una macchina nella stessa sotto rete del server, 192.168.10.5, il server istruirà il client della prima rete a chiedere una pagina alla macchina 192.168.1.5. Ora, attenzione a ciò che viene detto nella RFC 1918:

Un’azienda che decida di utilizzare indirizzi che non facciano parte dello spazio di indirizzamento definito in questo documento (ovvero voglia utilizzare indirizzi privati, ndt), può farlo senza alcun coordinamento con lo IANA o un Internet registry. Lo spazio di indirizzamento può essere così utilizzabile da molte aziende. Gli indirizzi all’interno di questo spazio privato di indirizzamento saranno unici solo al’interno dell’azienda, o del gruppo di aziende che scelgano di cooperare in questo spazio in modo da comunicare l’una con l’altra all’interno della loro internet privata.

Cosa significa?

Semplicemente che chiunque, al di qua di un router, può utilizzare per la connettività interna alla propria rete degli indirizzi privati, senza alcun coordinamento con le autorità che gestiscono le numerazioni pubbliche. Al contempo, però, gli indirizzi privati non sono “routabili”, ovvero non possono uscire al di là del gateway che collega la rete privata, per esempio una rete aziendale o domestica, a internet.

Tutto ciò porta a due considerazioni interessanti:

1. L’orizzonte di visibilità di un indirizzamento privato ha come proprio limite il gateway di rete. Semplificando, le macchine possono vedere gli indirizzi privati solo fino al router, al di fuori del quale non hanno cognizione di altri indirizzamenti privati. Quindi, 192.168.1.5 significa una precisa macchina nella stessa rete del client che sta cercando di interrogarla, non su qualche altra rete privata remota;
2. Più reti private possono utilizzare gli stessi indirizzamenti privati, senza che questo porti a un qualche equivoco. L’indirizzo 192.168.1.5 è “qui”, all’interno della prima rete, per le altre macchine della stessa rete, ma è “qui” anche per le macchine della seconda rete, con due “qui” differenti ma coerenti, ognuno all’interno del proprio spazio di indirizzamento privato.

Date queste premesse, uno sguardo allo schema precedente rende bene l’idea del problema: se il client 192.168.1.5 della prima rete interroga un web server sulla seconda rete, chiamando il suo indirizzo pubblico, e questo rimanda a un collegamento a una macchina con indirizzo 192.168.1.5 nella propria sotto rete, qui, proprio qui, sorge un equivoco: il client 192.168.1.5 della prima rete si vedrà istruire dal web server della seconda rete a cercare una risorsa all’indirizzo 192.168.1.5. Il problema risiede nella limitatezza dell’orizzonte: il server intende puntare alla macchina 192.168.1.5 sulla seconda rete, ma per il client della prima rete 192.168.1.5 ha senso solo nella propria rete. Ergo, il client tenta di interrogare se stesso alla ricerca di una risorsa che è presente solo sulla rete privata remota.

Ecco l’equivoco: ognuno interpreta gli indirizzi privati “a casa propria”, non vede, non conosce altro che non sia sulla propria rete.

Una delle metologie approntate come ausilio per quelle applicazioni che non possono nativamente operare attraverso un NAT è l’Application Level Gateway (ALG), agenti in grado di interfacciarsi con i gateway NAT e consentire ai programmi in funzione su un host di contattare la propria controparte su un host appartenente a un reame di indirizzi differenti. L’implementazione di un ALG può differire notevolmente di situazione in situazione, ponendosi in dialogo diretto con il gateway NAT per gestire gli stati delle connessioni, modificare il payload dei pacchetti per riscrivere la mappatura degli indirizzi e, comunque, garantire tutte quelle operazioni necessarie a mettere in comunicazione servizi appartenenti a reti differenti (end-to-end). Questo tipo di soluzione ha un indubbio vantaggio: non richiede alcuna modifica ai client, ponendosi in maniera del tutto trasparente tra le applicazioni e il NAT. Di contro, la sua implementazione pone dei problemi soprattutto per quanto riguarda la scalabilità e affidabilità di esercizio.

Una soluzione più interessante è rappresentata dallo sviluppo del Middlebox Communications (MIDCOM) protocol (RFC 3304), un protocollo che consente, tramite l’utilizzo di agenti, connessioni fidate (trusted) con le Middlebox (RFC 3303).

Messa in questi termini, la questione appare inintellegibile.

Prima di tutto, cosa è una Middlebox?

In sostanza, si tratta di un apparato di intermediazione di rete che implementa un servizio, come per esempio un NAT o un firewall, ma con una particolarità che lo rende unico rispetto a un tradizionale firewall o NAT: è in grado di delegare in parte o tutta la logica di funzionamento dell’apparato a uno o più agenti MIDCOM.

Ora, pensate a un’applicazione in grado di utilizzare un agente MIDCOM per controllare un NAT e gestirne dinamicamente le funzionalità, in modo da aprirsi dei varchi per consentire le comunicazioni end-to-end tra reami di indirizzamento differenti.

A questo punto, gli intermediari di rete diventano flessibili, si adattano alle esigenze delle applicazioni, superano le rigidità imposte dai protocolli.

Interessante, vero?

Interessante ma poco fattibile. Una rete MIDCOM aware implica la sostituzione degli apparati tradizionali con le nuove versioni in grado di supportarne il protocollo e, specialmente in ambienti enterprise ciò implica un investimento e un grado di ristrutturazione non sempre affrontabili. Inoltre, vi sono casi in cui gli agenti MIDCOM non possono avere visibilità su tutti gli apparati di rete coinvolti, come nell’esempio citato nella RFC 3489: molti provider utilizzano un NAT sulle linee dei clienti residenziali, i quali a loro volta usufruiscono di un secondo NAT sulla loro rete privata. Se l’utente finale può avere visibilità e controllo su una middlebox MIDCOM nella rete privata, agli agenti installati sulle loro macchine non sarà dato alcun controllo sulle middlebox che gestiscono il NAT direttamente sulle infrastrutture del provider stesso.

E’ chiaro che una soluzione univoca per ogni possibile scenario è difficilmente applicabile, per differenti ordini di motivazioni: costi, flessibilità, sicurezza, il che lascia uno spazio progettuale per soluzioni specifiche, pensate e sviluppate per facilitare il funzionamento di singoli protocolli all’interno di ambienti in NAT.

STUN è proprio questo, in termine burocratese è un “facilitatore”, ma questo sarà l’argomento della terza puntata di questo lungo post.