Come Cancellare Dati da iPhone

Il tuo iPhone sta chiedendo pietà da svariate settimane ormai. Hai trasferito così tanti file dal computer ad esso, che la memoria è praticamente strapiena. Che ne pensi di cancellare tutto da iPhone? In questo modo potrai usufruire di un melafonino nuovo di zecca che esegue ogni operazione con una velocità ottima. Inoltre, la procedura che sto per mostrarti è consigliata pure in caso di vendita del cellulare.

Per cancellare tutti i dati presenti su un iPhone non occorre utilizzare alcun programma specifico né portare il melafonino in assistenza, bensì puoi farlo tu in men che non si dica. Nel cellulare è presente un’opzione che ti consente di portare l’iPhone allo stato di fabbrica. Questo significa che cancellerai i dati come foto, video, musica, contatti, applicazioni e così via.

Se vuoi effettuare una copia dei dati prima di rimuoverli, devi collegare l’iPhone al PC con il cavo USB ed aprire iTunes. Solamente tramite questo software è possibile eseguire un backup completo di tutti i tuoi dati. Ecco come fare backup iPhone con iTunes: premi sul menù File che trovi in alto, seleziona la voce Dispositivi e dall’elenco che ti appare scegli Backup.

Se vuoi verificare che il backup sia stato completato nel modo giusto, apri la sezione Preferenze di iTunes e scegli nuovamente la categoria dei Dispositivi. In questa schermata vedrai il nome e l’orario del backup più recente. Se utilizzi una versione meno recente di iTunes, la procedura per fare il backup è la seguente: clicca con il tasto destro del mouse sulla voce iPhone a sinistra e scegli la voce Backup.

A questo punto, sei finalmente pronto a rimuovere tutto dal tuo iPhone. Premi sull’icona delle Impostazioni, fai clic sulla sezione Generali e scorri la pagina fino ad arrivare alla voce Ripristina. Infine, non devi far altro che cliccare sul pulsante Cancella contenuto e impostazioni. Se utilizzi un codice di blocco, ti verrà richiesto per confermare che tu sia il possessore del dispositivo.

Clicca sul pulsante rosso con la scritta Inizializza iPhone e partirà la procedura di reset completo dei dati. Il cellulare si spegnerà e comparirà il logo di Apple (la classica mela morsicata), per cui attendi qualche minuto ed il gioco è fatto. Finalmente puoi usufruire di un iPhone nuovo di zecca, senza più errori e senza avere la memoria intasata di dati.

Server di Posta Basilare con Postfix

In questo articolo verrà trattata l’installazione basilare di un server di posta elettronica su un server Debian. La configurazione proposta rispecchia quella trattata nell’ambiente di test precedentemente descritto, dove verrà preso come server di posta il server Titano, il quale ha l’indirizzo IP 192.168.1.11 e su cui verrà configurato il dominio di posta urano.mail. I prodotti scelti per questa installazione di test sono Postfix, che funge da MTA ed espone il servizio SMTP, e Dovecot, che verrà utilizzato per esporre i servizi POP3 ed IMAP4, per far sì che gli utenti della rete possano consultare la propria posta elettronica. Lo scambio di e-mail avverrà con il server Exchange DCServer (dominio giove.mail) e con il server Linux Giapeto (dominio saturno.mail), il quale verrà configurato allo stesso modo del server Titano.

Cenni teorici

In questo articolo, verranno usati software che permettono la trasmissione e la ricezione di messaggi di posta elettronica. Per scambiare i messaggi tra i vari mail server, il protocollo usato sulla rete Internet è SMTP (Simple Mail Transfer Protocol), il quale, come dice il nome, è responsabile della trasmissione, e ricezione, dei messaggi di posta elettronica tra server di posta. Il server SMTP passa il messaggio ricevuto al Mail Delivery Agent (MDA), che spesso diventa un Local Delivery Agent (LDA), il quale si occupa di depositare il messaggio nella casella di posta elettronica dell’utente locale.

L’archiviazione del messaggio ricevuto, per quanto concerne il mondo Linux / Unix, può avvenire principalmente in due formati, mbox e maildir. Mbox ha la peculiarità di archiviare tutti i messaggi di posta elettronica in un unico file per ogni utente, mentre maildir crea un file per ogni messaggio ricevuto. Entrambi i sistemi presentano vantaggi e svantaggi in termini di flessibilità e prestazioni; a mio parere lo svantaggio principale di mbox è il fatto che, usando un unico file monolitico per ogni casella, in caso di problemi si rischia di perdere l’intero contenuto della casella stessa, cosa che diventa molto più difficile utilizzando maildir.

Un MTA ha il compito di movimentare i messaggi di posta, ma non è in grado di presentarli in una qualche forma all’utente finale. Per raggiungere lo scopo, bisogna installare un server POP3 e/o IMAP4, protocolli che permettono di poter presentare i messaggi di posta in un formato riconoscibile ad una applicazione client installata sull’host dell’utente finale, chiamata client di posta elettronica o Mail User Agent (MUA). POP3 è un protocollo piuttosto datato che consente appunto la lettura della posta elettronica tramite un Mail User Agent, il quale normalmente si connette al server POP3 e scarica i messaggi cancellandoli dal server; tale comportamento è d’ostacolo per quegli utenti che debbono consultare la posta da diverse posizioni, oppure per quegli utenti che condividono l’utilizzo di una mailbox. Per ovviare a questi problemi, esiste il protocollo IMAP4, che mantiene i messaggi di posta sul server, in modo tale da metterli a disposizione a prescindere dalla posizione dalla quale ci si connette; inoltre, mantiene una connessione permanente tra client e server, con i vantaggi del caso, rendendosi quindi il protocollo da scegliere per utilizzi professionali del servizio di posta elettronica.

Nel nostro caso, useremo Postfix come MTA, archiviando la posta nel formato maildir, quindi utilizzeremo Dovecot come server IMAP e POP3 e Outlook e Windows Mail come MUA.

Installazione e configurazione di Postfix

Per installare i software che ci servono, utilizzeremo i pacchetti .deb della distribuzione, in modo da mantenere un ambiente coerente, rinunciando però alle ultime versioni dei software (che è la filosofia di Debian, orientata alla stabilità ed alla sicurezza). Riguardo all’installazione di Postfix, basta un semplice:

apt-get install postfix

che richiede di specificare che tipo d’installazione di Postfix effettuare, noi sceglieremo “Sito Internet”, senza specificare uno smart host, poiché, nell’ambiente di test, non è necessario spedire mail al mondo reale, dopo ci verrà richiesto il dominio da utilizzare per la posta elettronica, noi indicheremo il dominio urano.mail.

Ora Postfix è installato, si tratta di fare qualche piccolo aggiustamento alla configurazione. Per prima cosa, abilitiamo la rete LAN del server Titano a mandare posta tramite il nostro MTA aggiornando il parametro mynetworks nel file di configurazione /etc/postfix/main.cf, che diventerà così:

mynetworks = 127.0.0.1/8 192.168.1.0/24

Quindi aggiungiamo due parametri, che indicano la directory di spooling delle mail e il formato di archiviazione dei messaggi delle mailbox, scegliendo Maildir, che creerà una directory Maildir per ogni home directory presente sul sistema:

queue_directory = /var/spool/postfix

home_mailbox = $HOME/Maildir/

Fatto questo, chiudiamo e salviamo il file /etc/postfix/main.cf, quindi possiamo far ripartire Postfix tramite il comando:

/etc/init.d/postfix restart

Ora, possiamo creare gli utenti di sistema, che fungeranno anche da mailbox per il server di posta. Gli utenti non hanno bisogno di un accesso shell, per cui verrà fornita loro la shell /bin/false, e faranno parte del gruppo mail:

useradd -m -g mail -s /bin/false salvor.hardin

useradd -m -g mail -s /bin/false hober.mallow

Ora possiamo provare a mandare una mail da un client di posta già configurato nell’ambiente di test all’indirizzo salvor.hardin@urano.mail, se tutto va come deve andare, dando il seguente comando

ls -l /home/salvor.hardin/Maildir/new

dovremmo vedere un file, ed aprendolo con un editor di testo, è possibile leggere il contenuto che altri non è che il testo della mail precedentemente inviata, comprese le intestazioni. A questo punto possiamo considerare terminata la configurazione di Postfix.

Installazione e configurazione di Dovecot

Per verificare il corretto funzionamento di Postfix, abbiamo consultato il file system del server Titano, ma per un utente “normale”, la cosa è alquanto scomoda. Si impone quindi l’installazione di un server POP3 – IMAP che consenta ad un qualsiasi client con installato un MUA di consultare la posta elettronica. La nostra scelta ricade su Dovecot, il quale ha la simpatica caratteristica di cercare di rendere semplice la propria configurazione e di supportare entrambi i formati di archiviazione della posta più diffusi, mbox e maildir. Per installare Dovecot ricorriamo al solito apt:

apt-get install dovecot-common dovecot-popd dovecot-imapd

Fatto questo, come per Postfix, anche con Dovecot dovremo fare qualche piccola modifica al file di configurazione, il cui percorso è /etc/dovecot/dovecot.conf. Per prima cosa, andremo a specificare quali protocolli rendere disponibili con Dovecot, impostando in questo modo la direttiva protocols:

protocols = imap imaps pop3 pop3s

Scendendo poco più giù nel file di configurazione, configureremo Dovecot in modo tale che accetti le password inviate dal client come testo in chiaro, impostando questa direttiva:

disable_plaintext_auth = no

Ora dobbiamo impostare il percorso in cui si trovano le caselle di posta ed il formato in cui sono archiviati, nel nostro caso maildir:

mail_location = maildir:~/Maildir

Il resto del file può essere lasciato invariato, quindi salviamo il file e riavviamo il demone Dovecot, tramite il solito

/etc/init.d/dovecot restart

dopodiché possiamo testare il nostro server IMAP configurando un qualsiasi MUA che supporti il protocollo IMAP; io ad esempio, per velocità, ho testato Windows Mail, il client di posta predefinito di Windows Vista, che funziona senza problemi con il server IMAP Dovecot senza bisogno di accorgimenti particolari, se si esclude il fatto che a prima vista sembra non comparire la cartella Posta in arrivo; in questo caso, basta sottoscrivere la cartella Posta in arrivo, la quale comparirà immediatamente rendendo possibile leggere i messaggi presenti nella casella di posta in oggetto.

Considerazioni personali sui MUA per Windows

Siccome, per i miei test, avevo a disposizione Windows Mail, ho utilizzato quello. Ho testato altri client di posta, cominciando da Microsoft Outlook (quello compreso nella suite Office, per intenderci), ed i risultati sono stati sconfortanti. Utilizzando Outlook 2003 per connettermi in IMAP sul server di posta, per prima cosa sul server vengono create solo le cartelle Posta in arrivo e Posta indesiderata, per cui, tra le altre cose, non viene creata la cartella Posta inviata; se anche creiamo la cartella Posta inviata a mano, con Outlook 2003 non c’è modo di archiviare la posta inviata nella cartella sul server.

Inizialmente, non usando praticamente mai IMAP, pensavo che fosse un mio problema, invece, surfando sul Web, ho potuto constatare che si tratta di una “caratteristica” di Outlook, che è aggirabile solamente creando una regola ad hoc. Per me tutto ciò è delirante. Si comporta leggermente meglio invece Outlook 2007, che ha gli stessi difetti di Outlook 2003, ma il cui comportamento relativamente alla posta inviata è modificabile in modo semplice agendo sulla configurazione dell’account di posta.

A questo punto ho voluto provare anche Thunderbird per Windows, che si comporta decisamente meglio, infatti, basta configurare normalmente un account di posta, che crea solamente le cartelle Posta in arrivo e Cestino, ma al primo invio di un messaggio, viene creata automaticamente sul server la cartella Posta inviata, così come viene creata una cartella Drafts se si salva un messaggio come bozza. Come già segnalato, Windows Mail si comporta piuttosto bene con IMAP.

Non ho provato alcun MUA per Linux, ma immagino che non diano particolari problemi.

Se qualcuno tra i lettori ha qualche suggerimento relativamente a quanto scritto con l’utilizzo di Outlook con IMAP, ed in particolare dell’interazione tra Outlook e Dovecot, i commenti sono a disposizione.

Conclusioni

Dopo aver testato con successo il corretto funzionamento di Postfix e Dovecot, possiamo ritenere conclusi, per il momento, i nostri test. Come scritto nell’avvertenza all’inizio dell’articolo, questa configurazione è adatta solamente a scopi (auto)didattici, poiché, configurando in questo modo un server di posta, non abbiamo nessuna protezione contro i virus, contro lo spam e contro il phishing (anche se, soprattutto nell’ultimo caso, la miglior protezione l’abbiamo sopra le spalle, basta usarla), inoltre, non utilizziamo quegli strumenti (come database relazionali o LDAP) per definire domini virtuali e caselle di posta. In poche parole, questa configurazione è decisamente migliorabile, e questi passi in avanti saranno oggetto dei prossimi articoli sull’argomento.

Come Gestire la Stampa con Terminal Services

Si consideri una rete aziendale con sedi distaccate, dove per i più svariati motivi, alcune applicazioni vengono utilizzate via Terminal Services su un server Windows Server 2003, utilizzando client Windows XP Professional o Windows Vista Business; in questo caso, è evidente che, quando si ha bisogno di stampare un qualsiasi documento, non è pratico mandare la stampa su una stampante presente nella sede principale, dovranno essere utilizzate le stampanti presenti nella sede distaccata.

Gestire le stampanti con Windows Server 2003 con abilitati i Terminal Services può essere una cosa piuttosto antipatica; perché le cose funzionino bene, è necessario che sul server sia installato il driver della stampante installato sul client, in più, per essere certi di non avere problemi, se possibile, sarebbe ancor meglio utilizzare per le stampanti i driver Microsoft, e non i driver dei vari produttori delle stampanti.

Microsoft ha migliorato le cose con Windows Server 2008, dove, se ho capito bene il tutto, abilitando i Terminal Services, il server invia la coda di stampa al client sotto forma di file XPS, che quindi viene stampato dal client utilizzando lo spooler ed il driver del client, eliminando il problema; non sono sicuro che le cose funzionino proprio così, ma non dovrei essermi allontanato troppo dal vero. Questo meccanismo prende il nome di Easy Print.

Tornando a Windows Server 2003, se per l’accesso ai servizi Terminal si utilizza un client Windows XP, è bene aggiornare il client RDP alla versione 6, quindi, bisogna fare i conti con le stampanti che si posseggono. Prendiamo ad esempio uno scenario in cui mi sono trovato ad operare: server Windows 2003 con abilitati i servizi Terminal, a cui accedono alcuni client con Windows XP (con client di servizi Terminal versione 6) tramite un collegamento geografico; questi client utilizzano una stampante HP LaserJet 2420 dn, cioè una stampante con un print server ed una unità fronte retro.

In una situazione simile, è una scelta obbligata quella di permettere la stampa da applicazioni distribuite tramite Terminal Services sulle stampanti locali dei client, per cui, bisogna fare in modo che il server Terminal riconosca le stampanti locali dei client. Nel caso in oggetto, bisogna quindi, all’atto della connessione, assicurarsi che le risorse locali (in questo caso le stampanti) vengano mappate sul server, tramite un’impostazione raggiungibile dal client RDP cliccando su Opzioni, tab Risorse locali, dove è possibile scegliere quali risorse locali “traslare” sul server.

Nell’immagine si può notare l’impostazione di mappatura delle stampanti, abilitata cliccando sulla casella relativa; a questo punto, è possibile connettersi per verificare se la stampante verrà installata anche sul server.

Una volta effettuata la connessione, se andiamo nella cartella stampanti, possiamo notare che la stampante HP LaserJet 2420 non è stata installata; nel event viewer (e più precisamente nel log System), abbiamo un evento con id 1111 ed origine TermServDevices che ci segnala l’impossibilità di installare il driver della stampante poiché sconosciuto.

Ciò è normale, e dipende dal fatto che il driver della stampante non è un driver Microsoft ma HP, che quindi Windows Server 2003 non ha e non può installare.

Una prima soluzione a questo problema, può essere quella di installare sui client una stampante HP LaserJet che stampi con protocollo PCL e che possieda la possibilità di installare un’unità fronte-retro, come ad esempio la HP LaserJet 4100, utilizzando il driver Microsoft configurato con un’unità duplex per il fronte-retro. Così facendo, la stampante viene correttamente installata, e anche nel log degli eventi compaiono diversi eventi (con id 20, 15, 9 e 2) ed origine Print che indicano i vari passaggi di installazione della stampante. Provando a stampare su quella stampante, le stampe arrivano alla stampante HP 2420 perfettamente, peccato però che non funzioni il fronte-retro, che andrebbe impostato sulla stampante ad ogni sessione Terminal, poiché, per un motivo che non conosco, ad ogni sessione questa impostazione viene perduta; una scomodità inaccettabile. Un’altra soluzione potrebbe consistere nell’installazione del driver HP della stampante LaserJet 2420, ma anche in questo caso non funziona il fronte-retro, che è disponibile ma dà problemi in fase di stampa; perchè questo avvenga, non l’ho proprio capito, probabilmente un’incompatibilità del driver in ambiente Terminal Services.

A questo punto, la prima soluzione al problema consiste nell’accontentarsi del mancato funzionamento del fronte-retro, mentre la soluzione n. 2 è un attimino più professionale, e prevede l’installazione di un driver HP chiamato Universal Print Driver, un driver appunto “universale”, rilasciato da HP che permette di installare un unico driver compatibile con tutte le stampanti di rete HP LaserJet e con gran parte delle stampanti inkjet HP, e che prevede la possibilità di abilitare diverse funzioni tra le quali il fronte-retro.

Scaricato questo driver, il primo passo consiste nell’installazione di una stampante HP Universal Printing sui client. Se nella rete sono presenti più stampanti HP, conviene installare il driver della stampante in modalità dinamica, in modo tale da poter scegliere di volta in volta su quale stampante mandare le code di stampa, altrimenti è possibile installare il driver in modalità tradizionale, in cui verrà richiesta la porta di stampa e le altre solite informazioni. Tenere presente che in modalità dinamica, verranno ricercate esclusivamente stampanti in rete (o almeno, io non ho visto nessuna voce di menu in cui poter scegliere di installare una stampante attaccata direttamente al PC), ed inoltre, se nella rete abbiamo stampanti con un print server JetDirect, è possibile lanciare una rilevazione che troverà automaticamente queste stampanti. Scelta una modalità di installazione, ed installata la stampante, verrà creata nella cartella stampanti un oggetto chiamato “HP Universal Printing PCL 6″ sui client; nel caso in esame, la cosa migliore secondo me è installare la stampante in modalità dinamica, poiché la HP LaserJet 2420 possiede un print server JetDirect, ed è quindi ricercabile tramite il comodo tool in fase di installazione.

Ora bisogna installare il driver sul server, utilizzando una modalità diversa da quella usata sui client, poiché sul server non abbiamo bisogno di installare una stampante, è sufficiente installare il driver; per far questo, andare nella cartella stampanti, quindi cliccare sul menu File -> Server properties, quindi cliccare sulla scheda Drivers, cliccare poi sul pulsante Add, partirà il classico wizard di installazione del driver della stampante tramite il quale va installato il driver HP Universal Printing, in tal modo il driver è presente ma sul server non viene creata la stampante.

Compiuti questi passaggi, se effettuiamo la connessione al server Terminal, possiamo notare in figura 4 che è stata creata sul server la stampante HP Universal Printing PCL 6

Fig. 4 - stampante HP Universal Print

Fig. 4 – stampante HP Universal Print

Tramite questa stampante, abbiamo la possibilità di stampare sulla stampante locale anche in fronte-retro, semplificando la gestione di altre eventuali stampanti HP e risparmiando quindi tempo e rotture di scatole. Bisogna dire però che questa modalità funziona solo con stampanti HP, e nemmeno con tutte, infatti ho avuto problemi con una multifunzione inkjet, che sarebbero oggetti anche utili in determinati contesti, ma che dal punto di vista dei driver rappresentano il Male. :-)

Non ho ancora avuto esperienze con stampanti non HP su server Terminal, però mi sento di consigliare in casi simili, quando possibile, di utilizzare sempre driver Microsoft per evitare problemi.

Gestire Alias e Domini Virtuali con Postfix

In un precedente articolo riguardante la posta elettronica su Linux (le cui avvertenze valgono anche per il presente post), è stato creato un mail server in grado di gestire un unico dominio di posta. Accade però piuttosto spesso di dover gestire più domini di posta, per cui, o si installa un mail server per ogni dominio (cosa che avrebbe un senso solo in caso di alto traffico), oppure, si fanno convivere sullo stesso server di posta più domini, che in caso di realtà medio-piccole è la soluzione ideale. Un’altra casistica non contemplata nel precedente articolo riguarda le liste di distribuzione, cioé la possibilità di avere un indirizzo di posta che recapiti il messaggio ricevuto su più caselle postali. Per questi test faremo riferimento all’ambiente di test descritto in precedenza, dove verrà utilizzato il mail server di test Titano, il quale gestisce il dominio urano.mail; tenere presente che dobbiamo creare le zone DNS relative ai domini virtuali utilizzati nel server DNS Windows Server 2003 DCServer.

Alias e domini virtuali

Per poter gestire la posta di più domini, è necessario definire, oltre al già citato urano.mail (indicato nella direttiva mydestination del file di configurazione /etc/postfix/postfix.conf) che sarà il dominio locale, anche i cosidetti domini virtuali, che corrispondono ai domini che dovremo gestire. A questo punto, è utile distinguere i domini locali dai domini virtuali: nel nostro caso, abbiamo un dominio locale, urano.mail, in cui, ad ogni utente creato sul sistema, corrisponde una casella di posta elettronica; in questo contesto, l’utilizzo di un dominio virtuale, ci consente di definire degli indirizzi di posta con dominio diverso da quello locale, che vengono mappati su una casella di posta elettronica del dominio locale, e che vengono quindi definiti alias virtuali.

Supponiamo, ad esempio, che il nostro mail server debba gestire i domini virtuali miranda.mail, ariel.mail e umbriel.mail; per farlo, dovremo dire a Postfix che intendiamo agire da server SMTP anche per questi domini, come mostrato di seguito:

virtual_alias_domains = miranda.mail ariel.mail umbriel.mail

Ora, dobbiamo inserire nel file di configurazione di Postfix (main.cf) il percorso del file in cui è contenuta la mappa con gli alias virtuali, in cui, ad una casella di posta locale, corrispondono uno o più indirizzi appartenenti ai domini virtuali definiti poc’anzi:

virtual_alias_maps = hash:/etc/postfix/virtual

Definito il file della mappa degli alias virtuali, dobbiamo creare il file stesso ed editarlo:

touch /etc/postfix/virtual

nano /etc/postfix/virtual

Il file va creato seguendo uno stile preciso, come mostrato di seguito:

h.mallow@miranda.mail    hober.mallow@urano.mail

s.hardin@ariel.mail    salvor.hardin@urano.mail

p.palver@umbriel.mail    preem.palver@urano.mail

s.gendibal@umbriel.mail   stor.gendibal@urano.mail

Come si può vedere, nella colonna sinistra del file mettiamo gli alias virtuali, mentre nella colonna di destra, indichiamo a quale utente di sistema va recapitata la posta indirizzata a quello specifico alias virtuale. Ora dobbiamo creare la mappa vera e propria, tramite la “compilazione” in formato binario del file /etc/postfix/virtual, con il comando postmap:

postmap /etc/postfix/virtual

che creerà il file /etc/postfix/virtual.db che sarà quello effettivamente usato da Postfix per l’interrogazione degli alias virtuali.

Così facendo, se spediamo ad esempio una mail a s.hardin@ariel.mail, questa verrà depositata fisicamente nella casella di posta salvor.hardin@urano.mail; ciò in alcune situazioni può andare bene, ma in altre situazioni, questo stato di cose potrebbe non andarci a genio, come in quei casi in cui vogliamo che le caselle di posta dei domini virtuali siano trattate come mailbox a sé stanti, e non legate agli utenti di sistema. Postfix permette di gestire anche queste casistiche, tramite le mailbox virtuali, che verranno esaminate in un articolo successivo.

Liste di distribuzione tramite alias virtuali

Tramite gli alias virtuali è possibile creare anche liste di distribuzione, ovvero indirizzi di posta elettronica virtuali che servono per reindirizzare i messaggi ricevuti dall’alias virtuale stesso agli indirizzi di posta specificati come destinatari del messaggio.

Vediamo un esempio: aggiungiamo una riga al file /etc/postfix/virtual come mostrato di seguito:

oratori@umbriel.mail   p.palver@umbriel.mail, s.gendibal@umbriel.mail

Come già specificato, sulla sinistra compare l’alias virtuale, sulla destra compaiono gli indirizzi di posta a cui vogliamo reindirizzare i messaggi ricevuti sull’indirizzo oratori@umbriel.mail; da notare che i diversi indirizzi devono essere separati da una virgola, e che, in questo caso i membri della lista di distribuzione sono a loro volta alias virtuali, ma potrebbero essere tranquillamente utenti di sistema.

Salvato il file, dobbiamo ricompilare il file /etc/postfix/virtual in questo modo:

postmap /etc/postfix/virtual

Ora possiamo testare il corretto funzionamento della lista di distribuzione, e se tutto va bene, inviando un messaggio all’indirizzo oratori@umbriel.mail, il messaggio arriverà ai due indirizzi p.palver@umbriel.mail e s.gendibal@umbriel.mail, i quali, essendo alias, non hanno una propria casella di posta e quindi il messaggio finirà effettivamente nelle caselle di posta preem.palver@urano.mail e stor.gendibal@urano.mail.

Conclusioni

In questo articolo abbiamo apportato qualche miglioramento al nostro server di posta basilare, ora possiamo gestire più domini sulla stessa macchina e possiamo gestire liste di distribuzione all’interno della nostra organizzazione. I metodi utilizzati possono essere utilizzati in piccole realtà, ma per ambienti più complessi, è bene utilizzare altre metodiche per raggiungere gli stessi risultati, che verranno illustrate in altri articoli sull’argomento.

Come Estrarre Foto da Video

Se ci sono dei video dalle cui scene più significative o più belle per te, desidereresti estrarre dei fotogrammi e ottenerne delle vere e proprie immagini, il programma che oggi ti presenterò fa al caso tuo.

Ti sto parlando di Free Video to JPG Converter, un programma completo nella sua categoria, eccezionale e soprattutto gratis.

L’applicazione una volta effettuato il download e l’installazione, non occuperà molto spazio, ha infatti una dimensione di soli 5,8 Mb.

Lancia quindi il programma, la cui interfaccia si presenta semplice e molto intuitiva, adatta anche per i meno esperti.
Ora segui questi essenziali e importanti passi.
Importa dalla voce Input il video dal quale devi estrarre le foto.
La barra in basso con i relativi pulsanti di riproduzione ti permetterà di scorrere il video per trovare il frame dal quale estrarre le foto e clicca su Make Snapshot.
Ma i frame possono essere estratti anche attraverso il campo Extract.
Oppure selezionando il campo Total e decidere quante foto estrarre dal video in totale. O ancora puoi selezionare Every frame per estrarre tutti i frame dal video.
Infine in alto sulla destra vi è il campo Output folder con il quale indicare la cartella dove salvare le foto in formato JPG, dunque clicca su Save e l’operazione è conclusa.

Molto interessante.

Come Scrivere Fattura con Word

Sei nel panico perché hai finito un lavoro e devi creare una fattura? Non sai nemmeno da dove poter iniziare per compilarla? Non disperare, in questa guida ti verrà presentato come potere creare una fattura personalizzata con il programma Word in modo semplice e veloce. In pochi secondi, potrai creare il tuo modello di fattura commerciale e soprattutto potrai utilizzarlo ogni qualvolta tu lo desideri per qualsiasi tipo di parcella che dovrai andare a creare.

Inizia quindi ad aprire il programma Word.
Successivamente dovrai iniziare a inserire il destinatario, quindi scrivi tutti i dati necessari. Mi raccomando ricorda di dare sempre l’“A capo”, o il cosiddetto “Invio”, per ogni informazione che inserirai, ultima compresa!
Una volta terminato, dobbiamo spostare sulla destra tutto questo primo blocco di testo.
Selezionalo tutto.
Quindi vai sul righello orizzontale, in “testa” al foglio, e sposta fin dopo la metà il rientro sinistro.

Adesso bisogna inserire del nuovo testo e delle tabelle quindi posizionati sul lato sinistro del tuo foglio, ovviamente più in basso rispetto al primo blocco di testo, e clicca due volte.
Ti apparirà il cursore che lampeggia, come se si dovesse immettere del testo.
Bene, ora sei pronto per inserire una prima tabella contenente il luogo, la data, il numero della fattura e il conto corrente su cui il destinatario dovrà versare il compenso pattuito.
Per inserirla, vai sul menù “Tabella”, “Inserisci” e seleziona “Tabella” ti apparirà un pop-up nel quale dovrai indicare il numero delle colonne e delle righe.
Compilalo con le tue preferenze e schiaccia “Ok”.

Ora non ti resta che scrivere nelle varie celle i campi che ti sei prefissato.
Se devi unire le celle o dividerle basta che le selezioni e schiacci il tasto destro del mouse, lì scegli “Unisci celle” o “Dividi celle”.
Mentre per centrare le varie celle basta che ti metti sul bordo, il cursore si trasformerà, e tiri a piacimento allungando e accorciando di quanto vuoi.

Finita questa parte si deve creare un’altra tabella dove dovrai andare ad inserire tutti i prodotti o le servizi erogati.
Per inserire una tabella o più tabelle devi fare lo stesso procedimento di prima.
Compila così le varie celle con i dati e i costi.
Hai così ottenuto la tua prima fattura.
Salva il documento che potrai riutilizzarlo più volte.

Ovviamente è possibile trovare diversi modelli anche in rete, per esempio su questo sito sulla fattura o sul sito Microsoft. I modelli possono poi essere modificati in base alle proprie esigenze.

Come Avviare e Spegnere Macchine Virtuali VMware da Riga di Comando

VMWare ESXi è un ottimo hypervisor di virtualizzazione, permette di avere “a gratis” un software di virtualizzazione robusto e dalle ottime prestazioni, purtroppo però manca di alcune funzioni, come, ad esempio, la possibilità di avvio automatico delle macchine virtuali in caso di spegnimento e riaccensione dell’host di virtualizzazione.

In caso di riavvio dell’host quindi, l’accensione delle macchine virtuali viene effettuato, di norma, tramite vSphere Client, in cui si effettua l’avvio delle virtual machine una alla volta tramite l’interfaccia grafica del programma. Il problema di questo approccio però, è che non è possibile utilizzare vSphere Client da remoto, a meno di non pubblicare l’accesso all’host ESXi su Internet, cosa che non so che significhi dal punto di vista del networking, e che non voglio nemmeno sapere per ovvi motivi di sicurezza; altro problema del vSphere Client è che funziona solo su Windows, quindi, se abbiamo a disposizione solo un client non Windows, non abbiamo la possibilità di gestire l’host di virtualizzazione.

In questi casi, per prima cosa è necessario abilitare l’accesso SSH all’host ESXi, il cosidetto Tech Support Mode, modalità che non è supportata in vSphere ESXi e che viene attivata seguendo queste istruzioni; a questo punto, accedere via ssh all’host ESXi utilizzando l’utente root e la password assegnata all’utente in fase di installazione, quindi, digitare questo comando:
vim-cmd vmsvc/getallvms
comando che serve per ottnere l’elenco delle macchine virtuali presenti su ESXi, dove comparirà anche la colonna Vmid, la quale rappresenta l’ID di ogni macchina virtuale, dato che ci servirà in seguito per le operazioni di avvio e spegnimento delle virtual machines.

Ottenuto questo elenco, per avviare una o più macchine virtuali, digitare il comando
vim-cmd vmsvc/power.on vmid
dove per vmid si intende l’ID della virtual machine ottenuto col comando visto nel paragrafo precedente, mentre per spegnere una o più macchine virtuali, digitare il comando
vim-cmd vmsvc/power.off vmid
dove per vmid si intende l’ID della virtual machine come visto in precedenza.

Questo tipo di accesso è utile anche per l’accesso remoto, accesso che si rende necessario se non siamo fisicamente presenti e dobbiamo avviare le macchine virtuali di un host ESXi che per qualche motivo si è spento, anche se in questo caso il mio consiglio è di non pubblicare direttamente l’host di virtualizzazione, ma di utilizzare una VPN o qualcosa di simile.

Come Creare Font Personalizzati

Se sei stufo dei soliti stili di scrittura, troppo semplici o complicati, una soluzione cè, direi che ne esistono davvero tante, ma oggi ti parlerò in particolare di un editor online.

Ti permette in maniera completa di aggiungere al già ricco elenco di font che esistono nel tuo pc, altri da personalizzare.

Si tratta dell’editor online FontStruct.
Accedi al sito, in lingua inglese, necessita di registrazione; quindi scegli uno username che puoi anche sostituire con la tua mail, e una password.

Il sito è suddiviso in una gallery, dove trovi tanti esempi e font pronti da scaricare e installare nel tuo pc, ce ne sono tanti, le pagine sono addirittura 18791, e tutti molto belli.
Ciò che molto semplicemente e rapidamente dovrai fare sarà quello di costruire i tuoi font personalizzati, condividerli e scaricarli gratuitamente.
Effettuare il download come TrueType file e installarlo nel proprio PC Windows o Mac.
Potrai utilizzarli anche come web font per il tuo sito.

La maniera più facile di creare font straordinari, con forme geometriche e ogni altra cosa possa venirti in mente puoi trovarla o ottenerla sul servizio gratuito tra i più completi nel web

Come Fare il Binding di IIS su un Solo Indirizzo IP

Si prenda in considerazione un server Windows Server 2003 con Internet Information Services 6 con installato almeno un sito Web; il server in questione ha due o più schede di rete, oppure una scheda di rete con definiti due o più indirizzi IP, ad esempio, il nostro server ha due indirizzi IP, 172.16.1.1 e 172.16.1.10. Questo server ha un’installazione di IIS predefinita, con uno o più siti Web installati. In tale situazione, IIS rimane in ascolto sulla porta 80 su tutti gli indirizzi IP definiti sulla macchina.

Ora esaminiamo l’ipotesi di dover far girare sulla stessa macchina un altro server Web, che deve anch’esso rimanere in ascolto sulla porta 80: in questo caso, bisogna fare in modo che i siti di IIS rimangano in ascolto, invece che su entrambi gli indirizzi IP, su un solo indirizzo IP; nel nostro caso scegliamo l’indirizzo 172.16.1.1, in modo da lasciare “libero” l’indirizzo 172.16.1.10 per l’altro server Web.

A prima vista, la soluzione sembrerebbe semplice, cioé configurare il sito Web per rimanere in ascolto solamente sull’indirizzo 172.16.1.1.

Purtroppo però questa soluzione non funziona, IIS continua a rimanere in ascolto sulla porta 80 su tutti gli indirizzi IP della macchina, com’è possibile vedere col comando netstat:

netstat -noa | find “:80”

il cui output risulta essere questo:

TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       2548

che indica appunto che IIS si appropria della porta 80 su tutti gli IP disponibili.

Configurazione di IIS

Con i normali strumenti messi a disposizione dalla console di gestione di IIS, che io sappia non c’è modo di superare questa limitazione; per risolvere il problema, possiamo utilizzare l’utility httpcfg, contenuta nel pacchetto Windows Server 2003 Support Tools, che consente di svolgere questo e altri compiti su IIS.

Il primo passo consiste nel verificare su quali porte sta in ascolto IIS, col comando

httpcfg query iplisten

che, nel mio caso, restituisce questo output:

HttpQueryServiceConfiguration completed with 1168

Ciò significa che IIS segue l’impostazione predefinita, ovvero rimane in ascolto su tutti gli IP disponibili sulla macchina. Con httpcfg posso cambiare questa impostazione, istruendo IIS per rimanere in ascolto solamente sull’IP 172.16.1.1:

httpcfg set iplisten -i 172.16.1.1

il quale restituisce questo messaggio che conferma la corretta esecuzione del comando:

HttpSetServiceConfiguration completed with 0

La conferma è utile, ma è meglio controllare se la configurazione è corretta, digitando di nuovo il comando

httpcfg query iplisten

il cui output stavolta è differente:

IP                      : 172.16.1.1

La configurazione è avvenuta correttamente, per renderla attiva è necessario riavviare il servizio HTTP e i servizi dipendenti, HTTP SSL e World Wide Web Publishing Service:

net stop http /y

L’opzione /y riavvia http e i servizi dipendenti da questo senza attendere la conferma dell’utente; procediamo ora all’avvio dei servizi fermati:

net start http

net start w3svc

Dopo aver riavviato i servizi, verifichiamo con netstat che IIS si sia piegato al nostro volere:

netstat -noa | find “:80”

ora l’output del comando netstat è quello “giusto”:

TCP    172.16.1.1:80          0.0.0.0:0              LISTENING       3928

Conclusioni

httpcfg è un’utility che consente di ovviare a quella che è una “curiosa” mancanza della GUI di IIS; una volta che se ne conosce l’esistenza e le modalità d’utilizzo, è abbastanza semplice arrivare al risultato desiderato, ma il sysadmin che si trova per la prima volta di fronte ad un problema simile può perdere anche parecchio tempo prima di risolvere il problema, e ciò secondo me è negativo e soprattutto poco sensato.

Mailbox Virtuali con Postfix

Facendo riferimento ai due precedenti articoli su Postfix e Dovecot, dove si era vista una configurazione minimale di un server di posta e l’utilizzo di alias e domini virtuali, sempre basandoci sull’ambiente di test precedentemente illustrato, in questo articolo vedremo come utilizzare le mailbox virtuali su Postfix, e quindi come accedere a queste mailbox con Dovecot. L’utilizzo di mailbox virtuali è un passo avanti rispetto alle configurazioni precedentemente trattate, poiché con questo tipo di caselle di posta elettronica, facciamo in modo che le mailbox siano completamente distinte dagli utenti di sistema, in questo modo non saremo costretti a creare un utente Linux da utilizzare ogniqualvolta abbiamo bisogno di una casella di posta. Oltre alle mailbox, avremo anche dei domini virtuali, in tal modo potremo ospitare sullo stesso server caselle di posta elettronica riferite a diversi domini, con tutti i vantaggi del caso. Le informazioni su mailbox e domini virtuali saranno contenute in file di testo sul file system del sistema operativo.

Configurazione di Postfix

Andremo a configurare mailbox virtuali sul server Giapeto per i domini cerere.mail e saturno.mail. In questa situazione, se esistono, è bene cancellare dal file di configurazione /etc/postfix/main.cf tutte le impostazioni relative ad alias e domini virtuali, poiché queste impostazioni andranno eventualmente riscritte secondo il formato richiesto dalle mailbox virtuali. La configurazione precedentemente descritta si esplicita nelle seguenti direttive nel file di configurazione /etc/postfix/main.cf; le altre informazioni riferite ai parametri basilari di Postfix rimangono quelle descritte nell’articolo riguardante la configurazione di base di Postfix:

virtual_mailbox_domains = cerere.mail saturno.mail
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 5000
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_alias_maps = hash:/etc/postfix/virtual

La prima riga fa riferimento ai domini virtuali per i quali il sistema è abilitato a ricevere messaggi di posta, cioè cerere.mail e saturno.mail. La seconda riga fa riferimento alla directory di base scelta come deposito di tutta la posta ricevuta su questo server, al cui interno vi saranno le varie sottodirectory relative ai domini virtuali, e per ogni dominio virtuale vi saranno le directory riferite alle varie mailbox di quel dominio, dove verrà depositata la posta elettronica, secondo il formato di archiviazione Maildir, come vedremo di seguito. La terza riga indica il file dove vengono elencate le mailbox virtuali definite sul sistema e la loro posizione sul file system, a partire dalla directory definita in precedenza col parametro virtual_mailbox_base. La quarta riga specifica l’id minimo dell’utente utilizzato dal sistema per andare a scrivere i file rappresentanti i messaggi di posta sul file system, nella posizione indicata con il parametro virtual_mailbox_base; questo utente avrà un ID utente e un ID di gruppo, specificati con precisione nella quinta e nella sesta riga della porzione del file di configurazione specificata poco sopra. La settima e ultima riga è opzionale, e indica la posizione del file contenente gli alias virtuali delle mailbox virtuali effettive, come descritto nell’articolo precedente riguardante gli alias virtuali, anche se nell’articolo precedente gli alias si riferivano alle mailbox di sistema e non a quelle virtuali.

Modificata la configurazione di Postfix, creiamo la directory che conterrà le mailbox virtuali:

mkdir /var/spool/vmail

Ora invece dobbiamo creare la mappa che conterrà l’elenco delle mailbox virtuali definite sul sistema:

touch /etc/postfix/vmailbox

Quindi andremo ad editare il file vmailbox appena creato per definire l’elenco delle mailbox sul nostro sistema, in questo modo:

salvor.hardin@cerere.mail   cerere.mail/salvor.hardin/ hober.mallow@cerere.mail    cerere.mail/hober.mallow/ preem.palver@saturno.mail   saturno.mail/preem.palver/ stor.gendibal@saturno.mail  saturno.mail/stor.gendibal/

Questo è un tipico file di mappa di Postfix, dove nella prima colonna sono indicate le mailbox virtuali, mentre nella seconda è indicato il percorso della casella in cui andrà depositata la posta, a partire dalla “radice” che altro non è che il percorso indicato nella direttiva virtual_mailbox_base del file main.cf, come visto in precedenza; ad esempio, la posta della mailbox virtuale salvor.hardin@cerere.mail verrà depositata nella directory /var/spool/vmail/cerere.mail/salvor.hardin. Da notare lo slash (/) alla fine del percorso di ogni mailbox virtuale, il quale indica a Postfix di archiviare la posta nel formato Maildir.

Creare a questo punto la mappa in formato .db partendo dal file appena editato:

postmap /etc/postfix/vmailbox

Ora editiamo il file di mappa /etc/postfix/virtual in cui andare ad inserire gli alias per le mailbox virtuali:

postmaster@cerere.mail salvor.hardin@cerere.mail

abuse@cerere.mail         salvor.hardin@cerere.mail

postmaster@saturno.mail   preem.palver@saturno.mail

abuse@saturno.mail        preem.palver@saturno.mail

e compiliamo quindi la mappa degli alias:

postmap /etc/postfix/virtual

Configurazione di Dovecot

Configurato Postfix, dobbiamo informare anche Dovecot delle mutate impostazioni di archiviazione della posta elettronica, per cui Dovecot dovrà essere informato della nuova posizione delle mailbox; inoltre, Dovecot non si baserà più sugli utenti di sistema per l’autenticazione sulla casella di posta, per cui andremo a fornirgli un file in cui sono elencati gli utenti ed un file in cui sono elencate le relative password, secondo lo schema stesso di Linux, basato su un file passwd dove sono indicati gli utenti, ed un file shadow dove sono elencate le password. Di seguito vediamo le impostazioni da inserire nel file di configurazione di Dovecot /etc/dovecot/dovecot.conf, fare attenzione ad aprire e chiudere le graffe, esistenti e non, all’interno del file di configurazione:

mail_location = Maildir:/var/spool/vmail/%d/%n
auth default {
mechanisms = plain login
userdb passwd-file {
args = /var/spool/vmail/%d/etc/passwd
}
passdb passwd-file {
args = /var/spool/vmail/%d/etc/shadow
}
}

Nella riga 1 andiamo a specificare la posizione in cui Dovecot andrà a leggere la posta archiviata da Postfix, utilizzando delle variabili; ciò consente a Dovecot di leggere la posta di più domini, utilizzando la variabile %d, che indica la parte dopo la chiocciola dell’indirizzo di posta (il dominio), e la variabile %n, che indica la parte prima della chiocciola dell’indirizzo di posta (il nome utente): tra l’altro, ciò comporta l’accortezza di autenticarsi indicando, alla richiesta del nome utente, l’indirizzo completo di posta.

La seconda riga indica l’inizio della sezione riguardante le impostazioni di autenticazione su Dovecot, che sono evidenziate ad iniziare dalla terza riga, che indica i meccanismi di transito sulla rete delle password, che nel caso illustrato vengono trasmesse in chiaro per l’autenticazione su Dovecot; questo causa qualche problema di sicurezza, poiché le password viaggiano in chiaro sulla rete, quindi basta sniffarla il tempo necessario per carpire le password. Quarta e quinta riga indicano la posizione del file in cui sono indicati gli utenti possessori di una casella di posta, mentre settima e ottava riga indicano il percorso del file contenente il nome utente e la relativa password; da notare che anche in questo caso è stata utilizzata la variabile %d, seguita dalla directory etc/ che conterrà i due file: tale directory è stata creata semplicemente per coerenza con la struttura delle directory Linux, ma non è assolutamente necessaria.

Creazione directory, utenti e password

Ora bisogna creare gli utenti e le password sia per l’accesso di Postfix alla directory /var/spool/vmail, sia per l’autenticazione su Dovecot da parte di un qualsiasi MUA (Mail User Agent). Cominciamo creando l’utente di sistema che useremo per l’accesso alla directory in cui saranno contenute le mailbox virtuali:

useradd -d /var/spool/vmail -s /bin/false -m -U -u 5000 vmail

Con questo comando creiamo l’utente vmail, a cui assegnamo la home directory /var/spool/vmail e la shell “fasulla” /bin/false, ed a cui assegnamo l’id utente 5000, come indicato nella configurazione di Postfix; inoltre, con l’opzione –U andiamo a creare un gruppo con caratteristiche identiche all’utente appena creato. È possibile notare che la home directory assegnata all’utente vmail corrisponde alla directory indicata in Postfix come directory “root” per l’archiviazione di posta elettronica, in questo modo assegnamo subito a questo utente l’ownership (ovvero la proprietà) della directory, poiché sarà l’utente vmail che effettivamente avrà il compito di archiviare sul file system la posta elettronica.

Il passaggio successivo consiste nel creare le directory relative ai domini, ai file contenenti utenti e password, ed alle mailbox virtuali. Iniziamo con le directory relative ai domini cerere.mail e saturno.mail:

mkdir /var/spool/vmail/cerere.mail
mkdir /var/spool/vmail/saturno.mai

Ora creiamo la directory etc per ogni dominio, che conterrà i file relativi ad utenti e password corrispondenti alle mailbox virtuali create per ogni dominio; gli utenti e le password verranno utilizzati da Dovecot per autenticare l’accesso alle caselle di posta virtuali:

mkdir /var/spool/vmail/cerere.mail/etc

mkdir /var/spool/vmail/saturno.mail/etc

Ora andiamo a creare, per ogni dominio, il file degli utenti (passwd) e delle password (shadow), coerentemente con quanto indicato nel file di configurazione di Dovecot:

touch /var/spool/vmail/cerere.mail/etc/passwd
touch /var/spool/vmail/cerere.mail/etc/shadow
touch /var/spool/vmail/saturno.mail/etc/passwd
touch /var/spool/vmail/saturno.mail/etc/shadow

Creati i file, bisogna inserire il contenuto relativo a utenti e password, di seguito sono elencati i comandi per inserire i contenuti dei due file degli utenti passwd:

Utenti per il dominio cerere.mail

echo salvor.hardin::5000:5000::/var/spool/vmail/cerere.mail/salvor.hardin >> /var/spool/vmail/cerere.mail/etc/passwd
echo hober.mallow::5000:5000::/var/spool/vmail/cerere.mail/hober.mallow >> /var/spool/vmail/cerere.mail/etc/passwd

Utenti per il dominio saturno.mail

echo preem.palver::5000:5000::/var/spool/vmail/saturno.mail/preem.palver >> /var/spool/vmail/cerere.mail/etc/passwd
echo stor.gendibal::5000:5000::/var/spool/vmail/saturno.mail/stor.gendibal >> /var/spool/vmail/cerere.mail/etc/passwd

Dall’analisi di questi file, si può intuire che nel file viene indicato il nome utente, poi l’ID utente e di gruppo (il 5000 preso per l’utente locale vmail), quindi viene indicata la directory in cui Dovecot andrà a leggere la posta per quell’utente

Ora bisogna popolare il file shadow con le password degli utenti. Siccome voglio che le password siano criptate (ad esempio utilizzando l’algoritmo md5, anche se non è il più sicuro che esista), per generare le password dovrò utilizzare il comando dovecotpw. Ad esempio, per assegnare a tutti gli utenti la password Password00, dovrò scrivere qualcosa del genere:

Password per il dominio cerere.mail

echo salvor.hardin:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/cerere.mail/etc/shadow

echo hober.mallow:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/cerere.mail/etc/shadow

Password per il dominio saturno.mail

echo preem.palver:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/saturno.mail/etc/shadow
echo stor.gendibal:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/saturno.mail/etc/shadow

A questo punto, avendo trafficato con l’utente root all’interno della directory /var/spool/vmail, è necessario reimpostare l’ownership della directory e del suo contenuto con il comando

chown –R 5000:5000 /var/spool/vmail

Collaudo del sistema

Per testare il server di posta elettronica, è sufficiente inviare una mail ad uno degli indirizzi di posta appena creati, e Postfix, alla ricezione della mail, creerà la directory in cui depositare la posta e che rappresenterà il deposito di tutta la posta per quella determinata mailbox. Se voglio controllare cosa accade durante la ricezione della mail, sia per curiosità, sia per motivi di troubleshooting, è possibile consultare il log della posta, contenuto nel file /var/log/mail.log, che ci darà tutte le informazioni che ci necessitano. Se invece voglio controllare in tempo reale che accade, posso utilizzare un’opzione sciccosa del comando tail in questo modo:

tail –f /var/log/mail.log

che mi mostrerà appunto in tempo reale le righe che vengono eventualmente aggiunte al file /var/log/mail.log.

Conclusioni

Questa configurazione comincia ad essere un tantino più professionale rispetto alle configurazioni proposte in precedenza, infatti ora possiamo gestire con maggiore flessibilità più domini ed i relativi utenti, che non sono più utenti di sistema, per cui possiamo avere lo stesso nome utente per domini diversi. Questa configurazione però ha anche alcuni difetti, ovvero il metodo di creazione di utenti e password per l’accesso alla posta elettronica, che è un po’ macchinoso basandosi sulla riga di comando; un’altra mancanza non indifferente è rappresentata dal fatto che sostanzialmente, con questa configurazione, ci fidiamo di tutto ciò che ci arriva, poiché non vi sono restrizioni sulla posta in arrivo.

Per la definizione delle mappe delle mailbox virtuali e degli alias, nonché per la definizione di utenti e password per Dovecot, vedremo in seguito una configurazione in cui Postfix e Dovecot utilizzano MySQL al posto delle tecniche trattate finora, mentre per spam e antivirus verranno analizzati alcuni strumenti come greylist e blacklist, e ClamAV come sistema di scansione antivirus della posta elettronica. Rimane fondamentale una corretta configurazione di Postfix per impedire che il nostro MTA funga da open relay, ciò dipende essenzialmente, per quanto visto finora, da ciò che si inserisce nel parametro mynetworks, come illustrato negli articoli precedenti.