Configurazione di un proxy mail linux verso MacOS

Iniziamo con questo primo HowTo la (spero lunga) collezione di configurazioni su cui ho dovuto sbattere la testa. Questo documento è scritto basandosi su un server interno MacOS e un server DMZ Linux Debian Lenny, però è possibile adattare la configurazione a qualsiasi altra distrubuzione Linux.

1) Qual è la situazione

In questo caso, il cliente parte avendo un classico server mail in DMZ basato su cyrus/postfix/horde con distribuzione Debian Lenny per la posta aziendale, ma ha successivamente acquistato un server MacOS in quanto utilizza per lo più client MacOS e l’ha collegato in rete LAN. Il cliente ora vuole consolidare la posta e ha quindi richiesto che il server interno MacOS funga anche da server mail.
Dato che il server MacOS contiene informazioni molto importanti, il cliente (giustamente) non vuole però che sia direttamente raggiungibile attraverso Internet; si assume che:

a) i server MX del dominio di posta sono dall’ISP e questi inoltreranno la posta ai server dell’azienda con un transport SMTP;
b) il server MacOS non spedirà direttamente su Internet la posta ma si utilizzerà il server relay dell’ISP che però necessita di autenticazione;
c) c’è l’esigenza di far accedere alla posta alcuni utenti che si connettono dall’esterno ma non si vuole né farli accedere direttamente al server MacOS aprendo le porte sul firewall, né costringere l’utente ad aprire un collegamento VPN sia per una questione di praticità, sia perché non si vuole esporre l’intero server MacOS all’utente che si collega in VPN.

Pertanto si riconfigurerà il vecchio server in DMZ in modo che funga sia da server webmail (Horde) accedendo alle caselle IMAP del server MacOS, sia da proxy per le connessioni IMAP provenienti dall’esterno e sia da server SMTP Auth per la spedizione delle mail degli utenti esterni sulla porta 587. Inoltre riceverà le mail in arrivo attraverso la porta 25 provenienti dai server MX dell’ISP e le girerà al server MacOS. Così facendo, solo il server Linux sarà esposto ad Internet (come avveniva prima dell’aggiunta del server MacOS) sulle porte 443 (Webmail), 25 (posta in ingresso dagli MX ISP), 587 (SMTP Autenticato), 143 (IMAP) e il server aziendale starà al sicuro all’interno della lan. Visto che le connessioni tra il server in DMZ e il server MacOS passano attraverso il firewall, sarà necessario permettere l’accesso alle porte 25 e 143 dal server in DMZ verso il server MacOS.

2) configurazione del server MacOS

Il server MacOS dispone di due ottimi pannelli di configurazione: Server Admin per configurazione dei servizi server e Workgroup Manager per la gestione utenti.
Attraverso il primo pannello è necessario innanzi tutto abilitare il servizio Mail. Quindi andremo nella scheda “Settings” del server Mail dove esistono sei sottoscede di configurazione. Vediamole in dettaglio:

General: contiene le impostazioni di base del nostro server mail. In “Domain Name” bisogna inserire il dominio pubblico del cliente (dominio.tld), in “Host Name” il nome host del server (host.dominio.tld) ricordandoci di abilitare la corrispondente voce nel DNS pubblico per pulizia di configuazione (difatti non sarebbe necessario in quanto la posta in uscita passa attraverso un server relay, però così facendo in caso di emergenza il clinte potrà spedire posta autonomamente evitando che le mail siano rigettate perchè manca il nome host). Abilitiamo i check su “Enable SMTP”, “Allow incoming mail”, “Relay outgoing mail through host” indicando nel campo seguente il nome host del server SMTP del nostro ISP, “Authenticate to relay with username” indicando nei due campi seguenti username e password del cliente; ovviamente abilitiamo anche “Enable IMAP” ed “Enable POP”.
Relay: in questa scheda non abilitiamo nulla, in quanto per la posta in spedizione eseguiremo l’autenticazione anche da rete interna
Filters: in questa scheda io ho preferito disabilitare tutte le funzionalità di antispam/antivirus, in quanto il server dell’ISP già si occupa di questi controlli. Ho comunque lasciato attivo il check su “Enable server side mail rules” in modo da permettere agli utenti la creazione di filtri sulla posta in arrivo direttamente sul server
Quotas: in questa scheda ho lasciato abilitata solo la funzionalità di rigettare posta più grande di 10 MB, che corrisponde al limite settato dall’ISP. Giusto per scrupolo…
Mailing List: tutto disabilitato
Logging: tutto a “Critical”
Advanced: ho abilitato solo i protocolli non sicuri (LOGIN e PLAIN) sia su SMTP, sia su POP3/IMAP, tanto si potrà accedere solo attraverso la rete LAN pertanto si possono migliorare le prestazioni evitando l’overriding dei sistemi di criptaggio senza perdere in sicurezza.

Il secondo pannello (Workgroup Manager) permette di creare e gestire gli utenti nel database LDAP del server MacOS. Ogni utente ha quindi uno “Short Name” che normalmente è nella forma nome.cognome che corrisponderà alla prima parte della casella email (nome.cognome@dominio.tld). Nella configurazione dell’utente è necessario entrare nella scheda “Mail” e cliccare sul radio button “Enabled” per far si che l’utente abbia accesso alla propria email.
Nel caso di alias (ad esempio la casella info@dominio.tld -> nome.cognome@dominio.tld) è comunque necessario creare un nuovo utente (magari in”Basic” levare la spunta su “Access Account”); poi nella scheda “Mail” impostare il radio “Forward” e inserire l’email di destinazione completa nel campo sottostante (nome.cognome@dominio.tld).

Qui nasce la prima difficoltà per il funzionamento: per spedire la posta, il server MacOS richiede che l’ISP supporti i protocolli criptati per la spedizione della password; purtroppo in questo caso questo non è possibile e, visto che non non esiste un parametro di configurazione all’interno del Server Manager, si rende necessario modificare manualmente il file di configurazione.
Aprire quindi il terminale e lanciare il comando

sudo nano /etc/postfix/main.cf

(chiederà la password dell’utente) ed aggiungere:

smtp_sasl_security_options =

Quindi lanciare

sudo postfix reload

per rendere attiva la configurazione

3) importazione dei messaggi di posta dalle vecchie caselle e dismissione del vecchio server di posta

Faremo questa operazione in più momenti in modo da garantire il minimo dei disservizi agli utenti della rete interna, sacrificando la continuità di servizio degli utenti che accedono dall’esterno. Quindi i passi saranno:

3a) prima importazione di tutti i messaggi dal server linux al server MacOS

Per questa operazione ci viene incontro il pacchetto ”imapsync” presente praticamente in tutte le distribuzioni linux e quindi anche su Debian Lenny. Una volta installato il pacchetto sul vecchio server linux, è sufficiente lanciare il comando:

imapsync --host1 127.0.0.1 --user1 nome.cognome@dominio.tld --password1 password --host2 servermacos.dominio.tld --user2 nome.cognome --password2 password--noauthmd5 --nofoldersizes --exclude 'Junk|Spam'

Notare la differenza nella login al server IMAP: sul vecchio server Cyrus (come in molti server degli ISP) la login corrisponde all’intera mailbox, mentre sul server MacOS si usa la username di collegamento (Short Name).

3b) far si che il server linux non riceva più la posta in arrivo ma vada direttamente al server MacOS (temporaneamente)

Una volta completata la prima sinronizzazione si procede a modificare la configurazione del firewall in modo che le connessione su porta 25 siano temporaneamente reindirizzate al server MacOS (nella situazione definitiva anche le connessioni su porta 25 per la posta in arrivo passeranno attraverso il vecchio server linux) e si riconfigurano i client della rete interna per accedere alla nuova mailbox.

3c) Riconfigurazione del server postfix in DMZ per inoltrare la posta nel modo corretto e non più in locale

A questo punto modifichiamo la configurazione di postfix del server in DMZ per inoltrare tutta la posta per dominio.tld al server MacOS e tutta la posta “esterna” al server relay dell’ISP e rimettiamo mano al firewall aziendale per far passare la posta attraverso il vecchio server Linux. Questo doppio passaggio ci permette di dare continuità di servizio ai client sulla rete interna senza perdere alcuna posta in arrivo, nemmeno temporaneamente.

<strong>sudo nano /etc/postfix/main.cf</strong>:

mydomain = dominio.tld
myhostname = host.dominio.tld
mynetworks = 127.0.0.0/8
mynetworks_style = host
mydestination =
local_recipient_maps =
local_transport = error:local mail delivery disabled
program_directory = /usr/lib/postfix
smtp_helo_name = host.dominio.tld
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_sasl_security_options =
smtpd_banner = host.dominio.tld ESMTP
smtpd_hard_error_limit = 1000
smtpd_soft_error_limit = 1000
smtpd_error_sleep_time = 0
smtpd_recipient_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unauth_destination,
  reject_unauth_pipelining,
  reject_invalid_hostname,
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
relay_domains = colorservice.net
relay_recipient_maps =
transport_maps = hash:/etc/postfix/transport




<strong>/etc/postfix/sasl/sasl_passwd:</strong>

relay.dominio.tld nomeutenteisp@dominio:password




<strong>/etc/postfix/transport:</strong>

dominio.tld        smtp:[ip_server_macos]

ricrdarsi di lanciare:

postmap /etc/postfix/sasl/sasl_passwd
postmap /etc/postfix/transport
postfix reload

per rendere effettive le modifiche,

3d) Rilanciamo l’IMAP Sync per sincerarci che anche l’ultima posta arrivata sul vecchio server venga copiata nel server MacOS e spegnamo il servizio IMAP sul server linux

/etc/init.d/cyrus2.2 stop

A questo punto il server interno è totalmtente funzionante per la rete interna ma gli utenti esterni non hanno più accesso alla posta elettronica… ma per poco!

4) Proxy IMAP

Ora che il server in DMZ non risponde più al servizio IMAP, possiamo concentraci su come proxare le connessioni esterne al server interno. Come per il problema al punto 3, fortunatamente esiste un pacchetto linux dedicato al proxaggio del protocollo IMAP e POP3 (configureremo solo il primo) che si chiama ”Perdition”.

Una volta installato, andremo ad editare il file /etc/perdition/perdition.conf andando a modificare i seguenti parametri:

<strong>/etc/perdition/perdition.conf:</strong>

imap_capability "IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA"
protocol IMAP4
outgoing_server ip_server_macos

Una volta salvato il file di configurazione e fatto partire il servizio, ecco che i nostri utenti esterni potranno ricominciare ad autenticarsi attraverso il protocollo IMAP e a leggere la posta presente sul nuovo server MacOS.
Inoltre, sul server in DMZ é già presente una webmail (Horde) che è già configurata per avere sia come server per la posta in ingresso, sia come server della posta in uscita (senza autenticazione) localhost, per cui già da ora gli utenti esterni hanno la possibilità di inviare e ricevere posta attraverso la webmail. Non tratteremo in questa sede come configurare la WebMail Horde perchè è piuttosto semplice e si trovano già molti altri HowTo.

5) Autenticazione per la posta in uscita dall’esterno

Su questo punto ho dovuto soffrire non poco perchè inizialmente avrei voluto utilizzare l’autenticazione attraverso LDAP, ma mi sono dovuto scontrare con le difficoltà sul metodo di criptaggio delle password all’interno del database LDAP di MacOS (Kerberos) e quindi ho dovuto trovare un metodo alternativo. La soluzione stava dietro l’angolo in quanto il pacchetto Cyrus SASL che ho utilizzato per gestire l’autenticazione di Postfix dul server in DMZ supporta la possibilità di utilizzare una connessione IMAP. In questo caso la password tra il server in DMZ e il server interno passa in chiaro, ma così facendo evito di aprire altre porte verso il server interno dal server in DMZ: infatti il firewall è impostato per lasciar passare solo le porte 143 (IMAP) e 25 (SMTP).

Innanzi tutto quindi modifichiamo il file di configurazione del demone saslauthd che in Debian si trova in /etc/default/saslauthd:

<strong>/etc/default/saslauthd:</strong>

START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="rimap -O ip_server_macos"
OPTIONS="-r -c -m /var/spool/postfix/var/run/saslauthd"

E’ giusto notare la path nella quale girerà il demone: nel caso di Debian Lenny (come in moltissime altre distribuzioni) Postfix gira in un ambiente chrooted per cui non ha visibilità all’intero albero del filesystem, quindi bisogna far girare il demone saslauthd in una directory visibile a postfix.

A questo punto è possibile lanciare il demone e testare la funzionalità del sistema di autenticazione con:

<span style="font-family: Arial;">testsaslauthd</span> <span style="font-family: Arial;">–</span><span style="font-family: Arial;">u</span> <span style="font-family: Arial;">USER</span> <span style="font-family: Arial;">–</span><span style="font-family: Arial;">p</span> <span style="font-family: Arial;">PASS</span>

Ora passiamo all’untima configurazione di postfix: è necessario dar si che l’utente postfix abbia il permesso di accedere al socket di saslauthd, quindi è necessario modificare il file /etc/group e aggiungere l’utente postfix al gruppo sasl.

Infine bisogna editare il file /etc/postfix/sasl2/smtpd.conf:

<strong>/etc/postfix/sasl2/smtpd.conf:</strong>

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

Ora lanciare il demone saslauthd e ricaricare postfix per ultimare la configurazione.