IMAP howto

Un nuovo HowTo scritto dal grande Ferdinando... ;)
Seguendo questo HowTo è possibile configurare un server di posta IMAP per scaricarla e leggerla con qualsiasi client.





IMAP Howto


Author: Ferdinando Ferranti
Contact: zap@teppisti.it
Revision: 0.1
Date: 13/01/2005
Copyright: Questo documento viene rilasciato sotto licenza GPL

Premessa

Motivazioni: cambio PC, finalmente una macchina che permette di usare qualsiasi software grafico etc. etc.
Francamente sinora ho usato intensivamente la console sul mio pc, ma non perchè sono un fondamentalista ma piuttosto perchè se c'è una cosa che odio è attendere i comodi del mio pc. Forse sono appassionato di informatica proprio perchè sul mio pc io sono l'assoluto, faccio ciò che voglio e tutti mi devono ubbidire, immediatamente, pena la rimozione! ;-)))

In pratica, mi piace giocare con il pc a realizzare cose nuove, ma considero indispensabile la velocità, non accetto, per esempio, di attendere per leggere la posta e quindi finora sono sempre andato in cerca di software che mi garantissero la maggior efficienza, robustezza e velocità.
Niente di meglio che configurare il mio SMTP, ovvero Postfix,
Fetchmail per scaricare la posta, Procmail per distribuirla dove meglio ho creduto ed infine Mutt, un mitico MUA per console.
Per capirsi, Mutt va benissimo ed è soprattutto merito suo se sono arrivato a configurare il sistema che vado a descrivervi, perchè non volevo rinunciarvi, non si sa mai, se vuoi usare la posta in console come fai?
Sempre meglio avere a disposizione un'installazione funzionante di Mutt! :-)

Naturalmente il sistema, basato su mailbox di tipo mbox era veloce e prestante ma aveva un paio di difetti, il primo è che le mbox sono più delicate rispetto a quelle in formato Maildir ed il secondo era non permettere agevolmente di usare altri lettori di posta grafici e non. Si poteva anche fare, ma con tante mailbox per ogni Mailing List sottoscritta e caselle di posta remota, diventava tutto molto ma molto complicato. Senza contare poi che il nuovo MUA grafico era temporaneo perchè poi si rivelava lento e alla fin fine lo rimuovevo senza pietà! ;-)

Adesso invece ho un sistema totalmente nuovo e velocissimo, francamente mi stupisco delle prestazioni che hanno raggiunto i pc odierni, non ci volevo credere, in pratica adesso qualsiasi applicazione mi ritrovi ad aprire, non mi crea il minimo fastidio, non ho mai la sensazione di attendere troppo.

Quindi quale occasione migliore che configurare un sistema di posta più moderno, che permetta di utilizzare il più moderno formato Maildir e soprattutto sia trasparente alle applicazioni, permettendo, con pochissima fatica, di usare qualsiasi lettore di posta?

La mia risposta a queste esigenze è stata usare il protocollo IMAP per gestire la posta, precisamente il server Courier IMAP.

Per gli script del presente documento, considerate che i vari nomi che saltuariamente appaiono tra < o > vanno considerati come da sostituire, ad esempio <utente> può diventare zap, <nome host> può diventare daneel.foundation.loc etc. etc...
Dove appaiono direttamente nomi o host inventati è perchè è evidente che sono nomi da sostituire con i vostri.

Hardware

Si parte da una Debian GNU/Linux per realizzare un server di posta IMAP, questo perchè è la distribuzione che uso e quindi che conosco meglio, però non è che con qualsiasi altra distribuzione GNU/Linux o addirittura sistema operativo basato su *NIX il sistema che descriverò potrà essere molto diverso, anzi, suppongo varranno le medesime considerazioni. Si può dire altrettanto per il server di posta, esistono mille alternative, come anche per quanto riguarda software per scaricare la posta, come l'ottimo Getmail o Maildrop per smistare la posta.

Un'altra precisazione è d'obbligo, perchè altrimenti con tutte le accortezze che si dovranno mettere in atto si rischia pure di perdere l'obiettivo finale dell'Howto che è tutto sommato avere un sistema robusto ed efficiente di posta ed essere in grado di provare in tranquillità qualsiasi altro MUA che ci capiti sotto mano.

Usare un sistema complesso (soprattutto per il risultato) come quello che ci accingeremo a realizzare è tutto sommato "stupido", chi si mette ad usare un simile sistema o anche il solo server IMAP sulla stessa macchina senza connessioni esterne o ha veramente molto tempo da perdere o è uno squilibrato... ;-)))

Solo che a me fa piacere essere in grado di gestire un server di posta, specie adesso che con la tecnologia wireless e le connessioni a banda larga è sempre più semplice e comune avere una piccola LAN in casa.
Ovviamente, per ora, si fa affidamento di avere un solo computer, una connessione via modem e quindi non costante, magari potremmo
fare delle prove successivamente con un portatile, ne potrebbe uscire qualcosa di interessante interessante... ma dovremo tenere
conto che in questo caso questo sistema non è sicuro, quantomeno occorre usare Courier IMAP SSL, ovvero con autenticazione criptata. Insomma, magari per i più intraprendenti, a questo Howto sarebbe bello farne seguire una seconda parte, dove potremo usare metodi più sicuri e magari perchè no, a questo punto una webmail come ad esempio SquirrelMail! :-)

Per il momento però, dovremo inventarci un po' di file, perchè oggettivamente questo sistema presenta delle piccole pecche:

  • Solitamente le varie distribuzioni sistematicamente inseriscono degli script in /etc/ppp/ip-up.d/ (nel nostro caso sarà lo script postfix) che indicano al server che, non appena sia connesso, debba spedire la posta che si ritrova in coda;
  • Come conseguenza il sistema "salta" perchè la posta che spediremo non parte da un dominio valido, l'host su cui facciamo relay non autentica e quindi ci rientra subito alla base, non consegnata. Da notare che questo non avviene sempre ma solamente quando i server di destinazione (ormai quasi tutti) fanno un controllo se l'email di partenza è giunta da un dominio esistente.

In pratica il server di posta deve "tenere la posta in coda" fino al nostro comando e spedirla solamente dopo che ci saremo fatti autenticare dal "relayhost" che avremo deciso.

Non stiamo parlando di cose "turche", ma di piccoli accorgimenti che ci obbligheranno a rendere le cose forse un po' più complicate di quanto pensavamo.

Iniziamo subito con il bloccare l'invio automatico di posta non appena ci connettiamo, modificando come segue il file /etc/ppp/ip-up.d/postfix:

#!/bin/sh -e
# Called when a new interface comes up
# Written by LaMont Jones <lamont@debian.org>

# start or reload Postfix as needed
if [ ! -x /sbin/resolvconf ]; then
        cp /etc/resolv.conf $(postconf -h queue_directory)/etc/resolv.conf
        /etc/init.d/postfix reload >/dev/null 2>&1
fi

# If master is running, force a queue run to unload any mail that is
# hanging around.  Yes, sendmail is a symlink...
############ Mio commento ##############################################
#if [ -f /var/spool/postfix/pid/master.pid ]; then
#        pid=$(sed 's/ //g' /var/spool/postfix/pid/master.pid)
#        exe=$(ls -l /proc/$pid/exe 2>/dev/null | sed 's/.* //')
#        if [ "X$exe" = "X/usr/lib/postfix/master" ]; then
#               if [ -x /usr/sbin/sendmail ]; then
#                       /usr/sbin/sendmail -q
#               fi
#        fi
#fi
########################################################################

Con questo piccolo accorgimento ed una riga meglio descritta nel file di configurazione di Postfix saremo noi a dover decidere di spedire la posta manualmente, altrimenti rimarrà in coda in eterno! ;-)

I software coinvolti

Iniziamo a vedere le vostre variabili d'ambiente, se sono giuste, preparate per IMAP e la posta nel formato Maildir:

$ echo $MAIL
/var/mail/<utente>

In /etc/login.defs c'è anche da configurare la variabile per $MAILDIR:

...
# Ho decommentato QMAIL_DIR e commentato MAIL_DIR

QMAIL_DIR      Maildir/
#MAIL_DIR        /var/mail
#MAIL_FILE      .mail
...

Ottenendo:

$ echo $MAILDIR
/home/<utente>/Maildir/

Veniamo quindi agli strumenti che dovremo usare per ottenere un server IMAP funzionante, innanzitutto i software:

  1. Postfix, il server SMTP;
  2. Fetchmail, che "raccoglierà" la nostra posta in giro per il web;
  3. Sudo, che ci permetterà da utente di svolgere dei piccoli compiti amministrativi con permessi superiori;
  4. Procmail, che smisterà la posta ricevuta da fetchmail (questo per chi non lo sapesse è un MDA, Mail Delivery Agent);
  5. Courier IMAP ovvero il server IMAP di email in formato Maildir.

Postfix

Postfix è un server di posta "vero", non è assolutamente un giocattolo e anche se noi lo usiamo localmente, come se fosse un software per gestire la posta di un Desktop in realtà è un server SMTP in grado di smistare un numero spropositato di email al giorno, viene usato correntemente da molte organizzazioni presenti su web, anche ISP, in Italia per esempio, se non ricordo male, wind e tiscali per dirne due non proprio piccoli...
Ma anche altre organizzazioni se non useranno Postfix come SMTP useranno altri server analoghi, come Sendmail (che è stato il primo SMTP in circolazione) o Qmail o altri ancora come Exim o Courier.
Tutti questi software forniscono le funzionalità da server di posta e la loro presenza sostanzialmente è determinata da scelte
dell'amministratore del sistema più che dalla validità dell'uno o dell'altro prodotto.
Insomma, un po' come accade con gli utenti e le varie distribuzioni GNU/Linux, ognuno si affeziona alla sua, ma in linea di massima sono equivalenti, differiscono nei dettagli.

Per la configurazione della posta è molto semplice, innanzitutto io ho sostituito il server predefinito di Debian, ovvero Exim con Postfix, perchè lo preferisco, se non l'avete ancora fatto procedete a configurare il server: semplicemente eseguite `dpkg-reconfigure -plow postfix` e rispondete con "posta inviata tramite uno smarthost; ricevuta tramite via SMTP o fetchmail", in pratica questo significa che spediremo la posta "passando" (lo smarthost) da un provider in rete, solitamente quello che ci fornisce la connessione, dimodochè potremo essere autenticati ovunque.
Ci viene creato un nuovo host "virtuale", ovvero mail.<nomehost>.<nome dominio>, insomma, va bene così come suggerito!
Ci viene ulteriormente chiesto a chi deve essere indirizzata la posta, di norma ad un utente diverso da root, per una questione di sicurezza, sceglieremo quindi il nostro utente. Tutte queste opzioni potranno essere in futuro cambiate agevolmente con il medesimo procedimento.
Il file di configurazione, main.conf, verrà salvato in /etc/postfix/.
Dovrete aggiungervi qualche altra riga, come indicato sotto, precisamente defer_transports, sender_canonical_maps e virtual_maps, se volete spedire backup ad un'altro utente, anche la direttiva commentata always_bcc.

Per orientare meglio alla comprensione gli utenti che hanno una qualche altra distribuzione e poca dimestichezza con Postfix, qui a seguito alleghiamo il file di configurazione di Postfix /etc/postfix/main.cf, per meglio fugare i dubbi rimasti:

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

myhostname = daneel.foundation.loc
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.daneel.foundation.loc, daneel.foundation.loc, \
localhost.foundation.loc, localhost, daneel

#  Questa direttiva implica la trasmissione manuale della posta
#+ in coda, così facendo Postfix sta buono, non prova
#+ periodicamente a spedire la posta! ;-)))
defer_transports = smtp

#  La posta per poter spedire a chiunque, deve essere autenticata
#+ da un host esistente e fidato, quindi le nostre email
#+ passeranno prima da wind, poi andranno all'SMTP del destinatario
#+ che potrà fare affidamento sulla certificazione di inwind.
#+ Ovviamente questo se vi collegate mediante inwind, altrimenti
#+ dovrete usare l'ISP che usate per connettervi.
relayhost = mail.inwind.it

mynetworks = 127.0.0.0/8
mailbox_command = procmail -a "$EXTENSION"

# All'utente x verrà associata l'email predefinita Y
sender_canonical_maps = hash:$config_directory/sender_canonical

#  Se un altro SMTP vi consegna la posta per <utente>@inventato.it
#+ potrete specificare che tale email è dell'utente X
virtual_maps = hash:$config_directory/virtual

mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

#  Lo dice già il nome, spedisce ogni mail in copia carbone
#+ all'utente (in questo caso) backup, ma potrebbe essere
#+ qualunque utente. Insomma, un metodo veloce per fare backup...
#always_bcc = backup

Per fare veramente un lavoro fatto bene, è opportuno informare postfix, tramite due file, quali sono gli indirizzi che giungono sul nostro host ma che vanno considerati locali e quindi indirizzati ad uno specifico utente e con quali indirizzi email debbono essere convertiti i nostri indirizzi email locali, quindi ci appresteremo a scrivere due semplici file (e nel file di configurazione
già sono presenti):

/etc/postfix/sender_canonical

#  Converte il nome di un utente locale in indirizzo
#+ email in uscita da Postfix

<utente>              zap@teppisti.it

/etc/postfix/virtual

# Associa ad un utente locale un indirizzo email che riceverà Postfix:

zap@teppisti.it             <utente>
zap@zonapython.it           <utente>

Fetchmail

Fetchmail è il software che ci permette semplicemente di scaricare la posta da internet e depositarla nella nostra "cassetta della posta", ovvero nella nostra mailbox standard, normalmente residente in /var/mail/<utente>.
Usare fetchmail è molto semplice, il file di configurazione locale (~/.fetchmailrc) per il singolo utente, con una sola casella di posta remota da cui scaricare la posta potrebbere essere come il seguente:

~/.fetchmailrc

poll mail.acdc.it timeout 30 with proto POP3
user <user> there
with password "xxxxxxxxxx"
is <utente> here options mda "/usr/bin/procmail -f -" fetchall

Fetchmail è un software robusto, nato un bel po' di anni fa, non è un software poliedrico che fa 10.000 cose, scarica semplicemente la posta, però quest'unico compito lo fa bene, francamente non si sente in giro molta gente che ha perso la posta per colpa di fetchmail, anzi non si sente proprio nessuno! :-)

Sudo

Con Fetchmail dovremo creare un paio di script e specialmente ~/fetchmail-postfix conterrà un comando che necessita dei privilegi di amministratore per spedire la posta in coda dopo che ci saremo autenticati, come abbiamo visto in precedenza.
È quindi necessario prima di iniziare a scrivere i due script capire quale compito svolge Sudo.

In realtà è molto semplice, Sudo è un software che permette di regolare accessi a comandi solitamente destinati ad essere utilizzati solamente dall'amministratore del sistema. Molto semplicemente si possono associare comandi da amministratore ad utenti che svolgono per l'appunto compiti amministrativi, selezionando gruppi di comandi di cui si possono avvalere.
Naturalmente per quanto riguarda il nostro caso il tutto è ancora più semplice, ma fate attenzione, configurazioni errate del file /etc/sudoers possono creare falle di sicurezza a dir poco ferali!!!

/etc/sudoers

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL

User_Alias      FULLTIMERS = <utente>

Cmnd_Alias      REBOOT = /sbin/reboot
Cmnd_Alias      SHUTDOWN = /sbin/shutdown
Cmnd_Alias      HALT = /sbin/halt
Cmnd_Alias      TAIL = /usr/bin/tail
Cmnd_Alias      PLOG = /usr/bin/plog
Cmnd_Alias      MAILQ = /usr/bin/mailq
Cmnd_Alias      EXIM = /usr/sbin/exim
Cmnd_Alias      FLUSH = /usr/sbin/postfix

Defaults:FULLTIMERS    !lecture

FULLTIMERS      ALL=NOPASSWD: REBOOT, SHUTDOWN, HALT, TAIL, \
                    PLOG, MAILQ, EXIM, FLUSH

#<utente> ALL=NOPASSWD: /bin/cat

Come si può notare, io ho deciso che un particolare <utente> avrà a disposizione tutti i comandi del gruppo FULLTIMERS, una simile configurazione è molto comoda anche per estendere i vari comandi...

Un'alternativa è l'ultima riga del file di configurazione, attualmente commentata, ovvero, ad un particolare utente, viene concesso un singolo comando. Funziona anche così, ma aggiungere ogni comando è più noioso e soprattutto disordinato.

fetch.test

Torniamo quindi ai due script che fanno uso di Fetchmail e che ci permetteranno di autenticarci prima e di spedire poi in tutta tranquillità la posta in coda.

Il primo, fetch.test ci autenticherà al POP con il quale ci colleghiamo e che comunque sarà il POP che avremo indicato nel main.cf di Postfix per fare relay (nel nostro caso: relayhost = mail.inwind.it).

poll popmail.inwind.it timeout 600 with proto POP3
user <user> there
with password <password>
is <utente> here options mda "/usr/bin/procmail -f -" fetchall

Sembra un normale file di Fetchmail per scaricare la posta, ma richiamato con le opportune opzioni ci permetterà di autenticarci senza necessariamente scaricare la posta dal POP.

~/fetchmail-postfix

Adesso, potremo finalmente realizzare il nostro semplicissimo script:

#! /usr/bin/env sh

#  Il parametro -f di fetchmail indica il percorso per trovare il file
#+ di configurazione alternativo al canonico .fetchmailrc
#+ L'opzione -c invece ordina a fetchmail di controllare la posta ma
#+ di non eseguire altri compiti, come ad esempio scaricarla... ;-)
fetchmail -f fetch.test -c

read -p "scarico la posta e la invio? (s/n): " s

if [ $s == 's' ]; then
    echo
    echo "Ok, allora scarico la posta con fetchmail"
    echo "e spedisco anche la posta in coda..."
    echo
#  Eccolo qui... l'uso di sudo per svuotare la coda della posta
#+ e` necessario...
    sudo /usr/sbin/postfix flush
#  Infine viene lanciato fetchmail che, senza particolari
#+ opzioni, prendera` le sue direttiva dal file .fetchmailrc
    fetchmail
 else
    echo
    echo "Va bene, allora esco!!!"
    echo
fi

Procmail

Procmail è un Mail Delivery Agent, ovvero un software che serve a smistare la posta.
Come saprete i server di posta, come il nostro Postfix, svolgono solamente il compito, peraltro non semplice, di ricevere e trasmettere la posta, non la smistano ai vari utenti, normalmente la posta viene o spedita all'esterno del nostro host o "ricevuta" via internet.
I server di posta quando devono spedire fanno una cosa molto semplice, prendono l'email, controllano a quale server devono chiedere (dal dominio dell'email che hanno in carico) e poi si mettono a colloquiare, ovvero interrogare il server di posta che dovrebbe ricevere l'email per controllare se è giusto. Se i controlli vanno a buon fine, il server di posta destinatario acquisisce l'email e la deposita semplicemente in /var/mail/<utente>.
A questo punto poi deve entrare in azione un software che normalmente viene indicato già all'interno del file di configurazione del server di posta stesso, nel nostro caso, in /etc/postfix/main.cf:

mailbox_command = procmail -a "$EXTENSION"

come potete vedere, il nostro Postfix già è stato informato che, una volta giunta la posta sul nostro host, dovrà esserne lasciato il controllo per giungere alla vera destinazione finale a Procmail.
Vi chiederete perchè sto perdendo tutto questo tempo su Procmail, che all'apparenza non è un software così "importante" come Postfix o Fetchmail, in realtà dei tre è l'unico software che agisce solamente in locale. Ma voi non sapete ancora che proprio Procmail è un software "magico", vi darà la maggior parte delle soddisfazioni proprio nel gestire la posta, inizialmente potrà sembrarvi ostico, ma quando sarete riusciti a penetrarne una piccola parte dei segreti non ne potrete più fare a meno!

I file di configurazione sono molti, per una nostra scelta, e li inseriremo tutti (tranne quello principale) nella directory
~/Maildir/.Pm.
In pratica, nel primo file definiremo le variabili che ci potranno essere utili, come ad esempio dove verrà recapitata la posta, la
directory principale ed il percorso per richiamare tutti gli altri file di configurazione; quest'ultimi verranno divisi secondo un senso "logico", almeno per noi ;-)

Quindi avremo, per il file di configurazione ~/.procmailrc:

~/.procmailrc

MAILDIR = $HOME/Maildir/   # Maildir, qui finiranno le
#+ email non processate da altre regole...
PMDIR = $HOME/Maildir/.Pm   # create anche questa dir (e le altre...)
PMSRC = $PMDIR

# Se proprio non ce la fate a creare le maildir, questo script
#+ lo fara` per voi... ;-)

DUMMY=`test -d $MAILDIR || maildirmake $MAILDIR`
DUMMY=`test -d $PMDIR || mkdir $PMDIR`
DUMMY=`test -d $MAILDIR/.Sent-mail || maildirmake $MAILDIR/.Sent-mail`

#varie
SHELL=/bin/sh
LINEBUF=8192
PATH=$HOME/bin:/bin:/usr/bin:/usr/local/bin

#  Se non definita, le email solitamente finiscono in
#+ /var/spool/mail/nomeutente.
DEFAULT=$MAILDIR/

FORMAIL=/usr/bin/formail    #  path di formail, usato per processare
#+ alcune email
SENDMAIL=/usr/sbin/sendmail # path di sendmail

# log -- Usate mailstat: `mailstat ~/Maildir/.Pm/pm.log`
VERBOSE = no   # impostare a "no" dopo il debug, produce log MOLTO estesi
LOGABSTRACT = yes   # se non si vogliono log impostare a "no"
LOGFILE = $PMDIR/pm.log   # dove troveremo i file di log

#  Variabili utili (possono essere usate nelle regole per abbreviarne
#+ la scrittura, ad esempio come $NomeVariabile)
NL = "
" # nuova linea (un invio tra "")
WSPC = "    "   # blank: spazio + tab
SPC = "[$WSPC]"   # Regexp: spazio + tab
SPCL = "($SPC|$)"   # spazio o tab o nuova linea
NSPC = "[^$WSPC]"   # NON spazio o tab
s = $SPC   # abbreviazione: come in Perl \s
d = "[0-9]"   # una cifra -- Perl \d
w = "[0-9a-z_A-Z]"   # una parola alfanumerica -- Perl \w
W = "[^0-9a-z_A-Z]"   # NON una parola alfanumerica  -- Perl \W
a = "[a-zA-Z]"   # una parola, solo alfabetica

# imposta la variabile DATE come "mese_esteso-anno" attenzione,
# gli apici sono inversi, quindi ALT-GR più l'apice normale!
DATE = `date +%B-%Y`

#file .rc aggiuntivi
INCLUDERC = $PMDIR/general.rc   #  file generico a cui delegare
# diversi "lavoretti", backup o rimozione di doppioni ad esempio...
INCLUDERC = $PMDIR/lists.rc     # Per le varie ML a cui siamo iscritti
INCLUDERC = $PMDIR/friends.rc   # Per le email private, amici etc. etc.

Il nostro ~/.procmailrc è quindi pronto, i commenti dovrebbero essere esaustivi, anche se forse è il caso di anticipare qualcosa riguardo al comando maildirmake che viene usato nel file di configurazione.

maildirmake è un comando facente parte del pacchetto courier-base, ovvero pacchetto richiesto necessariamente (sto ovviamente parlando di Debian) da courier-imap.
In pratica quel comando, installando il server IMAP di Courier ve lo ritroverete disponibile e sarà necessario per creare le varie Maildir che vi serviranno.

Con maildirmake pippo creerete una maildir completa, ad esempio:

$ maildirmake pippo
$ ls -la pippo/
drwx------   5  120 2006-02-05 17:02 .
drwxrwxrwt  12  472 2006-02-05 17:01 ..
drwx------   2   48 2006-02-05 17:00 cur
drwx------   2   48 2006-02-05 17:00 new
drwx------   2   48 2006-02-05 17:00 tmp

Mentre con maildirmake -f pippa pippo/ otterrete una cartella, naturalmente predisposta per accogliere posta nel formato Maildir, all'interno di una maildir. Prima di fornirvi l'esempio è forse utile ricordarvi che ognuna delle directory create con questa opzione -f diventerà una cartella dove i filtri che creeremo con Procmail smisteranno le varie email.

$ maildirmake -f pippa pippo/
$ ls -la pippo/
drwx------   5  120 2006-02-05 17:02 .
drwxrwxrwt  12  472 2006-02-05 17:01 ..
drwx------   2   48 2006-02-05 17:00 cur
drwx------   2   48 2006-02-05 17:00 new
drwx------   5  152 2006-02-05 17:06 .pippa
drwx------   2   48 2006-02-05 17:00 tmp

$ ls -la pippo/.pippa
drwx------  5   152 2006-02-05 17:06 .
drwx------  6   144 2006-02-05 17:06 ..
drwx------  2    48 2006-02-05 17:06 cur
-rw-------  1     0 2006-02-05 17:06 maildirfolder
drwx------  2    48 2006-02-05 17:06 new
drwx------  2    48 2006-02-05 17:06 tmp

Le altre opzioni, per rendere le maildir condivisibili ed altre ancora, le potrete leggervele sulla pagina man: $ man maildirmake.

~/Maildir/.Pm/general

Ricordo a tutti i lettori che, a parte la maildir principale ~/Maildir le altre (come ad esempio .Lists.ML-debian-italia) andranno create con maildirmake e l'opzione -f.

Inoltre, dove nei file potrete leggere mailbox si intenderà una mailbox in formato mbox ed invece dove troverete mailbox/ si intenderà una mailbox in formato maildir.

#  Esegue il backup di tutte le email in ingresso
#+ N.B.: se non si vuole un backup compresso, si
#+ dovranno invertire i caratteri di commento ("#")
#+ NB "backup.gz è una mailbox in formato mbox!
	:0c
|gzip -9fc >> backup.gz
#:0c:
#.backup

# corregge possibili intestazioni from errate
	:0fhw:pippo.lock
| $FORMAIL -I "From " -a "From "


#  In pratica questo e` un filtro per lo SPAM che funziona "se" il
#+ vostro fornitore di servizio email contrassegna le email con un
#+ bel simbolo [SPAM] nel "Subject" altrimenti non va...
	:0
* ^Subject: .*SPAM]
.Lists.SPAM/

#  killfile = Tizio
#+ NON vogliamo ricevere email da pincopallino@...
	:0
* ^From: .*pincopallino@tiscalinet.it
.Lists.SPAM/

# elimina i messaggi doppi, copiandoli per sicurezza in un file
	:0Whc:msgid.lock
| $FORMAIL -D 8192 $PMDIR/msgid.lock
	:0a:
.duplicati/


#  La forma "^TO_" viene espansa da Procmail e corrisponde a
#+ molti destinatari tra cui To, Cc, Bcc etc. etc.
#+ Comunque, in breve, tutto cio` che e` diretto a root finisce
#+ nella maildir .INadmin/
	:0:
* ^TO_root
.INadmin/

#correzione vecchi messaggi pgp
	:0
* !^Content-Type: message/
* !^Content-Type: multipart/
* !^Content-Type: application/pgp
{
	:0 fBw
    * ^-----BEGIN PGP MESSAGE-----
    * ^-----END PGP MESSAGE-----
    | formail -i "Content-Type: application/pgp; format=text; x-action=encr

	:0 fBw
    * ^-----BEGIN PGP SIGNED MESSAGE-----
    * ^-----BEGIN PGP SIGNATURE-----
    * ^-----END PGP SIGNATURE-----
    | formail -i "Content-Type: application/pgp; format=text; x-action=sign
}

# corregge indicatori di firme errati
	:0 fBw
* ^--$
| sed -e 's/^--$/-- /'

# corregge prefissi di risposta errati (tipico di outlook...)
	:0 fHw
* ^Subject:.*R:
| sed -e 's/R:/Re:/g'

Per quanto riguarda lo SPAM, se ad un certo punto comincia ad essere troppo si può, prima di affidarsi a sistemi più "robusti" iniziare con il creare un nostro particolare file di configurazione, magari richiamandolo in .procmailrc con la direttiva INCLUDE, come ad esempio: INCLUDERC = $PMDIR/spam.rc.
Se ancora non dovessero bastare i nostri filtri casalinghi, come il killfile visto sopra, allora si possono usare vari sistemi, dall'affidarsi ad elenchi da cui attingere, sempre con l'ausilio di Procmail, all'uso di appositi programmi nati proprio con l'intento di sconfiggere tale piaga, come l'ormai famoso Spamassassin o il forse meno famoso ma non meno efficace Bogofilter, entrambi usano filtri bayesiani.

~/Maildir/.Pm/list.rc

############## Mailing List debian Italia ########################

	:0:
* ^List-Post: .*mailto:debian-italian@lists.debian.org
.Lists.ML-debian-italia/

##################################################################

Per un filtraggio preciso e puntuale delle vostre email provenienti da Mailing List a cui siete iscritti io consiglio di usare intestazioni proprie delle ML, come in questo caso ^List-Post:, invece del semplicistico ^TO_. Tutto questo però ha un inconveniente, l'eccesso di pignoleria vi farà andare "a vuoto" se, ad esempio, una ML che seguite verrà spostata su un altro dominio; in compenso però vi accorgerete immediatamente del cambiamento! ;-)

~/Maildir/.Pm/friends.rc

# Qui ci sono le mie caselle postali personali

	:0:
* ^TO_zap@zonapython.it
.Friends.zap@zonapython/

	:0:
* ^TO_zap@teppisti.it
.Friends.zap@teppisti/

Courier IMAP

Come dicevo all'inizio, io uso questo sistema, ma non è da tutti e per tutti soprattutto perchè non so se ne vale davvero la pena, ma d'altra parte ognuno è libero di divertirsi come vuole e poi da qui in poi noi potremo usare senza alcun tipo di problema qualsiasi MUA che supporti IMAP ed ormai il supporto ce l'hanno quasi tutti.

Inoltre avremo un sistema veramente robusto e per fare i backup della posta ci metteremo davvero un attimo, anzi, potremo, volendo (ma è di un rozzo... :-( ) fare il backup di un'unica directory senza problemi di sorta.

Usare IMAP?

Beh, questa è veramente la parte più semplice di tutto l'HOWTO, in pratica non dovremo fare altro cher indicare ad ogni nostro MUA dove registrare le cartelle e il resto lo farà da solo il nostro Courier IMAP. Nel file di configurazione di IMAP, /etc/courier/imapd in fondo osserveremo che MAILDIRPATH=Maildir, per Procmail abbiamo già risolto...

Adesso dovremo vedercela con i nostri MUA, nel caso di Kmail ad esempio, andremo in Impostazioni, Configura Kmail, nell'identità prescelta e indicheremo Sent-mail come cartella dove verranno conservate le mail spedite.
Con la sottoscrizione delle varie cartelle potremo selezionare quali cartelle Kmail dovrà visualizzarci.

Insomma, queste sono questioni più relative ai nostri MUA che al resto, l'unica cartella che ci interessa, per un backup delle
mail è ~/Maildir che conterrà le mail che spediamo, ~/Maildir/Sent-mail e ~/Maildir/backup.gz per le email in ingresso.

Per il resto adesso non dovrete far altro che connettervi con il vostro MUA al server IMAP e goderne dei benefici, le mail saranno sempre quelle, nessuno ce le "toccherà" più direttamente, ma di questo, con gli indubbi vantaggi se ne occuperà il vostro server IMAP.

Provate ad esempio (ma ricordatevi che con questa configurazione non è per niente sicuro...) a connettervi non solo dalla medesima macchina, ma addirittura con il portatile al vostro server IMAP con il vostro programma di posta preferito. In pratica dovrete rispondere a quelle 4 domandine per configurare una casella di posta IMAP e potrete leggere la posta anche da remoto, inserendo user e password del vostro utente. Ad esempio, al volo con Mutt dovrete eseguire: mutt -f imap://127.0.0.1, già vi verrà suggerito il nome del vostro utente ed a voi non rimarrà altro da fare, dopo l'invio, che inserire la password, et voilà, il gioco è fatto!