Post by Enrico CPost by DOCstoneA cominciare dala frase cardine, quella evidenziata, l'unica su
<<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>>
In effetti, detta così, non pare neanche a me molto convincente,
perché di spam da Usenet ne arriva eccome.
Cambierei "è inutile nascondere" in "non basta proteggere"...
Ne sono contento
Post by Enrico CMeglio dire "proteggere", in
generale. Poi ognuno sceglie come farlo, "nascondendo" l'indirizzo
oppure usando email filtrate.
Hai ragione.
Post by Enrico CPost by DOCstoneQuesto è solo uno dei molti punti che non condivido.
Anche quella di alterare anche la parte a destra della chiocciola,
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