Archivio Tag: AntiSPAM

febbraio 9, 2010

Difendersi dallo SPAM, ma anche dagli spammer

La lotta allo SPAM è sacrosanta e doverosa, è una guerra vera e propria contro un nemico subdolo e vigliacco, che non si pone alcuna remora nell’utilizzare qualsiasi metodo, anche quelli maggiormente detestabili per invadere le nostre caselle di posta di ogni schifezza possibile.

La lotta contro gli spammer è sostanzialmente preventiva, con misure antiSPAM più o meno efficaci, ma è possibile talvolta combatterli dopo, anche sul fronte giuridico. Certo è impensabile pensare di aprire un contenzioso con gli spacciatori di viagra e affini, ma almeno con gli spammer nostrani, quelli che pensano che noi si sia tutti bramosi di conoscere le loro imperdibili offerte di cartucce per stampanti e accessori di vario genere, con questi è possibile prendersi qualche piccola soddisfazione.

Specialmente quelli che, alla fine delle loro odiose mail massive, ti mettono pure la pseudo-postilla, ipocrita quanto ridicola, che il nostro indirizzo mail è stato ricavato in rete in modo totalmente legale, e pertanto ogni loro missiva è lecita. Mortacci loro…
Continua a leggere →

gennaio 20, 2010

Mail firmate e dispositivi mobili

Abbiamo visto in più occasioni come le mail “firmate”, grazie all’utilizzo di strumenti come DomainKeys ed SPF, aiutino a salvaguardare la reputazione del dominio, per quanto riguarda ovviamente la posta elettronica, ed evitare il più possibile che delle mail spedite dal dominio possano essere prese per SPAM, anche solo come falsi positivi.

Spesso però si dimentica, o almeno alcuni lo fanno visto il feedback che sto ricevendo, che questo vale solo se le mail vengono inviate utilizzando il corretto server SMTP, ossia quello dichiarato negli SPF ed abbinato ai DomainKeys. La musica cambia se si utilizza un altro server SMTP o un dispositivo mobile che utilizza un proprio servizio SMTP, un Blackberry ad esempio.

Il servizio Blackberry lavora in modo egregio per quanto riguarda gli SPF, le mail in uscita dai loro server assumono un Return-Path coerente con il server SMTP utilizzato, e tutti i server SMTP di blackberry.com hanno i loro bei record SPF ben dichiarati nei DNS. Tutto verificato.
Giusto per la cronaca, questi sono gli headers di una mail destinata ad un indirizzo gmail.com inviata tramite il mio Blackberry di servizio (ebbene sì ne devo usare uno pure io), con indirizzo mail, IP e server opportunamente camuffati per ovvi motivi:

Return-Path: <SRS0=TsraiT=JA=quesse.it=robxx@srs.tris.de.blackberry.com>
Received: from smtp05.tris.de.blackberry.com (smtp05.tris.de.blackberry.com [226.53.145.101])
by mx.google.com with ESMTP id 16si4505603qyk.74.2010.01.15.15.57.11;
Fri, 15 Jan 2010 15:57:11 -0800 (PST)
Received-SPF: pass (google.com: domain of SRS0=TsraiT=JA=quesse.it=robxx@srs.tris.de.blackberry.com designates 226.53.145.101 as permitted sender) client-ip=226.53.145.101;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of SRS0=TsraiT=JA=quesse.it=robxx@srs.tris.de.blackberry.com designates 226.53.145.101 as permitted sender) smtp.mail=SRS0=TsraiT=JA=quesse.it=robxx@srs.tris.de.blackberry.com

(I riferimenti mail ed IP sono stati modificati per ovvi motivi) Continua a leggere →

gennaio 3, 2010

Spamassassin e le mail del 2010

Dall’inizio del nuovo anno prolificano nei forum le richieste di aiuto per problemi di mail inviate nel 2010 e prese come SPAM.
Controllando gli header, si scopre che il colpevole è la regola FH_DATE_PAST_20XX di Spamassassin, che dallo scattare del 2010 assegna diversi punti positivi a tutte le mail in ingresso:

X-Spam-Status: Yes, score=2.808 tagged_above=-999 required=2.50
tests=[BAYES_00=-2.599, FH_DATE_PAST_20XX=3.188, TVD_SPACE_RATIO=2.219]

È un bug noto come Y2K10 Rule Bug, e in realtà il colpevole è l’amministratore di sistema, o Postmaster che dir si voglia, che non si tiene troppo informato o non aggiorna Spamassassin da parecchi mesi, perché si tratta di un problema noto e “archiviato”, o per meglio dire risolto, molto prima di capodanno. Un aggiornamento del sistema, o solamente di Spamassassin se non è possibile fare altrimenti, metterà le cose a posto.

Ma se non si ha la possibilità di aggiornare direttamente il sistema si può comunque risolvere il problema, almeno temporaneamente, aggiungendo alla fine del file local.cf, il file di configurazione di Spamassassin la regola

score FH_DATE_PAST_20XX 0.0

Questa regola in pratica disattiva il controllo FH_DATE_PAST_20XX, assegnando un valore 0 che non modifica il punteggio generale delle mal in ingresso.
Dopo la modifica bisogna ovviamente riavviare Spamassassin.

ottobre 9, 2009

Indirizzi IP in blacklist, ancor prima di utilizzarli

ethernetHo imparato una cosa: prima di iniziare la procedura di instasllazione e attivazione di un server mail presso il cliente, sulla sua connettività, devo assolutamente fare una verifica della qualità dell’indirizzo IP da utilizzare.

Non è la prima volta che mi capita, talvolta per la fretta di finire un lavoro, altre perché magari dovevo intervenire a completamento di una installazione già iniziata, ma è veramente fastidioso che un cliente poi ti chiami per dei problemi di recapito della sua posta elettronica, un sacco di mail che gli tornano indietro rifiutate dai server dei destinatari.

Quando poi vai a controllare, e scopri che il problema è nell’IP appena assegnato dal fornitore della connessione, che compare in diverse blacklist antiSPAM (RBL) già da prima della data di assegnazione. Vaglielo a spiegare al cliente…

“Ma come, l’indirizzo IP è nuovo, ce l’hanno appena assegnato con la nuova connettività, lo abbiamo richiesto appositamente per il server…”

È un brutto quarto d’ora, anche perché le soluzioni, come vedremo, non sono certo immediate. Continua a leggere →

ottobre 1, 2009

Le Whitelist con Greylist

Ritornando a parlare di Greylist, sistema AntiSPAM, ed in particolare della parte relativa alla configurazione, è possibile definire delle whitelist di domini e/o di specifici indirizzi.

Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare. È possibile utilizzare espressioni regolari, il tutto in questo file che probabilmente sarà già esistente e con già dei domini inseriti, comodi anche come esempio:

/etc/postgrey/whitelist_clients

In un altro file invece è possibile indicare quali sono i destinatari che non devono essere filtrati :

/etc/postgrey/whitelist_recipients

In genere i destinatari che non dovrebbero essere filtrati sono gli account postmaster e abuse , e difatti questi sono già presenti nel file che l’installazione di Postgrey provvede a collocare al giusto posto.

Nota bene: per gli esempi indicati, stiamo parlando di Greylist su Debian, ossia del pacchetto Postgrey. In altre distribuzioni il percorso ed il nome dei files di configurazione delle whitelist potrebbero essere differenti, meglio vedere la documentazione del pacchetto Greylist installato.