Postfix

Guida rapida: Mailscanner + Postfix su Fedora

In questa breve guida si affronta l'installazione di Mailscanner integrato con Postfix su Fedora/RedHat. Quanto qui indicato si può applicare senza sostanziali differenze anche su altre distribuzioni.

Rimozione di Sendmail e installazione Postfix :
yum install postfix
rpm -e sendmail

La configurazione di Postfix va fatta secondo le proprie necessità. Semplificando al massimo, verificare e modificare i seguenti parametri in /etc/postfix/main.cf:
myhostname, mydomain, inet_interface, mydestination, mynetworks.

Installazione di Mailscanner. Rigorosamente consigliato è l'uso dell'ottimo installer per sistemi basati su RPM dal sito ufficiale (prendere l'ultima versione stable):
wget
http://www.sng.ecs.soton.ac.uk/mailscanner/files/4/rpm/MailScanner-4.39.6-1.rpm.tar.gz

L'installazione richiede compilatore e strumenti per creare rpm, se non sono già installati procedere con yum:
yum install rpm-build
yum install gcc

Procedere con l'installazione. La fase di compilazione può durare qualche minuti, in quando l'installer ricrea ed installa i pacchetti RPM per il propri sistema dai rispettivi sorgenti:
tar -zxvf MailScanner-4.39.6-1.rpm.tar.gz
cd MailScanner-4.39.6-1
./install.sh

L'integrazione con Postfix è semplice, aggiungere alla fine di /etc/postfix/main.cf la riga:
header_checks = regexp:/etc/postfix/header_checks
e creare il file /etc/postfix/header_checks  con questo contenuto:
/^Received:/ HOLD

La configurazione di MailScanner prevede numerose opzioni che possono essere adattate alle proprie esigenze. Le modifiche fondamentali su /etc/MailScanner/Mailscanner.conf sono:
Run As User = postfix
Run As Group = postfix
Incoming Queue Dir = /var/spool/postfix/hold
Outgoing Queue Dir = /var/spool/postfix/incoming
MTA = postfix

Assicurarsi che l'utente postfix con cui gira Postfix e lo steso Mailscanner abbia permesso di lettura e scrittura sulle directory usate per le code di Mailscanner:
chown -R postfix /var/spool/MailScanner

A questo punto si può provare a riavviare i servizi Mailscanner e Postfix e guardare gli header delle mail in entrata e in uscita: se esistono header aggiunti da Mailscanner, facilmente riconoscibili, il filtro e attivo e la sua configurazione dipende da come si vuole integrare con sistemi antivirus e antispam. Considerare che porvvede lo script di avvio di MailScanner ad avviare Posftix:
/etc/init.d/postfix stop
/etc/init.d/MailScanner restart

Quando tutto funziona secondo le ns esigenze possiamo configurare l'avvio dei servizi al boot:
chkconfig --level 345 postfix off
chkconfig --level 345 MailScanner on

Per integrare Mailscanner con l'antispam Spamassassin aggiungere/modificare le seguenti righe in /etc/MailScanner/Mailscanner.conf:
Use SpamAssassin = yes
SpamAssassin User State Dir = /var/spool/MailScanner/spamassassin
Ricordarsi di creare questa directory con i giusti permessi:
mkdir /var/spool/MailScanner/spamassassin
chown postfix.postfix /var/spool/MailScanner/spamassassin

Per integrarlo con l'antivirus ClamAV editare MailScanner.conf con:
Virus Scanners = clamav
Monitors for ClamAV Updates = /var/lib/clamav/*.cvd

Da zero a postfix in cinque minuti

Vediamo insieme come configurare un server SMTP con Postfix sulla nostra Linux-box.
L'articolo assume per scontato che il lettore sappia compilare ed installare un pacchetto software.

Cos'è Postfix ?
Postfix è un demone per la gestione del servizio SMTP.
Esso è stato sviluppato nel 1998 da Wietse Zweitze Venema, i suoi punti cardine:
. Un demone sicuro e stabile;
. Buon supporto per il protocollo UUCP;
. Un sistema di configurazione semplice ed efficace.

Installazione
Puntiamo il nostro browser al sito: http://www.postfix.org/download.html.
Eliminiamo eventuali mail agent dal nostro PC.
Compiliamo i sorgenti, creiamo gli utenti ed installiamo Postfix nelle directory opportune.

In alternativa, essendo utenti slackware, possiamo ricorrere al relativo tarball.
Scarichiamo il package da linuxpackages.net e diamo il consueto installpkg postfix....tgz.

Configurazione
I file di configurazione di Postfix si trovano in /etc/postfix/: prenderemo in esame main.cfg.
Il suddetto file dovrà essere modificato tenendo conto del nome dell'hostname, del nostro domain e di eventuali ip presenti nella rete locale.

Altri parametri inerenti al nodo uucp di collegamento personale (relayhost) possono essere configurati diversi da arci01.

Infine dobbiamo modificare il file inetd.conf (/etc/inetd.conf) per quanto riguarda i servizi POP3 e SMTP.
Ecco un esempio tipico di configurazione opportunamente commentato:
--- MAIN.CF ---
#- la directory della coda di spool di postfix
queue_directory = /var/spool/postfix

#- la directory dove risiedono gli eseguibili di postfix
program_directory = /usr/sbin

command_directory = $program_directory

#- librerie
daemon_directory = /usr/lib/postfix

#- il possessore dei processi di postfix
mail_owner = postfix

#- i privilegi di default dell'agente di smistamento locale
default_privs = nobody

#- la directory di spool di default, dove finiscono le email in arrivo
mail_spool_directory = /var/spool/mail

#- il programma usato per lo smistamento locale delle email.
mailbox_command = /usr/bin/procmail

#- l'hostname del PC
myhostname = HOSTNAME = /var/spool/postfix

#- il dominio
mydomain = esempio.it

relayhost = arci01

disable_dns_lookups = yes

mynetworks = 192.168.165.0/8, 127.0.0.0/8

debug_peer_level = 2

debugger_command =
     PATH=/usr/bin:/usr/X11R6/bin
     xxgdb $daemon_directory/$process_name $process_id & sleep 5


--- /MAIN.CF/ ---

E' bene conoscere la possibilità di creare liste di discussione mediante i file tools/aliases e tools/lists.
Se vogliamo, ad esempio, creare la lista PIPPO creeremo /etc/postfix/lists/pippo contenente gli indirizzi mail degli utenti partecipanti alla lista, dopodichè inseriremo in /etc/aliases la riga seguente:
tex-willer: :include:/etc/postfix/lists/pippo.

Postfix problemi con resolv.conf

Quando si installa un server SMTP con Postfix dal pacchetto RPM (quantomeno su RedHat 9) si può notare che all'avvio in /var/log/maillog postfix segnala che /etc/resolv.conf e /var/spool/postfix/etc/resolv.conf sono differenti, e di conseguenza se si va a modificare i DNS di sistema le modifiche NON riguarderanno Postfix con conseguenti possibili problemi.

Per ovviare all'inconveniente pare che non basti creare un link simbolico tra il file resolv.conf vero e quello che utilizza Postfix, in questo caso il server SMTP non riesce a risolvere e quindi a recapitare le email, ma bisogna editare il file in tutti i casi per aggiornare i DNS.
Pertanto ricordarsi di mantenere aggiornati e sincronizzati sia il file "ufficiale" (/etc/resolv.conf) che quello di Postfix (/var/spool/postfix/etc/resolv.conf).

/etc/postfix/aliases

E' il file di configurazione attraverso il quale specificare gli alias di posta del mailserver Postifx.

E' un file di testo, può contenere linee vuote e di commento (le quali iniziano con il carattere #). Può risiedere in /etc/posftix/ oppure in /etc/. Ogni entry deve essere nel formato nome:valore. Impostando webmaster:homer sul sistema Joker.net, si indica a Postfix di reindirizzare le mail dirette all'utente [email protected] all'utente [email protected].

La parte nome di ogni linea di configurazione è intesa come locale, di conseguenza non è neccessario aggiungere il nome di dominio.  
Per quanto riguarda la parte valore, essa può essere può contenere diversi tipi di destinazione:  
- address: Un indirizzo email compatibile alla RFC 822;  
- file/name: La mail viene accodata al file specificato. E' possibile utilizzare normali file, ma anche file speciali come  /dev/null;  
- | comando: Le mail possono essere inviate tramite pipe ad un comando;  
- :include:/file/name: La mail viene inviata agli indirizzi elencati nel file specificato;

Esempio di configurazione:  
# Basic system aliases -- these MUST be present  
#  
MAILER-DAEMON:  postmaster  
postmaster:     root  
root:            homer  

# Alias generali  
bin:            root  
daemon:         root  
named:          root  
nobody:         root  
uucp:           root  
www:            root  
ftp-bugs:       root  
postfix:        root  

# Alias locali  
arnaldo:        homer  
webmaster:      homer  
Reindirizzamento di tipo address: le mail dirette ad hannibal vengono inviate ad alberto:  
hannibal:       alberto  
Reindirizzamento file/name: Le mail inviate a bart verrano accodate nel file bartmail   
bart:    /home/bart/bartmail  
La mail inviata a programmatori verrà inviata a tutti gli indirizzi presenti all'interno del file programmers-list.txt:
programmatori:   :include:/list/programmers-list.txt  

Una volta aggiunti i nuovi alias, al fine di rendere effettive le modifiche, è necessario lanciare il comando newaliases, il quale si occuperà di aggiornare il database degli alias.

Configurare postfix e vm-pop3 per gestire domini di posta virtuali

Questo è un howto che permette una volta installato postfix di farlo funzionare con più domini, usando vm-pop3d come pop3 server.

Postfix è reperibile sul sito ufficiale http://www.postfix.org/
vm-pop3d è reperibile su www.reedmedia.net

Obiettivi: creazione di un mailserver per n domini.

Aggiungere l'utente di sistema virtual al file /etc/passwd:
virtual:*:200:200:Postino:/dev/null:/bin/nologin

Installato Postfix (make -- make install) modificare il file /etc/main.cf:
# Aggiungeremo:
virtual_mailbox_base = /var/spool/virtual
virtual_mailbox_maps = hash:/var/spool/virtual/vmailbox
virtual_mailbox_domains = hash:/var/spool/virtual/vmaildomains
virtual_uid_maps = static:200
virtual_gid_maps = static:200
virtual_minimun_uid = 200
virtual_mailbox_lock = dotlock

# Modifica variabili.
# Questo lo commentiamo
#$mydomain =

# I domini verranno specificati in quelli virtuali.. non ne inseriremo nessuno
$mydestination = $hostname

# Non vogliamo finire nelle blacklist di mezzo mondo quindi attenzione
# Metteteci solamente gli IP abilitati a spedire posta per evitare di aprire il relay a tutti:
$mynetworks =  10.10.10.0/24

Per il resto lasciamo invariato.
Ora dobbiamo creare la dir e i file di amministrazione:
mkdir /var/spool/virtual
touch /var/spool/virtual/vmailbox
touch /var/spool/virtual/vmaildomains

La dir /var/spool/virtual conterrà le dir con tutti i domini virtuali e i file degli utenti virtuali
Attenti ai permessi sulla dir: è l'utente "virtual" che dovrà avere accesso alle mailbox, quindi dare un
chown -R 200:200 /var/spool/virtual

Creiamo i domini che vogliamo utilizzare, ad esempio pippo.it pluto.it e paperino.it. Editiamo /var/spool/virtual/vmaildomains:

#Lista domini con commento
pippo.it           pippo
pluto.it           pluto
paperino.it        paperino

Ora inseriremo qualche utente, naturalmente "[email protected]" e "[email protected]"  sono due account diversi. Editiamo /var/spool/virtual/vmailbox:

#Lista utenti per dominio
[email protected]        pippo.it/tex
[email protected]        pluto.it/tex
[email protected]        pippo.it/ciccio
[email protected]    paperino.it/ciccio
[email protected]        [email protected]

Ora passiamo alla creazione delle dir per i domini quindi:
mkdir /var/spool/virtual/pippo.it
mkdir /var/spool/virtual/pluto.it
mkdir /var/spool/virtual/paperino.it

Ora creiamo i file db per i domini e utenti necessari per il funzionamento: ogni qualvolta aggiungiamo un utente o un dominio si ripete questa operazione:
postmap vmailbox
postmap vmaildomains

Per quanto riguarda il POP per scaricare la posta installiamo vm-pop3d prima di tutto modifichiamo il file vm-pop3d.h dovremo specificargli:
VIRTUAL_UID 200
VIRTUAL_MAILPATH "/var/spool/virtual"
VIRTUAL_PASSWORDS_PATH "/var/spool/virtual"
VIRTUAL_PASSWORD_FNAME "passwd"

Questa configurazione varia da persona a persona.. se non siete sicuri lasciate così ,se volete chiamare il file delle password "gigi" siete liberissimi di farlo ricordatevelo però!
Diamo un
make install
di default in qualche distro viene installato pop3. A noi non interessa quindi andiamo a modificare /etc/inet.conf (o /etc/xinet.d/ipop3d) togliendo pop3d e mettendo vmpop3d (con path completo) per specificare il programma da lanciare quando arriva una connessione sulla porta pop3. Ristartiamo (x)inetd.

Per definire le password andiamo a posizionarci nella VIRTUAL_PASSWORDS_PATH che per esempio è "/var/spool/virtual" la stessa dove andranno a finire la mail. Le dir le abbiamo già create quindi procediamo per il primo utente creando il file passwd:
cd /var/spool/virtual/pippo.it
htpasswd -bc passwd tex lamiapassword
e così per tutti gli utenti (togliere -c --create per andare ad aggiungere una password ad un file esistente). Avremo quindi un file passwd per ogni dominio. Il file delle password deve essere leggibile dall'utente virtual.

Per fare il login pop3 e controllare la casella postale si deve iserire il nome utente con il relativo dominio. Es: [email protected].

Possiamo anche testare subito il virtual pop3:
telnet hostname 110
user [email protected]
pass n0nn4p4p3r4
stat
quit

Rimuovere un messaggio dalla coda di Postfix

Visualizzazione delle code di Postfix e rimozione dei messaggi prima della spedizione.

root@Joker:~# postqueue  -p
Tramite il flag -p di postqueue è possibile visualizzare l'identificativo di ogni mail in coda con le relative dimensioni, data ed ora di arrivo, dimensioni, mittente e destinatari
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
91C6A19679*  293782 Sun Jul 25 13:39:40  [email protected]
                                         [email protected]
                                         [email protected]
                                         [email protected]
                                         [email protected]
                                        
-- 287 Kbytes in 1 Request.

A questo punto, una volta a conoscenza dell'identificativo della coda, è possibile rimuoverla grazie all'utility postsuper
root@Joker:~# postsuper -d 91C6A19679
postsuper: 91C6A19679: removed
postsuper: Deleted: 1 message

Disabilitare l'uso di VRFY in Postifx

Il protocollo SMTP offre una serie di comandi utili per visualizzare informazioni inerenti il server di posta. Questi comandi però possono esser sfruttati per scopi non del tutto etici.

Per evitare ciò è consigliabile disabilitare alcuni comandi tra cui il VRFY che permette la verifica di inidirizzi email sul server. Ad Esempio:
telnet pippo.com 25
220 pippo.com ESMTP Postfix
vrfy pippo
252 pippo

Nel file di configurazione di Postfix ( main.cf ) inserire la seguente dichiarazione:
# disabilita il comando VRFY
disable_vrfy_command = yes

Per attivare la modifica alla configurazione di postfix è necessario ricaricare il servizio ( /etc/init.d/postfix reload )

telnet pippo.com 25
220 pippo.com ESMTP Postfix
vrfy pippo
502 VRFY command is disabled

Il comando VRFY sul server pippo.com è disabilitato.

Postfix + ClamAV + Spamassassin

Una richiesta sempre più frequente quando si installa e configura un mail server linux è la possibilità che quest'ultimo processi le email in arrivo per filtrare i virus, e le email di spam.
Tutto ciò è facilmente applicabile utilizzando i seguenti applicativi:
- Postfix (MTA)
- ClamAV (Engine Antivirus)
- Clamsmtpd (per gestire il passaggio della posta da Postfix a ClamAV)
- Procmail (per gestire il delivery della posta e filtrarla con Spamassassin)
- Spamassassin

Supponiamo di avere già installato Postfix e Spamassassin (tipicamente presenti come pacchetti in molte distribuzioni).
Gli altri due programmi (ClamAV e Clamsmtpd) sono invece, generalmente, da scaricare e da compilare a mano.
La versione ultima di ClamAV al momento in cui si scrive questo infobox è la 0.80 che potete trovare qui:
Clamav
Per quando riguarda invece Clamsmtpd l'ultima è la 1.2 disponibile qui:
Clamsmtpd

Dopo aver scaricato i due pacchetti spostiamo in /usr/local/src e scompattiamoli.
Per l'installazione e compilazione vi rimando a questo infobox. La configurazione la vedremo invece insieme.

CONFIGURAZIONE CLAMD
Di seguito vediamo cosa cambiare in /etc/clamd.conf per quello che vogliamo andare a fare:
LocalSocket /tmp/clamd Commentare la seguente linea perchè andremo a far ascoltare il demone clamd sulla socket TCP 3310, per farlo scommentare la seguente riga:
TCPSocket 3310
Il resto della configurazione di default va benissimo così com'è.

FRESHCLAM
Freshclam è il sistema utilizzato da ClamAV per aggiornare il proprio database. Il default di /etc/freshclam.conf va bene in quanto sarà in modalità demone che provvede ad aggiornare il sistema AV ogni 2 ore.

INSTALLAZIONE E CONFIGURAZIONE CLAMSMTPD
Questo fantastico software ci permette di impostare e gestire i vari passaggi che devono avvenire tra Postfix e ClamAV per i processi di filtering delle email che arrivano all'MTA.
Prima di tutto dobbiamo compilare il programma, per farlo spostiamoci in clamsmtpd-1.2 sotto /usr/local/src.
La compilazione avviene in modo standard ./configure; make; make install;
Al termine del tutto bisogna però spostare in /etc il file di conf che è presente nei sorgenti: cp clamsmtpd-1.2/doc/clamsmtpd.conf /etc/.
Fatto questo vediamo come configurarlo secondo le nostre esigenze:
Rispetto alla configurazione di default bisogna apportare i seguenti cambiamenti:
OutAddress: 127.0.0.1:10026 Output address
ClamAddress: 127.0.0.1:3310 Parametro che imposta dove ascolta Clamd

Avviare il demone clamsmtpd con il seguente comando:
/usr/local/sbin/clamsmtpd -f /etc/clamsmtpd.conf

IMPOSTARE POSTFIX PER UTILIZZARE I DUE SOFTWARE INSTALLATI
A questo punto basta dire a Postfix che le email che arrivano devono essere passate a clamsmtpd che provvederà a passarle a clamav e se CLEAN le rigirerà a Postfix per lo smistamento o, come nel nostro caso, per i controlli di antispam.
Per farlo basta aggiungere a /etc/postfix/main.cf le seguenti righe:
content_filter = filter:127.0.0.1:10025
receive_override_options = no_address_mappings
Ed in fondo a /etc/postfix/master.cf:
# SMTP filter (used by content_filter)
filter   unix  -       -       n       -       16      smtp
        -o smtp_send_xforward_command=yes
# For injecting mail back into postfix from the filter
127.0.0.1:10026 inet  n -       n       -       16      smtpd
        -o content_filter=
        -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
        -o smtpd_helo_restrictions=
        -o smtpd_client_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks_style=host
        -o smtpd_authorized_xforward_hosts=127.0.0.0/8

UTILIZZO DI SPAMASSASSIN
Dato per scontato che spamassassin sia installato, il modo più semplice per utilizzarlo è di gestire il tutto tramite procmail, per quanto questa soluzione non sia l'ideale per grossi volumi di posta.
In pratica bisogna configurare Postfix per gestire il local delivery delle email tramite procmail. Per fare ciò basta scommentare la seguente linea di /etc/postfix/main.cf:
mailbox_command = /usr/bin/procmail
IMPORTANTE: prima di riavviare il servizio di postfix bisogna configurare /etc/procmailrc con cui configuriamo a livello globale sulla configurazione di procmail.
Editare /etc/procmailrc come segue:
DROPPRIVS=yes
LOGFILE=/var/log/procmail.log
VERBOSE=yes

:0fw
* < 256000
## | spamc -f
| /usr/bin/spamassassin

:0:/tmp/spam.lock
*^X-Spam-Flag: YES
/var/spool/mail/spam

Spieghiamo ora brevemente le parti importanti di procmailrc:
- LOGFILE specifichiamo il file dove procmail logga le attività che svolge.
- * < 256000 Specifichiamo a procmail di chiamare spamassassin SOLO per le email più piccole di 256K, in caso contrario si rischia di appesantire il processo di parsing delle email stesse
- | /usr/bin/spamassassin Specifica di usare il binario di spamassassin (non uso il spamd perchè ho avuto problemi di mailbox bloccate quando muore il demone)
- *^X-Spam-Flag: YES - /var/spool/mail/spam
Se trova il flag nell'header dell'email (inserito da spamassassin per le email ritenute spam) sposta la mail in una mailbox chiamata appunto "spam"

Per concludere tenete presente che in caso di traffico mail notevole è necessaria una macchina ben carrozzata.

Postfix e greylisting: postgrey

La tecnica del greylisting e' un metodo emerso recententemente nella lotta allo spam, che in molti casi consente di bloccare la maggior parte delle mail indesiderate a livello del mailserver.
  In estrema sintesi, un MTA che adotti questa tecnica scarta "in via temporanea" qualsiasi email proveniente da mittenti non conosciuti, segnalando loro che la mailbox del destinatario non e' temporaneamente disponibile. Esso continuera' a scartare simili email, identificate secondo la terna indirizzo IP dell'host sorgente, email del mittente e del destinatario, fino allo scadere di un determinato timeout.
Normalmente un mail server legittimo, prevede la ritrasmissione del messaggio email in casi simili. Una volta scaduto il timeout previsto, quindi, il server di destinazione potra' accettare il messaggio ritrasmesso.
Tale meccanismo di ritrasmissione, invece, non viene comunemente implementato dalle applicazioni specificatamente dedicate allo spamming. Inviano il messaggio una sola volta, esso puo' quindi  essere filtrato da partete del mailserver destinatario.
Questa soluzione puo' essere utilizzata ovviamente anche con postfix, appoggiandosi a software quali gps o postgrey.
In particolare si vuole illustrare un'esempio di utilizzo di postgrey.
Presumendo di utilizzare un sistema debian, esso e' disponibile gia' pacchettizzato, e pertanto e' installabile semplicemente con il comando: apt-get install postgrey.
Una volta installatolo e' sufficiente editare il file /etc/default/postgrey, indicando la porta da utilizzare, il timeout trascorso il quale accettare un messaggio scartato precedentemente, ed il numero di giorni dopo il quale eliminare le terne indirizzo IP, email mittente e destinatario dal database utilizzato dal programma:

POSTGREY_OPTS="--inet=127.0.0.1:54000 --delay=180 --max-age=15"

Naturalmente in seguito alla modifica e' necessario riavviare postgrey:/etc/init.d/postgrey restart.
Per abilitare il greylisting in postfix e' invece sufficiente inserire la riga check_policy_service inet:127.0.0.1:54000 in /etc/postfix/main.cf sotto smtpd_recipient_restrictions:

smtpd_recipient_restrictions =
    [...]
    check_policy_service inet:127.0.0.1:54000,
    [...]

Anche in questo caso, perche' le modifiche apportate abbiano effetto si richiede ri riavviare il servizio in questione: /etc/init.d/postfix restart.
Per verificare il funzionamento del sistema e' sufficiente controllare i log di postfix dopo avere ricevuto un'email da un mittente non ancora registrato nel database di postgrey. Esso dovrebbe contenere un record simile al seguente:

[...]
450 <[email protected]>: Recipient address rejected: Greylisted for 180 seconds (see http://isg.ee.ethz.ch/tools/postgrey/help); from [email protected]
[...]

Nel mio caso, infatti, la mailbox dell'utente andrea, non appena ricevuto il messaggio da parte di postfix appariva vuota.
Trascorsi alcuni minuti, l'email e' stata rispedita automaticamente dall'SMTP di libero. In questo caso, pero', essendo trascorsi i 180 secondi specificati in /etc/default/postgrey essa e' stata accettata da postfix e correttamente recapitata alla mailbox dell'utente.

Amavisd-new e Postfix, controllo sui virus

Amavisd è un demone scritto in Perl che permette di chiamare programmi esterni in grado di scomprimere, decodificare e classificare il contenuto dei messaggi e degli allegati di posta.
Accetta le mail dall'MTA usato, chiama moduli Perl esterni e programmi che controllano il messaggio di posta e infine li riinoltra all'MTA per la consegna, il rifiuto o la quarantena del messaggio.

Per usare amavisd-new bisogna assicurarsi che si stia utilizzando una versione di Postfix abbastanza recente e che supporti il parametro content_filter = valore

Innanzi tutto occorre creare un utente e un gruppo per usare questo demone.
Di norma si usa amavis come utente e sweep come gruppo. Per motivi di sicurezza non usare assolutamente utenti di sistema come nobody o altri relativi al sistema di posta come maildrop.
Il file una volta scompattato non occorre di compilazioni, all'interno del pacchetto si trovano l'eseguibile amavisd e il suo file di configurazione amavis.conf più uno script di init da inserire nella directory relativa ai file di init del sistema. Questi file vanno copiati nelle loro giuste directory prestando attenzione ai permessi e agli utenti che ne hanno la proprietà. Come home directory per l'utente si può definire /var/amavis/ o /var/lib/amavis/

#cp ./amavisd /usr/sbin/
#chown root /usr/sbin/amavisd
#chmod 755 /usr/sbin/amavisd

e di conseguenza il file di configurazione
#cp ./amavisd.conf /etc/
#chown root /etc/amavisd.conf
#chmod 644 /etc/amavisd.conf

Può essere utile creare una directory che serva da destinazione per i messaggi in quarantena.
#mkdir /var/quarantena
chown amavis.amavis /var/quarantena/
chmod 750 /var/quarantena/

A questo punto sarà necessario editare il file di configurazione amavisd.conf e di conseguenza anche i file di configurazione di Postfix.
Nel amavisd.conf sarà importante fare attenzione ad alcuni parametri in particolare anche se è consigliabile leggerlo tutto perchè le opzioni possibili sono numerose.
Innanzi tutto si settano i parametri $daemon_user e $daemon_group specificando l'utente e il gruppo scelto per far girare il demone. In questo modo al momento del lancio, come root, di amavisd, automaticamente parte come se lanciato dall'utente specificato.
Le opzioni
$HOME
per definire la home directory dell'utente amavis.
$TEMPBASE
dove si definisce la directory in cui vengono temporaneamente posti i messaggi in elaborazione.
$QUARANTINEDIR
la directory di quarantena in cui i messaggi sospetti o certamente infetti vengono riposti per un eventuale controllo e pulizia.

E' possibile anche non creare nessuna directory di quarantena e fare in modo che tutta la mail destinata a questa "coda" sia inviata ad un account di posta preposto per questo.
Si crea una voce relativa nel file /etc/aliases o a seconda dell'installazione /etc/postfix/aliases
infected = /var/spool/mail/infected
e a seconda che si desideri o meno un mailbox-style aggiungere uno slash finale. Lanciare il comando newaliases o postalias /etc/postfix/aliases per aggiornare il database.
Infine specificare nel file amavisd.conf la direttiva
$virus_quarantine_to = 'infected@';
in modo da inviare tutta la posta in quarantena all'indirizzo infected.

Sarà necessario poi prestare attenzione agli altri parametri presenti nella 'Section I', $mydomain e @local_domains_acl = valore, e per finire agire sui valori di specifica del software antivirus usato nella 'Section VII'. A questo punto amavisd può essere lanciato e se dovessero mancare alcuni prerequisiti, come qualche modulo Perl, uscirà con un errore mostrando una lista di cosa è venuto a mancare.
Configurato amavisd sarà necessario lavorare sui file di configurazione di Postfix main.cf e master.cf.
Nel master.cf dovranno essere aggiunte le seguenti voci
smtp-amavis unix -    -    y/n    -    2  smtp
    -o smtp_data_done_timeout=1200
    -o disable_dns_lookups=yes

127.0.0.1:10025 inet n    -    y/n    -    -  smtpd
    -o content_filter=

Dove y/n corrispondono al campo "chroot" e serve ad indicare se si è o meno in un ambiente di lavoro chroot.
Infine con il comando
#postconf -e 'content_filter = smtp-amavis:[127.0.0.1]:10024'
si modifica il main.cf e si fa in modo che Postfix inizi a inviare tutta la posta che riceve ad amavisd.
Effettuare un relaod della configurazione con il comando
#postfix reload
Controllare i file di log di Postfix e di amavisd per verificare che tutto funzioni. Volendo all'interno della directory del pacchetto Amavis è presente una sotto-directory test-messages contenente alcuni file utili per testare il funzionamento del nuovo sistema di filtraggio della posta.

Usare Postfix con connessioni dial-up (non permanenti)

Come ottimizzare Postfix su workstation con connessione ad Internet non permanente.

La configurazione di Postfix generalmente utilizzata su macchine con una connessione non permanente ad Internet (ad esempio una workstation casalinga) prevede l'uso della direttiva defer_transports=smtp, che consente di mantenere in coda la posta inviata evitando l'avvio automatico di connessioni PPP indesiderate.
La posta in giacenza verrà effettivamente inviata alla successiva connessione, tramite un postfix flush nello script /etc/ppp/ip-up.
Ciò è scomodo, in quanto costringe l'utente ad eseguire manualmente il flush se desidera inviare un messaggio mentre la connessione è già attiva.

Una configurazione più funzionale istruisce Postfix a mantenere la posta in coda mentre la workstation non è connessa ad Internet e a spedirla immediatamente quando la connessione è attiva.
Ciò è possibile grazie al comando postconf, aggiungendo le seguenti istruzioni in /etc/ppp/ip-up o, meglio, in /etc/ppp/ip-up.local (ricordo che per ragioni di sicurezza questi script vengono eseguiti in un environment protetto, le variabili di ambiente non sono disponibili ed è pertanto obbligatorio specificare il path per esteso di ciascun comando):

# Istruisce Postfix per inviare subito la posta
/usr/sbin/postconf -e "defer_transports="
/usr/sbin/postfix reload
# Invia la posta in coda
/usr/sbin/sendmail -q >dev/null 2>/dev/null &

In /etc/ppp/ip-down.local rimettiamo le cose a posto:
/usr/sbin/postconf -e "defer_transports=smtp"
/usr/sbin/postfix reload

pop-before-smtp con Postfix

Postfix è integrabile con diversi sistemi di autenticazione, di controllo dei virus, di applicativi webmail e può raggiungere livelli molto elevati di complessità strutturale. Molti strumenti e metodi utilizzati con Sendmail sono disponibili anche con Postfix.
Sul sito ufficiale del pacchetto alla pagina http://www.postfix.org/addon.html sono disponibili diversi riferimenti a utility, patch e documentazione per implementare diverse funzioni.

Attualmente Postfix è integrabile con molti dei principali sistemi di posta pop3/imap come Cyrus IMAP, Qpopper, Courier-imap, con vari software antivirus, con sistemi di controllo delle autenticazioni before-smtp come DRAC, whoson o pop-before-smtp o con sistemi anti-UCE come SpamAssassin. Alcune di queste funzioni implicano la ricompilazione del pacchetto, altre necessitano di particolari accorgimenti, come spesso succede nel mondo Linux ci sono molti modi di ottenere lo stesso effetto ed è difficile stabilire quale sia il migliore.

Un metodo di autenticazione molto usato è pop-before-smtp.
Per far questo si può utilizzare DRAC Dinamic Relay Authorization Control, un demone che si occupa di scrivere un database di indirizzi autenticati attraverso pop3/imap ma implica alcuni fattori poco favorevoli quali l'uso di Remote Procedure Call e quindi la necessità di avere portmap attivo e il fatto di dover ricompilare i demoni usati per pop3/imap, si può usare whoson una patch per Postfix che quindi implica la sua ricompilazione oppure usare pop-before-smtp un demone scritto in Perl.
L'ultima è probabilmente la soluzione più funzionale e pratica, non implica ricompilazioni particolari ed è portabile su molte piattaforme differenti, unico neo che potrebbe far preferire DRAC a questo metodo è che non opera da remoto implica per ciò che i file necessari siano presenti sulla macchina del server di posta.

Il pacchetto, disponibile su sourceforge si può trovare in formato rpm o in formato tar.gz, una volta appurato che siano presenti i modili Perl necessari per far funzionare pop-before-smtp installabili attraverso un Bash script all'interno della directory contrib dei sorgenti scaricati, chiamato getfromcpan che li scarica, ne crea il pacchetto rpm e se lanciato come root li installa o per i puristi con il comando Perl per accedere all'immenso archivio dei moduli di Perl:
#perl -MCPAN -e 'install Time::HiRes'
#perl -CPAN -e 'install File::Tail'
#perl -MCPAN -e 'install Date::Parse'
#perl -MCPAN -e 'install Net::Netmask'

A questo punto premesso di avere un'installazione funzionante di un sistema di posta, in questo caso poniamo un server pop3 e Postfix, sarà necessario lavorare principalmente sulla configurazione di pop-before-smtp e sul main.cf di Postfix.
Il file di configurazione principale pop-before-smtp-conf.pl è molto ben commentato ed è consigliabile leggerlo tutto per chiarire appieno il funzionamento e le possibili configurazioni, di norma si dovrà fare attenzione ad alcuni parametri:
# Set the log file we will watch for pop3d/imapd records.
Con questo commento inizia la sezione che specifica il log file del server pop3d/imapd. Notare che è presente del codice che tenta di effettuare questa operazione automaticamente.
if (!-f $file_tail{'name'}) {
    foreach (qw( /var/log/mail/info /var/log/mail.log
         /var/log/messages /var/adm/messages )) {
    if (-f $_) {
        $file_tail{'name'} = $_;
        last;
    }
    }
}

Mentre sarà importante fare attenzione alle definizioni della variabile $pat per determinare le azioni da eseguire sui file di log, di cui il default è
# For UW ipop3d/imapd and their secure versions. This is the DEFAULT.
$pat = '^(... .. ..:..:..) \S+ (?:ipop3s?d|imaps?d)\[\d+\]: ' .
    '(?:Login|Authenticated|Auth) user=\S+ ' .
    'host=(?:\S+ )?\[(\d+\.\d+\.\d+\.\d+)\]';

Sarà necessario identificare il server pop3d/imapd usato e scommentare le righe di codice che lo riguardano.
A questo punto se è tutto a posto si potrà lanciare il comando o usando
#/usr/sbin/pop-before-smtp
o a seconda della distribuzione lo script di init
/etc/init.d/pop-before-smtp start
Di default dovrebbe creare il file pop-before-smtp.db nella directory /etc/postfix/ e sarà necessario configurare il main.cf di conseguenza agendo sul parametro di restrizione dei recipienti
smtpd_recipient_restrictions = permit_mynetworks,reject_non_fqdn_recipient,
        check_client_access hash:/etc/postfix/pop-before-smtp,
        check_relay_domains
In questo modo quando un client si autenticherà via pop da qualunque indirizzo ip, poniamo dei dipendenti che viaggiano spesso e si collegano con il modem, il demone pop-before-smtp aggiornerà il file database contenente le informazioni sul client di modo che Postfix ne conceda l'inoltro (relay) della posta. I metodi possibili per gestire l'autenticazione per limitare il relay di Postfix sono molte, questo è forse uno dei metodi più semplici e pratici ma consigliabile fare riferimento alla documentazione presente in Internet per questo argomento che spesso contiene informazioni molto utili per la comprensione delle architetture implementabili con Postfix.

Introduzione a Postfix

Postfix nasce con l'intento di sostituire Sendmail come server di posta. E' stato concepito quindi con un occhio di riguardo alla compatibilità con questo sistema di modo da facilitarne la migrazione.
Inoltre è studiato con molta attenzione nei riguardi della sicurezza tanto da venire considerato da molti il più sicuro mailer in circolazione.

Questo sistema di posta anzichè essere costituito da un unico grosso programma che effettua la maggior parte delle azioni è suddiviso in diversi programmi che svolgono una azione specifica e un programma principale che si occupa di chiamare il programma giusto quando necessario e di gestire le varie azioni. Solo il programma master necessita di privilegi elevati e va infatti lanciato da root, gli altri invece possono girare con privilegi molto bassi, ad esempio usando un utente creato appositamente, inoltre possono essere eseguiti in un ambiente "gabbia" chroot.
In questo modo si ha un isolamento dei singoli processi con un maggior controllo sulle singole azioni eseguite dal server. Inoltre è pensato per resistere a condizioni di lavoro con carichi di traffico elevati e utilizza particolari routines per evitare che un eventuale crash possa compromettere il comportamento dell'intera macchina. Oltre a non avere nessun programma SUID, Postfix non "crede" al contenuto delle code e in se non conosce il contenuto dei file in coda. I programmi che si occupano di un passaggio dell'elaborazione dati effettuano i controlli degli stessi allo scopo di indirizzarli verso il programma o la coda giusta.
Ogni programma che compone questo complesso sistema agisce in modo autonomo senza avere processi "figli" e in questo modo si cerca di evitare relazioni tra i processi che potrebbero condizionare il comportamento dei child in caso il processo "genitore" sia compromesso.
I dati che vengono ricevuti dalla rete vengono opportunamente filtrati e subiscono controlli diversi dai singoli programmi che si occupano della loro elaborazione, inoltre si evita di salvare tali dati sul disco ma vengono processati in primis dal programma e susseguentemente passati al programma successivo.

Postfix si avvale principalmente  di quattro importanti code:
maildrop, incoming, active, deferred
La posta viene innanzitutto depositata in maildrop da dove dopo alcune elaborazioni passa alla coda incoming, questa coda è per la posta che è appena arrivata e che non è ancora stata elaborata dal manager delle code. La coda active invece è una piccola zona in cui la posta al suo interno è aperta dal manager ed è in attesa di essere instradata. Quella posta che non può, per vari motivi, essere instradata viene mandata alla coda deferred.
Il gestore delle code mantiene in memoria solo i dati presenti nella coda active in questo modo si evita che il processo si intasi in caso di una grossa mole di traffico.
Oltre a queste code Postfix mantiene due spazi "parcheggio" una si chiama hold e contiene tutti quei messaggi che sono congelati nella coda e per i quali non viene attuato nessun tentativo di smistamento. L'unico modo di rilasciare questi messaggi è con il comando postsuper. Il secondo parcheggio invece si chiama corrupt e al suo interno vengono salvati quei file che non sono riconosciuti validi, e vengono lasciati lì per permettere all'amministratore di controllarli.

Installazione di Postfix, file principali

La maggior parte delle principali distribuzioni Linux comprende i pacchetti rpm di Postfix nel CD di installazione. Alcune come Suse lo hanno ormai sostituito a Sendmail nell'installazione di default. In certi casi comunque potrebbe essere necessario installare dai sorgenti.    

Sul sito di Postfix, http://www.postfix.org, si trovano le indicazioni per scaricare i sorgenti dell'applicazione. Si noterà che, fedelmente al proposito di sostituire il diffusissimo Sendmail, è ormai disponibile il supporto per la compilazione su quasi tutte le versioni unix esistenti a patto di seguire in certi casi pochi accorgimenti.
Una volta scaricato e scompattato il pacchetto, cambiata la directory di lavoro in quella dei sorgenti appena creata, si può procedere con l'installazione.
All'interno dei sorgenti, tra i diversi file, si troveranno oltre alla documentazione ufficiale alcuni file utili per cominciare il processo di installazione. In caso si stia utilizzando un SO come Solaris che ha notevoli differenze da Linux, pur restando uno unix, nel file INSTALL si troveranno consigli utili per la compilazione su questa piattaforma e su altre che impongono diversi parametri.
Se si compila su un sistema che usa le GCC, vedi Linux, con il comando
make
si dà inizio al processo di compilazione. I parametri definibili in questa fase sono per lo più inerenti alla modifica della posizione di default dei file di configurazione o dei programmi che compongono Postfix.

Eseguita questa fase si procede nell'installazione. Si dovrà creare un utente dedicato che non necessita ne di una home directory ne di una shell con il comando
adduser postfix -s /bin/false -d /dev/null
e settare un record nel file delle password con il comando
passwd -l postfix
Dopo di che sarà necessario creare due gruppi, postfix e postdrop usando il comando groupadd.
Queste operazioni sono necessarie per il successo dell'installazione.

Si procede con il comando
make install
per concludere l'installazione. Questo comando nel caso di Postfix è interattivo, permettendo di specificare parametri diversi da quelli di default, ponendo semplici domande e mostrando inoltre quali sono i valori standard.

Una volta installato tutto senza particolari modifiche ai valori standard si troveranno all'interno della directory /etc/postfix tutti i file di configurazione e le tabelle.
Il file più importante è il main.cf dove si specificano quasi tutti i parametri di configurazione, ma anche master.cf, che regola il comportamento del programma master che si occupa di gestire gli altri programmi che compongono postfix e i parametri con cui questi programmi vengono eseguiti. Un'altro file di grande importanza e che generalmente viene editato prima di procedere con l'avvio del server è il file /etc/aliases che a volte può trovarsi dentro la directory /etc/postfix/. Ricordarsi che ogni volta che questo file viene modificato occorre lanciare il comando newaliases perchè le modifiche abbiano effetto.
La directory radice dove si troveranno tutte le code si trova in /var/spool/postfix/.
La documentazione verrà salvata in /usr/share/doc o in /usr/doc ma può cambiare a seconda della distribuzione usata.

La suite di postfix si compone di numerose applicazioni. Alla fine dell'installazione, se eseguita con i valori standard si troveranno tutti i demoni all'interno della directory /usr/libexec/postfix/.
%ls -al /usr/libexec/postfix
drwxr-xr-x    2 root     root          536 2003-05-31 22:24 .
drwxr-xr-x  100 root     root        35976 2003-06-17 15:20 ..
-rwxr-xr-x    1 root     root       159994 2003-03-17 16:35 bounce
-rwxr-xr-x    1 root     root       192637 2003-03-17 16:35 cleanup
-rwxr-xr-x    1 root     root       147535 2003-03-17 16:35 error
-rwxr-xr-x    1 root     root       146107 2003-03-17 16:35 flush
-rwxr-xr-x    1 root     root       185928 2003-03-17 16:35 lmtp
-rwxr-xr-x    1 root     root       206273 2003-03-17 16:35 local
-rwxr-xr-x    1 root     root       102287 2003-03-17 16:35 master
-rwxr-xr-x    1 root     root       180167 2003-03-17 16:35 nqmgr
-rwxr-xr-x    1 root     root       145316 2003-03-17 16:35 pickup
-rwxr-xr-x    1 root     root       165959 2003-03-17 16:35 pipe
-rwxr-xr-x    1 root     root       130586 2003-03-17 16:35 proxymap
-rwxr-xr-x    1 root     root       174767 2003-03-17 16:35 qmgr
-rwxr-xr-x    1 root     root       158236 2003-03-17 16:35 qmqpd
-rwxr-xr-x    1 root     root       146374 2003-03-17 16:35 showq
-rwxr-xr-x    1 root     root       227117 2003-03-17 16:35 smtp
-rwxr-xr-x    1 root     root       257641 2003-03-17 16:35 smtpd
-rwxr-xr-x    1 root     root       139319 2003-03-17 16:35 spawn
-rwxr-xr-x    1 root     root       164847 2003-03-17 16:35 tlsmgr
-rwxr-xr-x    1 root     root       150312 2003-03-17 16:35 trivial-rewrite
-rwxr-xr-x    1 root     root       162184 2003-03-17 16:35 virtual

Le utility di gestione del servizio invece saranno all'interno della directory /usr/sbin/
%ls -al /usr/sbin/post*
-rwxr-xr-x    1 root     root       132952 2003-03-17 16:35 /usr/sbin/postalias
-rwxr-xr-x    1 root     root        27185 2003-03-17 16:35 /usr/sbin/postcat
-rwxr-xr-x    1 root     root       145688 2003-03-17 16:35 /usr/sbin/postconf
-rwxr-sr-x    1 root     postdrop    95451 2003-03-17 16:35 /usr/sbin/postdrop
-rwxr-xr-x    1 root     root        69141 2003-03-17 16:35 /usr/sbin/postfix
-rwxr-xr-x    1 root     root        75112 2003-03-17 16:35 /usr/sbin/postkick
-rwxr-xr-x    1 root     root        71534 2003-03-17 16:35 /usr/sbin/postlock
-rwxr-xr-x    1 root     root        68576 2003-03-17 16:35 /usr/sbin/postlog
-rwxr-xr-x    1 root     root       125326 2003-03-17 16:35 /usr/sbin/postmap
-rwxr-sr-x    1 root     postdrop    85781 2003-03-17 16:35 /usr/sbin/postqueue
-rwxr-xr-x    1 root     root        84165 2003-03-17 16:35 /usr/sbin/postsuper

Configurare Postfix, file principali e parametri

Postfix principalmente si controlla attraverso due importanti file, "main.cf" e "master.cf".
Rispettivamente regolano il comportamento generale dell'applicazione e la configurazione del master daemon che gestisce il comportamento di tutti i demoni che compongono questo sistema di posta.
Di norma il master.cf può essere lasciato intatto a meno che non si stia lavorando su configurazioni più complesse come ad esempio intergrare Postfix con Cyrus.

Il main.cf è il file più importante. Attraverso questo file è possibile configurare Postfix come un semplice relay server per una piccola rete casalinga fino ad arrivare a configurazioni di alto livello per sistemi "enterprise".
Il file si presenta molto ben commentato e spesso i valori di default vanno benissimo, ma rimane un file complesso e molto grosso, i diversi parametri sono molti, più di 250 stando a quanto scritto nelle primissime righe di commento. Per questo generalmente Postfix dispone di un nutrito set di file di esempio e molto utili se si desidera conoscere molti parametri di default che non sono presenti nel main.cf a installazione completata. Ci si può inoltre aiutare usando il comando postconf.
Le direttive vengono separate tra di loro e riunite in categorie (Queue and process ownership, Internet host and domain name, Sending mail...) facilitando in questo modo la comprensione del significato dei singoli parametri.
Di norma per avere un sistema di posta funzionante non occorre che modificare poche variabili.
- Quale dominio usare per la posta in uscita.
- Quale invece di cui ricevere la posta.
- Quali client hanno modo di inviare la posta attraverso il server.

La direttiva
myorigin = valore
permette di specificare il dominio da usare per la posta inviata attraverso questo server. Il valore di default è la variabile $myhostname ma a meno che non si utilizzi il server per una piccola rete locale sarà opportuno modificarlo con $mydomain.
myorigin = $mydomain

mydestination = valore
specifica per quali domini il sistema di posta deve instradare localmente i messaggi anzichè inviarli ad un altro server. Generalmente si compone di una lista di nomi, si possono specificare anche file o tabelle, di norma occorrerà aggiungere $mydomain ai valori di default in modo che il server sia il mail server del dominio.
mydestination = $myhostname localhost.$mydomain $mydomain
Dove i primi due valori sono quelli di default.

mynetworks = valore
Questa variabile volendo permette di impostare host per host le macchine che possono usare il server per l'inoltro dei messaggi. Di default si usa la direttiva complementare mynetworks_style.
mynetworks_style = [class] [subnet] [host]
subnet è il valore di default e indica che Postfix inoltrerà la posta per tutti i client nella sottorete locale.
class Postfix considererà validi tutti i client provenienti dal network di classe A, B o C a cui è collegato.
host l'inoltro sarà abilitato esclusivamente per la macchina locale.

myhostname = valore
Questo parametro permette di specificare una importante direttiva usata da altri parametri del file di configurazione con la variabile $myhostname. Il nome dell'host va specificato nella forma FQDN (Fully Qualified Domain Name). Di default Postfix usa il nome dell'host locale ma se questo non fosse un nome di dominio completo o fosse in ascolto su un'interfaccia virtuale si deve specificare il nome di dominio completo per il server.
myhostname = mail.esempio.com
myhostname = mail.virtualesempio.com

mydomain = valore
Permette di specificare il dominio a cui appartiene il server. Di norma è usato il valore di $myhostname togliendo la prima parte del nome a meno che non si riduca ad un dominio di primo livello.
mydomain = esempio.com

Configurati questi parametri si dovrebbe cominciare ad avere un server di posta utilizzabile.
Nel caso in cui la macchina che si sta usando possiede più di un indirizzo su un'interfaccia di rete o più interfaccie verrà utile specificare inoltre

inet_interfaces = valore
Di default in ascolto su tutti gli indirizzi (all) con questa direttiva si possono specificare le interfaccie virtuali.
inet_interfaces = virtual.esempio.com
Perchè la modifica di questa variabile sia effettiva non basta effettuare un reload ma si deve fermare e riavviare il sistema di posta.

Postfix: configurazioni anti-spam e abusi

Una volta configurato il server con i parametri per l'invio, la ricezione e l'inoltro della posta si può prendere in considerazione l'ottimizzazione del servizio e un maggiore controllo delle sue funzioni.

Esistono molte possibilità per definire il comportamento di Postfix e in special modo per controllarne gli accessi, sia da un punto di vista di consumo delle risorse sia dal controllo di cosa può passare e cosa invece no per evitare, ad esempio, l'invio massivo attraverso il server di UCE (Unsolicited Commercial Email) o comunemente SPAM. Per controllare l'invio di SPAM di default l'SMTP-server di Postfix accetta esclusivamente la posta per il network o il dominio locale e per i domini ospiti del server, in modo che dagli estranei non si accetti alcuna connessione. Esistono diversi modi per assumere maggior controllo su questa problematica usando liste di accesso in stile Sendmail o RBL (Real Time Blackhole List) e per un approfondimento si può fare riferimento alla documentazione ufficiale disponibile sul sito di Postfix, www.postfix.org, o nella directory di sistema dedicata alla documentazione dei pacchetti installati.
E' importante inoltre controllare le quantità di posta processabile, ad esempio per limitare il numero di processi contemporanei anche se si dispone di un limite massimo di 1000 client.

default_process_limit = valore
permette di controllare il numero di processi in uscita e in entrata. Di default è settato a 100 ma nel caso di una piccola rete casalinga andrebbe benissimo un valore di 10 mentre per un mail server principale di un provider andrebbe meglio un valore di 1000 o 10000.

Per controllare che il server non sia usato per un attacco tipo DoS o per spam si usano alcune variabili che ai loro valori di default dovrebbero andare benissimo.
initial_destination_concurrency = valore (default:2)
che controlla quanti messaggi sono inizialmente inviati verso la stessa destinazione prima di attuare un invio multiplo.
local_destination_concurrency_limit = valore (default:2)
che controlla quanti messaggi sono inviati contemporaneamente allo stesso recipiente locale.
default_destination_concurrency_limit = valore (default:20)
che impone il limite di messaggi inviabili contemporaneamente alla stessa destinazione.

Ulteriori parametri permettono quanto meno di limitare l'uso del server da parte di client sbadati o maliziosi, rallentando di fatto le loro connessioni fino a chiuderle senza troppi imbarazzi. Il server incrementa un conteggio per sessione degli errori dovuti a richieste da parte dei client non riconosciute valide o sconosciute e di tutte le richieste che in qualche modo violano le regole UCE. Questo conteggio si azzera quando un messaggio viene inviato correttamente. Se il conteggio aumenta il server limita i danni rallentando il client.
Le variabili che controllano queste funzioni sono:
smtpd_error_sleep_time = valore (va bene il valore di default:1)
che in sostanza cerca di evitare gli errori di un client quando il conteggio è ancora basso ponendo un tempo limite in cui il server resta in pausa mentre comunica l'errore al client.
smtpd_soft_error_limit = valore
di default 10 stabilisce che quando il numero di errori per sessione supera il valore impostato il server attende il valore del conteggio in secondi prima di rispondere ad un'altra richiesta del client.
smtpd_hard_error_limit = valore
di default 20 e stabilisce che al superare nel conteggio del valore impostato il server SMTP taglia la connessione.

postfix

La suite di Postfix si compone di numerosi demoni e di una decina di comandi che servono a regolare specifiche operazioni. Il principale e più importante è il comando postfix che serve a controllare il programma stesso. Con esso si avvia o si ferma il demone master del sistema di posta, si verifica lo stato o si ricarica la configurazione.

La sua sintassi è semplice e senza troppe opzioni, ma ha vari sotto-comandi.
postfix [-Dv] [-c directory_file_conf] comando_interno
-D: Usata solo con il sotto-comando start permette di lanciare i demoni di postfix sotto il controllo delle direttive di debug specificate nel main.cf.
-v: Anche questa opzione è orientata al debug del software, si possono specificare più volte per avere ancora più informazioni.
-c: Permette di specificare una directory alternativa a quella di default in cui il comando andrà a cercare i file di configurazione. Utile nel caso si stiano eseguendo più server di posta sulla stessa macchina.

I comandi interni regolano diverse operazioni
start: Avvia il sistema di posta. Effettua anche un controllo della configurazione come se si usasse il comando check.
stop: Ferma il sistema di stampa regolarmente. I processi in corso hanno modo di terminare quanto prima ma completando le loro operazioni.
abort: Ferma il sistema di stampa forzatamente. I processi in corso sono costretti a fermarsi immediatamente.
check: Verifica la configurazione del sistema di posta e mostra degli alert per errori nei permessi dei file o delle directory.
flush: Forza l'inoltro di ogni messaggio in attesa di essere inviato. Utile nel caso si usi una connessione verso Internet di tipo PPP o ISDN che non è sempre attiva.
reload: Permette di ricaricare i file di configurazione senza fermare il sistema di posta.

Questo comando va utilizzato esclusivamente dall'utente root.

postconf

Il comando postconf è una utility a riga di comando che permette diverse operazioni su un file di configurazione di Postfix. Con postconf si possono consultare i parametri presenti al momento nel sistema di posta, si può editare il file specificato, si possono verificare i valori di default per una particolare direttiva.

postconf [-dhmlnv] [-c directory_file_conf] [parametro ...]
postconf [-ev] [-c directory_file_conf] [parametro=valore ...]

La maggior parte delle opzioni riguardano principalmente il controllo dei valori configurati e di quelli standard.
-c directory_file_conf: Permette di specificare la directory che contiene i file di configurazione su cui si desidera agire.
-d: Mostra i valori di default per tutti i parametri.
-h: Mostra esclusivamente i valori e non il nome dei parametri configurati.
-m: Mostra una lista delle tipologie di tabelle supportate.
-l: Mostra una lista di metodi per il lock delle mailbox.
-n: Mostra tutti i valori che non sono default nel file specificato.
-e: Questa è l'opzione più importante perchè è necessaria per editare un particolare parametro del file di configurazione.

Per avere un quadro quanto più complessivo delle numerose opzioni di Postfix occorre fare riferimento a diverse fonti. Con l'ausilio dei commenti del main.cf standard, della lettura dei file di esempio e grazie a questa utility è possibile ottimizzare al meglio il proprio MTA (Mail Transfer Agent) e adattarlo a diverse architetture di accesso dati. Una grande utilità di questo comando è che se lanciato senza opzioni mostra tutti i valori della configurazione attuale in modo da avere una idea complessiva di tutti i parametri presenti nei file di esempio.

postsuper

Questo comando è inteso per la gestione e la manutenzione dei processi nelle code di Postfix. L'uso di questo comando è inteso per il superutente, l'amministratore del sistema mentre l'utente semplice per agire sui file di una coda Postfix può usare postqueue.

La sua sintassi
postsuper [-psv] [-c directory_file_conf] [-d][-h][-H][-r] [id_coda] [directory_coda]

Di default postsuper effettua le operazioni su tutte le directory di coda di Postfix, quindi incoming, active e deferred le principali code per i file di mail, e sulle directory con i log files, bounce, defer, e flush.

Le sue opzioni
-c directory_file_conf: Specifica la directory dove si trova il main.cf per l'istanza di Postfix su cui si desidera lavorare.
-d id_coda: Questa opzione elimina un messaggio che ha l'id specificato dalla code (di default: hold, incoming, active e deferred). Se si usa come id il simbolo "-" il programma legge gli id dallo standard input. Questo rende possibile usare postsuper all'interno di script.
Per rimuovere tutti i messaggi si usa il suffisso ALL che va specificato in maiuscolo per motivi di sicurezza. Se si definisce una coda in particolare verranno cancellati tutti i messaggi per quella coda:
postsuper -d ALL deferred
eliminerà tutti i file di posta presenti nella coda deferred.

Occorre notare che l'id di un file in coda viene riutilizzato dal sistema di posta. Questo comporta il rischio di eliminare il messaggio errato. Per esempio, il queue manager cancella il messaggio indicato da postsuper perchè ha finito il suo ciclo all'interno del sistema. Arriva posta nuova e ad un messaggio viene dato l'id che postsuper ha richiesto di rimuovere. Il messaggio nuovo viene eliminato al posto di quello giusto.
Occorre quindi prestare attenzione se si desidera eliminare dei messaggi mentre il sistema di posta è attivo.

-h id_coda: Questa opzione sposta il messaggio definito dalla coda o dalle code (di default, incoming, active e deferred) alla coda hold di modo che nessuna operazione di inoltro venga effettuata prima del suo rilascio da parte del postmaster.  Anche con questa opzione se al posto di un id di messaggio si utilizza il simbolo "-" il programma legge gli id dall'input di tastiera. Anche questa opzione supporta la chiave ALL che va utilizzata in maiscolo per forzare l'attenzione su questa delicata operazione.
-H id_coda: Con questa opzione si esegue il rilascio della posta messa "on hold", trattenuta nella coda hold. La posta rilasciata viene messa all'interno della coda deferred Anche per questa funzione valgono le chiavi ALL e "-"
-p: Pulisce i vecchi file temporanei che vengono creati in caso di un crash del sistema o del software di posta.
-r id_coda: Rielabora nuovamente il messaggio specificato dall'inizio come fosse appena arrivato. Il messaggio viene preso dalla coda o dalle code (di default: hold, incoming, active e deferred). Per riimpostare file multipli è consigliato usare l'opzione più volte. Anche questo parametro supporta le chiavi "-" e ALL. Un messaggio riinserito in coda viene spostato nella coda maildrop da dove viene copiato dal pickup daemon in un nuovo file. Questo viene rielaborato, subendo nuovamente le operazioni di address rewriting e sostituzione. Questa operazione è utile quando si sono modificate alcune regole o la mappatura virtuale. Va ricordato che gli id delle code sono riutilizzati e quindi c'è una minima possibilità di effettuare questa operazione su un file sbagliato ma senza particolari conseguenze (non viene eliminato) e solo se il sistema di posta è attivo.
-s: Questa operazione è importante e andrebbe eseguita sempre prima che Postfix venga lanciato. Effettua un controllo strutturale dei file e ripara gli errori.
In sostanza rinomina i file il cui nome non è associato all'inode giusto. Questo è utile in caso si stia recuperando la posta di un'altra macchina o da un backup. Infine sposta i file che non si trovano al posto giusto e rimuove le sotto directory che non sono più necessarie.
-v: Abilita i messaggi per propositi di debug e testing. L'uso multiplo di questa opzione abilita maggiori informazioni.

postqueue

Mentre postsuper effettua operazioni di carattere amministrativo sui file delle code in Postfix, all'utente finale viene fornito uno strumento per agire sui propri file di posta. In se implementa operazioni che tradizionalmente sono disponibili con il comando sendmail di Postfix. Questo comando è ideato per essere set-group ID (SGID) di modo che possa comunicare con i processi appartenenti ai demoni interni al sistema di posta.

La sua sintassi
postqueue [-c directory_file_conf] [-f][-p] [-s sito] [-v]

Le opzioni sono poche
-c directory_file_conf: Specifica la directory dove si trova il file di configurazione. A dimostrazione dell'attenzione prestata alla sicurezza per evitare che un utente smaliziato sia in grado di usare il set-group ID per i propri discutibili motivi, non si può in realtà specificare una directory arbitraria. Una directory arbitraria e concessa solo se se elencata nel file main.cf con il parametro alternate_config_directories oppure se il comando è lanciato dall'super-utente root.
-f: Pulisce la coda. In sostanza tenta l'inoltro di tutta la posta in coda.
-p: Produce una lista dei file nelle code. Usa uno stile alla "sendmail".
Per ogni file in coda mostra l'ID, la misura del messaggio, l'orario di arrivo, chi lo ha inviato e i recapiti a cui va inoltrato. Se la posta in questione non è stata inoltrata per qualche motivo mostra la ragione di questo fallimento. L'ID di un messaggio a volte viene mostrato seguito da un carattere speciale.
Se si trova un asterisco "*" il messaggio si trova nella coda active e sta per essere inoltrato.
Se invece è presente un simbolo "!" il messaggio si trova nella coda holde non sarà inoltrato finchè l'amministratore non lo rilascierà.
-s sito: Con questa opzione si stabilisce l'inoltro di tutta la posta in coda per il dominio specificato. Di norma sono ammessi tutti i domini per cui Postfix è abilitato come relay-server o quelli presenti nel parametro di configurazione fast_flush_domains.
-v: Opzione per avere maggiori informazioni sullo stato dei processi messi in atto dal comando. Se usato più volte abilita ulteriori informazioni. Da intendersi per l'uso in casi di debugging.

Controllo sulle connessioni con Postfix

Di default Postfix accetta esclusivamente connessioni dal network locale e dai domini che ospita ma in situazioni di rete complesse può essere necessario assumere un maggiore controllo sulle connessioni al server.

Per questo vengono incontro numerosi parametri del file main.cf con cui è possibile effettuare diversi controlli sul traffico di posta del server.
Attraverso il main.cf si può:

Stabilire il comportamento del server al momento della connessione del client.
Si lavora a livello del protocollo SMTP andando a modificare il comportamento del server.
Ad esempio costringendo il server ad accettare connessioni strettamente aderenti allo standard stabilito nella rfc 821 o modificandone il comportamento in concomitanza con alcuni comandi SMTP.
I parametri per queste operazioni riguardano comandi interni al protocollo SMTP, è consigliabile leggere le RFC sull'argomento e fare riferimento alla documentazione ufficiale del pacchetto.
Un parametro tra questi che può essere importante è
smtpd_helo_restrictions = valori
che permette di definire diverse regole di comportamento del server in relazione a quali host possono inviare un comando HELO, l'inizio di norma di qualunque connessione SMTP. Questo parametro è equivalente e viceversa ad altri utilizzabili nel main.cf, come restringere i nomi dei client o i loro indirizzi IP con il parametro
smtpd_client_restrictions = valori
oppure agire sul campo sender
smtpd_sender_restrictions = valori
o sul comportamento del relay della posta
smtpd_recipient_restrictions = valori

Effettuare controlli sugli header di un messaggio e sul corpo dei messaggi.
Stabilendo delle regole di filtraggio delle intestazioni di un messaggio contenenti informazioni sul tipo di programma client e sulle macchine attraverso cui il messaggio è passato dando la possibilità in questo modo di implementare delle liste nere di server da cui non accettare mai la posta e filtrando i contenuti di un messaggio stabilendo delle liste di termini non permessi. Per i parametri e il metodo da usare per implementare questo tipo di controlli fare riferimento alla documentazione ufficiale di Postfix

Restringere l'inoltro della posta per quanto riguarda l'utente specificato nel campo "sender".
In questo modo si può stabilire che il server non accetti posta da client che non specificano un nome di dominio FDQN oppure accettare l'inoltro solo da utenti definiti.
Il parametro che si occupa di questa operazione è
smtpd_sender_restrictions = valori
La sua sintassi, simile nei parametri complementari visti in precedenza, permette di restringere l'uso del server di posta agendo sul campo sender. Opzioni possibili per questo sono
reject_unknown_sender_domain
reject_non_fqdn_sender
oppure un file database con le specifiche per i sender autorizzati con l'utilizzo di una sintassi particolare tipo_file:percorso_file
hash = /etc/postfix/access

Agire sui recipient di inoltro della posta.
Stabilendo regole sulla funzione di relay del server e agendo in sostanza sugli indirizzi concessi nel campo SMTP RCPT TO di modo da limitare o dare accesso per il relay della posta a client non appartenenti alla sotto-rete del server. Questo metodo è consigliato quando si utilizzano controlli di accesso tipo pop-before-smtp che permette l'uso del relay solo a client che si sono autenticati via pop precedentemente.
Il parametro principale è
smtpd_recipient_restrictions = valori
le cui opzioni impongono che sia presente sempre una voce tipo reject, defer, defer_if_permit o reject_unauth_destination altrimenti il server rifiuterà comunque la ricezione di posta.
Per esempio quindi si userà
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
Questo parametro è utilizzabile anche specificando un'opzione di controllo sui client
check_client_access = tipo_file:percorso_file

Le combinazioni di parametri e opzioni possono rendere una configurazione molto complessa e le possibilità offerte sono innumerevoli, è consigliabile prima di approfondire con la configurazione accertarsi di aver compreso come funziona il protocollo SMTP visitando il sito delle request for comments http://www.rfc-editor.org e cercando le rfc 821 e 2821.

usare Postfix per la posta elettronica certificata (PEC)

usare Postfix per la posta elettronica certificata (PEC)

Per impostare rapidamente Postfix, si può procedere così
vim main.cf

e modificare i parametri
myhostname = nomeserver.dominio.it
mydomain = dominio di appartenenza del server (per esempio: dominio.it)
myorigin = indica il dominio per la posta inviata dal server (generalmente: $mydomain)
inet_interfaces = interfaccia di rete da utilizzare (generalmente: all)
mydestination = sono i domini che il server riconosce come locali (generalmente:
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
mail.$mydomain, www.$mydomain)
mynetworks = sono le reti sulle quali il server opera (generalmente:
127.0.0.0/8, 192.168.1.0/24, 10.0.0.0/24

Infine, per controllare se il server sta funzionando
nc -w 1 localhost 25 </dev/null

Passiamo ora alla configurazione avanzata per usare un relay host remoto (smarthost)
sudo vim /etc/postfix/main.cf

e modificare in questo modo
relayhost = smtp.tuoprovider.com

quindi ricaricare la configurazione con
sudo /etc/init.d/postfix reload

Se necessario, si possono aggiungere uno o più indirizzi IP "fidati" dai quali può essere accettata posta da inoltrare, modificando il solito file main.cf
mynetworks = 127.0.0.0/8, 192.168.0.1/24, 10.11.22.33/32, x.x.x.x

Se invece occorre ritrasmettere la posta elettronica per domini specifici (ad esempio quelli locali), si può agire tramite il file transport
dominioqualsiasi.com smtp:[10.0.0.1]:25
unaltrodominio.com smtp:10.0.0.2:25

In generale la regola è questa
dominio_per_cui_fare_relay smtp:ip_server_remoto:porta

Se vogliamo disabilitare la verifica del record MX relativa al dominio in questione verificheremo che nel file /etc/postfix/main.cf ci sia la riga
transport_maps = hash:/etc/postfix/transport

Ricordandosi di impartire il comando postmap ogni volta che si modificano i file di riferimento di  Postfix. Se vogliamo analizzare il traffico SMTP possiamo scrivere
tcpdump -l -s0 -w - tcp dst port 25 | strings | grep -i 'MAIL FROM\|RCPT TO'

Potrebbe nascere l'esigenza di gestire la coda dei messaggi, quindi possiamo seguire le istruzioni che ci da Roberto Pennolino sul suo blog opuntia.biz
postsuper -d ALL

per cancellare la coda dei messaggi
postsuper -d ALL incoming

per cancellare la coda dei messaggi in entrata, eventualmente usare gli altri switch hold, deferred, active
postsuper -d ID_messaggio

per cancellare un singolo messaggio conoscendo il suo identificativo e infine
postqueue -p

per vedere quanti messaggi ci sono ancora nella coda. Ovviamente per inviare tutti i messaggi in coda il comando è
postqueue -f

Andiamo al sodo: configurare il file
/etc/postfix/sasl_passwd

in modo da permettere l'autenticazione SMTP
smtp.example.com [email protected]:password

quindi scriviamo
chown root:root /etc/postfix/sasl_passwd

e poi
chmod 0600 /etc/postfix/sasl_passwd

infine
postmap hash:/etc/postfix/sasl_passwd

A questo punto nel file /etc/postfix/main.conf andiamo a scrivere
relayhost = smtp.example.com
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =

Per tutelare la riservatezza dei messaggi evitiamo di aprirli, ma se fosse necessario controllare l'oggetto, possiamo scrivere gli header_checks nel file main.cf
"regexp:/etc/postfix/header_checks"
main.cf entry = "header_checks = regexp:/etc/postfix/header_checks"

e aggiungiamo
"/^Subject:/ WARN"

questa operazione permette di aggiungere l'oggetto delle email nel file di log di Postfix. Infine, veniamo alla questione cruciale: mi è stato chiesto se la posta elettronica certificata spedita attraverso un MTA Postfix sia valida come quella spedita da altri programmi similari. Si è valida! E spiego perché...

Received: from postino (11.22.33.44) by relay.postecert.it (8.5.137.01) (authenticated as  [email protected])
id 4FB27BD800D15FCC for [email protected]; Wed, 26 Sep 2012 10:19:02 +0200
Received: by postino (Postfix, from userid 1000)
id 6B69B42250; Wed, 26 Sep 2012 10:47:00 +0200 (CEST)
Subject: prova
To:
X-Mailer: mail (GNU Mailutils 2.2)
Message-Id:
Date: Wed, 26 Sep 2012 10:47:00 +0200 (CEST)From: [email protected] (kalos)
X-Riferimento-Message-ID: <20120926084700 data-blogger-escaped-.6b69b42250="" data-
blogger-escaped-postino="">

Dando per scontato che si conoscano le due RFC:  RFC6109 e RFC822 è chiaro che non è importante qual è il programma che spedisce il messaggio, sia che si tratti di Microsoft Outlook che di un qualsiasi altro programma simile.

Difatti, il funzionamento della PEC è molto semplice: quando si utilizza la PEC, viene fornita al mittente una ricevuta che costituisce prova legale dell’avvenuta spedizione del messaggio e dell'eventuale documentazione allegata.

Allo stesso modo, quando il messaggio giunge al destinatario, il gestore invia al mittente la ricevuta di avvenuta (o mancata) consegna, con precisa indicazione temporale. Quando un mittente invia un messaggio al destinatario, attraverso il server di PEC del proprio gestore, il server stesso ne controlla le credenziali d'accesso (nome utente e password).

Quindi il gestore controlla le caratteristiche formali del messaggio e invia al mittente una ricevuta di accettazione (o eventualmente di non accettazione) con tutti gli estremi: data e ora dell'invio, mittente, destinatario, oggetto.

Il messaggio viene quindi "imbustato" dentro un altro messaggio, chiamato "busta di trasporto", firmato digitalmente dal gestore stesso. Questa operazione consente di certificare ufficialmente l'invio e successivamente la consegna. La "busta" viene ricevuta dal gestore PEC del destinatario che controlla la validità della firma del gestore del mittente e la validità del messaggio. Se tutti i controlli hanno avuto esito positivo, invia all'altro gestore una ricevuta di presa in carico e, contestualmente, il messaggio stesso al destinatario.

Quest'ultimo non è detto che lo legga subito. Infatti, il messaggio arriva in un "punto di consegna", che è una specie di cassetta postale. Il punto di consegna ha una funzione importante perché, appena riceve il messaggio, invia una ricevuta di avvenuta consegna al gestore del mittente.

A questo punto il mittente troverà la ricevuta nella propria casella postale. Vediamo come fare "telnet" al server Postfix da Windows... Per installare telnet da riga di comando in windows sette si apre una finestra "MD-DOS" con i permessi di amministratore e si scrive
pkgmgr /iu:"TelnetClient"

(nota: il comando funziona anche su Windows Server 2008 R2, Windows Server 2008 e Windows Vista).

Per verificare che telnet sia correttamente installato, sempre rimanendo nella finestra a riga di comando, scrivere
telnet.exe

Adesso proviamo a connetterci al server di posta, ricordando che telnet non fa distinzione tra maiuscole e minuscole. Scriviamo quindi
set localecho

e premiamo invio per confermare. Questa impostazione permette di visualizzare quello che si scriverà. Quindi...
set logfile [nomefile]
open smtp.nomeprovider.it 25

dove smtp.nomeprovider.it sarà sostituito dal vero nome del vero server SMTP al quale vogliamo collegarci. Premiamo il tasto invio... e scriviamo
EHLO mionomehost.com

(al solito, usate il vero nome host). E poi
MAIL FROM:[email protected]

(invio...)

RCPT TO:[email protected] NOTIFY=success,failure

(invio...)

Lo switch NOTIFY tranquillizza i più ansiosi... perché chiede al server SMTP di inviare una notifica sullo stato del recapito (per chi volesse evolvere le proprie conoscenze i messaggi DSN vengono definiti nella RFC 1891).

Scriviamo adesso
DATA

(il solito "invio"...)

Riceveremo una risposta dal server SMTP che ci indica come terminare la digitazione del corpo del messaggio, andiamo a scrivere allora
Oggetto: la mia email

(invio... 2 volte! - perché la RFC2822 richiede che l'oggetto sia separato dal corpo del messaggio da un "invio")
Caro amico ti scrivo...

(invio... 2 volte! - per il motivo di cui sopra...)

Adesso scriviamo un "punto"
.

per comunicare al server che abbiamo terminato di scrivere il messaggio. Dovrebbe apparire un messaggio di conferma tipo questo
250 2.6.0 [ID] Queued mail for delivery

dove [ID] è l'identificativo univoco assegnato a quel messaggio. Per chiudere la connessione si digita
QUIT

e si preme invio... Il server, educatamente, saluterà con qualcosa del tipo
221 2.0.0 Service closing transmission channel

Per chiudere il programma TELNET si scriverà ancora
QUIT

seguito da invio... Dal blog di Roberto Pennolino vediamo adesso come inserire un filtro sulle ricevute di ritorno. Iniziamo con la configurazione di Postfix editando il file
vi, /etc/postfix/main.cf

ed andiamo a cercare il parametro mailbox_command in questo modo
mailbox_command = /usr/bin/procmail -a “$EXTENSION” DEFAULT=/home/$USER/Maildir/
MAILDIR=/home/$USER/Maildir/

Successivamente entriamo con le credenziali dell'utente della casella di posta elettronica sulla  quale si deve effettuare il filtraggo e modifichiamo
vim .procmailrc

Mettiamo ora all’interno del file le nostre regole
#directory
MAILDIR = $HOME/Maildir/ # Le email finiranno qui
# sposta le ricevute di lettura in
# /home/utente/Maildir/.Notifiche\ lettura/
:0
* ^Subject.*Letto:*
#/dev/null
/home/utente/Maildir/.Notifiche\ lettura/
:0
* ^Subject.*Read -*
#/dev/null
/home/utente/Maildir/.Notifiche\ lettura/
:0
* ^Subject.*Notification for*
#/dev/null
/home/utente/Maildir/.Notifiche\ lettura/
:0
* ^Subject.*Recapitato:*
#/dev/null
/home/utente/Maildir/.Notifiche\ lettura/



Risorse e riferimenti:
http://www.postfix.org/TLS_README.html#client_smtps
http://www.rigacci.org/wiki
http://postfix.state-of-mind.de
http://www.hostingtalk.it/articoli/mail-server-e-posta
http://www.rfc.it/
http://www.zimbra.com/
http://www.seacom.it