Spam, il sorpasso

Era previsto ed è forse inevitabile, ma sapere che più della metà delle email che arriva sul posto di lavoro è spam è inquietante. Contro lo spam si rincorrono le tecnologie e qualcuno spera nella taglia sugli spammer


Roma – Più del 50 per cento delle email che arrivano sul posto di lavoro è spam. Questo il dato che emerge dalle rilevazioni per il mese di maggio di MessageLabs, società di sicurezza da anni in prima fila nell’analisi dell’espansione dello spam sui network di tutto il mondo.

Secondo MessageLabs alle imprese che fanno parte del proprio panel di rilevazione sono arrivate nel mese di maggio 133,9 milioni di email. Di queste più della metà (il 51 per cento) è stato considerato spam, cioè messaggi di posta elettronica non desiderati.

Il sorpasso, come viene definito questo dato atteso e previsto da un certo tempo, è testimonianza di costi sempre più elevati che vengono affrontati dai fornitori di connettività e in generale dai manutentori dei network a causa dello spam.

In questi anni sono molti i paesi, come l’Italia, che si sono dotati di infrastrutture normative atte a respingere lo spam, perlomeno quello prodotto all’interno del paese, ma sono molti di più i paesi in cui nulla si è fatto. E ve ne sono alcuni nei quali prosperano server e servizi utilizzati da spammer di tutto il mondo, spesso con la connivenza di provider che operano anche su mercati nei quali lo spam è malvisto o fuorilegge.

In quanto alle tecnologie antispam sono sempre di più i produttori di sistemi di sicurezza e filtraggio che consentono tanto agli utenti quanto ai fornitori di servizi di difendersi dallo spam ma, come appare evidente dai dati di MessageLabs, si è ancora ben lontani dal definire un risultato. La stessa MessageLabs in passato aveva predetto scenari terrificanti per lo spam che, se non fermato, potrebbe mettere a rischio l’utilità stessa della posta elettronica.

Oltre ai prodotti sul mercato è di interesse la proposta antispam di Lawrence Lessig, celebre professore americano di cyberlaw, una proposta che punta a mettere una taglia sulla testa degli spammer…

Per seguire da vicino la questione spam è a disposizione il Canale Spam di Punto Informatico.

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Anonimo scrive:
    Esperienza pratica
    Dalle nostre prove pratiche Java è veloce quanto il C++. E' particolarmente vero se si sfruttano pesantemente modelli ad oggetti (tra l'altro tipici nei sistemi di simulazione e nei videogiochi). Il JIT traduce il byte code in codice macchina nativo e lo memorizza in RAM. Questo ne velocizza l'esecuzione ma ne penalizza l'occupazione di memoria (ma tanto la RAM costa poco). Invece sono veramente lente le classi Swing (interfaccia utente). Penso sia poprio questo il motivo che fa percepire Java come un sistema lento. A questo proposito si può provare Eclipse, un IDE open source non basato su Swing. Se la RAM è abbondante dopo un po' di minuti di esecuzione è indistinguibile da un sistema di sviluppo nativo.
    • avi74 scrive:
      Re: Esperienza pratica
      Quanto affermato non e' convalidato da niente e nessuno.Come faccia un programma scritto con un linguaggio interpretato, o meglio precompilato, anche se ottimizzato con un compilatore JIT, ad avere le stesse performance di un linguaggio compilato... e' un mistero. A me non sembra affatto scientifico. Se invece si voleva dire che le differenze di velocita' sono trascurabili, beh, allora si dovrebbe dire in quale ambito, con quale tipo di applicazione, con quale macchina virtuale, su quale processore, fornire dei dati.Di fatto un programma Java e' piu' lento, e lo sara' sempre, di un programma scritto in un linguaggio compilato, a parita', si intende, di soluzioni algoritmiche. Affermare il contrario sarebbe come dire:if(1 < 0) cout
  • Anonimo scrive:
    reale analisi
    riguardo all'analisi fatta nell'universita' danese guardate almeno i grafici al link http://www.rolemaker.dk/articles/evaljava/Java%20Evaluation.zipsono interessanti in quanto dimostrano come l'informazione che passata sin'ora sia almeno parzialmente distorta nel senso che, per quanto evidenzi come alcune soluzioni siano piu' performanti di altre, mette anche in chiaro come l'ordine di grandezza sia comunque pressoche' quellochiunque abbia studiato un minimo di analisi dei tempi di calcolo del software sa bene che non e' importante se un algoritmo richiede un ciclo di cpu in piu' o in meno ma conta come crescono le richieste al crescere dell'inputper chi e' meno del ramo faccio un esempio se io ho 2 meccanismi che per fare un calcolo impiegano un tempo x*x+1 e l'altro x*x+100 (dove x e' la "grandezza" del mio input), e' vero che per x piccoli il primo e' piu' performante, ma per x grandi si vede come la differenza non sia influente (se ho x=1000 diventano 1000001 e 1000100 ossia una differenza minore del 0,1%)se parliamo di una applicazione allora non si tratta di una esecuzione di una procedura con un solo input, ma generalmente di una grossa serie di esecuzioni con input "grossi"in altre parole, almeno per l'analisi di java in questo contesto, la differenza c'e' ma non conta
    • avi74 scrive:
      Re: reale analisi
      Direi che non significa nulla. Se intendi dire che valutando la complessita' di due algoritmi O(n^2), non hanno alcuna rilevanza i termini "+1" e "+100", ti rispondo, hai ragione, ma che ci azzecca Java e C++? Non si stanno confrontando soluzioni e design del software, ma soltanto l'efficienza, intesa come consumo delle risorse (CPU, memoria, banda etc.), di due software identici dal punto di vista di design e algoritmi, scritti pero' con linguaggi diversi.
  • wergio scrive:
    Evaluating Java for Game Development
    Alcuni dati scaturiti da una lavoro inerente un dottorato di riceca pressao un'università in danimarcahttp://www.rolemaker.dk/articles/evaljava/ciao
    • Anonimo scrive:
      Re: Evaluating Java for Game Development
      Se non leggo male:Here we see that the fastest Java version is approximately 3 times slower than thefastest C++ version.? Nothing is gained in this case by using a static compiler like Jet over a Hotspot VM.? The IBM JVM is in this case no faster than the Sun Hotspot JVMs. This is a bitsurprising since it generally has the reputation of being the overall fastest JVMavailable.? It is the Java 1.4 client that is the fastest JVM. This is surprising since we wouldnormally have expected the Sun server JVM to be the faster of the two.
  • Anonimo scrive:
    Per maggiori informazioni
    Vi consiglio di visitare wirelessgaming.it, dove troverete anche alcuni speciali che parlano più approfonditamente del linguaggio J2ME e dei giochi che vi girano.
    • Anonimo scrive:
      Re: Per maggiori informazioni
      - Scritto da: Anonimo
      Vi consiglio di visitare wirelessgaming.it,
      dove troverete anche alcuni speciali che
      parlano più approfonditamente del linguaggio
      J2ME e dei giochi che vi girano.Naaa, non funziona bene, preferisco aspettare l'uscita di J2XP :) :) rotfl che (troll)ata di classe :)
  • Anonimo scrive:
    Per gli scettici
    IL2 Sturmovik e IL2 Forgotten Battles, due dei migliori simulatori di volo sulla seconda guerra mondiale (e prossimamente ci sarà anche un simulatore con aerei odierni) sono realizzati con tecnologia Java e OpenGL. E il simulatore è notevolmente più veloce e graficamente accattivante di tutti i concorrenti (Flight Simulatori, Fly 2, Combat Flight Sim, X-Plane) e come X-Plane utilizza veri modelli aerodinamici piuttosto che 4 parametri che definiscono come si comporta il tuo aereo.E cose come la definizione della struttura interna dell'areo su cui è montata la fusoliera (che si stacca a frammenti se ti colpiscono e si buca) e le sollecitazioni meccanico-fisiche dovute alle manovre acrobatiche (con tanto di suoi iperrealistci), nonché i piloti che si muovono nella cabina del loro aereo (e ti fanno pure i gestacci!) non sono cosa da tutti i simulatori...Eppure è Java e a differenza di molti concorrenti gira ottimamente anche sul mio Athlon 850...
  • Anonimo scrive:
    Ahahah
    "negli ultimi anni Java è divenuto un linguaggio estremamente veloce e ottimizzato e perfettamente in grado di gestire grafica anche molto complessa".Almeno ne sono convinti... Senza offesa per Java ma se ci cercano prestazioni Java è l'ultima cosa da scegliere....
    • Anonimo scrive:
      Re: Ahahah

      Almeno ne sono convinti... Senza offesa per
      Java ma se ci cercano prestazioni Java è
      l'ultima cosa da scegliere..se si ha una cpu che interpreta il byte code, java e' veloce...
      • nop scrive:
        Re: Ahahah
        - Scritto da: Anonimo

        Almeno ne sono convinti... Senza offesa
        per

        Java ma se ci cercano prestazioni Java è

        l'ultima cosa da scegliere..

        se si ha una cpu che interpreta il byte
        code, java e' veloce...Prima scrivevi software per girare su una CPU...Adesso progetti la CPU per poter far girare il codice...Eh.... i tempi cambiano......
        • Anonimo scrive:
          Re: Ahahah
          Forse e' quello che hanno fatto M$ e Intel per una decina di anni a sta parte??
          • nop scrive:
            Re: Ahahah
            - Scritto da: Anonimo
            Forse e' quello che hanno fatto M$ e Intel
            per una decina di anni a sta parte??Non mi risulta che Intel ha in programma un Itanium.NET.....
        • Anonimo scrive:
          Re: Ahahah

          Prima scrivevi software per girare su una
          CPU...
          Adesso progetti la CPU per poter far girare
          il codice...

          Eh.... i tempi cambiano......guarda che mica scherzavo.esistono gia' cpu che possono far girare nativamente codice bytecode java.
          • nop scrive:
            Re: Ahahah


            guarda che mica scherzavo.
            esistono gia' cpu che possono far girare
            nativamente codice bytecode java.Lo so che esistono ... ed infatti il mio post affermava proprio quello.Tra un po arriverà il Pentium.NET.......:-)))
      • avi74 scrive:
        Re: Ahahah
        Hanno provato a fare qualcosa, ma progettare una CPU che utilizzi il bytecode Java (l'hai visto? e' un bytecode ad alto livello, non semplice da realizzare su silicio, e certamente costoso) non credo sia logico.
    • Anonimo scrive:
      Re: Ahahah
      - Scritto da: Anonimo

      "negli ultimi anni Java è divenuto un
      linguaggio estremamente veloce e ottimizzato
      e perfettamente in grado di gestire grafica
      anche molto complessa".


      Almeno ne sono convinti... Senza offesa per
      Java ma se ci cercano prestazioni Java è
      l'ultima cosa da scegliere....Vero ha tantissimi pregi specialemnte lato server, ma scriverci giochi mi sermbra un po azzardato ma se questo contribuira' ad ottimizzare la JVM e l'interpretazione del byteCode ben venga ;-)
    • FDG scrive:
      Re: Ahahah
      - Scritto da: Anonimo
      Almeno ne sono convinti... Senza offesa per
      Java ma se ci cercano prestazioni Java è
      l'ultima cosa da scegliere....Non è importante se è il più veloce, ma se è veloce abbastanza. Anche perché la velocità non è tutto.
      • Elwood_ scrive:
        Re: Ahahah
        - Scritto da: FDG
        - Scritto da: Anonimo


        Almeno ne sono convinti... Senza offesa
        per

        Java ma se ci cercano prestazioni Java è

        l'ultima cosa da scegliere....

        Non è importante se è il più veloce, ma se è
        veloce abbastanza. Anche perché la velocità
        non è tutto.ma ANCORA CON STA PRESUNTA VELOCITA' DEI PROCESSORI?ah ma allora ci sono i furbi che si comprano l'ultimo processore?attualmente il processore che usi tra un interrupt e un altro, si sciaqua i cybertesticoli!Ma quale velocità andate blaterando?date un occhiatina all'architettura degli interrupt.poi ne discutiamo...ah aspe come dicono molto "performante", sta kaz di parola che la usano sempre quelli che parlano a sproposito.per quello che ci fai tu un pentium 4 a un 1GHZ basta e avanzica.ma vi bevete tutto quello ce vi dice la intel e la AMD?CIAUZ
        • FDG scrive:
          Re: Ahahah
          - Scritto da: Elwood_
          ma ANCORA CON STA PRESUNTA VELOCITA' DEI
          PROCESSORI,,,Che ti sei fumato oggi? Non hai capito un tubo di quello che ho detto.
          • Elwood_ scrive:
            Re: Ahahah
            - Scritto da: FDG
            - Scritto da: Elwood_


            ma ANCORA CON STA PRESUNTA VELOCITA' DEI

            PROCESSORI,,,

            Che ti sei fumato oggi? Non hai capito un
            tubo di quello che ho detto.aho mi sembrava che ce l'avevate co sta storia dei processori... è vero commento mio inutile e offo topikequindi mi autosilenzio per vergogna:-)
  • Anonimo scrive:
    Mah . . .
    Personalmente adoro Java ma pensarlo come linguaggio di sviluppo per videogiochi mi sembra molto difficile . . . staremo comunque a vedere
    • Anonimo scrive:
      Re: Mah . . .
      - Scritto da: Anonimo
      Personalmente adoro Java ma pensarlo come
      linguaggio di sviluppo per videogiochi mi
      sembra molto difficile . . . staremo
      comunque a vedereConsidera che molti engine usano internamente linguaggi interpretati come supporto per lo sviluppo dei giochi.
      • Anonimo scrive:
        Re: Mah . . .
        Gia', ma virtual machine != interprete ...
        • Anonimo scrive:
          Re: Mah . . .
          - Scritto da: Anonimo
          Gia', ma virtual machine != interprete ...La virtual machine è un interprete di bytecode.
          • Anonimo scrive:
            Re: Mah . . .
            - Scritto da: Anonimo
            - Scritto da: Anonimo


            Gia', ma virtual machine != interprete ...

            La virtual machine è un interprete di
            bytecode.Beh, e' un po limitativa come definizione... Molta parte del codice viene compilata/ottimizzata e diventa codice nativo...
      • avi74 scrive:
        Re: Mah . . .
        Sono linguaggi interpretati si, ma non sono linguaggi general purpose, sono linguaggi ad hoc per l'engine del gioco. Inutile dire che a quel punto il gioco vale la candela. Ma non e' un discorso che puoi applicare a Java.
Chiudi i commenti