Rieccomi a parlare del fastidioso problema dello spam.
Nulla di particolare vi racconto l’analisi fatta su delle mail di spam che mi venivano recapitate 50/60 volte al giorno, e che apparentemente erano impossibili da intercettare.
Seconda parte del tutorial per la creazione di un relay antispam per un migliore filtraggio della posta in entrata.
Domandone per i lettori, entrate e vedete 
Se anche tu fai parte della schiera degli "scaricatori assassini" leggi attentamente quello che sta per seguire, ti semplificherà la vita…
Oggi parliamo di Mophant una GUI per il client multiprotocollo lphant…
Con la guida all’installazione di postfix, pubblicata un pò di tempo fa, installiamo a tutti gli effetti un completo server di posta con servizio pop/imap/smtp con ssl o senza, e con circa il 99% di volume di spam filtrato…
ma mi sono reso conto che proprio completo non è in quanto manca una piccola funzionalità…
Eggià, me ne sono accorto un paio di giorni fa quando mi sono reso conto che le mail di ebay non mi arrivavano; “vuoi vedere che vengono riconosciute come spam?” pensai, ed in effetti controllando i log qualche email riconosciuta come spam con dominio ebay c’era, ma si sa il campo from non è mai attendibile al 100%.
Ma venne in mente un problema che poteva essere serio, ossia quello dei falsi positivi, cioè le mail considerate spam ma che in realtà non lo sono.
E’ può essere un problema serio questo, mail talvolta importanti possono non essere mai lette a causa di questo problema. Ed il server cosi come l’abbiamo impostato mette si le mail in quarantena ma l’utente non riceverà mai la mail.
Preciso che, controllando meglio i log, di falsi positivi non c’è ne stato manco uno…questo perchè amavis+spamassassin+greylisting+controllo RBL e tutto il resto che abbiamo impostato è un sistema altamente efficiente ed affidabile (alla faccia dei superantispam da milioni di dollari); però può essere comodo avere una cartella di posta indesiderata dentro la quale spostare tutta la posta inutile.
Fortunatamente con amavis si può impostare anche spamassassin quindi con un unico file di configurazione riusciamo a fare tutto. Andiamo a modificare quindi il file /etc/amavis/conf.d/20-debian_defaults in particolare:
# abilito il report dello spam (score status ecc) nell’header delle mail
$sa_spam_report_header = 1;
con questa direttiva facciamo si che le mail controllate dall’antispam/virus vengano modificate nell’header aggiungendo l’avvenuto check e il relativo score ottenuto, poi dobbiamo modificare la direttiva:
$sa_tag_level_deflt = -9999;
il valore di default è 20.0, io ho messo -9999 cosi qualsiasi mail che passa dal server verrà segnata nell’header come “checked”, questo per provare che effettivamente clamav e spamassassin stanno svolgendo il loro lavoro.
$final_spam_destiny = D_PASS;
il valore di default è D_DISCARD, inserendo PASS facciamo si che la mail sebbene riconosciuta come spam non venga bloccata ma venga comunque consegnata all’utente, di modo da lasciare all’utente stesso la gestione dello spam.
$virus_quarantine_to = undef;
questo è un parametro che ho dovuto aggiungere, indica di non tenere la quarantena per la mail riconosciute come contenenti virus, vengono quindi rifiutate e non mantenute (che ce ne facciamo di mail con virus, di falsi positivi in questo caso non ne avremo mai è solo spazio occupato sul server).
$X_HEADER_LINE = “by $myproduct_name using ClamAV at $mydomain”;
con questa direttiva, facciamo in modo che nell’header della mail venga stampata la stringa:
X-Virus-Scanned: by amavisd-new using ClamAV at dominio.tld
poi riavviamo il servizio con:
# /etc/init.d/amavis restart
Lato server abbiamo finito. Adesso le mail considerate spam verranno comunque recapitate all’utente, il filtraggio vero e proprio sarà quindi affidato al client di posta. Da notare che abbiamo seguito una linea più elegante rispetto allo standard, infatti non abbiamo detto ad amavis di modificare l’oggetto della mail (come di solito si fa), aggiungendo ad esempio ***SPAM*** per permettere il filtraggio, ma lo abbiamo configurato in modo che ad essere modificato sia l’header della mail, cosi in caso di falsi positivi non avremo la Inbox tempestata di mail con ***SPAM*** sul subject.
L’header infatti, delle mail riconosciute come spam, ha una voce in più rispetto al normale:
X-Quarantine-ID: <id_quarantena>
possiamo quindi impostare i filtri a livello di header e non di subject inserendo come condizione…
->Se…
—-> Il campo X-Quarantine-ID
——–>Inizia con:
————> <
—————-> Sposta su:
——————–> Cartella Posta Indesiderata
Farlo su icedove/thunderbird è semplice, andiamo su strumenti e poi su filtri, e creiamone uno nuovo:
in questo caso il filtro antispam c’è già perchè l’ho creato prima 
ma facciamo finta che non c’è e creiamolo, ed impostiamolo cosi:
Il campo X-Quarantine-ID non lo vedrete mai perchè non c’è, ma nel menu a discesa c’è la voce personalizzato, e nella nuova finestra che appare dovrete scrivere a manina proprio quella voce (occhio è case sensitive), impostiamo la voce “inizia con”, e mettiamo come valore “<” praticamente per farla “funzionare” sempre, ogni volta che quel campo è presente (quindi in ogni mail di spam).
Finito, adesso tutte le mail di spam verranno taggate come SPAM e il client le sposterà nella cartella apposita, se eventualmente volete provare le modifiche ho creato un account su libero dal quale mi sono mandato un pò di spam per verificare il funzionamento, se non avete voglia di farlo anche voi lasciate scritto il vostro indirizzo di posta nei commenti (ma mi raccomando che sia una casella di prova altrimenti verrete bersagliati di spam dai lamer che girano su internet), od in alternativa scrivetemelo su una mail.
Questa parte funge da approfondimento, propongo un tweak per aumentare la sicurezza e le prestazioni del nostro MTA…
Una volta messo in piedi il nostro servizio di relay di posta, dobbiamo farci la croce e prepararci a quando verremo letteralmente invasi dallo spam.
Circa un buon 60-70% del volume di spam in entrata verrà filtrato con successo da spamassassin, ma non è abbastanza soprattutto su server con alti picchi di traffico.
Ed è soprattutto a questa tipologia di server che servirà questo tutorial, chi “bazzica” infatti da tempo nell’ambiente sistemistico linux, sa bene come spamassassin non è un assassino solo per lo spam, ma anche per la cpu quando il traffico inutile diviene importante.
E’ necessario quindi effettuare ulteriori controlli, per arrivare addirittura al punto in cui lo spam non riesce nemmeno ad entrare nel server, vediamo come:
Il primo passo sta nell’applicare alcune policy, di modo che postfix in fase di connessione faccia alcuni check, qualora uno di questi non andasse a buon fine la mail verrà rifiutata; editiamo quindi /etc/postfix/main.cf
### Checks to remove badly formed email
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
unknown_address_reject_code = 554
unknown_hostname_reject_code = 554
unknown_client_reject_code = 554
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, regexp:/etc/postfix/helo.regexp, permit
### When changing sender_checks, this file must be regenerated using postmap , to generate a Berkeley DB
smtpd_recipient_restrictions =
check_client_access hash:/etc/postfix/helo_client_exceptions
check_sender_access hash:/etc/postfix/sender_checks,
reject_invalid_hostname,
### Can cause issues with Auth SMTP, so be weary!
reject_non_fqdn_hostname,
##################################
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_unauth_destination,
# Add RBL exceptions here, when changing rbl_client_exceptions, this
#file must be regenerated using postmap , to generate a
#Berkeley DB
check_client_access hash:/etc/postfix/rbl_client_exceptions,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rhsbl_sender dsn.rfc-ignorant.org,
check_policy_service inet:127.0.0.1:60000
permit
con queste direttive forniamo prima di tutto una lista di blacklist dalle quali postfix può controllare se l’ip di provenienza è già segnalato come ip di spam, ed inoltre alcune policy di errore definitivo (554), per determinati eventi.
Se eventualmente vogliamo estendere la lista di rbl possiamo reperire altri link qui.
Adesso dobbiamo creare il file /etc/postfix/helo.regexp ed inserirci queste stringhe:
/^subdomain\.host\.com$/ 550 Don’t use my own hostname
/^xxx\.yyy\.zzz\.xxx$/ 550 Don’t use my own IP address
/^\[xxx\.yyy\.zzz\.xxx\]$/ 550 Don’t use my own IP address
/^[0-9.]+$/ 550 Your software is not RFC 2821 compliant
/^[0-9]+(\.[0-9]+){3}$/ 550 Your software is not RFC 2821 compliant
con questo file riusciamo a bloccare gli spammers che provano a presentarsi con un helo impersonando il nostro stesso server, oppure che inviano traffico che non rispetta l’rfc 2821.
Possiamo creare un file di eccezioni, per ip che possono by-passare il check fqdn di cui sopra, creiamo quindi il file /etc/postfix/helo_client_exceptions:
#These client IP addresses are allowed to bypass fqdn checks
# Some Comment to identify IP address below
#www.xxx.yyy.zzz OK
A volte capita che alcuni server non siano capaci di mandare in maniera corretta il comando di helo, e quindi dobbiamo inserire il loro ip in questa lista per permettergli di fare traffico con noi.
ATTENZIONE: ogni qualvolta questo file viene modificato, lo si deve ricaricare in postfix col comando:
postmap /etc/postfix/helo_client_exceptions
Adesso creiamo il file /etc/postfix/rbl_client_exceptions:
## Some Random comment
#www.xxx.yyy.zzz OK
con questo file creiamo un database di eccezioni di ip dal controllo rbl, anche questo va ricaricato con postmap. Finito questo ricarichiamo postfix e apprestiamoci ad applicare un ultimo meccanismo di antispam (il mio preferito).
Recentemente è stata introdotta una tecnica di prevenzione antispam, che consente di ridurre il volume di spam di oltre il 90%. Tale tecnica si chiama greylisting e si basa su un concetto molto semplice:
Gli spammer non hanno a disposizione cluster di relay di posta, molto spesso fanno uso di script che si collegano direttamente ai server destinatari e mandano migliaia e migliaia di mail ad altrettanti indirizzi, una sola volta, non interessa infatti quante ne giungono a destinazione, interessa solo generare traffico e sovraccaricare i server; e soprattutto non possono star li a riprovare ad ogni email fallita, in quanto sanno bene che molte di quelle sono email non più esistenti magari, il tentativo quindi viene fatto una sola volta.
Quando invece viene mandata una mail attraverso un sistema di posta, noi ci colleghiamo all’smtp del nostro fornitore di servizi internet, tale server tiene la nostra mail in coda e tenta di contattare il server di posta destinatario, qualora il tentativo di relay della mail non avesse successo, il server mittente fa in automatico altri tentativi ad intervalli di tempo regolari (3/4 tentativi massimo dipende dalla configurazione), falliti anche questi la mail viene cestinata ed al mittente viene ritornato un messaggio d’errore.
Il principio di greylist si basa proprio su questo, inizialmente io rifiuto tutte le mail dando un errore di tipo temporaneo (440), cosi il mittente sa che “ho un problema temporaneo sul server” e quindi dovrà riprovare tra un pò, nel frattempo registro il suo hostname ed il suo ip, come “temporaneamente bannato”; di default questo avviene per un arco massimo di 5 minuti, che sono variabili in base alla conf.
Passati i 5 minuti quando il mittente riprova a mandarmi la mail, io alla connect vedo che quell’host con quell’ip è già stato greylistato, quindi non riapplico la policy e lo lascio passare ai successivi controlli antivirus/antispam.
Un messaggio di spam quindi viene rigettato sin da prima che esso entri sul server, quando lo script dello spammer mi contatta io inizialmente gli rifiuto tutto, tanto lo script non rifarà un altro tentativo e la mail non entrerà mai sul mio server e spamassassin non commette svariati omicidi sulla mia cpu 
Vediamo quindi come impostare il greylisting su postfix, i repo ci vengono in aiuto:
apt-get install postgrey
poi editiamo il file /etc/default/postgrey inserendo un parametro alla stringa POSTGREY_OPTS:
POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=60"
inserendo il parametro –delay infatti abbassiamo il tempo di “ban” che di default è di 5 minuti (che secondo me è troppo) e 60 secondi. Poi riavviamo postgrey:
/etc/init.d/postgrey restart
Adesso dobbiamo dire a postfix di fare ciò che gli dice postgrey prima di qualsiasi operazione, editiamo il file /etc/postfix/main.cf ed aggiungiamo le righe:
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
check_policy_service inet:127.0.0.1:60000
adesso ricarichiamo la conf in postfix:
postfix reload
Finito, ammirate la purezza e la pace che regnano nella vostra casella di posta totalmente priva di spam
Con questo abbiamo anche concluso la serie di tutorials sulla messa in piedi di un relay di posta. Recapitolando ora abbiamo a disposizione un server smtp, con un efficace sistema antispam ed antivirus, contornato da un completo pannello di controllo per la gestione dei domini e degli amministratori, un servizio di webmail, e la possibilità di far autenticare i nostri utenti via pop ed imap con o senza ssl, cosa volere di più dalla vita? Un Lucano??!! O_o
Adesso che abbiamo installato e configurato il db e l’smtp vero e proprio, tocca configurare i programmi “accessori”, partiamo da Courier il demone che permetterà ai nostri utenti di autenticarsi attraverso i protocolli pop ed imap.
la prima cosa da fare è dire “al corriere” (courier ndr.), di effettuare l’autenticazione sul db e non sul sistema, andiamo quindi a modificare la stringa authmodulelist del file /etc/courier/authdaemonrc.
authmodulelist="authmysql"
adesso dobbiamo cancellare il contenuto di /etc/courier/authmysqlrc e sostituirlo con altri valori, dopo averne fatto una copia di backup ovviamente:
cp /etc/courier/authmysqlrc /etc/courier/authmysqlrc_orig
cat /dev/null > /etc/courier/authmysqlrc
e incolliamoci dentro:
MYSQL_SERVER localhost
MYSQL_USERNAME mail_admin
MYSQL_PASSWORD mail_admin_password
MYSQL_PORT 0
MYSQL_DATABASE mail
MYSQL_USER_TABLE users
MYSQL_CRYPT_PWFIELD password
#MYSQL_CLEAR_PWFIELD password
MYSQL_UID_FIELD 5000
MYSQL_GID_FIELD 5000
MYSQL_LOGIN_FIELD email
MYSQL_HOME_FIELD "/home/vmail"
MYSQL_MAILDIR_FIELD CONCAT(SUBSTRING_INDEX(email,'@',-1),'/',SUBSTRING_INDEX(email,'@',1),'/')
#MYSQL_NAME_FIELD
MYSQL_QUOTA_FIELD quota
fatto questo diamo il restart al demone courier:
/etc/init.d/courier-authdaemon restart
/etc/init.d/courier-imap restart
/etc/init.d/courier-imap-ssl restart
/etc/init.d/courier-pop restart
/etc/init.d/courier-pop-ssl restart
adesso per testarne il funzionamento possiamo effettuare un telnet su localhost sulla porta pop3, e se otterremo risposta allora significa che tutto è andato bene:
logubuntu:/var/log# telnet localhost pop3
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
+OK Hello there.
quit
+OK Better luck next time.
Connection closed by foreign host.
Per la gestione dei sistemi di posta, generalmente viene utilizzato un account “fittizio” chiamato mailer_deamon o postmaster, o come si vuole…noi in questo tutorial abbiamo scelto di utilizzare il postmaster, però non può essere un vero e proprio account finto, deve puntare a qualcosa, ed essendo l’account di management dell’MTA dobbiamo definire in /etc/aliases che esso punti al nostro account root del server:
postmaster: root
root: postmaster@yourdomain.tld
ricordiamoci che ogni volta modifichiamo il file degli alias dobbiamo ricaricarlo col comando newaliases. Definito l’alias riavviamo postfix…
Secondo me dopo l’aids il secondo virus del nuovo millennio sono gli spammer, gente che molesta la serenità altrui con stupidi messaggi pubblicitari, spesso dietro compenso. Al giorno d’oggi non esiste server di posta che non abbia un servizio antispam, e giorno dopo giorno questo servizio si deve evolvere e migliorare. Sul nostro server abbiamo deciso di implementare un meccanismo di content analyzing accoppiando con amavisd-new sia ClamaV per i virus, che spamassassin per le mail di spam:
apt-get install amavisd-new spamassassin clamav clamav-daemon zoo unzip bzip2 unzoo libnet-ph-perl libnet-snpp-perl libnet-telnet-perl nomarch lzop pax
dopo averli installati quindi andiamo a decommentare le stringhe che attivano il check antivirus ed antispam nel file di amavisd /etc/amavis/conf.d/15-content_filter_mode:
@bypass_virus_checks_maps = (
\%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
——
@bypass_spam_checks_maps = (
\%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);
eventualmente potete anche dare una modifica alle policy antispam/antivirus nel file /etc/amavis/conf.d/20-debian_defaults, di default i valori vanno bene per gli usi più generali, ma è bene sapere che potete gestirlo come meglio credete.
Dopodiche andiamo a modificare /etc/amavis/conf.d/50-user aggiungendo una stringa:
$pax='pax';
modificata la configurazione andiamo quindi a riavviare sia clamav che amavisd:
adduser clamav amavis
/etc/init.d/amavis restart
/etc/init.d/clamav-daemon restart
/etc/init.d/clamav-freshclam restart
adesso andiamo ad istruire postfix in modo che esso passi tutte le mail ad amavisd per il content filtering:
postconf -e 'content_filter = amavis:[127.0.0.1]:10024'
postconf -e 'receive_override_options = no_address_mappings'
cosi facendo qualsiasi mail che arriverà, verrà prima spedita verso 127.0.0.1 alla porta 10024, verso amavisd, dopo che clamav e spamassassin avranno fatto il loro lavoro, se la mail non è di spam, questa verrà rispedita a postfix attraverso 127.0.0.1 sulla porta 10025, per fare questo però dobbiamo aggiungere al file /etc/postfix/master.cf alcune righe:
amavis unix – - – - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes127.0.0.1:10025 inet n – - – - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_bind_address=127.0.0.1
fatto questo riavviamo postfix; adesso se diamo “netstat -tap” vedremo che si sono aperte due porte, rispettivamente la 10024 e la 10025, la prima è ascoltata da amavis, la seconda da master, che altri non è che postfix:
tcp 0 0 localhost.localdo:10024 *:* LISTEN 14491/amavisd (mast
tcp 0 0 localhost.localdo:10025 *:* LISTEN 14869/master
Spamassassin da solo non ce la può fare, sebbene sia un ottimo motore antispam. Possiamo quindi affiancarlo con altri spamfilters che sono mirati soprattutto all’antiphishing:
apt-get install razor pyzor dcc-client
e poi modifichiamo /etc/spamassassin/local.cf per dire a spamassassin di fare riferimento a loro per un ulteriore livello di content filtering, aggiungiamo quindi:
# dcc
use_dcc 1
dcc_path /usr/bin/dccproc
dcc_add_header 1
dcc_dccifd_path /usr/sbin/dccifd#pyzor
use_pyzor 1
pyzor_path /usr/bin/pyzor
pyzor_add_header 1#razor
use_razor2 1
razor_config /etc/razor/razor-agent.conf#bayes
use_bayes 1
use_bayes_rules 1
bayes_auto_learn 1
e poi restartiamo amavis:
/etc/init.d/amavis restart
Se vi ricordate ad inizio tutorial vi ho fatto patchare i sorgenti di postfix, in quanto questo di default non ha abilitata la gestione delle quote delle caselle, ma non possiamo, una volta che il sistema è a regime, andare ogni giorno a verificare quante e quali caselle sono “over quota”. Andiamo quindi a scaricare uno script da inserire in crontab per la notifica automatica:
cd /usr/local/sbin/
wget http://puuhis.net/vhcs/quota.txt
mv quota.txt quota_notify
chmod 755 quota_notify
poi andiamo a modificarlo per adattarlo alle nostre esigenze, in particolare modificando le prima righe:
my $POSTFIX_CF = “/etc/postfix/main.cf”;
my $MAILPROG = “/usr/sbin/sendmail -t”;
my $WARNPERCENT = 80;
my @POSTMASTERS = (‘postmaster@yourdomain.tld’);
my $CONAME = ‘My Company’;
my $COADDR = ‘postmaster@yourdomain.tld’;
my $SUADDR = ‘postmaster@yourdomain.tld’;
my $MAIL_REPORT = 1;
my $MAIL_WARNING = 1;
e dando un occhio alle ultime due:
print “Subject: WARNING: Your mailbox is $lusers{$luser}% full.\n”;
[...]
print “Your mailbox: $luser is $lusers{$luser}% full.\n\n”;
fatto questo aggiungiamo la seguente stringa al nostro crontab:
0 0 * * * /usr/local/sbin/quota_notify &> /dev/null
adesso facciamo una piccola verifica, dobbiamo vedere se il nostro postfix è configurato correttamente per l’autenticazione tramite starttls:
logubuntu:/var/log# telnet localhost smtp
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
220 mail.logubuntu.it ESMTP Postfix (Debian/GNU)
ehlo localhost
250-mail.logubuntu.it
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
221 2.0.0 Bye
Connection closed by foreign host.
se vediamo le due stringhe in grassetto allora possiamo tranquillizzarci
Bene, adesso il sistema è pronto e funzionante, non ci resta che popolare il database per le varie caselle, ma siccome il sistema che voglio configurare deve essere il più possibile completo, nei prossimi articoli andremo a vedere come installare una webmail e un pannello di controllo per amministratori di dominio, cosi da non doverci impelagare in query sql illeggibili
In questi giorni mi sono dedicato al nuovo vps in quanto volevo mettere in piedi un servizio di posta che fosse il più possibile completo…
l’intenzione era infatti di redigere questo how-to, che vi guidasse nella creazione di un MTA completo di pannello di controllo per amministratori, antispam, antivirus, greylisting, webmail, imap, pop, ed ssl per le comunicazioni criptate; e la gestione dei domini e degli utenti sarà virtuale, questo significa che ci appoggeremo ad un server mysql per la loro registrazione anzichè dover creare vere e proprie utenze sul sistema come normalmente di sovrebbe fare, ed inoltre effettueremo un patching di postfix per abilitare la gestione delle quote sulle mailbox degli utenti.
il principio di funzionamento è il seguente: postfix riceve una mail, inizialmente risponde con un errore non definitivo (440) segnalando il greylist, ed invitando a riprovare dopo 5 minuti, al secondo tentativo da parte del mittente, dopo aver controllato tramite saslauthd che l’indirizzo di destinazione sia presente sul database, e quindi valido, effettua una connessione tramite amavisd (in localhost) per passare la mail a clamav e spamassassin per il content filtering, se la mail passa anche questo controllo viene rispedita a postfix che effettuerà il local delivery verso la casella dell’utente.
Il software utilizzato sarà:
Partiamo; come già detto nel titolo, il sistema è rivolto agli utilizzatori di sistemi debian stable (etch, con sarge cambia qualcosina quindi se volete utilizzarlo documentatevi un pò prima ci sono numerosi how-to in giro), teoricamente dovrebbe funzionare anche con ubuntu, al limite può cambiare il nome di qualche pacchetto, anche in questo caso…chiedete a me o documentatevi eventualmente, io farò il possibile per aiutarvi.
Aggiorniamo il sistema se non l’abbiamo già fatto ed installiamo i primi pacchetti (do per scontato che stiate lavorando come root):
apt-get install postfix postfix-mysql postfix-doc mysql-client mysql-server courier-authdaemon courier-authlib-mysql courier-pop courier-pop-ssl courier-imap courier-imap-ssl postfix-tls libsasl2 libsasl2-modules libsasl2-modules-sql sasl2-bin libpam-mysql openssl phpmyadmin apache2 libapache2-mod-php5 php5 php5-mysql
Con questo comando andremo ad installare il mail server postfix, courier per l’autenticazione tramite pop/imap, saslauthd per la gestione dell’autenticazione in plain text con le librerie sasl, ed infine il database mysql con l’interfaccia phpmyadmin per il management via web-gui del database. Durante la configurazione dei pacchetti ci verranno poste alcune domande:
Create directories for web-based administration ? <– No
General type of configuration? <– Internet Site
Mail name? <– server1.example.com
SSL certificate required <– Ok
Fatto questo dobbiamo applicare una patch ai sorgenti di postfix, con tale patch abiliteremo la gestione delle quote delle caselle, che di default non è presente in postfix.
apt-get install build-essential dpkg-dev fakeroot debhelper libgdbm-dev libldap2-dev libpcre3-dev libssl-dev libsasl2-dev postgresql-dev po-debconf dpatch libdb4.3-dev libmysqlclient15-dev lsb-release libcdb-dev
Dopo avere scaricato i pacchetti necessari scarichiamo i sorgenti di postfix:
cd /usr/src
apt-get source postfix
E poi controlliamo la versione che abbiamo, per scaricare poi la patch apposita:
postconf -d | grep mail_version
Sul mio server ad esempio ho:
logubuntu:~# postconf -d | grep mail_version
mail_version = 2.3.8
milter_macro_v = $mail_name $mail_version
In questo caso quindi, scarichiamo la patch per la versione 2.3.8:
wget http://vda.sourceforge.net/VDA/postfix-2.3.8-vda.patch.gz
gunzip postfix-2.3.8-vda.patch.gz
cd postfix-2.3.8
patch -p1 < ../postfix-2.3.8-vda.patch
Prima di creare il pacchetto però dobbiamo effettuare un piccolo cambiamento al file di changelog, cosi com’è infatti avremo un pacchetto di versione 2.3.8-2 che creerà problemi di dipendenze con il pacchetto postfix-pcre che ha per dipendenza necessaria la versione 2.3.8-2+b1:
nano debian/changelog
e cambiamo nella prima riga 2.3.8-2 con 2.3.8-2+b1 salviamo e chiudiamo:
dpkg-buildpackage
e creiamo il pacchetto deb (in realtà ne verranno creati di diversi) che poi andremo ad installare:
cd ..
dpkg -i postfix_2.3.8-2+b1_i386.deb
dpkg -i postfix-mysql_2.3.8-2+b1_i386.deb
Adesso andremo a preparare il database con le tabelle che conterranno le caselle di posta dei nostri utenti.
Di default mysql server viene installato con l’utenza root senza password, la prima cosa che facciamo è quindi impostarla:
mysqladmin -uroot password propria_password
Adesso creiamo il database di postfix, l’utente mail_admin con i relativi privilegi, e inseriamo le tabelle necessarie:
mysqladmin -u root -p create mail
mysql -u root -p
GRANT SELECT, INSERT, UPDATE, DELETE ON mail.* TO 'mail_admin'@'localhost' IDENTIFIED BY 'mail_admin_password';
GRANT SELECT, INSERT, UPDATE, DELETE ON mail.* TO 'mail_admin'@'localhost.localdomain' IDENTIFIED BY 'mail_admin_password';
FLUSH PRIVILEGES;
USE mail;
CREATE TABLE domains (
domain varchar(50) NOT NULL,
PRIMARY KEY (domain) )
TYPE=MyISAM;
CREATE TABLE forwardings (
source varchar(80) NOT NULL,
destination TEXT NOT NULL,
PRIMARY KEY (source) )
TYPE=MyISAM;
CREATE TABLE users (
email varchar(80) NOT NULL,
password varchar(20) NOT NULL,
quota INT(10) DEFAULT '10485760',
PRIMARY KEY (email)
) TYPE=MyISAM;
CREATE TABLE transport (
domain varchar(128) NOT NULL default '',
transport varchar(128) NOT NULL default '',
UNIQUE KEY domain (domain)
) TYPE=MyISAM;
quit;
Come è facile immaginare, la tabella domain conterrà i vari domini che gestirà il nostro server, nella tabella forwardings saranno presenti le caselle alias per redirezionare il traffico verso una casella reale, nella tabella users avremo lo username dell’utente, che è poi la stessa casella di posta, la password (criptata ovviamente), e la quota massima che può occupare la casella.
La tabella transport è opzionale, ed è per un utilizzo più avanzato, in questa tabella inseriamo i dati necessari per far si che il server possa reinstradare le mail per una singola casella, o per un intero dominio, verso un altro server.
Due gioni fa mi ero deciso a provare il nuovo kernel linux con Hardy heron, come oramai sono solito fare…ecco le mie prime impressioni…
Vi anticipo che, almeno nella mia esperienza, non è tutto rose e fiori…
Nel complesso il kernel va più che bene, stabile e funzionale, una fracca di moduli e driver aggiuntivi (che a me non servono) e come al solito “a lot of bugfixes” come si dice sempre alla release di un qualsiasi software…
Ma morto un baco se ne fa un altro (mi pare si dicesse cosi ) in particolare un paio di mio diretto interesse riguardanti la mia scheda wireless, ed altri non riguardanti me, motivo che mi ha indotto a provarlo, come già anticipato nell’articolo sopra linkato…
[ 21.330295] pnpacpi: exceeded the max number of mem resources: 12
…
* Starting Avahi mDNS/DNS-SD Daemon avahi-daemon
Timeout reached while waiting for retun value
Could not receive return value from daemon
Questo come dicevo, il motivo di fondo che mi ha indotto a provare questo kernel, il primo è solo un warning e dalla mailling list di lkml, direttamente dalla tastiera di linus, sembra che non siano interessati a portare il numero massimo da 12 a 16, per questioni di righe di codice e di grandezza del modulo…
Il secondo sembra essere un bug legato ad apparmor, peraltro già presente in feisty, che in alcune macchine manda in timeout il demone avahi; bug risolto con gutsy e speriamo non si ripresenti in hardy
La mia serenità non è stata turbata in quanto fortunatamente la mia macchina non soffre di questo bug, i miei problemi sono ben altri 
Al riavvio dopo l’installazione del mio nuovo kernel noto che la scheda wireless (ipw3945) non funziona, all’inizio mi stranisco un attimo perchè mi aspettavo che i driver venissero riconosciuti correttamente essendo già stati compilati…ma va beh…dare un altro make non costa nulla; se non fosse che i driver sembrano NON compilare con questo kernel -.-’ (come riavvio mi salvo gli errori in un wordpad e aggiorno l’articolo).
Poco male…ho di fronte un kernel che mi permette di utilizzare i driver open della mia scheda, quindi armiamoci di pazienza aggiungiamo il modulo e riproviamo…già mi insospettisco quando, aggiunto il modulo, do:
sudo make modules modules_install
e il modulo non viene installato 
controllo e ricontrollo che sia tutto a posto, lo è…allora opto per la soluzione più drastica e semplice, aggiorno la revision del kernel e ricompilo. Ci riesco il modulo è dentro, peccato non poterlo compilare come statico (a differenza degli ipw2200), ma tanto verrà caricato all’avvio in automatico.
Essendo io, fondamentalmente un niubbo, non mi curo di vedere il dmesg al boot e lo ignoro completamente sicuro che tutto fosse a posto, mentre quando gnome mi saluta noto con piacere che la scheda non c’è…controllo dmesg e li trovo il corpo del reato:
iwl3945: iwlwifi-3945-1.ucode firmware file req failed
(chi sa quanti di voi si sono accorti dell’errore, voglio che mi dite la verità nei commenti 
)
ecco perchè la scheda non funziona, mi documento è trovo su bughost quest’altro bagarospo…
Poco male penso, recupero un firmware iwl, lo copio in /lib/firmware e riavvio…ma al riavvio:
iwlwifi: Error reading from microcode: 22
bene…non ho trovato un emerita fava su questo, l’unica soluzione è scaricare l’ultima versione del firmware iwl ed utilizzare quella, vi saprò dire in seguito…
Update: vi sto scrivendo da hardy con la mia scheda wireless come pensavo è bastato scaricare l’ultima versione del firmware ed applicare un semplice workaround:
wget http://www.logubuntu.it/wp-content/uploads/2008/01/iwlwifi-3945-ucode-2144.tgz
tar xvf iwlwifi-3945-ucode-2144.tgz
cd iwlwifi-3945-ucode-2.14.4
sudo cp iwlwifi-3945.ucode /lib/firmware && sudo mv iwlwifi-3945.ucode iwlwifi-3945-1.ucode
e poi riavviare
Che dire…il kernel va da dio, solo che farà smadonnare un pò di più a noi utilizzatori, ma d’altronde per noi geek ricompilatori assassini di kernel non è che un dolce passatempo
I posti dove puoi trovarmi sono:
If you enjoyed the post, make sure you subscribe to the RSS feed.
© 2010
Powered by WordPress. Design by 
