Unban ip Failban

Step 1: Find IP Address to Unblock

Log in to your server via SSH and type in the following command:

iptables -L -n

Look for the IP address you want to unblock / unban.

Step 2: Get Jail Name of fail2ban Blocked IP Address

Now we must find the jail name this IP address is in. To do so, type the following to find the jail list settings:

fail2ban-client status

Step 3: Unban IP Address from fail2ban

For this example, we will remove an IP address jailed within ssh. To do so, type in the following:

fail2ban-client set <jail-name> unbanip 123.123.123.123

The IP address should now be unbanned from fail2ban.

Apache vs Nginx

Apache vs Nginx from here

28 gennaio 2015 ApacheNginx

Introduzione

Apache e Nginx sono i due server web open source più comuni al mondo. Assieme, sono responsabili della gestione di oltre il 50% del traffico Internet. Entrambe le soluzioni sono in grado di gestire carichi di lavoro di vario tipo e operare con altri software per fornire uno stack web completo.

Mentre Apache e Nginx condividono molte qualità, non dovrebbero essere considerati come del tutto intercambiabili. Ognuno eccelle a modo suo ed è importante comprendere le situazioni in cui potrebbe essere necessario rivalutare quale web server scegliere. Questo articolo sarà dedicato alla discussione su come ciascun server sia più adatto in differenti impieghi.

Panoramica generale

Prima di immergersi nelle differenze tra Apache e Nginx, diamo un rapido sguardo alla storia di questi due progetti e alle loro caratteristiche generali.

Apache

L’ “Apache HTTP Server” è stato creato da Robert McCool nel 1995 ed è stato sviluppato sotto la direzione della Apache Software Foundation dal 1999. Dal momento che il server web HTTP è il progetto originale della fondazione ed è di gran lunga il loro più famoso software, viene spesso chiamato semplicemente “Apache”.

Il server web Apache è il server più popolare su internet fin dal 1996. A causa di questa popolarità, Apache gode di un’ottima documentazione e della completa integrazione con altri software.

Gli amministratori di sistema scelgono di frequente Apache per la sua flessibilità, potenza, e un ampio supporto. È estensibile attraverso un sistema di moduli caricabili dinamicamente e in grado di far funzionare un gran numero di linguaggi interpretati senza dover usare programmi esterni ad Apache stesso.

Nginx

Nel 2002, Igor Sysoev iniziò a lavorare su Nginx in risposta al problema C10K, che è stato una sfida per i server web nell’intraprendere la gestione di diecimila connessioni contemporanee come requisito per un web al passo con i tempi. La prima release pubblica è del 2004, ed ha raggiunto l’obiettivo affidandosi ad una architettura asincrona guidata dagli eventi (events-driven).

Fin dal suo debutto, Nginx ha visto crescere la sua popolarità grazie all’utilizzo minimo delle risorse e la sua capacità di scalare facilmente su un hardware minimale. Nginx eccelle nella gestione rapida dei contenuti statici ed è stato progettato per passare le richieste dinamiche ad altri software più adatti allo scopo.

Gli amministratori di sistema scelgono di frequente Nginx per la sua efficienza nel gestire le risorse e la sua reattività sotto carico. I sostenitori di Nginx sottolineano la sua propensione alle caratteristiche di base da server web e a quelle di server proxy.

Architettura della gestione delle connessioni

Una grande differenza tra Apache e Nginx è il modo vero e proprio in cui gestiscono le connessioni e il traffico. Questa è forse la differenza più significativa nel modo in cui rispondono alle diverse condizioni di traffico.

Apache

Apache fornisce una varietà di moduli multi-processo (Apache li chiama MPM) che indicano il modo in cui vengono gestite le richieste dei client. Fondamentalmente, ciò consente agli amministratori di sistema di cambiare facilmente l’architettura della gestione delle connessioni. Queste architetture sono:

  • mpm_prefork: Per gestire la richiesta, questo modulo genera processi con un singolo thread. Ogni figlio può gestire una sola connessione alla volta. Finché il numero di richieste è inferiore al numero di processi, l’MPM è molto veloce. Tuttavia, le prestazioni degradano rapidamente quando le richieste superano il numero di processi, quindi in determinati contesti non è una buona scelta. Ogni processo ha un impatto significativo sul consumo di RAM, quindi l’MPM è difficile da scalare in maniera efficace. L’MPM può essere ancora una buona scelta se viene utilizzato in combinazione con altri componenti che non sono sono stati pensati per i thread. Ad esempio, il PHP non è thread-safe, quindi l’MPM è raccomandato quale unico modo sicuro di lavorare con mod_php, il modulo Apache per l’elaborazione dei file PHP.
  • mpm_worker: Questo modulo genera processi che possono gestire più thread per ciascuno. Ognuno di questi thread può gestire una singola connessione. I thread sono molto più efficienti rispetto ai processi, il che significa che questo MPM scala meglio rispetto all’MPM prefork. Poiché ci sono più thread che processi, vuol dire anche che le nuove connessioni possono usare immediatamente un thread libero invece di dover attendere un processo libero.
  • mpm_event: Nella maggior parte dei casi, questo modulo è simile al modulo worker, ma è ottimizzato per gestire connessioni keep-alive. Quando si utilizza l’MPM worker, una connessione mantiene un thread indipendentemente dal fatto che ci sia una connessione attiva. L’evento MPM gestisce connessioni keep-alive accantonando dei thread dedicati alla gestione delle connessioni keep-alive e facendo passare le richieste attive ad altri thread. Ciò fa sì che il modulo eviti di rimanere invischiato da richieste keep-alive, permettendo così un’esecuzione più veloce. È stato definito stabile con il rilascio di Apache 2.4.

Come si può vedere, Apache fornisce un’architettura flessibile nella scelta di diversi algoritmi di gestione delle connessioni e delle richieste. Le scelte sono principalmente una funzione dell’evoluzione del server e della crescente necessità di concorrenza, come è stato per l’intera internet.

Nginx

Nginx è salito alla ribalta dopo Apache, con una maggiore consapevolezza sui problemi di concorrenza che si trovano ad affrontare i siti scalabili. Sfruttando questa conoscenza, Nginx è stato progettato da zero ed utilizza un algoritmo asincrono, non-bloccante, di gestione delle connessioni in base agli eventi (event-driven).

Nginx genera processi worker, ognuno dei quali in è grado di gestire migliaia di  connessioni. I processi worker fanno ciò implementando un veloce meccanismo di loop che verifica ed elabora continumanente gli eventi. Il disaccoppiamento dell’effettivo carico di lavoro dalle connessioni permette a ciascun worker di occuparsi di una connessione solo quando viene attivato un nuovo evento.

Ciascuna delle connessioni gestite dal worker viene posta all’interno del loop di eventi dove risiede con le altre connessioni. All’interno del ciclo, gli eventi vengono elaborati in modo asincrono, consentendo all’elaborazione di venire gestita in modo non bloccante. Quando la connessione viene chiusa, viene rimossa dal loop.

Questo stile di elaborazione delle connessioni consente a Nginx di scalare davvero tanto con risorse limitate. Dal momento che il server è single-threaded e i processi non vengono generati per gestire ogni nuova connessione, l’utilizzo della memoria e della CPU tende a rimanere relativamente costante, anche nei momenti di carico pesante.

Contenuto Statico vs Dinamico

In termini di casi d’uso reali, uno dei paragoni più comuni tra Apache e Nginx è il modo in cui ciascun server gestisce le richieste di contenuti statici e dinamici.

Apache

I server Apache sono in grado di gestire i contenuti statici utilizzando l’ordinaria modalità basata sui file. L’esecuzione di queste operazioni è principalmente compito dei metodi MPM sopra descritti.

Apache può elaborare anche contenuti dinamici grazie all’integrazione di un interprete del linguaggio che si vuole usare, in ciascuna delle sue istanze dei worker. Ciò permette di eseguire il contenuto dinamico nel web server stesso, senza dover ricorrere a componenti esterni. Questi interpreti possono essere attivati ​​attraverso l’uso di moduli caricabili dinamicamente.

La capacità di Apache di gestire contenuti dinamici internamente implica che la configurazione dell’esecuzione di contenuti dimanici tende ad essere più semplice. La comunicazione non ha bisogno di essere coordinata con un software aggiuntivo ed i moduli possono essere scambiati facilmente nel caso in cui ci sia un cambiamento di ciò che necessita ai contenuti [per essere processati, NdT].

Nginx

Nginx non ha alcuna capacità di elaborare contenuti dinamici in modo nativo. Per gestire PHP ed altre richieste dal contenuto dinamico, Nginx è costretto a passare l’esecuzione ad un interprete esterno ed attendere di poter reinviare il contenuto elaborato. In tal caso il risultato può essere trasmesso al client.

Per gli amministratori di sistema, ciò significa dover configurare la comunicazione che intercorre tra Nginx e l’interprete attraverso uno dei protocolli che Nginx è in grado di gestire (http, FastCGI, SCGI, uWSGI, memcache). Ciò può complicare leggermente le cose, soprattutto quando si cerca di anticipare il numero di connessioni consentite, dato che verrà utilizzata un’ulteriore connessione per ogni chiamata all’interprete.

Tuttavia, anche questo metodo presenta alcuni vantaggi. Dal momento che l’interprete dinamico non è incorporato nel processo worker, l’overhead dato dall’interprete riguarderà il solo contenuto dinamico. Il contenuto statico può essere servito in un colpo solo e l’interprete sarà chiamato solo quando necessario. Anche Apache può funzionare in questo modo, ma così non si potranno avere i benefici visti nella sezione precedente.

Configurazione Distribuita VS Centralizzata

Per gli amministratori di sistema, una delle differenze che saltano più facilmente all’occhio tra questi due software è se sia consentita o meno una configurazione a livello di directory all’interno delle directory stesse.

Apache

Apache include un’opzione che consente l’uso di configurazioni aggiuntive basate sulle directory. Ciò avviene controllando e intepretando le direttive poste in file nascosti all’interno delle directory stesse. Questi file sono noti come file .htaccess .

Dal momento che questi file risiedono all’interno delle directory stesse, durante la gestione di una richiesta Apache controlla la presenza di un file .htaccess in ogni parte del path del file richiesto e applica le direttive che trova al suo interno. Ciò permette una configurazione decentrata efficace del server web, che viene spesso utilizzata per implementare l’URL rewrite, le restrizioni di accesso, l’autorizzazione e l’autenticazione, ed anche le politiche di caching.

Mentre gli esempi di cui sopra possono essere configurati nel file di configurazione principale di Apache, i file .htaccess hanno alcuni vantaggi importanti. Innanzitutto, poiché i file vengono interpretati ogni volta che vengono trovati in un path della richiesta, il loro scopo trova subito compimento, senza dover far ripartire il server. In secondo luogo rende possibile consentire agli utenti non privilegiati il controllo di alcuni aspetti dei loro contenuti web senza dar loro il controllo sull’intero file di configurazione.

Questo, per alcuni software web come i sistemi di gestione dei contenuti, facilita la configurazione del proprio ambiente senza dover fornire l’accesso al file di configurazione centrale. Ciò viene usato anche dai fornitori di shared hosting per mantenere il controllo della configurazione principale dando allo stesso tempo ai clienti il ​​controllo sulle proprie  specifiche directory.

Nginx

Nginx non interpreta file .htaccess né fornisce alcun meccanismo per valutare una configurazione per directory al di fuori del file di configurazione principale. Ciò può essere meno flessibile rispetto al modello di Apache, ma ha i suoi vantaggi.

Il miglioramento più importane rispetto al sistema di configurazione a livello di directory offerto da .htaccess, è l’aumento delle prestazioni. Per una tipica configurazione di Apache che può consentire un .htaccess in ogni directory, il server verifica la presenza di questi file in ognuna delle directory genitore che portano al file richiesto, per ogni richiesta. Se in questa ricerca vengono trovati uno o più file .htaccess, devono essere letti e interpretati. Non permettendo l’override delle directory, Nginx può servire richieste più velocemente facendo una sola ricerca della directory e una sola lettura di file per ogni richiesta (assumendo che il file si trovi nella struttura convenzionale della directory).

Un altro vantaggio è legato alla sicurezza. Distribuire l’accesso alle configurazioni a livello di directory distribuisce anche la responsabilità della sicurezza ai singoli utenti, sui quali non si dovrebbe far affidamento per una corretta gestione di questo compito. La garanzia che l’amministratore mangenga il controllo sull’intero web server è in grado di prevenire alcuni passi falsi riguardanti la sicurezza che possono verificarsi quando l’accesso è dato a terzi.

Se queste preoccupazioni vi saltano all’orecchio, tenete a mente che in Apache è possibile disattivare l’interpretazione degli .htaccess.

Interpretazione basata sui file vs interpretazione basata su URI

Un’altra area nella quale i due server differiscono è il modo in cui il server web interpreta le richieste e le associa alle effettive risorse del sistema.

Apache

Apache ha la capacità di interpretare una richiesta come una risorsa fisica sul filesystem o come un URI che necessita di una valutazione più astratta. In generale, nel primo caso Apache utilizza i blocchi <Directory> o <Files>, nel caso di risorse più astratte utilizza i blocchi <Location>.

Dato che Apache è il risultato di una progettazione di un web server da zero, il comportamento predefinito è di solito quello di interpretare le richieste come risorse del file system. Si inizia prendendo la directory root del documento, aggiungendo la parte della richiesta seguita dal numero di host e dalla porta per cercare di trovare un file vero e proprio. In sostanza, la gerarchia del filesystem è rappresentata sul web come l’albero dei documenti raggiungibili.

Apache fornisce una serie di alternative per i casi in cui la richiesta non trova corrispondenza al filesystem sottostante. Per esempio, una direttiva Alias può essere utilizzata per mappare ad una posizione alternativa. Usare i blocchi <Location> è un metodo per lavorare con l’URI stesso anziché con il filesystem. Ci sono anche varianti con le espressioni regolari che possono essere utilizzate per usare la configurazione sul filesystem in maniera più flessibile.

Sebbene Apache sia in grado di operare sia sul filesystem sottostante sia sullo spazio web, fa pesantemente affidamento alle funzioni del filesystem. Ce ne si può rendere conto in alcune delle decisioni nella progettazione, compreso l’uso dei file .htaccess per la configurazione a directory. Nei casi in cui la richiesta rispecchia il filesystem sottostante, è la stessa documentazione Apache (Apache Docs) a diffidare dall’utilizzo dei blocchi basati sugli URI per la limitazione dell’accesso.

Nginx

Nginx è stato creato per essere sia un server web che un server proxy. A causa dell’architettura richiesta per questi due ruoli, Nginx lavora principalmente con gli URI, facendone la trasposizione al file system quando necessario.

Ce ne si può rendere conto in certi modi in cui i file di configurazione di Nginx sono costruiti ed interpretati. Nginx non prevede un meccanismo per specificare la configurazione di una directory del filesystem, analizza invece l’URI stesso.

Ad esempio, i blocchi di configurazione principali per Nginx sono i blocchi server e location. Il blocco server interpreta l’host richiesto, mentre i blocchi location sono responsabili della ricerca di una corrispondenza con porzioni di URI che stanno dopo l’host e la porta. A questo punto, la richiesta viene interpretata come un URI e non come una posizione nel filesystem.

Per i file statici, tutte le richieste alla fine devono essere mappate su un percorso nel filesystem. In primo luogo, Nginx seleziona i blocchi server e location che gestiranno la richiesta e quindi unisce la directory root del documento con l’URI, adattando tutto ciò che è necessario in base alla configurazione specificata.

Ciò potrà sembrare dello stesso tipo [di quella di Apache, NdT], ma fare come prima cosa il parsing delle richieste come URI invece che come posizioni nel filesystem, consente a Nginx di operare più facilmente in ambedue i ruori di  server web/mail e di server proxy. Nginx viene configurato impostando semplicemente il modo di rispondere a diversi pattern di richiesta. Nginx non controlla il filesystem fino a quando non è pronto a servire la richiesta, il che spiega il motivo per cui non utilizza un formato tipo i file .htaccess.

Moduli

Sia Nginx che Apache sono espandibili attraverso dei sistemi a moduli , ma il modo in cui operano differisce in modo significativo.

Apache

Il sistema modulare di Apache permette di caricare o scaricare moduli in modo dinamico in modo da soddisfare ogni esigenza nel corso dell’esecuzione del server. Il nucleo di Apache è sempre presente, mentre i moduli possono essere attivati ​​o disattivati, aggiungendo o rimuovendo funzionalità aggiuntive e hook [tecnica di codifica di un programma che permette all’utente di estenderlo, NdT] al server principale.

Apache utilizza questa funzionalità per una grande varietà di compiti. Grazie alla maturità della piattaforma, vi è una vasta disponibilità di moduli. Questi moduli possono essere utilizzati per modificare alcune delle funzionalità di base del server, per esempio mod_php che incorpora un interprete PHP in ciascun worker in esecuzione.

I moduli però non sono limitati al trattamento dei contenuti dinamici. Tra le altre funzioni, i moduli possono essere utilizzati per la riscrittura degli URL, l’autenticazione dei client, l’hardening del server, il log, il caching, la compressione, le funzioni di proxy, la limitazione della banda e la cifratura. I moduli dinamici possono estendere le funzionalità di base in modo significativo senza richiedere troppo lavoro extra.

Nginx

Anche Nginx implementa un sistema modulare, ma è piuttosto diverso dal sistema Apache. In Nginx, i moduli non sono caricabili dinamicamente, quindi devono essere scelti e compilati nel programma principale.

Per molti utenti, ciò rende Nginx molto meno flessibile. Questo è vero soprattutto per gli utenti a cui non piace mantenere le proprie versioni dei programmi compilati al di fuori del tradizionale sistema di gestione dei pacchetti della distribuzione. Mentre i pacchetti delle distribuzioni tendono ad includere i moduli più comuni, se si ha bisogno di un modulo non standard si dovrà compilare da sé il server dai sorgenti.

I moduli Nginx sono tuttavia molto utili e permettono di far fare al server ciò che si desidera semplicemente includendo la funzionalità che si intende utilizzare. Qualche utente potrebbe anche considere tutto ciò più sicuro, visto che non si possono far caricare al server delle componenti arbitrarie. Tuttavia, se il server viene sempre lasciato in una modalità in cui questo è possibile, è probabile che sia già compromesso.

I moduli Nginx permettono molte delle stesse funzionalità dei moduli di Apache. Ad esempio, i moduli Nginx sono in grado di fornire il supporto proxy, la compressione, la limitazione di banda, il logging, la riscrittura, la geolocalizzazione, l’autenticazione, la crittografia, lo streaming e le funzionalità di posta elettronica.

Supporto, Compatibilità, Ecosistema e Documentazione

Un punto importante da considerare è che il vero modo per rendere un sistema funzionante sarà dato dall’offerta di assistenza e supporto disponibile con altri software.

Apache

Visto che Apache è stato popolare per così tanto tempo, il supporto per il server è discretamente onnipresente. È disponibile una grande quantità di documentazione ufficiale e di terze parti per il server principale e per i casi che coinvolgono Apache con altri software.

Assieme alla documentazione, molti strumenti e progetti web includono strumenti che permettono a questi strumenti e progetti stessi, il bootstrap all’interno di un ambiente di Apache. Questo ambiente può essere incluso nei progetti stessi, o nei pacchetti manutenuti dalle persone che si occupano dei pacchetti della vostra distribuzione.

Apache, in generale, troverà maggiore supporto in progetti di terze parti semplicemente per la sua quota di mercato e per il periodo di tempo da cui è disponibile. Gli amministratori di sistema hanno una più alta probabilità di avere pratica con Apache, non solo a causa della sua diffusione, ma anche perché molte persone cominciano con lo shared hosting che si basa quasi esclusivamente su Apache a causa delle capacità di gestione distribuita, possibili grazie ad .htaccess .

Nginx

Nginx sta avendo un supporto crescente visto che sempre più utenti lo adottano per la sua attitudine alle prestazioni pure, ma ha ancora un po’ di ritardo da recuperare in alcuni settori chiave.

In passato era difficile trovare della documentazione completa riguardante Nginx in lingua ingles , perché la maggior parte dello sviluppo iniziale e la documentazione erano in russo. Dal momento che l’interesse per il progetto è cresciuto, la documentazione è stata completata e ora ci sono un sacco di risorse sulla gestione di Nginx sul sito ufficiale e non.

Per quanto riguarda le applicazioni di terze parti, il supporto e la documentazione stanno diventando disponibili con sempre più facilità e i manutentori dei pacchetti stanno cominciando, in alcuni casi, a fornire la scelta tra la configurazione automatica per Apache e quella per Nginx. Anche senza supporto, la configurazione di Nginx per poter funzionare con software alternativo è di solito chiara, a condizione che il progetto stesso documenti le sue esigenze (permessi, header, ecc.).

Uso combinato di Apache e Nginx

Andando oltre i vantaggi e i limiti sia di Apache che di Nginx , si può avere un’idea migliore di quale server sia più adatto alle vostre esigenze. Tuttavia, molti utenti trovano fattibile sfruttare i punti di forza di ciascun server usandoli assieme.

La tipica configurazione usata per ottenere questa collaborazione è quella di mettere Nginx a precedere Apache come proxy inverso. Ciò permetterà a Nginx di gestire tutte le richieste da parte dei client. Questo sfrutta la rapida velocità di elaborazione di Nginx e la sua capacità di gestire un gran numero di connessioni contemporaneamente.

Per i contenuti statici, nei quali Nginx eccelle, i file saranno serviti velocemente e direttamente al client. Per i contenuti dinamici, per esempio i file PHP, Nginx delegherà la richiesta ad Apache, che può così elaborare i risultati e restituire la pagina elaborata. Nginx può quindi passare il contenuto al client.

Questa configurazione funziona bene per molte persone, perché permette a Nginx di funzionare come una macchina di smistamento. Essa si occuperà di tutte le richieste che potrà e lascerà passare quelle che non riesce a servire nativamente. Riducendo le richieste che il server Apache è chiamato a gestire, siamo in grado di attenuare alcuni dei blocchi che si verificano quando un processo o un thread di Apache è occupato.

Questa configurazione permette anche di scalare, tramite l’aggiunta di server di backend aggiuntivi quando ve ne sarà bisogno. Nginx può essere configurato per migrare facilmente su un gruppo di server, aumentando la resilienza al fallimento e le prestazioni di questa configurazione.

Conclusioni

Come si può vedere, sia Apache che Nginx sono potenti, flessibili e fanno quello che devono. La decisione su quale server sia per voi il migliore si deve in gran parte alla valutazione delle vostre specifiche esigenze e dai test effettuati con i modelli che ci si aspetta di ottenere.

Ci sono differenze tra i progetti che hanno un impatto davvero importante sulle prestazioni vere e proprie, quelli sulle capacità, e quelli sul tempo di implementazione necessari per ottenere ciascuna soluzione funzionante. Tuttavia, queste soluzioni sono di solito il risultato di una serie di compromessi che non dovrebbero essere scartati con noncuranza. Alla fine, non ci sono web server che vanno bene per tutto, dunque usate la soluzione che meglio si adatta ai i vostri obiettivi.

Non esiste Democrazia senza fiducia (tratto da beppegrillo.it)

di Ivan Krastev – Ho paura che questo sarà uno di quegli argomenti di cui sarebbe stato meglio non parlare. Ora che sapete cosa aspettarvi, procediamo con la storia.

È un piovoso giorno di elezioni in un piccolo paese, può essere il mio paese, ma potrebbe anche essere il vostro. E per colpa della pioggia fino alle 4 del pomeriggio, nessuno è andato ai seggi. Ma poi ha smesso di piovere e la gente è andata a votare. Dopo lo scrutinio, tre quarti della gente aveva votato scheda bianca. Il governo e l’opposizione sono rimasti semplicemente paralizzati. Perché si sa cosa fare in caso di proteste. Si sa chi arrestare e con chi negoziare.

Ma cosa fare con le persone che votano scheda bianca? Allora il governo ha deciso di ripetere le elezioni. E la seconda volta ancora più gente, l’83% delle persone, votò scheda bianca. In sostanza andarono ai seggi a dire che non avevano nessuno per cui votare.

Questo è l’inizio di un bellissimo romanzo di Jose Saramago intitolato “Saggio sulla Lucidità”. Dal mio punto di vista, coglie molto bene una parte del problema della democrazia attuale in Europa. Da un lato nessuno mette in discussione che la democrazia sia la migliore forma di governo. La democrazia è l’unica opzione possibile. Dall’altra incomincia ad apparire ovvio che una gran parte della popolazione pensi che non vale la pena giocare.

Cosa fare? Negli ultimi 30 anni, gli studiosi di politica hanno osservato un declino costante dell’affluenza alle urne, e hanno visto che le persone meno interessate a votare sono quelle che hanno più da guadagnare dal voto: come i disoccupati, i meno privilegiati.

Ed è un problema importante. Perché adesso con la crisi economica, si è evidenziato un fatto. Il modello occidentale è stato messo in ginocchio dalla crisi, e ci si aspettava che la “democrazia” aiutasse il popolo, invece è servita a salvare gli istituti finanziari, la finanza, ecc. Insomma abbiamo visto che lo strumento del popolo non serve al popolo, ma ai nuovi aristocratici.

Così la fiducia nella politica, la fiducia nelle istituzioni democratiche, è stata davvero distrutta. Secondo l’ultima ricerca fatta dalla Commissione Europea, l’89% dei cittadini europei crede che ci sia un vuoto crescente tra le opinioni dei politici e l’opinione del pubblico. Solo il 18% degli italiani e il 15% dei greci credono che il loro voto conti. In sostanza le persone cominciano a capire che possono cambiare i governi, ma non possono cambiare la politica.

Quindi la domanda che voglio farvi è la seguente: Com’è possibile che viviamo in società che sono più libere di quanto non lo siano mai state prima, abbiamo più diritti, possiamo viaggiare più facilmente, abbiamo accesso a più informazioni e, allo stesso tempo, la fiducia nelle istituzioni democratiche sia crollata?

Qualcosa è andato bene e qualcosa è andato storto in questi ultimi 50 anni. É evidente.

La prima cosa che è andata bene, ovviamente, sono queste cinque rivoluzioni che, dal mio punto di vista, hanno cambiato molto il nostro modo di vivere e approfondito la nostra esperienza democratica. La prima è stata la rivoluzione culturale e sociale del 1968 e degli anni ’70, che ha messo l’individuo al centro della politica. Era il periodo dei diritti umani. Sostanzialmente fu una grande rivolta, una cultura di dissenso, una cultura basata sull’anti-conformismo, mai sperimentata prima.

Poi c’è stata la rivoluzione del mercato degli anni ’80; e benché molte persone di sinistra cerchino di odiarla, la verità è che è stata la rivoluzione del mercato a diffondere il messaggio: “Il governo non sa fare meglio.” Così ci sono società più guidate dalle scelte. Certo, c’è il 1989, la fine del Comunismo, la fine della Guerra Fredda. È stata la nascita del mondo globale. C’è Internet che ha cambiato il nostro modo di comunicare e il nostro modo di vedere la politica. L’idea stessa di comunità politica è totalmente cambiata. Citerò un’altra rivoluzione, ed è la rivoluzione delle neuroscienze, che hanno cambiato completamente la nostra comprensione del processo decisionale.

Questo è quello che è andato bene. Se vogliamo vedere cosa è andato storto, finiremo per elencare le stesse cinque rivoluzioni. Perché la rivoluzione culturale degli anni ’60 e ’70 in un certo senso ha distrutto l’idea di uno scopo collettivo. É difficile coinvolgere le persone nella politica quando credono che quello che conta veramente è il successo personale.

C’è la rivoluzione di mercato degli anni ’80 e il pesante incremento delle ineguaglianze nelle società. Ricordatevi che, fino agli anni ’70, la diffusione della democrazia è sempre andata di pari passo con il declino delle disuguaglianze. Più le nostre società sono diventate democratiche, più sono diventate eque. Ora abbiamo la tendenza opposta. La diffusione della democrazia va di pari passo con l’aumento delle disuguaglianze. E lo trovo un dato molto preoccupante, quando parliamo di cosa è andato bene e di cosa è andato male nella democrazia moderna.

Se tornate al 1989, quando c’era ancora l’Unione Sovietica, i ricchi e i potenti avevano bisogno delle persone, perché ne avevano paura. Ora le élite sono state liberate. Sono molto libere. Non si possono tassare. E in sostanza non hanno paura delle persone. Il risultato è questa situazione molto strana in cui le élite sono al di fuori del controllo degli elettori. Non è un caso che gli elettori non abbiano più interesse a votare.

Quando parliamo di Internet, è vero che Internet ci connette tutti, ma sappiamo anche che Internet ha creato altre potenze. È l’altro lato delle cose che ci piacciono. Tutto ha un lato negativo.

Infine abbiamo le neuroscienze, e quello che i consulenti politici hanno imparato dai neuroscienziati, è che non devono più parlare di idee, o di programmi politici. Quello che conta è manipolare le emozioni delle persone. Ed è una pratica così diffusa che, anche se sentite parlare di rivoluzioni, sono rivoluzioni il cui nome non ha più nulla a che fare con le idee o le ideologie. Prima le rivoluzioni avevano nomi ideologici. Potevano essere comuniste, potevano essere liberali, potevano essere fasciste o islamiche. Ora le rivoluzioni vengono definite dal mezzo utilizzato. Ci sono le rivoluzioni Facebook, le rivoluzioni Twitter. Il contenuto non ha più importanza, il problema è il mezzo.

Lo dico perché se cerchiamo di capire come si possa fare per cambiare la situazione, se cerchiamo di capire cosa fare per la democrazia, dovremmo tenere a mente queste ambiguità.

Quindi voglio parlarvi di cosa abbiamo fino ad oggi messo in campo per cambiare la situazione: La trasparenza. Premetto che la trasparenza è un fatto positivo, sono del tutto favorevole. Voglio parlarvi però di cosa significa.

Questa spinta alla trasparenza, questa combinazione tra cittadinanza attiva, nuove tecnologie e legislazioni molto più trasparenti è data perché si crede che con le nuove tecnologie e la gente pronta ad utilizzarle, sia molto più difficile mentire per i governi, che per loro sia molto più difficile rubare. É vero. Ma questo è come dire: non ci fidiamo, sappiamo che ruberete e che mentirete se non facciamo questo. Quindi se il problema è la fiducia, così ammettiamo che la trasparenza è la gestione politica della sfiducia. Diamo per scontato che le nostre società saranno basate sulla sfiducia.

E in effetti, la sfiducia è sempre stata molto importante per la democrazia. Ecco perché ci sono controlli e bilanci. Tutti noi ci sentiamo perseguitati dalle istituzioni, ci tracciano, controllano ogni mossa, e pretendono troppo. Perché? Perché la situazione economica è pessima. Ma chi l’ha prodotta? Il popolo risponde che è stata la politica, ed è allora che nota che i sacrifici vengono fatti solo dal popolo e mai dalla nuova aristocrazia.

Penso che tutto sia buono e tutto sia cattivo, basta cambiare angolazione. Non dimenticate che svelando una cosa se ne nasconde un’altra. Non importa quanto trasparenti vogliano essere i governi: saranno trasparenti in maniera selettiva. Mostreranno quello che vogliono mostrare.

Vi faccio un esempio. Nel paese che non cito, hanno preso una decisione, questo è un caso vero, che tutte le decisioni del governo, le discussioni del consiglio dei ministri, vengano pubblicate su Internet 24 ore dopo la fine delle discussioni in consiglio. E il pubblico era assolutamente euforico. Così ho avuto la possibilità di parlare al primo ministro, sul perché di questa decisione. Ha detto: “Questo è il modo migliore di tenere chiusa la bocca dei miei ministri. Perché per loro sarà molto difficile dissentire sapendo che 24 ore dopo verrà tutto reso disponibile al pubblico, ed è una strada che porta diritto alla crisi politica.”

Quindi, quando parliamo di trasparenza, quando parliamo di apertura, credo veramente che dovremmo tenere a mente che quello che è andato bene è anche quello che è andato storto. Perché se veramente non siamo pronti a cambiare le cose, a fare una rivoluzione, a rischiare di commettere degli errori, allora non cambierà mai nulla.

Goethe, qualche secolo fa disse: “C’è molta ombra dove c’è molta luce.”

Ports mail server

Default Ports:

Server: Authentication: Port:
SMTP Server (Outgoing Messages) Non-Encrypted AUTH 25 (or 587)
Secure (TLS) StartTLS 587
Secure (SSL) SSL 465
IMAP Server (Incoming Messages) Non-Encrypted AUTH 143
Secure (TLS) StartTLS 143
Secure (SSL) SSL 993

 

This list is without any warranties and not sorted alphabetically.
See also: A List of SMTP and POP3 Mail Server (Mail Server List)

Init Gitlab after installation before first commit

Document link

It is important to configure your Git username and email address, since every Git commit will use this information to identify you as the author.

On your shell, type the following command to add your username:

git config –global user.name “YOUR_USERNAME”

Then verify that you have the correct username:

git config –global user.name

To set your email address, type the following command:

git config –global user.email “your_email_address@example.com”

To verify that you entered your email correctly, type:

git config –global user.email

You’ll need to do this only once, since you are using the –global option. It tells Git to always use this information for anything you do on that system. If you want to override this with a different username or email address for specific projects, you can run the command without the –global option when you’re in that project.

Check your information
To view the information that you entered, along with other global options, type:

git config –global –list

Lambda expressions are cool

Lambdache?
Quindi, cosa sono le lambda expression? Definiamo la lambda expression come funzioni anonime, sì funzioni come quelle del linguaggio C, per capirsi e anonime: senza, cioè, una dichiarazione che le dia un nome. Abbiamo, quindi, un nuovo approccio al codice, possiamo cioè scrivere codice funzionale: passare funzioni a funzioni così come adesso passiamo oggetti ad oggetti, restituire funzioni da funzioni, come adesso restituiamo oggetti a partire da oggetti ma soprattutto possiamo usare oggetti e funzioni assieme semplificando il codice. Detta così non è ancora chiara la portata della novità, per cui codice, codice, codice! Partiamo da come scriviamo il codice oggi e arriviamo a come si può scrivere con Java 8.

Lambda expressions are cool
In questo post faremo un unico esempio che andremo via via a modificare introducendo le lambda expression: abbiamo una lista di stringhe e vogliamo stamparla su console. Scriviamo il primo codice che ci viene in mente:

package it.cosenonjaviste.lambda;

import java.util.*;

public class SevenMinutesLambda {

public static void main(String[] args) {

List strings = Arrays.asList(“Lambda “, “expressions “, “are “, “cool”);

for (int i = 0; i < strings.size(); i++) { System.out.print(strings.get(i)); } } } Quanto abbiamo scritto fa quello che ci aspettiamo, ma con l’uso dei generics possiamo fare di meglio: package it.cosenonjaviste.lambda; import java.util.*; public class SevenMinutesLambda { public static void main(String[] args) { List strings = Arrays.asList(“Lambda “, “expressions “, “are “, “cool”);

for (String element : strings) {
System.out.print(element);
}
}

}
Questo codice è sicuramente familiare, perché lo usiamo da anni e a colpo d’occhio sappiamo cosa fa. Siamo sicuri però che sia il codice più semplice da scrivere e quello più performante? Prima di procedere riflettiamo per un attimo su quello che abbiamo di fronte, siamo davanti ad un caso di iterazione esterna, cioè stiamo dicendo alla collezione di stringhe: dammi una stringa, poi dammene un’altra e un’altra ancora, è il codice client che chiede alla lista un elemento alla volta e poi decide cosa farne, in pieno stile imperativo.

Iterazione interna
L’interazione interna invece, è tutta un’altra storia e mi permetto di prendere in prestito l’esempio di Mario Fusco al JavaOne per far capire la differenza tra i due. L’iterazione esterna è un po’ come far riordinare i giochi alla propria figlia piccolina:

“prendi quella palla laggiù”
“e adesso?”
“mettila nella cesta dei giochi”
“e adesso?”
“prendi quella bambola qui”
“e adesso?”
“mettila nella cesta dei giochi”
e adesso?

L’iterazione interna invece assomiglia di più a “prendi i tuoi giochi e mettili nella cesta” (sottointeso: scegli tu l’ordine con cui farlo e se hai l’altra mano libera e passi vicino ad un giocattolo, e ti va di prenderlo, prendi anche quello). Sicuramente anche chi non è genitore apprezza la compattezza e semplicità della seconda soluzione 😉 .

Cosa ci offre Java 8 per usare questo tipo di iterazione nel caso visto sopra? Il nuovo metodo forEach:

1
2
void forEach(Consumer action)
//Performs an action for each element of this stream.
che prende in ingresso un Consumer, una nuova interfaccia di Java 8 (per la precisione è una interfaccia funzionale ma lasciamo questo argomento per un prossimo post). La cosa che ci interessa sapere ora è che questa interfaccia è come quelle che conosciamo e che ha un metodo da implementare:

1
void accept(T t) //Performs this operation on the given argument.
Scriviamo quindi una inner class anonima che implementa Consumer e la passiamo direttamente al forEach.

package it.cosenonjaviste.lambda;

import java.util.*;
import java.util.function.Consumer;

public class SevenMinutesLambda {

public static void main(String[] args) {

List strings = Arrays.asList(“Lambda “, “expressions “, “are “, “cool”);

strings.forEach(new Consumer() {
public void accept(String s) {
System.out.print(s);
}
});
}
}
Il risultato non cambia, ma quello che abbiamo fatto è un cambio di paradigma, non diciamo più alla lista come produrre il risultato, ma cosa voglia che venga fatto su ogni elemento della collezione, ci concentriamo meno sul modo per farlo ma su cosa vogliamo ottenere. Un altro vantaggio è che l’iterazione è nascosta nell’implementazione. Non solo non rischiamo più di commettere errori nella costruzione del ciclo, ma l’implementazione è polimorfica in base alla classe a cui si applica il metodo. Di conseguenza, l’iterazione interna può essere ottimizzata a seconda del tipo di struttura dati e, quando richiesto e dove applicabile, può essere svolta in parallelo.

Basta un poco di zucchero e..
Tuttavia, il codice che abbiamo adesso non sembra così invitante: abbiamo scritto molte più righe per ottenere lo stesso risultato di prima. Fortunatamente, possiamo sostituire la inner class con una lambda expression, liberandoci di tutto il codice in più e, di fatto, scrivendo tutto in un’unica riga.

import java.util.*;
import java.util.function.Consumer;

public class SevenMinutesLambda {

public static void main(String[] args) {

List strings = Arrays.asList(“Lambda “, “expressions “, “are “, “cool”);

strings.forEach((String s) -> System.out.print(s));

}
}
Adesso sì che abbiamo qualcosa di un po’ più “alieno” sotto gli occhi. Esaminiamo la nostra lambda (=funzione anonima) con attenzione. Una funzione ha un nome, una lista di parametri, un corpo e un valore ritornato. Abbiamo la lista di parametri (String s) separata dal corpo (System.out.print(s)) con la freccia ->. Il tipo di ritorno viene dedotto dal contesto, in questo caso è void. Il nome invece non c’è: era anonima la inner class prima, è anonima la funzione adesso. Ora la definizione di lambda che abbiamo dato all’inizio ha più senso.

Quindi, dove possiamo utilizzare le lambda? Dovunque ci sia una interfaccia che preveda tra i suoi metodi uno e un solo metodo astratto. Beh, ma le interfacce non hanno implementazioni, tutti i metodi di una interfaccia sono astratti per definizione, direte. No, da Java 8 è possibile avere interfacce che hanno dei metodi implementati (detti di default), anche questo argomento lo lasciamo per un prossimo post.

Meno verboso, meno noioso
Si può fare ancora di meglio, dal contesto il compilatore sa che stiamo applicando la nostra lambda ad una collezione di stringhe attraverso la type inference, quindi possiamo semplificare la funzione omettendo il tipo per s.

package it.cosenonjaviste.lambda;

import java.util.*;

public class SevenMinutesLambda {

public static void main(String[] args) {

List strings = Arrays.asList(“Lambda “, “expressions “, “are “, “cool”);

strings.forEach(s -> System.out.print(s));

}
}
Ora la nostra lambda è talmente semplice che.. si può semplificare ancora! Dato che l’unica cosa che facciamo al suo interno è chiamare un metodo, possiamo usare un method reference al posto della nostra espressione. Anche questa è una novità introdotta dalla versione 8. Possiamo pensare i method reference come delle lambda expression che non sono anonime, ma che si riferiscono ad un specifico metodo di una determinata classe (o di una istanza). Ad esempio, String::valueOf o Integer::compare sono esempi di method reference per metodi statici. Detto questo, non ci resta che usare questo nuovo costrutto nel nostro codice e modificare il nostro esempio per l’ultima volta.

package it.cosenonjaviste.lambda;

import java.util.*;

public class SevenMinutesLambda {

public static void main(String[] args) {

List strings = Arrays.asList(“Lambda “, “expressions “, “are “, “cool”);

strings.forEach(System.out::print);

}
}
Il passaggio alle lambda è completo ora, siamo passati da un ciclo for, classico esempio di iterazione esterna, a una iterazione interna gestita attraverso una funzione anonima o un method reference, sicuramente un bel po’ della verbosità di Java è stata eliminata a vantaggio della chiarezza e semplicità.

Installing and configuring an SSL certificate on Postfix/Dovecot mail server

From here ….thanks…

This guide describes the ways to enable the SSL/TLS encryption using a trusted SSL certificate for receiving secured incoming and outgoing connections on a Postfix-Dovecot server.

For testing purposes, a Comodo PositiveSSL certificate has been used; however, to secure your mail server, you can purchase any certificate with us as they meet your needs.

The testing was done on the following server stack:

  • Ubuntu 16.04
  • Postfix 3.1.0
  • Dovecot 2.2.22

If you do not have any issued (trusted) certificate yet for the hostname of your mail server, it is necessary to purchase it, generate a CSR needed for activation and once done, activate  it.

If you have your certificate issued, you are able to download it from the SSLs.com user account or from the email (fulfillment email) received  from the Certificate Authority to the administrative contact email address you have chosen during the activation process.

The first thing you need to do is to upload and concatenate the certificate files on the server. You can follow the actions below:

1. Upload the certificate file yourdomainname.crt to the server along with the CA bundle. Keep in mind that the CA bundle can be either in a single file (example.ca-bundle) or in separate files (COMODORSADomainValidationSecureServerCA.crt, COMODORSAAddTrustCA.crt, AddTrustExternalCARoot.crt as in our case). The following files should be saved in the following way: the certificate and CA bundle files in the /etc/ssl/certs/ directory; the corresponding private key (example_com.key) in the /etc/ssl/private/ folder.

2.Combine the uploaded files into one using one of the commands below:

2.1. Create a file with the server certificate and CA chain:

  • cat /etc/ssl/certs/yourdomainname.crt /etc/ssl/certs/yourdomainname.ca-bundle >> /etc/ssl/certs/certificate.crt
  • cat /etc/ssl/certs/yourdomainname.crt /etc/ssl/certs/COMODORSADomainValidationSecureServerCA.crt /etc/ssl/certs/COMODORSAAddTrustCA.crt /etc/ssl/certs/AddTrustExternalCARoot.crt >> /etc/ssl/certs/certificate.crt

2.2. One file with the combined certificate, CA chain and Private Key can be acceptable for Postfix and  Dovecot. One of the commands below can be used to create it:

  • cat /etc/ssl/certs/yourdomainname.crt /etc/ssl/certs/yourdomainname.ca-bundle /etc/ssl/private/yourdomainname.key >> /etc/ssl/certs/certificate_and_key.crt
  • cat /etc/ssl/certs/yourdomainname.crt /etc/ssl/certs/COMODORSADomainValidationSecureServerCA.crt /etc/ssl/certs/COMODORSAAddTrustCA.crt /etc/ssl/certs/AddTrustExternalCARoot.crt /etc/ssl/private/yourdomainname.key >> /etc/ssl/certs/certificate_and_key.crt

In order to check the content of the new file in question, run the following command: cat /etc/ssl/certs/certificate.crt or cat /etc/ssl/certs/certificate_and_key.crt.

It is necessary to check whether there are no excessive white spaces between or inside the PEM-encoded certificate and key blocks in the output.

If you notice such spaces, they can be edited manually – open the file in a text editor like “vi” or “nano” and remove the odd elements.

The editing of Postfix and Dovecot configuration files to enable SSL/TLS on specific ports

The process of sending and receiving mail over the Internet is a complex system of endpoint and intermediary instances (mail server and client software) labeled as mail user agents (MUA), mail submission agents (MSA), mail transfer agents (MTA) and mail delivery agents (MDA) depending on the functions they perform. Normally, an email is passed over each type of the above-mentioned parties, and different transport protocols are used on every step, namely submission protocol, Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP3) and Internet Message Access Protocol (IMAP).

The below chart shows the use of ports for specific transport protocol execution.

Protocol Usage Plain text / encrypted session Encrypted session only
POP3 Incoming mail 110 995
IMAP Incoming mail 143 993
SMTP Outgoing mail 25 465
Submission Outgoing mail 587

The Opportunistic TLS approach gives the possibility to use ports 25, 110, 143 and 587 either in the plain text (unencrypted) or secure (encrypted) mode. According to this approach, the STARTTLS command is requested when an existing active plain text session happens.

Technically, using ports 465, 993 and 995 and the way HTTP protocol is used over SSL/TLS are similar: 1) secure ports are detached from their “unsecured” counterparts; 2) any data exchange can be performed after establishing an encrypted session.

NOTE: Although port 465 is not listed as the SMTPS port in the official standards of IANA’s documentation, it is used to serve encrypted outgoing mail traffic by mail server administrators.

Both techniques described above are considered to be used in the Internet mail system nowadays. In order to secure your mail, it is better to install an SSL certificate on every mail port you are planning to use.

The steps below will help you to install your SSL certificate for both mail ports: incoming and outgoing ones:

Port 25 (SMTP with STARTTLS)

  1. Open to edit the file named main.cf (Postfix configuration file). You can usually find it in the /etc/postfix/ directory.
  2. Locate the TLS parameters section in the main.cf file and make the changes in the following values of certain directives. See the example below:
  • if  you save the certificate and private key in separate files:

smtpd_tls_cert_file=/etc/ssl/certs/certificate.crt

smtpd_tls_key_file=/etc/ssl/private/yourdomainname.key

  • if  you save the certificate and private key in a single file:

smtpd_tls_cert_file=/etc/ssl/certs/certificate_and_key.crt

smtpd_tls_key_file=$smtpd_tls_cert_file

NB: It is necessary to make sure that smtpd_use_tls directive is set to yes:

smtpd_use_tls=yes

Once done, close the main.cf file and save the changes you made.

http://helpdesk.ssls.com/hc/article_attachments/115000773949/post1.jpg

Ports 587 (Submission with STARTTLS) and 465 (SMTPS)

  1. Locate the Postfix’s master.cf file in the /etc/postfix/ directory and open it;
  2. When it is opened, uncomment (or edit if needed) the next lines:
  • to open and protect port 587:

submission inet n       –       y       –       –       smtpd

-o syslog_name=postfix/submission

-o smtpd_tls_security_level=may

-o smtpd_sasl_auth_enable=yes

  • to open and protect port 465:

smtps     inet  n       –       y       –       –       smtpd

-o syslog_name=postfix/smtps

-o smtpd_tls_wrappermode=yes

-o smtpd_sasl_auth_enable=yes

Now you can close this file.

http://helpdesk.ssls.com/hc/article_attachments/115000773969/post2.jpg

Ports 110 (POP3 with STARTTLS), 143 (IMAP with STARTTLS), 993 (IMAPS) and 995 (POP3S)

If you need to install an SSL certificate for Dovecot, it is essential to follow the next steps:

  • Open the file named 10-ssl.conf. This file can be usually located in the /etc/dovecot/conf.d/ directory.
  • Edit the following lines:

 

  • if  you save the certificate and private key in separate files:

ssl_cert = </etc/ssl/certs/certificate.crt

ssl_key = </etc/ssl/private/yourdomainname.key

  • if  you save the certificate and private key in a single file:

ssl_cert = </etc/ssl/certs/cert_and_key.crt

ssl_key = </etc/ssl/certs/cert_and_key.crt

Make sure that thessl directive is set to yes:

ssl = yes

When the changes are made, close the 10-ssl.conf file.

 

If the steps mentioned above are made, the SSL certificate is installed for all incoming ports now.

http://helpdesk.ssls.com/hc/article_attachments/115000773989/post3.jpg

Please note that if you have the Dovecot version 1.x, the directives for SSL certificates in configuration files may slightly differ:

  • it is necessary to check whether /etc/dovecot/dovecot.conf has the following line:

protocols = imap pop3 imaps pop3s

  • edit the /etc/dovecot/conf.d/10-ssl.conf file in the following way:

ssl_disable = no

 

– if  you save the certificate and private key in separate files:

ssl_cert_file = </etc/ssl/certs/certificate.crt

ssl_key_file = </etc/ssl/private/yourdomainname.key

 

– if  you save the certificate and private key in a single file:

ssl_cert_file = </etc/ssl/certs/cert_and_key.crt

ssl_key_file = </etc/ssl/certs/cert_and_key.crt

 

Useful tips:

Below you can find the information regarding some additional settings which can be useful in setting up your mail server’s SSL/TLS handling. For further information, you can refer to Postfix andDovecot official documentation regarding this matter as well.

It is possible to use the STARTTLS port on Postfix in the “wrapper” mode with the smtpd_tls_wrappermode directive. Instead of showing the STARTTLS support and waiting for the request from a remote client, this option helps to run  a secure connection from the very beginning. The following directive should be added to /etc/postfix/master.cf , for instance:

smtps inet n     –     n     –     –     smtpd

-o smtpd_tls_wrappermode=yes

On Dovecot, when you try to log in, there is an opportunity to set the ssl directive to required value (ssl=required), which implies forcing the SSL handshake.

In such cases, the password will be sent in a secure way, meanwhile with ssl = yes, email clients are not requested to use SSL/TLS in precedence. Both plaintext and non-plaintext authentication mechanisms can be applied with this setting.

In order to switch off the plaintext authentication mechanism, it is possible to use disable_plaintext_auth directive (/etc/dovecot/conf.d/10-auth.conf):

disable_plaintext_auth=yes

The following directives on Dovecot (/etc/dovecot/dovecot.conf) can be used for eliminating the ciphers which are better not to be used due to low encryption strength:

ssl_dh_parameters_length = 2048

ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL

To exclude certain ciphers or protocols for opportunistic (STARTTLS) or mandatory (regular SSL) encryption, it is possible to use the following directives in /etc/postfix/main.cf and assign the corresponding values to them:

– for mandatory TLS

smtpd_tls_mandatory_exclude_ciphers = [cipher] smtpd_tls_mandatory_protocols = ![protocol]

– for opportunistic TLS

smtpd_tls_exclude_ciphers = [cipher]

smtpd_tls_protocols = ![protocol]

 

To set the server side cipher list more preferable over the client-side one, these directives can be used:

– on Dovecot (/etc/dovecot/conf.d/10-ssl.conf)

ssl_prefer_server_ciphers = yes

– on Postfix (/etc/postfix/main.cf)

tls_preempt_cipherlist = yes

 

How to check SSL installation

OpenSSL

 

The OpenSSL toolkit helps to check the SSL certificate installation on a server both remotely and locally.

In order to check STARTTLS ports, the following command should be run. Replace [port] with the port number and [protocol] with smtp, pop3 or imap value:

openssl s_client -connect example.com:[port] -servername example.com -starttls [protocol]

In order to check non-STARTTLS ports, use the following command:

openssl s_client -connect example.com:[port] -servername example.com

http://helpdesk.ssls.com/hc/article_attachments/115000774009/post4.jpg

 

How to check your secure connection

 

In order to check your mail server connectivity over SSL/TLS, the online checkers listed below can be used.

You need to specify the server hostname and port number or an existing email account and run the test.