SIAMO GEEK

Tag: postfix

  • Forward secrecy in Postfix

    È possibile implementare la forward secrecy anche nelle sessioni TLS di Postfix.

    Questa guida parte dal presupposto che Postfix abbia TLS configurato e funzionante, non importa se con un certificato auto-emesso o rilasciato da un’autorità PKI, e si applica alla versione 2.10, le versioni precedenti potrebbero aver bisogno di qualche aggiustamento dei parametri, come indicato nel readme apposito.

    Lo scopo è di avere delle chiavi di sessione effimere con una vita relativamente breve al fine di rendere più ardua la cosiddetta retrospective decryption attraverso una rigenerazione periodica dei parametri p e g dell’algoritmo Diffie-Hellman per lo scambio di chiavi.

    (altro…)

  • Postfix: forzare IPv4 o IPv6 con un dominio

    Questo articolo spiega come forzare la connessione IPv4 o IPv6 verso un dominio specifico utilizzando Postfix.

    Se si imposta inet_protocols = all con un MTA che ha sia un record A sia un record AAAA Postfix sceglie di volta in volta a caso se utilizzare IPv4 o IPv6 per minimizzare i problemi di recapito.

    Durante il primo periodo di adozione dell’IPv6 ci possono essere degli MTA con il record AAAA nel DNS ma con dei problemi a ricevere mail via IPv6. Oppure semplicemente si vogliono fare dei test con un dominio specifico senza modificare la configurazione generale di Postfix.

    (altro…)

  • Postfix: forzare il dialogo cifrato fra due MTA

    È possibile forzare il dialogo cifrato TLS tra due server di posta elettronica (MTA).

    Di seguito viene spiegato come farlo con Postfix 2.10.2, l’ultima disponibile, compilata sul server in cui gira con il supporto TLS attivato. È naturalmente possibile ottenere lo stesso risultato anche con altri MTA o con versioni precedenti di Postfix (sconsiglio di scendere sotto la 2.6.0 ed è meglio evitare il range  2.9.0 – 2.9.5 (incluse) perché hanno un baco nel calcolo del fingerprint della chiave pubblica.

    È fondamentale una certa padronanza con Postfix, che viene data per scontata dalla procedura descritta di seguito.

    (altro…)

  • Mail server in IPv6

    Questo articolo spiega come passare in IPv6 un mail server Linux con Postfix, Amavisd-new e Dovecot.

    Il sistema di partenza è un Linux con il dual stack IPv4/IPv6 attivo e funzionante con un indirizzo pubblico IPv4 e uno IPv6. Anche il sistema di posta elettronica è perfettamente funzionante in IPv4 con le ultime versioni dei programmi indicati sopra installati da sorgente, non da pacchetto della distribuzione Linux. Ciò perché con IPv6 è sempre meglio avere le ultime versioni, anche se la maggior parte delle istruzioni che seguono dovrebbero funzionare anche con le versioni distribuite nei pacchetti standard.

    Continua a leggere

  • Bloccare le conferme di lettura con Postfix

    Alcune organizzazioni vogliono impedire che vengano inoltrate le conferme di lettura dei messaggi.

    Con Postfix questo blocco si attua attraverso la funzione header_checks. Nel file main.cf si specifica qualcosa tipo

    header_checks = regexp:/etc/postfix/header_checks

    La distribuzione standard di Postfix contiene un file header_checks senza direttive ma con alcune istruzioni sommarie nei commenti.

    Tenendo presente che le conferme di recapito hanno generalmente tra gli header la direttiva MIME che indica che il contenuto è di tipo Multipart/Report (RFC6522), è sufficiente aggiungere una riga di questo tipo a /etc/postfix/header_checks

    /^Content-type: Multipart\/report/   DISCARD

    Il file va quindi compilato con

    postmap /etc/postfix/header_checks

    e alla fine si ricarica Postfix per attivare la configurazione.

  • Postfix: snellire la coda

    Chi gestisce degli MTA ha ben presente il problema dello spam.

    Tra gli effetti collaterali di questo fenomeno ci sono elle code di mail che si riempiono di messaggi inutili. Questo avviene secondo uno scenario tipico: lo spammer invia un messaggio con un mittente farlocco ad un utente che non esiste; il nostro MTA genera diligentemente un NDR e tenta di recapitarlo al presunto mittente del messaggio, ma l’MTA di destinazione rifiuta la connessione, non è raggiungibile o il recapito dà un errore temporaneo (4xx). Risultato: rimangono in coda per dei giorni dei messaggi di nessuna utilità che non fanno altro che sprecare (pochissima) banda e falsare un dato che potrebbe essere utile come sintomo di problemi (il numero dei messaggi non recapitati in coda).

    Questo è un tipico esempio dello scenario descritto sopra:

    $ mailq
----Queue ID----- --Size-- ---Arrival Time---- --Sender/Recipient------
3Vgspm0WfDz30Dy       3152 Mon Apr 30 06:14:56 MAILER-DAEMON
   (connect to h1784190.stratoserver.net[85.214.66.15]:25: Connection refused)
                                               root@h1784190.stratoserver.net

    Si tratta, quindi, di togliere di mezzo i messaggi in coda provenienti da MAILER-DAEMON, a questo scopo basta eseguire questo comando:

    mailq | grep MAILER-DAEMON | awk '{print substr($1,1,16)}' | postsuper -d -

    La dimensione dell’ID è quella di Postfix >= 2.9 con enable_long_queue_ids abilitato. Viene considerato un carattere in più per fare in modo di non cancellare messaggi attivi (‘*’ dopo l’ID) o in hold (‘!’ dopo l’ID).

  • Postfix: bloccare le mailing list hackerate

    Capita ogni tanto di dover bloccare un flusso cospicuo di mail in arrivo da un indirizzo o una mailing list hackerata o che rifiuta il comando di disiscrizione e di doverlo fare adesso.

    I filtri applicati ai client possono essere efficaci, ma non comunicano al mittente la nostra intenzione di non voler ricevere più i suoi messaggi. Nel caso di un list server, inoltre, la raffica di delivery failure dovrebbe provocare la rimozione amministrativa dell’account.

    (altro…)