Tophost

[doGmaI]

Premetto che quello che scrivo in seguito non lo metto sul forum per farmi bello dinnanzi alla community perchè ho avuto un'idea e l'ho suggerita a TopHost (anche perchè bisogna vedere se è fattibile/utile), ma con puro scopo di collaborazione. Magari da questo spunto a qualcuno viene un'idea che può aiutare tutti nella costruzione di un filtro antispam migliore...

Comincio allegando parte del sorgente di una mail di spam che ho ricevuto in questi giorni:

Return-Path: <buckh@accor-hotels.com>
Received: from smtp-f1.localhost (smtp-f1.seeweb.it [212.25.179.73])
        by m-01.th.seeweb.it (8.13.4/8.13.4/Debian-3) with ESMTP id k3EC8O8u013388
        for <@isketch-italian.net>; Fri, 14 Apr 2006 14:08:24 +0200
Received: from localhost (localhost [127.0.0.1])
        by smtp-f1.localhost (Postfix) with ESMTP id 1DA2E618104
        for <@isketch-italian.net>; Fri, 14 Apr 2006 14:08:24 +0200 (CEST)
Received: by smtp-f1.localhost (Postfix, from userid 1001)
        id D0044618452; Fri, 14 Apr 2006 14:08:23 +0200 (CEST)
Received: from LLS-422D2D875FE (unknown [61.172.16.95])
        by smtp-f1.localhost (Postfix) with SMTP id 915516180DE
        for <@isketch-italian.net>; Fri, 14 Apr 2006 14:08:16 +0200 (CEST)
Received: from click (unknown [220.172.222.202])
        by XRVFL (QIBSys) with ESMTP id 4FCF6381690
        for <@isketch-italian.net>; Fri, 14 Apr 2006 07:07:17 -0600
Date: Fri, 14 Apr 2006 07:07:17 -0600
From: "Sergio Dunbar" <buckh@accor-hotels.com>
To: @isketch-italian.net
Subject: Pre-approved Application #yireolwL421096024
Content-return: allowed
X-mailer: Foxmail 5.0 [en]
X-Authentication-Warning: localhost.localdomain: apache set sender to buckh@accor-hotels.com using -f
X-Virus-Scanned: amavisd-new at yahoo.com
Mime-Version: 1.0
Content-Type: multipart/related;
        boundary="=====002_Dragon293460404751_=====";
        type="multipart/alternative"
Message-Id: <21504467748126.IB1LAlxLuc@father>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on smtp-f1.seeweb.it
X-Spam-Status: No, hits=3.0 required=6.0 tests=HTML_MESSAGE,
        RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,RCVD_IN_DSBL autolearn=no
        version=2.63
X-Spam-Level: **
X-Virus-Scanned: by AMaViS

NOTA: l'indirizzo @isketch-italian.net ovviamente è farlocco, semplicemente perchè cerco di diffondere il meno possibile quello reale a cui ho ricevuto la mail di spam visto che già ne ricevo molto

Ora veniamo all'idea
Visto che fare un filtro banale considerando l'oggetto della mail o particolari parole presenti nel corpo della stessa non porterebbe a buoni risultati (scontato!), perchè potrei sempre ricevere una vera mail dall'oggetto Pre-approved Application da un contatto inglese ho pensato di controllare una discreta quantità di mail per ricercare aspetti comuni che permettessero in qualche modo di identificare una mail come spam.

Una cosa c'è: molte mail non presentano alcun testo, ma un'immagine che ritrae una pagina di testo come allegato (o come immagine nella versione HTML della mail). Ma anche questa soluzione sarebbe ben poco affidabile (ho diversi amici che mi mandano magari una barzelletta sotto forma di immagine e non scrivono niente nella mail, quindi...)

Poi mi è venuta una specie di illuminazione: ovviamente gli spammer, per spedire mail non sono tanto stupidi da usare il loro vero indirizzo di posta, e pertanto se ne inventano uno. Spesso si trattava di indirizzi completamente inventanti (del genere chdxyz@chdteud.fds) e ovviamente questo impediva di filtrare le mail in base al mittente perchè ogni volta l'indirizzo sorgente cambiava. Ma questo problema è in parte risolto dai filtri come quelli adottati da TopHost.
Quindi gli spammer si sono aggiornati e ora cosa fanno per evitare questo filtro? Usano un indirizzo di posta che ha come dominio di provenienza un dominio realmente esistente. In questo modo la mail non risulta palesemente "sballata" e passa i filtri. Ora però c'è ancora una cosa "che li frega" secondo me...
Ho provato a fare questo controllo:
* ping www.accor-hotels.com e mi restituisce 217.174.. (6 cifre eliminate per sicurezza, non si sa mai, cmq chiunque può vedere quali sono ste cifre).
* controllo il percorso fatto dalla mail e come primo "mailserver" vedo un bel Received: from click (unknown [220.172.222.202]) by XRVFL (QIBSys) with ESMTP id 4FCF6381690 for <@isketch-italian.net>; Fri, 14 Apr 2006 07:07:17 -0600[/b] e come si nota dall'IP evidenziato, non corrisponde per niente all'IP del dominio accor-hotel.com
Credo che un controllo "incrociato" su IP del reale dominio e IP del primo mail server attraversato non sia un lavoro mastodontico da fare (visto quello che già farà l'antispam) e potrebbe essere una discreta misura per filtrare mail di spam (se io mando una mail a gente che conosco non mi sogno minimamente di cambiare IP o indirizzo del mittente)

Ovviamente si potrebbe sempre obiettare che una volta scoperto il barbatrucco gli spammer potrebbero adeguarsi e andare a ricavare prima l'IP di accor-hotels.com e poi mettere quello come indirizzo del primo mailserver.
A questo punto non resterebbe che andare a controllare se l'utente buckh@accor-hotels.com esiste (e non esiste ) come fa il sito http://www.dnsstuff.com/

--------------
Va da se che tutto quanto scritto non vuole essere la risposta definitiva al problema dello spam (se fosse così facile non ci sarebbe più spam circolante da diversi anni), ma solo uno spunto (spero proficuo) per i tecnici di tophost (in caso magari non abbiano pensato a questo ulteriore controllo) e per i partecipanti al forum, che magari possono avere qualche "illuminazione" migliore della mia e consigliare a loro volta come perfezionare il filtro...

Detto questo chiudo uno dei post più lunghi che abbia mai fatto lasciando la parola a chi vuole commentare o aggiungere altro (o alla stessa TopHost se vuole mandarmi a quel paese )

[step76]

E' esattamente quello che già fa il Sender Policy Framework, in breve SPF, su cui puoi trovare maggiori info qui: http://www.openspf.org/

Praticamente sfruttando il campo TXT dei DNS si inserisce per un determinato dominio una stringa in formato SPF che elenca gli IP che possono mandare mail per qual dominio. I server di posta che supportano SPF per ogni mail ricevuta controllano che il dominio sender abbia SPF e in quel caso controllano che l'ip sia autorizzato. In caso di match negativo respingono la mail prima ancora di averla ricevuta.

Io mi sono configurato il server di posta con SPF e greylist e addio spam (forse passa un messaggio al mese).

 

[doGmaI]

Non sapevo dell'esistenza di SPF
Evidentemente come dicevo nel messaggio qualcuno ci ha già pensato

Devo ancora leggere approfonditamente ma da una scorsa sommaria mi pare di aver capito che questo meccanismo viene implementato sul server mittente della mail o sbaglio?

La mia idea era applicata al ricevente. In questo modo se qualcuno si appoggia ad un server non SPF il problema non è risolto. Mentre applicando il ragionamento sul server ricevente, anche se uno spammer si appoggia su un mailserver non SPF lo spam viene cmq filtrato...

edit:
Ovviamente mi son scordato...
A questo punto tiro in gioco anche TopHost chiedendo se loro hanno SPF o meno (in tal caso non sarebbe male che venisse installato se possibile)

[step76]

Allora, SPF deve essere implementato in un record TXT del dominio del mittente e deve essere implementato sul mail server del ricevente.

La prima cosa da fare e informare il mondo di quali computer sono autorizzati ad inviare mail a mio nome.
Ad esempio, prendiamo la configurazione di gmail.com:

Codice:

; <<>> DiG 9.2.4 <<>> gmail.com txt
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11544
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmail.com.                     IN      TXT

;; ANSWER SECTION:
gmail.com.              300     IN      TXT     "v=spf1 ip4:216.239.56.0/23 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ?all"

;; Query time: 126 msec
;; SERVER: 209.51.143.76#53(209.51.143.76)
;; WHEN: Fri Apr 21 17:18:17 2006
;; MSG SIZE  rcvd: 129

il testo sopra mi dice quali sono i computer abilitati a mandare mail per il dominio gmail.com.

Il secondo passo e configurare il mio mail server in modo che controlli SPF per ogni mail in arrivo, nel momento in cui una mail che dice di arrivare da un indirizzo gmail.com scopro che a recapitarla non nessuno dei computer elencati sopra, la butto via immeddiatamente, facendo fallire il comando SMTP RCPT TO:.

Il metodo che dici tu, che fa affidamento alla rete del computer www è pericoloso perché grandi compagnie potrebbero avere i server www e i server mail che si occupano dell'uscita su server differenti. Ad esempio, sempre parlando di gmail.com guarda cosa mi dice il DNS riguardo al www:

Codice:

; <<>> DiG 9.2.4 <<>> www.gmail.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21055
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.gmail.com.                 IN      A

;; ANSWER SECTION:
www.gmail.com.          83711   IN      CNAME   mail.google.com.
mail.google.com.        39      IN      CNAME   googlemail.l.google.com.
googlemail.l.google.com. 300    IN      A       64.233.185.83
googlemail.l.google.com. 300    IN      A       64.233.185.19

;; Query time: 161 msec
;; SERVER: 209.51.143.76#53(209.51.143.76)
;; WHEN: Fri Apr 21 17:23:13 2006
;; MSG SIZE  rcvd: 116

come vedi gli indirizzi IP del server web non sono compresi nelle classi indicate nel record SPF, ovvero i server web sono su reti differenti rispetto ai server delle mail in uscita.
 

[doGmaI]

Si il problema delle classi di IP lo sospettavo.
Tuttavia (tenendo sempre presente che non conoscevo SPF) avevo buttato lì l'idea considerando il fatto che solitamente o comunque in buona parte gli spammer non usano grandissime società ma medio piccole (tipo appunto quello che ho citato). Di conseguenza le classi IP solitamente coincidono.

Detto questo è chiaro che il metodo SPF è sicuramente molto ma molto + affidabile, anche se vedo un neo nel fatto che pure il mittente debba adottare SPF perchè tutto il meccanismo stia in piedi (ovviamente grandi servizi tipo hotmail, gmail o comunque servizi gestiti da società serie adotteranno SPF o equivalente, ma resteranno sempre i problemi di migliaia di server medio piccoli che permetteranno cmq l'invio di mail spammose (chiaramente come dicevo prima non è un problema risolvibile in quattro e quattr'otto quello dello spam) )

Comunque l'idea di SPF è davvero carina, me lo segno tra i software essenziali e lo consiglierò appena posso

[step76]

Io mi sono configurato SPF sul mio dominio, poi, avendo un MTA ho potuto installare il controllo SPF. Logicamente se il dominio mittente non ha il record TXT con le informazioni SPF la mail passa .
Insieme ad SPF ho aggiunto anche la tecnica delle greylist: ovvero rifiutare tutte le richieste in arrivo la prima volta, per accettarle poi la seconda volta. In questo modo gli spammer, che di solito non usano sistemi di invio con code non ritentano più, mentre i server "buoni" fanno sempre più tentativi di invio. Unico neo è che ricevo le mail con un pò di ritardo.
Ma da quando ho messo in piedi l'accoppiata SPF+greylist lo spam si è ridotto in una maniera impressionante, direi che ora è tendente a zero.

Per maggiori info e per configurazioni su Exim e Postfix puoi dare un'occhiata qui http://www.soft-land.org/articoli/greylist
 

[doGmaI]

Davvero una soluzione interessante...

Quella delle greylist non la sapevo proprio

Direi che non ho altro da aggiungere a questo punto se non ringraziarti per i link e le informazioni

[Tophost]

Salve,

Veramente interessanti le considerazioni esposte in questo thread. Noi SPF gia' lo usiamo. Sulle GL ("greylist") ci sono pareri contrastanti anche perche', per esempio, se uno si iscrive a paypal, con GL non riceverebbe mai la prima mail di conferma della password e non ne uscirebbe piu'.

[step76]

Veramente interessanti le considerazioni esposte in questo thread. Noi SPF gia' lo usiamo. Sulle GL ("greylist") ci sono pareri contrastanti anche perche', per esempio, se uno si iscrive a paypal, con GL non riceverebbe mai la prima mail di conferma della password e non ne uscirebbe piu'.

Sono veramente contento di vedere un vostro intervento e mi incuriosisce questo discorso di paypal. Effettivamente la GL si basa sulla fiducia che un MTA "normale" ricevendo un rifiuto temporaneo poi ritenti l'invio della mail in un momento successivo. Invece paypal non segue questa logica? Cioè se il server risponde con un 450 per un qualunque motivo paypal non ritenta l'invio? Il 450 può essere dovuto anche ad altri fattori, durante i miei test è capitato anche con gmail che qualcuno dei loro MTA rispondesse 450 per temporanei sovraccarichi. Questo per approfondire il discorso paypal.

Per quanto riguarda SPF sono ben felice che voi lo avete adottato sui vostri server, a questo punto, come suggerimento, che ne dite di implementarlo anche sui domini degli utenti in modo da certificare la loro posta?
 

[doGmaI]

Beh, forse il sistema GL da solo potrebbe portare a questo problema.

Magari sarebbe meglio adottare una soluzione combinata: white list + grey list + black list + SPF

SPF funziona come deve e ok
Se poi la mail non viene filtrata da SPF, si potrebbe fare un confronto in questo modo con le liste:
1) prima viene controllato se il dominio (o il singolo indirizzo di posta addirittura) rientra nella blacklist. (questa lista dovrebbe teoricamente essere ridotta. Blacklistare un intero dominio è piuttosto "cattivo". Magari invece di una blacklist pura, si potrebbe pensare ad una struttura stile host.allow e host.deny, in cui magari si specificare DENY *.libero.it EXCEPT abuse@libero.it)
2) se la mail non rientra nella blacklist allora si controlla la white list. Qui andrebbero memorizzati gli indirizzi in qualche modo sicuri (ad esempio tutto gli indirizzi email provenienti da domini ospitati su TopHost, indirizzi di paypal ecc ecc.).
3) se la mail non "viene filtrata" da alcuna delle due liste si potrebbe ricadere nella greylist.

Faccio un paio di esempi per spiegare cosa intendo...

Scenario 1: mail proveniente dal dominio isketch-italian.net con IP falsificato (scusate lo spam del mio dominio, ma è per fare un esempio concreto. Suppongo che isketch-italian.net abbia SPF attivo.
SPF riconosce che l'indirizzo è falsificato e filtra la mail

Scenario 2: mail proveniente da un MTA che fa un solo tentativo, non SPF in whitelist (es paypal)
*@paypal.it non è nella blacklist
*@paypal.it è nella whitelist allora la mail passa
Volendo, si potrebbe mettere in whitelist invece di *@paypal.it l'indirizzo supporto@paypal.it (o quale che sia che spedisce la mail con la password)

Scenario 3: mail proveniente da un MTA che fa più tentativi, non SPF, non in whitelist, non spam (tale indirizzo isketch-italian.net )
*@farlocco.net non è nella blacklist
*@farlocco.net non è nella whitelist
*@farlocco.net viene valutato in base alla greylist->al primo tentativo la mail viene rifiutata. L'MTA ritenta e al secondo tentativo la mail viene accettata. A questo punto *@isketch-italian.net viene inserito in whitelist

Scenario 4: mail proveniente da un MTA che fa più tentativi, non SPF, non in whitelist, spam (tale indirizzo isketch-italian.net )
Come il caso precedente, la mail passa e finisce in whitelist.

In questo caso (se sono riuscito a spiegarmi bene), passerebbe una quantità ridotta di spam.

Magari si potrebbe prevedere, invece di mettere un dominio direttamente in whitelist, una sorta di "periodo" di tempo in cui il dominio resta cmq in greylist, ovvero per un certo periodo di tempo si aspetta comunque che l'MTA faccia più tentativi prima di porlo in whitelist.

PS: io l'idea in testa ce l'ho chiara, non so però se lo è altrettanto la spiegazione

[Shake]

Praticamente, se non ho capito male, SPF confronta l'IP del mittente con quello del dominio da cui è stata mandata la mail e in caso non coincidano la respinge, giusto?

Se è veramente così, però mi sorge un dubbio :dubbio:..

Se invio una mail da una pagina php presente sul mio sito, avrò che come mittente qualcosa del genere nome@miodominio.tdl mentre come dominio di invio w-01.th.seeweb.it, e quindi tutte le mail mi verrebbero bloccate?

Altro esempio, io sono un utente fastweb e a volte, devo usare il server smtp di fastweb, anzichè quello fornito dal servizio di email, quindi anche in questi casi gli indirizzo IP non coinciderebbero e mi verrebbero bloccate tutte le mail?

[step76]

Altro esempio, io sono un utente fastweb e a volte, devo usare il server smtp di fastweb, anzichè quello fornito dal servizio di email, quindi anche in questi casi gli indirizzo IP non coinciderebbero e mi verrebbero bloccate tutte le mail?

Se il server del destinatario effettua controlli SPF allora si e sempre che il tuo provider email abbia specificato un record SPF in cui specifica chi invia le email.

Avendo io implementato SPF sull'MTA del mio dominio e avendo anche google implementato un record SPF su gmail se tu mi inviassi una email con indirizzo mittente @gmail.com da un server SMTP che non sia di google la mail verrebbe cestinata.

Nell'esempio citato in realtà la cosa non accade poiche google ha implementato la direttiva ?all che indica che gli indirizzi IP elencati non sono esaustivi.

Diciamo che se si sceglie di implementare SPF (non tanto come controlli sull'MTA ma quanto sul record TXT del proprio dominio) allora si deve prestare molta attenzione a dove parte l'email. Cmq nel record SPF potrei anche indicare w-01.th.seeweb.it tra i server autorizzati ed evitare il problema.
 

[wergio]

Salve,

Veramente interessanti le considerazioni esposte in questo thread. Noi SPF gia' lo usiamo. Sulle GL ("greylist") ci sono pareri contrastanti anche perche', per esempio, se uno si iscrive a paypal, con GL non riceverebbe mai la prima mail di conferma della password e non ne uscirebbe piu'.

Salve, sono un vostro utente, sarebbe interessante avere nel pannello dns anche l'opzione di settare i record TXT per permettere la configurazione di SPF anche agli utenti che hanno solo la gestione DNS con voi (vedo che nell'help a sinistra del pannell si parla dei record TXT ma alla fine non è possibile settarli)

[DigItalWarrior]

Ciao a tutti,
continuo questo thread con questa domanda per capire se SPF ed affini possono concorrere ad un problema occorsomi:
da molto tempo non inviavo newsletters agli oltre 1800 utenti di un mio forum che risiede sul mio server e che utilizza postfix per l'invio delle email. Ieri mi sono accorto che inviando, appunto, questa newsletter mi sono tornati indietro quasi un migliaio di messaggi tipo il seguente:

Codice:

This is the mail system at host zeus.x-treme.it.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<xxxxxx@hotmail.com>: host mx1.hotmail.com[65.54.245.8] said: 550 Requested
    action not taken: mailbox unavailable (in reply to RCPT TO command)

Ora, fermo restando che circa una ventina sono tornate indietro per "overquota", i rimanenti, tutti con questo risultato e con i più svariati provider, da tiscali a yahoo, passando da tin, libero, ecc.
Possibile che di colpo ci siano state circa un migliaio di cancellazioni di indirizzi email? Non credo. Allora può essere un problema del mio gestore di invio email? Anche qui nutro seri dubbi perché le rimanenti email, 800 circa sono arrivate a destinazione. Qualche consiglio?
Potrebbe essere un problema legato a SPF, whitelist, blacklist, ecc?

[mem]

Tempo fa la mia newsletter aveva raggiunto quota 8.000 email... una newsletter vecchia di 3/4 anni, quindi non tanto aggiornata. Di queste 6.000 mi tornavano puntualmente con errori del genere "unavailable" o semplicemente senza spiegazione (ovviamente impossibile come dici tu che tante email siano all'improvviso sparite)... alla fine ho scoperto che il server smtp era in blacklist, ed infatti spesso i filtri antispam rispondono dicendo che l'email non esiste più. Tutto risolto cambiando hoster.