Difference between revisions of "Small Business Server (Italiano)/Mail Server"

From ArchWiki
Jump to: navigation, search
Line 7: Line 7:
 
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.
 
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.
 
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server.  Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.
 
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server.  Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.
++ Un lavoro di squadra
+
== Un lavoro di squadra ==
 
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.
 
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.
 
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta.  
 
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta.  

Revision as of 09:38, 30 January 2008

Ad un SBS che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.

Premessa

Il mail server che andremo ad implementare è un mail server ufficiale. Questo significa che :

  1. Il nostro ipotetico dominio mede.it deve essere pubblicamente registrato
  2. L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip fisso
  3. Il maintainer del nostro dominio, se gestisce anche il DNS "pubblico" di mede.t, deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di mede.it siamo noi.

Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità relay. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo andarci a prendere la posta in arrivo dal server del provider se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.

Un lavoro di squadra

La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ping pong dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da virus e spam se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di qualche giorno prima di venire bannati dagli altri. Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a 6 voci, dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. Vediamo quali sono i nostri interpreti:

  1. Postfix : Il nostro MTA che implementa il server SMTP della nostra azienda
  2. Postgrey : Servizio che implementa il greylisting
  3. Clamav : L'antivirus usato da amavis-new per scanarizzare le mail
  4. Spamassassin : Usato da amavis-new per individuare lo spam
  5. Amavis-new : Il content filter che analizza le mail con Clamav e SpamAssassin
  6. Dovecot : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server

Un bel coretto non c'è che dire ...

Installazione

Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.

Postfix

sudo pacman -S postfix

controlliamo ora che il file /etc/passwd contenga :

postfix:x:73:73::/var/spool/postfix:/bin/false

e che /etc/group contenga :

postdrop:x:75:
postfix:x:73:

Postgrey

Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR. Prima installamo i moduli perl necessari :

sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex 

e ora il pacchetto da AUR

yaourt -S postgrey

N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.

Clamav

sudo pacman -S clamav

Spamassassin

sudo pacman -S spamassassin

Amavis-new

Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :

sudo pacman -S make patch

E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.

yaourt -S amavisd-new

Alla fine rientra in gioco il mio repository radioattivo.

pacman -Sf  stenoweb/perl-file-temp

Amavis vuole "espressamente" la versione 0.19 di perl-file-temp. Noi siamo gentili e gliela forniamo.

Dovecot

sudo pacman -S dovecot

Il giochino delle parti

Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee. Quando un messaggio arriva al nostro MTA succederà questo:

  1. Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey
  2. Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo
  3. Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis
  4. Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.
  5. Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.
  6. Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.

Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena... IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.