Premettiamo innanzitutto che per gestire direttamente la posta è necessario un ip pubblico fisso. Inoltre nella maggior parte dei casi, questo indirizzo sarà assegnato ad un router, che di norma “filtra” il traffico verso la rete interna dell’azienda. Nel caso meno probabile che la macchina su cui è installato MDaemon è “pubblicata” direttamente, è ovviamente possibile saltare la parte relativa alla configurazione del router, ma vale tutto il resto.
Per semplificare la spiegazione verranno utilizzati convenzionalmente (a puro titolo di esempio) i seguenti dati:
- 10.10.10.10 – indirizzo privato del server MDaemon
- 2.2.2.2 – indirizzo pubblico del router
- nomeazienda.it – nome di dominio assegnato
- mail.nomeazienda.it – alias per il puntamento MX (email).
Le prime due operazioni da eseguire non si possono fare autonomamente, ma ci si deve rivolgere direttamente al fornitore di servizi:
-
- a chi gestisce il nome di dominio è assolutamente necessario chiedere di “modificare il puntamento MX nel DNS per il dominio nomeazienda.it” in modo che punti a 2.2.2.2 e di “creare l’alias mail.nomeazienda.it” in modo che punti sempre allo stesso 2.2.2.2
- a chi fornisce la linea internet si deve chiedere di impostare il “reverse DNS” per 2.2.2.2 su mail.nomeazienda.it
La prima richiesta è essenziale per poter ricevere le email direttamente, la seconda è per diminuire la possibilità di finire in BlackList o che le mail inviate dal proprio server vengano rifiutate da sistemi antispam.
Appena effettuata la richiesta (non dopo che è stata eseguita, altrimenti per qualche giorno potremmo non ricevere la posta ne sul vecchio server ne sul nuovo) si può procedere nella configurazione di MD:
-
- Dominio
nel dominio primario: nomeazienda.it
FQDN: mail.nomeazienda.it
nome computer: mail.nomeazienda.it
dominio ip: (dovrebbe esserci in automatico l’ip della macchina) 10.10.10.10
- Dominio
- Consegna
contrassegnare la flag: invia i msg in uscita al server di posta del destinatario
in questo caso la parte di host intelligente non serve: se le richieste 1 e 2 ai fornitori di servizi precedentemente descritte vengono completate correttmanete non vi è ragione per passare dall’SMTP del provider. Eventualmente per qualche giorno possiamo impostare la configurazione per l’host intelligente ed utilizzare l’SMTP del provider, finchè non si saranno propagate le informazioni relative alla modifica DNS richiesta (normalmente un paio di giorni).
Configurazione del router
Molto probabilmente il router/firewall avrà tutte le porte dall’esterno chiuse verso l’interno, per evitare intusioni nella propria rete aziendale. Occorre quindi aprire le porte che vogliamo utilizzare con MD dall’esterno verso la macchina su cui gira MD: cioè dall’esterno le richieste sulla porta 25 devono essere girate su 10.10.10.10 (si ricordi che è un indirizzo di esempio) sulla porta 25.
In uscita dovrebbe essere tutto aperto, ma vale la pena di controllare che la 25 sia aperta anche in uscita, almeno per il nostro server 10.10.10.10.
Discorso analogo va fatto per altre porte: 110 (POP), 143(IMAP), 443(SSL), 3000 (WorldClient), 1000(WebAdmin) ecc. ecc. a seconda dei servizi che intendo utilizzare da fuori sede sul MDaemon. Ad esempio se i client di posta e gli utilizzatori delle caselle sono TUTTI sulla rete locale, l’apertura della porta 25 è sufficiente per il corretto funzionamento del server.
Per modificare le impostazioni del router, la procedura dipende dai modelli, è necessario quindi far riferimento al manuale del produttore.
Le caselle nomeutente@nomeazienda.it come sono configurate attualmente, cioè prima di utilizzare MD per gestire direttamente la posta?
Presumibilmente se già si utilizzava MDaemon, sono configurate in MultiPOP o in DomainPOP. Allora è necessario verificare che nella configurazione del Multipop (o DomainPOP) di ogni casella ci sia il server POP3 corretto e se corrisponde proprio a quello scelto da noi (mail.nomeazienda.it) dovremo utilizzare l’indirizzo IP numerico del vecchio server corrispondente.
Con questa operazione abbiamo sufficiente garanzia che, nei giorni di “transitorio” in cui l’informazione relativa al cambio di DNS si sta propagando, la nostra azienda continua regolarmente a ricevere i messaggi di posta.
Nel giro di qualche giorno dovrebbe essere possibile disabilitare le vecchie caselle in MultiPOP (o DomainPOP) e ricevere direttamente: lo si vede dai log del DomainPOP o MultiPOP che l’attività di scarico dal vecchio server diminuisce progressivamente fino a terminare del tutto.
Di default MD attiva tutte le impostazioni necessarie per NON agire come OpenRelay, per cui non sono necessarie altre impostazioni particolari.
Best practice
La configurazione di default di MDaemon è tale per cui esso non può essere considerato un open relay.
Tuttavia, alcuni sistemi che gestiscono le liste fanno controlli particolari per verificare che la configurazione di un server di posta sia “a regola d’arte”. Occorre quindi accertarsi che il proprio server sia configurato in maniera opportuna.
Ecco un elenco di operazioni da eseguire:
- Verificare che tutti i domini gestiti dal server abbiano un account o un alias del tipo: postmaster@dominio.
- Verificare che tutti i domini gestiti dal server abbiano un account o un alias del tipo: abuse@dominio.
- Verificare se il mail server recapita un’email inviata da postmaster@dominio a un destinatario remoto nell’ambito di una sessione non autenticata.
- Verificare che nel menu Accounts->Address aliases->Options (in MDaemon 10 il menu Accounts->Account settings->Aliases->Options) sia abilitata l’opzione “Mail From postmaster … “.
- Evitare di creare gli account root e test a meno di aver abilitato l’autenticazione per tutti gli account.
- Verificare che nel menu Security->Relay/Trusts/….->Relay Settings (in MDaemon 10 il menu Security->Security settings->Relay control) siano abilitati i flag
- “Do not allow message relaying”, “SMTP MAIL…”
- “SMTP RCPT TO …”.
- Verificare che siano abilitate le “strong password”, controllando il menu Setup->Miscellaneous options->Misc (IN MDaemon 10 il menu Accounts->Account settings->New Account defaults) e abilitando il flag “Require strong passwords”.
- Attivare il protocollo SPF nei propri DNS.
Mail server secondario
Si consideri inoltre che passando a una configurazione in cu MDaemon riceve la posta direttamente si diventa responsabili in tutto e per tutto di una eventuale indisponibilità di MDaemon: caduta di linea, blocco del server, ecc.
E’ quindi opportuno disporre di un server di posta secondario, detto anche MX secondario.
Si può disporre di un server secondario in differenti modalità:
- può essere il proprio ISP a fornire il servizio
- può essere il fornitore che ha registrato il dominio
- si può avere un proprio server residente in una sede differente da dove risiede il server principale.
Qualora il server MDaemon primario non sia disponibile, la posta elettronica verrà recapitata al server di posta secondario. Quando il server primario poi tornerà inlinea sarà necessario svuotare le code dal server secondario. Questa operazione può essere eseguita in vari modi.
Il metodo standard e probabilmente più è l’ETRN.
Si tratta di un comando che l’MDaemon primario può inviare al server secondario chiedendo di svuotare le code. Naturalmente il server secondario deve supportare tale comando, ma non dovrebbe essere un problema in quanto è un comando standard per la gestione della posta elettronica.
Per eseguire questa operazione:
Per fare questa operazione è necessario inserire nei DNS un secondo record MX con priorità più bassa rispetto al server MDaemon (si ricordi che il numero che indica la priorità dei server di posta funziona “al contrario” ossia il server con il numero più basso è quello con la priorità di alta, ossia il primario).
- In MDaemon 9.x i comandi per inviare al server remoto il segnale di svuotamento delle code si trova in Setup->Primary domain->Dequeue.
- In MDaemon 10 i comandi per inviare al server remoto il segnale di svuotamento delle code si trova in Setup->default domain->mail release.
