È ormai una consuetudine o forse più una moda inserire in fondo alle e-mail inviate un disclaimer con una frase in una o più lingue tipo:

“This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message …”

Quanto valore giuridico abbiano poi certi disclaimer è una domanda che spesso ci si pone.

Poichè il management spesso richiede che il disclaimer sia presente in calce alle email, è conveniente che sia il sistema di posta utilizzato ad inserire automaticamente nelle email in uscita (internamente non ha molto senso!) una frase che svolge la funzione di disclaimer.

1. PROCEDURA
L’inserimento automatico del disclaimer richiede alcuni passaggi completamente gestiti dal Domino Administrator. Accedere quindi al Domino Administrator ed effettuare il login.

Selezionare la pagina Configuration per accedere alla sezione richiesta. Selezionare nella parte sinistra Messaging –> Configurations e cliccare sul bottone Edit Configuration.

Accedere alla sezione Router/SMTP –> Message Disclaimer. Impostare il campo Message disclaimers come Enabled.

Cliccare su Save & Close per salvare la configurazione appena impostata.

Accedere alla pagina People & Groups e selezionare Settings nella parte sinistra. Cliccare sul bottone Add Settings e selezionare l’opzione Mail.

Assegnare nel campo Name un nome significativo (es. Disclaimer) per identificare il parametro e nel campo Description una descrizione operativa della configurazione.

Selezionare successivamente Mail –> Message Disclaimers per impostare il tipo di messaggio che deve essere allegato alle email. Abilitare (Enable) il campo Notes client can add disclaimers ed inserire in Disclaimer text il testo che si vuole visualizzare. Cliccare infine su Save & Close per salvare la configurazione impostata.

A questo punto non rimane che creare una policy per abilitare nel dominio la funzionalità del disclaimer. Dalla pagine People & Group selezionare Policies e cliccare sul bottone Add Policy.

Assegnare la Policy name specificando il dominio del sistema, una Policy type di tipo Organizational e una Description. Nei Setting Type cliccare sulla freccia in corrispondenza del campo Mail e selezionare dalla finestra che appare la configurazione Disclaimer precedentemente impostata. Cliccare su Save & Close per salvare la policy.

Nella parte destra della schermata sono visualizzate le policy applicate al dominio.

A questo punto la configurazione è conclusa e non rimane che abilitarla.

Per abilitare immediatamente la policy nel server utilizzare dalla console il comando:

tell adminp process mailpolicy

Nel caso la policy non risultasse operativa, riavviare il server. La procedura è conclusa e pronta per la fase di test.

2. TESTARE LA CONFIGURAZIONE
Dal client di posta inviare una email ad un indirizzo interno della rete (sottolineato in rosso nella figura) e una ad un indirizzo esterno (sottolineato in verde) per verificare il comportamento del sistema.

L’email ricevuta nella casella esterna riporta il disclaimer correttamente.

L’email ricevuta nella casella interna invece, non presenta il disclaimer. E’ esattamente il comportamento voluto con questa configurazione.

Il sistema provvederà quindi ad inserire automaticamente il disclaimer in tutte le email destinate all’esterno della rete, quindi all’azienda, mentre per le comunicazioni interne le email non presenteranno nessuna dicitura.

Hai già letto questi articoli?

• Configurare ID Vault in Lotus Domino 8.5.3
• Configurare iNotes per l’accesso alla webmail di Lotus Domino tramite browser in Windows 2008 R2
• Gestire le prenotazioni di meeting room e risorse con Lotus Domino
• Rinnovare il certificato Notes User ID in Lotus Domino

La posta elettronica è ormai un servizio indispensabile per il business di qualsiasi azienda. Testare nuove soluzioni per contenere i costi e migliorare la produttività è ormai un target per tutti gli addetti informatici.

Tra le varie proposte del mercato, Zimbra (acquisita nel 2010 da VMware) sembra essere una valida alternativa ai più blasonati sistemi di posta Microsoft Exchange o Lotus Domino. Nelle tre edizioni disponibili, i tagli utenti offerti sono molto vantaggiosi e soprattutto le PMI possono avere a disposizione un buon sistema alternativo con una spesa contenuta.

Naturalmente, come ogni prodotto, una fase di test deve essere effettuata per verificare che le esigenze del proprio business siano effettivamente soddisfatte.

1. PREREQUISITI
Per eseguire l’installazione di Zimbra, sono richieste tre principali verifiche:

1. Spazio disco sufficiente
2. Presenza dei package prerequisiti
3. Impostazione corretta del file /etc/hosts

Poichè Zimbra viene installato come default nella partizione /opt, verificare che ci siano  almeno 10GB di spazio disponibili su disco per evitare problemi durante l’installazione.

Partendo da un’installazione minima di CentOS (fare riferimento a questo post), installare i package mancanti richiesti.

# yum install perl sudo libidn gmp sysstat

Editare il file /etc/hosts ed impostare i seguenti parametri:

127.0.0.1           localhost.localdomain localhost
ip_host         FQDN hostname

2. PROCEDURA
Scompattare il file scaricato dal sito di Zimbra ed eseguire l’installazione lanciando il comando install.sh. Installando l’applicazione su Linux CentOS, è necessario specificare il parametro –platform-override.

# tar –xzvf zcs-NETWORK-6.0.9_GA_2686.RHEL5.20101115224226.tgz
# mv zcs-NETWORK-6.0.9_GA_2686.RHEL5.20101115224226 zcs
# cd zcs
# ./install –platform-override

Durante la fase di installazione vengono verificati i prerequisiti di Zimbra. Nel caso manchi qualche package, il sistema blocca l’installazione visualizzando i prerequisiti mancanti.

Installare eventualmente i package mancanti e rilanciare lo script install.sh. Digitare Y per accettare l’EULA e premere Invio.

Successivamente specificare le opzioni che Zimbra deve installare.

Install zimbra-ldap [Y] y
Install zimbra-logger [Y] y
Install zimbra-mta [Y] y
Install zimbra-snmp [Y] y
Install zimbra-store [Y] y
Install zimbra-apache [Y] y
Install zimbra-spell [Y] y
Install zimbra-convertd [Y] y
Install zimbra-memcached [N] y
Install zimbra-proxy [N] y
Install zimbra-archiving [N]

Poichè l’installazione viene effettuata sul sistema CentOS, la procedura di installazione visualizza un warning. Digitare Y e premere Invio per continuare.

Alla domanda successiva, digitare Y e premere Invio.

Terminata la procedura viene visualizzato il menu principale. Nelle voci dove compare il doppio asterisco (Admin Password), è necessario specificare i parametri mancanti. Digitare 3 al prompt e premere Invio.

Viene visualizzato un altro menu Store Configuration. Le voci indicate dagli asterischi devono essere configurate.

Digitare 4 al prompt e inserire la password.

Digitare 25 al prompt e specificare il path del file.xml della licenza.

I parametri appena specificati vengono marcati come SET.

Digitare r per ritornare al Main menu. La configurazione è ora completa.

Per salvare la configurazione, digitare a al prompt e premere Invio. In questa fase viene  ultimata la configurazione del sistema.

Dopo qualche minuto la procedura di installazione termina con la visualizzazione del messaggio Configuration complete. Premere Invio.

Dal browser di Internet, digitare l’indirizzo https://IP_zimbra:7071 per accedere alla pagina di login della Administration Console. Per effettuare il login, digitare:

Username: admin
Password: la password specificata precedentemente

Cliccando sul bottone Log In si accede alla pagina di amministrazione di Zimbra.

3. RIMOZIONE DI ZIMBRA
Se per un qualsiasi motivo si ha l’esigenza di rimuovere l’applicazione, lanciare da console il comando:

# ./install –u

L’installazione di Zimbra è conclusa. Nella seconda parte dell’articolo viene analizzata la configurazione base e la verifica di funzionalità per implementare il servizio di posta.

Hai già letto questi articoli?

• Installare Zimbra come servizio di posta elettronica su CentOS 5.x – 2° parte
• Monitorare i sistemi con Nagios tramite check_mk in CentOS
• Monitorare AS/400 con Nagios in CentOS
• Monitorare server ESX(i) con Nagios tramite plugin check_esx su CentOS

Installato il mail server e l’appliance Brightmail, in questa terza parte viene analizzata la configurazione dell’applicazione per renderla finalmente operativa.

Naturalmente l’ottimizzazione della configurazione globale dell’applicazione dipende dalla tipologia e dimensione della rete. Fortunatamente il manuale fornito con Brightmail analizza in modo ampio le varie opzioni e parametri che si possono impostare.

1. CONFIGURAZIONE
Per accedere al pannello di configurazione è necessario effettuare il login tramite browser. Digitare http://IP_Brightmail utilizzando come parametro uno dei due IP assegnati durante la fase di installazione. Digitare come username admin e come password quella assegnata in fase di installazione.

Al primo accesso viene presentata l’EULA. Mettere il flag su “I accept the terms of the license agreement.” e proseguire cliccando su Next.

Quando è stato effettuato il download dell’applicazione dal sito della Symantec, nella casella email specificata durante la registrazione dovremmo trovare un file della licenza in formato 12345678.slf che permette l’utilizzo di Brightmail per 30 giorni. Tramite il bottone Browse caricare il file di licenza e cliccare su Register License.

La corretta esecuzione del comando viene confermata dal messaggio di registrazione avvenuta.

Attivato il prodotto, comincia la fase di configurazione. Specificare nella finestra che segue l’email dell’amministratore per ricevere le varie notifiche e messaggi del sistema.

Come visto più volte, tenere sincronizzati i sistemi presenti in una rete è un requisito fondamentale specialmente in presenza di strutture come Active Directory che richiedono la sincronizzazione del Time dei server per il protocollo di autenticazione Kerberos. E’ opportuno quindi attivare l’opzione Use NTP servers specificando dei server NTP pubblici (ad esempio inrim.it) o che risiedono all’interno della rete.

Specificare il System Locale per determinare il formato dei numeri, della data e del tempo.

Nella finestra successiva bisogna specificare lo Scanner Role che si vuole attribuire al sistema. Volendo controllare sia i messaggi in entrata che in uscita, si attiva l’opzione Inbound and Outbound mail filtering.

Assegnare quali interfacce Ethernet svolgeranno il compito di inbound/outbound filter. Come Inbound Mail Filtering specificare il primo IP configurato durante la fase di installazione.

Essendo lo scanner delle email in arrivo (Inbound Mail Filtering), il filtro stesso dovrà accettare tutti gli indirizzi IP per permettere l’arrivo delle email da qualsiasi host.

Specificare come Local Domains il dominio o domini di cui si vogliono ricevere le email. In pratica se il dominio aziendale è companydomain.com, questo è il dominio che deve essere indicato nel campo Domain or email address for which to accept inbound mail. Il domino utilizzato nel test è labtest.dyndns.org.

Come Outbound Mail Filtering specificare il secondo IP configurato durante la fase di installazione. Quindi delle due interfacce Ethernet configurate, una è assegnata per il controllo delle mail in entrata e la seconda per le mail in uscita.

Come Outbound Mail Filtering – Accepted Hosts specificare il dominio o gli indirizzi IP che lo scanner deve accettare per verificare le email in uscita. Aggiungere nel campo IP addresses/domains l’indirizzo IP del mail server aziendale.

Specificare come Mail Delivery l’hostname o l’indirizzo IP del mail server.

Come Mail Filtering – Non-local Mail Delivery, lasciare attiva l’opzione di default Use default MX Lookup.

Terminata la fase di configurazione, viene illustrato il riepilogo delle impostazioni effettuate.

Per attivare la configurazione appena terminata, salvare le impostazioni.

Quando il sistema viene attivato, si presenta la schermata inziale (Dashboard) dove vengono mostrate le varie statistiche. Inizialmente tutti i valori sono impostati a zero poichè non sono state processate ancora email.

2. TESTARE BRIGHTMAIL
Impostato il sistema, la prossima fase prevede il test inviando alcune email contenenti messaggio normali, virus e spam.

Tramite un account di posta esterno al dominio aziendale, inviare una serie di email ad un account di posta del dominio interno protetto da Brightmail.

Il primo messaggio inviato è normale, clean.

Viene inviato un secondo messaggio contenente un virus. Il virus per i test utilizzato è reperibile presso il sito eicar.org.

Il messaggio successivo contiene invece un codice di test che i sistemi riconoscono come spam.

Nel test sono inviati inoltre messaggi con virus contenuti all’interno di file .zip e .txt. Nella posta di uscita sono visibili i vari messaggi che vengono inviati verso Brightmail.

Effettuare l’invio delle varie email.

Se il tutto è stato configurato correttamente, al client di posta dell’account di dominio protetto da Brightmail dovrebbero arrivare le email inviate dall’account esterno.

Nel folder Junk compare anche la mail contenente la spam.

Aprendo il messaggio in cui era stato allegato un virus, si nota che il messaggio è stato scansionato da Brightmail che ha provveduto a cancellare il virus contenuto.

Dopo qualche minuto le statistiche dalla Dashboard vengono aggiornate dal sistema con le informazioni relative alle email appena ricevute.

Brightmail è operativo proteggendo il dominio di posta aziendale in base ai parametri impostati. Tramite il manuale operativo è possibile ritoccare alcuni parametri adattando la funzionalità dell’applicazione allo specifico ambiente di rete.

Hai già letto questi articoli?

• Proteggere il Mail Server da spam e virus con Brightmail – 2° parte
• Proteggere il Mail Server da spam e virus con Brightmail – 1° parte
• Installare il servizio FSRM in Windows Server 2008 R2 – parte 2°
• Evitare lo spamming dalla propria rete

Sapere tempestivamente se un sistema della nostra rete ha un problema è spesso la chiave per ridurre al minimo i disservizi. Non sempre però gli occhi sono puntati sul monitor per controllare che tutto sia up & running, specialmente se la rete è composta da molti dispositivi.

Avere la possibilità di ricevere gli alert via email invece, permette di acquisire l’informazione in tempo reale su diversi dispositivi (pc, blackberry o telefono) senza la necessità di essere fisicamente davanti al monitor di sistema. Questo permette un intervento tempestivo prima di essere sommersi di chiamate da parte degli utenti.

Utilizzando Nagios per monitorare la rete, è utile ricevere le notifiche via email degli alert generati dal sistema al verificarsi di un particolare evento poichè Nagios non ha questa funzione implementata internamente.

Per non complicare troppo il sistema, dotare Nagios del supporto email diventa indolore se ci si affida ad un sistema come ssmtp, un package che permette di inviare in maniera molto semplice le email ad un server SMTP… in pratica effettua il forward delle email generate in automatico ad un indirizzo di posta.

1. INSTALLAZIONE
Da console procediamo in questo modo:

# wget http://download.fedora.redhat.com/pub/epel/5/i386/ssmtp-2.61-11.8.el5.i386.rpm
# rpm –Uvh ssmtp-2.61-11.8.el5.i386.rpm

In CentOS il file eseguibile viene installato in /usr/sbin/.

Una volta installato il package, bisogna editare il file di configurazione ssmtp.conf per impostare i parametri corretti:

# vi /etc/ssmtp/ssmtp.conf

2. TESTARE sSMTP
Per verificare che il tutto funzioni correttamente, inviamo una email di prova nella casella di posta configurata:

# ssmtp mail@gmail.com

1. Digitiamo un testo, ad esempio “Test invio email con ssmtp…”
2. Premiamo INVIO
3. Premiamo CTRL+D

Se tutto funziona, riceveremo nella casella specificata una email da root con il testo digitato precedentemente.

3. CONFIGURARE NAGIOS
Una volta verificato che le email di test arrivano, bisogna configurare il file commands.cfg di Nagios per poter utilizzare ssmtp:

# vi /etc/nagios/objects/commands.cfg (path se installato solo nagios)
# vi /etc/nagiosql/commands.cfg (path se installato nagiosql)

Sostituire /bin/mail con il comando /usr/sbin/ssmtp.

define command{
command_name notify-host-by-email
command_line /usr/bin/printf “%b” “***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n” | /bin/mail /usr/sbin/ssmtp -s “** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **” $CONTACTEMAIL$
}

define command{
command_name notify-service-by-email
command_line /usr/bin/printf “%b” “***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$” | /bin/mail /usr/sbin/ssmtp -s “** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **” $CONTACTEMAIL$
}

Al verificarsi di un alert, Nagios invierà una notifica all’indirizzo email specificato nella configurazione di ssmtp.

Questo ci permette di essere avvisati immediatamente al verificarsi di un problema e quindi di poter intervenire tempestivamente limitando i disservizi al minimo.

TROUBLESHOOTING

Se sSMTP funziona inviando la mail manualmente ma Nagios non riesce ad inviare in automatico, verificare come prima cosa il log.

# cat /var/log/nagios/nagios.log

Questo indica che non è stato modificato correttamente il file di configurazione.

# vi /etc/nagios/objects/commands.cfg (path se installato solo nagios)
# vi /etc/nagiosql/commands.cfg (path se installato nagiosql)

Verificare inoltre la configurazione del file /etc/nagiosql/contacts.cfg.

Ricontrollare che SMTP, username, password e l’indirizzo email siano stati inseriti correttamente.

Hai già letto questi articoli?

• Configurare Nagios per monitorare sistemi in subnet diverse
• Monitorare i log di Windows con Nagios tramite check_logfiles
• Monitorare i sistemi con Nagios tramite check_mk in CentOS
• Monitorare i security updates per CentOS 5.x tramite Nagios