Newsgroup: it.cultura.cybersocieta
Titolo: Re: Web editor

 o filtrata bene contro lo spam
Quanto spam ricevi con la tua del Reply-to? (Non è una domanda 
retorica: la stessa fu posta da un altro utente insistentemente a Mamo 
un po' di tempo fa, purtroppo senza risposta, così mi è rimasta la 
curiosità
Xpost e Fup2
-- 
Ciao, DOCstone

 curiosità
Dunque, benché Gmail non faccia molto testo, perché a volte gli
indirizzi gmail sono esposti a bombardamenti di spam da centinaia di
email nel giro di poche ore (peraltro i filtri di gmail funzionano
ottimamente), su questo indirizzo attualmente ho 571 messaggi di spam
accumulatisi dal 31 ottobre. In questo totale 200 sono arrivati negli
ultimi tre giorni. Considera che ho notato flussi simili anche su altri
indirizzi Gmail mai esposti su usenet e nemmeno tutti usati per mailing
list.
-- 
yo| icq: 197-276-683
bb| msn: 
bubba....@gmail.com

 che il provider possa facilmente filtrarlo. O no?
Potrebbe essere un'idea, però IMHO più semplicemente basta falsificare
(anche) la parte a destra della chiocciola in modo che l'indirizzo non
corrisponda a un provider esistente (oltre ad aggiungere il suffisso
.invalid alla fine).
Per esempio, se pippo ha l'indirizzo pippo * 
example.org
potrebbe falsificarlo in
 pippo * example.org.PUSSAVIA.INVALID
che nessuno potrà registrare.

 mailing list.
Io invece l'indirizzo del From lo uso da oltre 2 anni e ricevo 1 
massimo 2 messaggi di spam al giorno. Prima o poi la dovrò cambiare 
perché  l'antispam è a pagamento.
-- 
Ciao, DOCstone

 rimasta la curiosità
Mi pareva avesse risposto, comunque rispondo anche io: mediamente 
ricevo una email di spam a settimana. Più o meno.
-- 
Ciao, Massimo | Jabber: 
pet...@jabber.linux.it
http://www.stambugia.com/blog/
 | ICQ: 57669970
«Ma poi, è proprio obbligatorio essere qualcuno?»

 travalica) lo spam propriamente detto.
Sarei il primo ad essere felice se non fosse più necessario ripetere 
sempre le stesse cose...


 ricevo una email di spam a settimana. Più o meno.
Ma hai il munging nel Reply-to oppure no?
-- 
Ciao, DOCstone

 perché  l'antispam è a pagamento.
Se vuoi un consiglio, un buon provider free italiano con filtri antispam
efficaci è 
people.it
, se non hai esigenze di spazio per gli allegati (la
mailbox ha capacità - mi pare - fino a 3,5 MB) è ottimo.


 antispam efficaci è 
people.it
Ti ringrazio, penso che passerò a google anche per i ng; già lo uso 
come indirizzo ufficiale anche sui biglietti da visita, dove ha 
scalzato persino 
poste.it
, nonstante sia imap4.
-- 
Ciao, DOCstone

 Ma hai il munging nel Reply-to oppure no?
Ovvio che non l'ha. Ti ha appena consigliato di segnalare il munging con
suffisso .invalid 
Vedi un .invalid alla fine del suo Reply-To che ne segnali l'invalidità?
No, dunque l'indirizzo fornito è valido.
-- 
"CAT-lendario 2007! Oltre 120 mici si sono messi in posa per aiutare gli
a-mici meno fortunati, nello specifico quelli abbandonati." 
http://catlendario.blogspot.com/

 scalzato persino 
poste.it
, nonstante sia imap4.
Buona scelta, oltre tutto i filtri antispam di Gmail sono veramente ben
tarati, i falsi positivi sono veramente rari, almeno per la mia
esperienza.


 con suffisso .invalid 
Si, è vero. Mi sembra anche che se ne parlò, in passato, del finto 
munging, ma ora non ricordo bene.
Con l'occasione ho (ri)letto 
http://wiki.news.nic.it/AntiSpam
 e 
sinceramente, trovo che molte affermazioni siano opinabili, se non 
contraddittorie.
A cominciare dala frase cardine, quella evidenziata, l'unica su sfondo 
colorato in tutto il testo:
<<oggi è inutile nascondere l'indirizzo sui newsgroup quando esistono 
moltissime altre situazioni, fuori dal nostro controllo, che fanno 
finire l'indirizzo email da proteggere direttamente nelle mani degli 
spammer professionisti>>
Non sono d'accordo: sarebbe come dire che è inutile chiudere a chiave 
la porta di casa, tanto i ladri entrano dalla finestra: occorre invece 
chiudere porta e finestra.
Gli harvester che cercano gli indirizzi in usenet esistono (e lo stesso 
testo lo riconosce più avanti) e sono una fonte di approviggionamento 
di email, anche se forse non la principale. Proteggere l'indirizzo su 
usenet è quindi utile, anche se non sufficiente.
In definitiva quella frase la scriverei più o meno così: "oltre a 
nascondere l'indirizzo sui newsgroup occorre proteggere il proprio 
computer da trojan e worms, e invitare i nostri interlocutori a fare 
altrettanto"
Questo è solo uno dei molti punti che non condivido.
-- 
Ciao, DOCstone

 venire comunque controllato. Non è la stessa cosa.
Primo: l'indirizzo invalido di cui stiamo parlando NON E' 
potenzialmente esistente, per definizione. Secondo: il traffico non lo 
genera chi pubblica su usenet l'indirizzo, ma lo spammer. Terzo: che il 
traffico di forwarding sia legittimo nulla toglie al fatto che impegni 
il server, e che lo impegni ben più che non rigettare una mail per lui 
invalida già all'arrivo.
-- 
Ciao, DOCstone

 Questo è solo uno dei molti punti che non condivido.
Beh, andrebbero anche aggiornate le info sui servizi di email gratuite e
forwarder.
Inoltre, preferirei come esempio di email falsificata correttamente
qualcosa del tipo
<us...@NOSPAMMERSexample.com.INVALID> 
piuttosto che
<userN...@example.com.invalid> 
che ha il difetto imho di usare una stringa troppo prevedibile e di non
alterare la parte che identifica il provider, dunque in teoria potrebbe
esistere un 
userN...@example.com
 .

 quando si fa munging? ;-)
Quello è imho un falso problema, e ti spiego perché.
L'uso del suffisso .invalid è giustificato, nel testo, dal fatto che:
<<se c'è ".invalid" nessuna macchina tenterà di inviare una mail a quel 
recapito esatto, così non si genererà mai alcun traffico inutile e 
sicuramente non staremo abusando di alcun indirizzo esistente.>>
Però più avanti si dice anche:
<<gli harvester possano altrimenti risalire al nostro recapito 
limitandosi a levare l'".invalid" finale>>
L'uso di .invalid è l'unico modo che il testo indica per <<falsificare 
correttamente un indirizzo, ove per "correttamente" si intende "in modo 
che non crei alcun fastidio a nessuno">>
Ma l'utilizzo di .invalid non è un metodo valido per evitare il 
traffico di spam verso un indirizzo (falsificato o meno), perché 
qualunque harvester, anche il più "artigianale", lo riconosce.
Parliamo ora di questi fastidi, che per quanto riguarda l'uso di 
.invalid consistono esclusivamente nel  traffico verso un indirizzo 
falsificato.
Quando uno spammer manda un post a un indirizzo falsificato, il server 
che lo riceve deve impiegare risorse per controllare l'esistenza 
dell'indirizzo e per rispondere che è inesistente. Quanto vale questo 
traffico in percentuale? sarà il 10% oppure lo 0,00001%? Io non lo so, 
ma prima di affermare che questo è un fastidio per il server sia 
necessario quantificarlo, soprattutto perché si dice che queste risorse 
"potrebbero essere allocate per risolvere problemi o migliorare il 
servizio!". Prima di far sentire una m..da un utente, sarebbe opportuno 
avere i dati alla mano.
Per contro, la lettura del testo impone un dispendio di energie da 
parte dei singoli utenti (moltiplicarto per migliaia) al fine di 
tutelare il server da _terzi_ spammatori. Vorrei davvero fare un 
confronto tra questo spreco di risorse e quello precedente. Inoltre 
IMHO dovrebbe essere il contrario: i fornitori di accesso divrebbero 
controllare i loro spammatori (qualora ne avessero  interesse).
Infine, se da un lato si suggerisce l'uso di .invalid per non dare 
fastidio ai server, dall'altro si suggerisce come crearne.
Nel testo si parla di forwarding. Tuttavia oltre a segnalare 
(correttamente) i servizi di forwarding nati proprio per combattere lo 
spam (sneakemail, spamgourmet, ecc.), al capitolo 3.1 si suggerisce di 
utilizzare un servizio mail qualsiasi con forward. In questo caso, 
ilservizio di forward offerto no serve per combattere lo spam, ma per 
facilitare l'utente nella gestione della posta. Quello suggerito è 
quindi un uso improprio, che non fa altro che raddoppiare il traffico 
spam.
Quello che suggerisco, il munging invalidante (ossia la falsificazione 
dell'indirizzo in modo da renderlo incompatibile con la sintassi del 
provider) elimina le risorse necessarie per cercare l'indirizzo 
all'interno del server, oltre a tutelare l'utente contro una possibile 
appropriazione dell'indirizzo falsificato da parte di terzi, poiché 
tale indirizzo è già invalido a tutti gli effetti.
Aggiungere .invalid a questo indirizzo non depisterebbe nè gli uomini 
nè le macchine.
Non ho finito. Ci sta ancora da parlare della gatta, del reply-to, e 
forse di qualcos'altro.
-- 
Ciao, DOCstone

 invalida già all'arrivo.
Io parlavo un pochino più in generale, non certo riferendomi solo a te.
Comunque, il server deve analizzare il traffico per eventualmente
rigettare mail con indirizzi sbagliati o intestate a utenti inesistenti,
quindi è sbagliato a prescindere. In questi casi si usa il munging,
qualsiasi altro metodo è scorretto.
Inoltre, il traffico e-mail generato dall'esposizione su usenet di
indirizzi corretti e appartenenti al poster (che siano nel from o nel
reply-to), a prescindere che si usi un forwarder oppure no, non è
necessariamente generato *solo* dagli spammer, a te non è mai capitato
di essere contattato in privato o di avere impostato un follow-up to
poster, deduco. 
In questi casi, quindi, non si può dire che chi usa un indirizzo valido
impegna i mail server ben più di chi usa mail non invalidate come si
deve, perché quello è il normale lavoro per il quale sono nati i mail
server, ricevere e smistare posta elettronica.


 Ma hai il munging nel Reply-to oppure no?
Come ti hanno già detto no, non ce l'ho.


 e forse di qualcos'altro.
Prego, sono qua :-)


 sufficiente. 
Tra "proteggere" e "nascondere" c'è una gran differenza.
Io ad esempio proteggo il mio indirizzo, ma non lo nascondo.


 in relazione ad altri provider email.
Sneakemail non lo consiglio, ha (aveva?), soglie troppo basse prima di 
rigettare tutte le mail, inviando l'avviso che per ricevere le altre è 
necessario l'account a pagamento.


 falsificato.
Il suffisso .invalid segnala anche agli utenti umani che quell'indirizzo è
invalido.

 o di avere impostato un follow-up to poster
Sono contrario per principio.
-- 
Ciao, DOCstone

 altre è  necessario l'account a pagamento.
Ok, grazie
-- 
Ciao, DOCstone

 Spero ti basti per cambiare idea sul tuo sistema.
Aggiungere .invalid non cambia niente. Alternative valide?
-- 
Ciao, DOCstone

 Come ti hanno già detto no, non ce l'ho.
E il finto munging è utile come arma di riduzione dello spam? Se sì, 
perché non indicarlo nel wiki?
-- 
Ciao, DOCstone

*Enrico C* ha scritto:



E qui arriviamo al problema della gatta.
Parlando di munging è scontato che si parli di intelligenza umana, 
perché il metodo si basa proprio sulla differenza tra un umano e una 
macchina.
Se il poster e chi vuole scrivergli in privato sono umani, sono anche 
intelligenti sia nel fare il munging che nel rimuoverlo, quindi 
.invalid è inutile. Già comprovato.
Invece nel testo non trovo tracce di questa intelligenza. Gli esempi 
che vengono fatti sono di quanto meno intelligente ci possa essere.
Si passa dalla standardizzazione (
userN...@example.com
) inutile per 
il più banale degli harvester, all'infantilismo 
(
user...@example.com
), decifrabile solo con il brute force ;-)
Questi esempi hanno in comune che non fanno appello all'intelligenza, 
per cui per principio non possono spiegare il munging.
Tra gli esempi di munging standard avrei messo
<user...@QUESTOexample.com>
<user...@exampleNO.comGRAZIE>
mentre tra quelli fantasiosi
<NOuser...@exampleNO.comPARTY>
se proprio uno vuole cazzeggiare può anche dire "per rispondermi togli 
la pubblicità" ma non è indispensabile per un umano-intelligente
-- 
Ciao, DOCstone

 sono legittimato a scrivere quello che mi pare nel campo from
Beh, nzomma... Secondo la RFC 1036... 
 
http://www.ietf.org/rfc/rfc1036.txt
2.1.1.  From
    The "From" line contains the electronic mailing address of the
    person who sent the message, in the Internet syntax.  It may
    optionally also contain the full name of the person, in parentheses,
    after the electronic address.  The electronic address is the same as
    the entity responsible for originating the message, unless the
    "Sender" header is present, in which case the "From" header might
    not be verified.  
[...]
Inoltre, dovresti verificare cosa dice la policy del niusserver che usi per
postare.
Quella di 
individual.net
 per esempio chiede 
http://news.individual.net/rules.php
The e-mail addresses given in "From:", "Reply-To:", and "Sender:" should be
your own and should be valid (= should not bounce because of invalidity).
Using addresses and name space of other people without their permission is
prohibited. 
http://news.individual.net/faq.php
5.3 May I mangle my "From:" header address so that I do not get SPAM?  
  We recommend creating a special e-mail address for use with Usenet
articles only and protecting it with suitable filtering rules. This way
your regular mailbox will stay untroubled, but you can still receive mail
responses to your Usenet articles. 
Another option is using the Top Level Domain ".invalid" (see RFC 2606). The
Top Level Domain ".invalid" is intended for construction of obviously
invalid addresses like "inv...@invalid.invalid". Such addresses do not
disturb and pollute regular name space and can easily be identified as
invalid by both humans and machines. 
 
Altre condizioni potrebbero essere poste a livello di gerarchia o di
singolo gruppo, specie nei NG moderati.

 la pubblicità" ma non è indispensabile per un umano-intelligente
Bah, non tutti sono utenti smaliziati che fanno uno studio attento
sull'indirizzo. Se è presente il suffisso .invalid, il programma segnala
all'utente che quell'indirizzo non è valido. Se invece non è presente, e
l'utente non si accorge dei tuoi giochi di parole, il messaggio parte lo
stesso verso un indirizzo inesistente o altrui.

 Questi atteggiamenti dogmatici fanno male a usenet, imho ovviamente.
A me pare che di "dogmatico" ci sia solo la tua ostinazione a fare come ti
pare senza tener conto di regole e cortesia. 


 Cambierei "č inutile nascondere" in "non basta proteggere"...
Se Massimo non si oppone, procederei col wiki... :)


 Non è proprio del munging che stiamo parlando? Che vuoi dire?
Andavo di fretta e mi sono espresso male. Intendevo dire che in quei
casi (mail con indirizzi sbagliati o intestate a utenti inesistenti)
l'indirizzo andrebbe camuffato in modo da non comportare problemi per i
mail server. Quindi andrebbero invalidate almeno anche nella parte
dell'indirizzo dopo at.


 
http://www.ietf.org/rfc/rfc1036.txt
:-D conoscevo la RFC1036 (e ne approfitto per segnalare che il link a 
usefor che dovrebbe sostituirla è morto, come tutto il progetto, credo)
Secondo quella norma siamo tutti in difetto: io, tu, Gesù, i newsreader 
che inseriscono il nickname tra le virgolette anziché tra le parentesi, 
e anche NIN che propone soluzioni diverse like 
"inv...@invalid.invalid"
La stessa RFC è morta di vecchiaia (è datata 1987, ossia prima dello 
spam)
C'è anarchia. Ribadisco che il campo from oggi è terra di nessuno.
-- 
Ciao, DOCstone

 "quiz", o non abbia voglia di perderci tempo.
Perché io mi devo sobbarcare di spam per permettere a uno svogliato di 
non perdee tempo a scrivermi?
Se non vuole perdere tempo mi risponde nel NG, cosa che preferisco.
-- 
Ciao, DOCstone

 come ti pare senza tener conto di regole e cortesia. 
No per favore non fare il Mamo anche tu.
Contesto questo modo di attaccare chi la pensa diversamente basandosi 
su "regole" indefinite e indefinibili prive di riferimenti oggettivi e 
su "cortesia" che significa solo assecondare le paturnie del primo che 
passa. Così se uno dice "no" è scortese. Andiamo...
Io sono qui per discutere. Puoi non essere d'accordo, ma non puoi dire 
che io non abbia argomenti per suffragare le mie tesi.
-- 
Ciao, DOCstone

 Se non vuole perdere tempo mi risponde nel NG, cosa che preferisco.
Quello che non capisco è:
1. perché non vuoi aggiungere un semplice suffisso che segnala a macchine e
umani che l'indirizzo non è valido?
2. perché non vuoi considerare, come modello antispam, un sistema molto più
semplice e sicuro per evitare di abusare di indirizzi altrui, basato
sull'alterazione del nome del provider?

 C'è anarchia. Ribadisco che il campo from oggi è terra di nessuno.
Appunto, è un caos. A chi fa munging, si cerca allora di consigliare i modi
che creano meno problemi. Poi  ognuno decide per sé. Ma troverei sbagliato
non spiegare le possibilità e le conseguenze.

 Contesto questo modo di attaccare chi la pensa diversamente 
Guarda che sei tu che hai dato giudizi, parlando di "atteggiamenti
dogmatici", e a proposito degli esempi della pagina wiki, di scarsa
"intelligenza" e "infantilismo"... 

 troverei sbagliato non spiegare le possibilità e le conseguenze.
Insomma, decine di post e stiamo ancora al punto di partenza. Non sono 
riuscito a far comprendere che parole come "problemi" "conseguenze" 
sono prive di significato se non sono suffragate dai numeri.
IMHO oltre a non essere convincenti con le masse, producono anche un 
effetto di allontamento da usenet.
-- 
Ciao, DOCstone

 altrui, basato sull'alterazione del nome del provider?
Perché non sono d'accordo che sia più semplice (è solo più vecchio), ma 
soprattutto perché il metodo indicato nel testo antispam non è affatto 
sicuro. Infatti suggerisce un munging qualsiasi con l'aggiunta del 
suffisso invalid. Un harvester toglie immediatamente il suffisso e 
manda monnezza all'indirizzo mungato. Invece secondo me occorre porre 
attenzione a _come_ si fa il munging, in modo da ridurre l'impegno dei 
server di posta. Quindi è più sicuro quest'ultimo metodo.
-- 
Ciao, DOCstone

 "intelligenza" e "infantilismo"... 
Non era riferito al testo o all'autore, ma agli esempi, e non era usato 
in tono offensivo, perché il ricorso all'antipatico termine 
"intelligenza"  era necessario per definire la differenza tra uomo e 
macchina.
Quindi quello che volevo dire era che degli esempi riportati, ilprimo 
non ingannava la macchina (e perciò mancava di intelligenza), mentre il 
secondo non era ricostruibile da un umano (e quindi non sfruttava la 
sua intelligenza).
Spero di aver chiarito che non era mia intenzione offendere.
-- 
Ciao, DOCstone

 soprattutto perché il metodo indicato nel testo antispam 
[...]
Quel testo si può correggere e migliorare, dove occorre, è un wiki! :)


 in alcun modo quel server.
Ancora con questi indirizzi altrui? Ancora ti sfugge che dopo munging 
c'è scritto INVALIDANTE? Ancora con il problema di impegnare un server 
senza dire QUANTO? 8-o
-- 
Ciao, DOCstone

 Ancora con il problema di impegnare un server senza dire QUANTO? 8-o
Alterando il TLD, come mi pare concordi, si evita del tutto il traffico
spurio a quel server.


 traffico spurio a quel server.
D'accordo, aggiriamo il problema proponendo la falsificazione del TLD, 
purché concludiamo che il problema era mal impostato.
-- 
Ciao, DOCstone

 purché concludiamo che il problema era mal impostato.
Se parli della pagina wiki, il wiki è fatto apposta per essere migliorato!
:-)


 migliorato!  :-)
Non mi riferisco solo alla wiki, bensì all'abitudine comune anche nei 
NG e anche in questo 3d, di lamentare il problema del server che riceve 
lo spam indirizzato a un indirizzo inesistente.
-- 
Ciao, DOCstone

 migliorato!  :-)
E quando c'è un punto di vista opposto sullo stesso argomento che si 
fa?
-- 
Ciao, DOCstone

 invalidante 
No, e te l'ho dimostrato.
-- 
Ciao, Massimo | Jabber: 
pet...@jabber.linux.it
http://www.stambugia.com/blog/
 | ICQ: 57669970
«Ma poi, è proprio obbligatorio essere qualcuno?»

 sì, perché non indicarlo nel wiki?
Credevo di averlo indicato, ricontrollerò.
(Sì, molto efficace.)


 Aggiungere .invalid non cambia niente. Alternative valide?
Usare un proprio indirizzo valido.


 (
user...@example.com
), decifrabile solo con il brute force ;-)
Gli harvester non fanno brute force, e come detto sopra si tratta di 
esempi reali.


 migliorare, penso che lo farò (se anche Gesù è d'accordo)
Ovviamente.
Tieni conto che *
example.org
* è il dominio da usare quando si fanno 
degli esempi (per questo non ne ho usati altri).


 l'impegno dei server di posta. 
Evidentemente parliamo due lingue diverse.


 (Sì, molto efficace.)
Bene allora, è una cosa da sperimentare. Per il momento evidenzia che 
gli harveser elaborano gli indirizzi eliminando le stringhe più banali.
-- 
Ciao, DOCstone

 Usare un proprio indirizzo valido.
Si, questa avrebbe il vantaggio di una migliore gestibilità dei propri 
messaggi ed è sicuramente più accettata a livello internazionale. Se 
solo non ci fossero gli svantaggi...
-- 
Ciao, DOCstone

 Quale dei due metodi spreca meno risorse?
Abbiamo appurato altrove che il mio attuale munging invalidante è tale 
solo per il servizio 
email.it
 (che non ammette l'underscore alla fine 
dello username); aabbiamo però appurato che esiste anche il munging 
invalidante assoluto, definito (ad esempio) dal mancato rispetto della 
RFC2822.
Tale munging invalidante è riconoscibile dal mailreader, che è quindi 
perfettamente in condizione di bloccare l'invio a un indirizzo 
certamente inesistente.
La differenza con .invalid è che i segni invalidanti sono tanti e 
quindi sono meno facilmente rimuovibili dagli harvester.
-- 
Ciao, DOCstone

 quindi sono meno facilmente rimuovibili dagli harvester.
Perdonate, non ho letto tutto  il  filone  con  attenzione,  e  non  vorrei
intervenire  a  sproposito,  ma:  appurato  che  non ha senso modificare un
indirizzo valido semplicemente aggiungendogli ".invalid" in fondo, che cosa
ti  impedisce  di  usare qualcosa come "docstone...@email.it.invalid"?
Magari, meglio, inserendo in firma le istruzioni precise su come modificare
il tuo From per renderlo valido. 
Ciò  detto,  una soluzione ineccepibile e pure comoda è quella di usare nel
From un indirizzo valido ma "di scarto" (per esempio un indirizzo  Hotmail,
come  faccio  io)  e nel Reply-To un altro indirizzo valido. Al From arriva
solo SPAM, e lo  svuoto  da  web  una  volta  ogni  due  o  tre  settimane,
segnalando  a  Hotmail[*]  che  è  tutto  SPAM  (il che dovrebbe aiutarli a
migliorare i loro filtri). Al Reply-To, invece, arriva una quantità di SPAM
praticamente *nulla*, anche senza filtri di sorta.
[*]  Ci  sono  servizi  molto  migliori di Hotmail, anche e soprattutto per
quanto  concerne  la  manutenzione  dei  filtri   antiSPAM,   per   esempio
mail.people.it
.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
__________________________________
Combatti l'AIDS col tuo computer: 
http://fightaidsathome.scripps.edu/

 è una risorsa.
Un indirizzo non assegnato e non assegnabile ai  sensi  della  RFC2822  non
è un indirizzo. E il From deve contenere una lista di indirizzi.


 indirizzi.
Anche su questo abbiamo già parlato della della RFC1036 (che disciplina 
il campo From) e del fatto che tale norma del 1987 sia antecedente alla 
nascita dello spam (1994).
-- 
Ciao, DOCstone