martedì 29 giugno 2010

How to write Spamassassin plugin - part 2

Come promesso eccoci al secondo e ultimo appuntamento di questa serie.
Precisiamo subito che semplici regole possono essere scritte direttamente all'interno dei file di configurazione. All'interno dei plugin vanno messe regole più complesse o che si basano su dati che cambiano frequentemente.

Per prima cosa bisogna ereditare dalla classe base Plugin
package Mail::SpamAssassin::Plugin::MyPlugin;
use Mail::SpamAssassin::Plugin;
use DBI;
our @ISA = qw(Mail::SpamAssassin::Plugin);

sub new {
my ($class, $mailsa) = @_;

# the usual perlobj boilerplate to create a subclass object
$class = ref($class) || $class;
my $self = $class->SUPER::new($mailsa);
bless ($self, $class);

# add rule
$self->register_eval_rule ("check_myplugin_header");

return $self;
}

1;

In questo modo abbiamo registrato la nuova regola già definita all'interno del file di configurazione.

A questo punto bisogna dare corpo alla nuova regola che vogliamo introdurre nel tool.
Nel frammento di codice sopra abbiamo importanto anche le librerie DBI che ci consentono di interrogare il database con un comodo Object Model.

Facciamo un esempio di implementazione di una regola basata su DB.
sub check_myplugin_header
{

my ($self, $pms) = @_;

# Extract desidered informations from mail header
$head = $pms->get('CustomHeader');

$result = 0;
study;

chomp($head);
$head =~ s/;//;

$dbh = DBI->connect("dbi:mysql:spamassassindb","user","pass");


if(!defined $dbh)
{
die "Connessione al database non riuscita: $DBI::errstrn";
}

$query = "SELECT count(accepted_headers) FROM headers WHERE accepted_headers = $head";

# Insert query into database instructions
$sth = $dbh->prepare($query);

# Database query execution
$sth->execute;

$count = $sth->fetchrow();


if($count eq 0)
{
# Report error
$result = 1;
}

# Disconnect from database
$dbh->disconnect();

return $result;
}

Questo frammento di codice è piuttosto semplice e fa una query al db, tramite DBI, dopo aver bonificato la stringa da passare.
Una cosa sicuramente da notare è il paramtro $pms che consente di accedere a tutti gli headers della mail.
Forniamo allora questo messaggio
From god@heaven.com  Thu Jun 17 21:33:41 2010
Return-Path: <god@heaven.com>
X-Original-To: account@post-server
Delivered-To: account@post-server
Received: from post-server (host [127.0.0.1])
by post-server (Postfix) with SMTP id B66E9424F5
for <account@post-server>; Thu, 30 Jun 2010 21:33:20 +0200 (CEST)
CustomHeader:blablabla
Subject:Try this

Simple mail to test my plugin.

a spamassassin e avremo due comportamenti diversi:
  • Se la stringa "blablabla" è contenuta nel database la regola non andrà ad aggiungere i punti definiti nel file di configurazione (2.0 dal post precedente)
  • Se la stringa "blablabla" non è contenuta allora la regola avrà un hit che sommerà 2 punti allo score totale. In questo secondo caso se questo punteggio fa superare la soglia (definita sempre nei vari file di configurazione) allora il messaggio verrà identificato come SPAM!!!


È un argomento piuttosto vasto che richiede tempo per essere assimilato. Questo è solo un input che vuole stimolare interesse. Spero di essere stato chiaro e sono a disposizione per un help in linea, per quanto posso fare.

Have fun ;)

domenica 27 giugno 2010

How to write Spamassassin plugin - part 1

Sono giunto a un buon punto di un progetto per un esame universitario (che verrà pubblicato non appena consegnato) che riguarda un argomento sul quale ho trovato pochissimo materiale.

Si sta parlando della scrittura di un plugin che valuti una regola complessa su un messaggio e-mail, per determinare se si tratta di spam oppure no.

C'è voluto molto tempo per raggiungere qualcosa di funzionante ma ora che ho fra le mani un po' di codice che gira posso scrivere un articolo come questo e colmare la lacuna che il web mi ha mostrato. (I'll translate this article soon for international usage)

Cominciamo con installare tutto quello che serve (a parte una VM con sopra Ubuntu): Documentazione Ubuntu - Mail Server

A questo punto il plugin ha bisogno di due cose:
  1. Un file di configurazione che permetta di richiamare la regola e le assegni un punteggio.
  2. Una classe Perl che implementi l'interfaccia Plugin e che definisca precisamente la regola che si vuole aggiungere a Spamassassin.


In questa prima parte ci concentreremo sul file di configurazione. Nel prossimo articolo parleremo di come scrivere un .pm che interroghi un database per la valutazione di un header.

Il file di configurazione che bisogna comporre va depositato all'interno della directory di sistema /etc/spamassassin.
Possiamo andare a scriverlo direttamente con il seguente comando:
sudo gedit /etc/spamassassin/25_myplugin.cf

All'interno di questo file andiamo a scrivere due cose. La prima è il collegamento della funzione che andremo a definire nella nostra classe. La seconda è lo score che la regola aggiunge alla valutazione se si verifica la condizione definita.
Il contenuto sarà pressochè il seguente:
# Rule load for MyPlugin
header MY_RULE eval:check_myplugin_header()
score MY_RULE 2.0

Per configurare la nostra personalizzazione manca solo un passaggio: bisogna far caricare a Spamassassin il nostro plugin. Va dunque cambiato un qualunque file *.pre. Apriamo quindi:
sudo gedit /etc/spamassassin/v310.pre

In coda a questo file vanno aggiunte le seguenti righe affinchè il nostro plugin venga caricato a successivo riavvio.
# load MyPlugin
loadplugin Mail::SpamAssassin::Plugin::MyPlugin

Conclusa la configurazione è il momento di scrivere il vero e proprio plugin ma sarà argomento del prossimo post.

Stay tuned ;)

Ah, quasi dimenticavo:
sudo /etc/init.d/postfix
sudo /etc/init.d/spamassassin

lunedì 21 giugno 2010

Google CL: una stupenda notizia!

Avevo già letto qualcosa nei giorni scorsi ma oggi un articolo dell'intramontabile Programmazione.it mi ha dato la certezza: Google ha fornito un set di strumenti da linea di comando per poter interagire tramite shell con i servizi che offre tramite il google-account.

Andando sul sito del progetto, rigorosamente googlecode, si possono individuare subito due cose.

La prima sono gli strumenti che è possibile utilizzare tramite linea di comando:
"We currently support the following Google services:
Blogger
$ google blogger post --title "foo" "command line posting"
Calendar
$ google calendar add "Lunch with Jim at noon tomorrow"
Contacts
$ google contacts list name,email > contacts.csv
Docs
$ google docs edit --title "Shopping list"
Picasa
$ google picasa create --title "Cat Photos" ~/photos/cats/*.jpg
Youtube
$ google youtube post --category Education killer_robots.avi"

Va aggiunto che sulla pagina principale del progetto è possibile anche trovare degli script di esempio che fanno capire meglio le potenzialità di questo strumento.

La seconda cosa che è possibile notare è il codice Python, liberamente consultabile (e ci mancherebbe altro, mi sento di aggiungere), che meglio ci può far comprendere l'utilizzo delle API e la duttilità di questo linguaggio di programmazione.

for i in {ls -l /home/myhome/pictures/} do echo i | google picasa post --title "My Photos"

;)

lunedì 7 giugno 2010

Google I|O: Una fucina di idee!

Ogni anno viene riproposto un evento. No, scusate, ogni anno viene riproposto L'Evento: il Google I|O, dove le menti più brillanti fanno vedere cosa si può fare con le moderne tecnologie a disposizione.



Una cosa in particolare ha catturato la mia attenzione. A questo link è possibile visionare un tech talk di quasi un'ora sul nuovo linguaggio di programmazione (Go-language). Questo talk è tenuto da Russ Cox, papà del linguaggio.

La particolarità di questa presentazione è il fatto che Russ si spinge in dettagli avanzati come la gestione degli oggetti e dei tipi che sicuramente hanno bisogno di chiarimenti da parte di chi ha concepito il linguaggio.

Ma i regali di G. non finiscono qua. Sul blog ufficiale della sezione code di Google è possibile guardare tutti i tech talk fra cui App Engine e Wave.

Buona visione a tutti ;)