Postfix Open relays server per ISP

Attenzione. Questa guida è stata proposta per la cancellazione in quanto contenente materiale potenzialmente dannoso, inutile o fuorviante. Motivo: Abbandonata, non completa, e la parte trattata è duplicato di Internet_Service_Provider_con_Debian

Internet Service Provider con Debian Wheezy

Prerequisiti Predisposizione ambiente e prerequisiti Server email Introduzione Postfix con Mysql come backend Postfix per l'invio delle email Dovecot Interfaccia di amministrazione remota del dominio e delle email/alias Interfaccia Webmail SPAM Sconfiggere lo SPAM Integrazione con altro software

Open relays server

Normalmente Postfix accetta una email solo se è verificato uno di questi criteri:

• il destinatario è un utente del mail server
• il mittente sta inviando la mail dal nostro local network, definito dalla direttiva mynetworks di Postfix
• il mittente si è autenticato sul server

Per motivi di sicurezza dovrebbe essere sempre impedito l'invio di email da parte di utenti che non si sono autenticati sul server e che provengono da reti sconosciute. In caso contrario uno spammer potrebbe facilmente sfruttare il nostro server per inviare milioni di email spam: questo porterebbe ad uno spreco di banda e, soprattutto, all'inserimento dell'IP del nostro server in tutte le blacklist del mondo, bloccando anche la posta dei nostri utenti autorizzati. Un server che si comporta in questo modo, permettendo l'invio di mail a tutti, è chiamato open relay.

Configurazione di Postfix per l'autorizzazione SMTP

Impostare la direttiva smtpd_recipient_restrictions correttamente è importantissimo. Normalmente è possibile definire le reti abilitate al relay sul nostro mail server attraverso la direttiva mynetworks contenuta nel file main.cf:

# postconf -e mynetworks=192.168.50.0/24

Purtroppo questa direttiva non è applicabile nel caso di un server che voglia agire da ISP, permettendo la spedizione e la ricezione delle email anche agli utenti che si connettono dal'esterno della nostra rete.
La soluzione è rendere gli utenti fidati attraverso la richiesta di una username e di una password, in mancanza dei quali il relaying sarà proibito dal server.
Questo è il momento in cui entra in gioco l'autenticazione SMTP.
Dalla versione 2.3 di Postfix è possibile fare in modo che sia Postfix stesso a richiedere a Dovecot la verifica del nome utente e della password. E siccome abbiamo già configurato Dovecot, avremo bisogno solo di alcune configurazioni extra in Postfix:

postconf -e smtpd_sasl_type=dovecot
postconf -e smtpd_sasl_path=private/auth
postconf -e smtpd_sasl_auth_enable=yes
postconf -e smtpd_tls_security_level=may
postconf -e smtpd_tls_auth_only=yes
postconf -e smtpd_tls_cert_file=/etc/ssl/certs/mailserver.pem
postconf -e smtpd_tls_key_file=/etc/ssl/private/mailserver.pem
postconf -e smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination

• smtpd_sasl_auth_enable abilita l'autenticazione SMTP
• smtpd_recipient_restrictions definisce le regole che sono controllate per permettere il relay. Nel nostro caso il relay è permesso se:
  • permit_mynetworks: l'utente proviene dalla nostra rete, oppure
  • permit_sasl_authenticated: l'utente si è autenticato, oppure
  • reject_unauth_destination: la mail è destinata a un utente di un nostro dominio virtuale

NOTA: la direttiva postconf -e smtpd_tls_auth_only=yes è da utilizzarsi solo se vogliamo che i nostri utenti siano costretti a utilizzare SSL per scaricare e inviare la loro posta.

Riavviamo infine Postfix:

# /etc/init.d/postfix restart

Test della configurazione

Proviamo la nostra configurazione con una connessione telnet sulla porta SMTP:

$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailtest ESMTP Postfix (Debian/GNU)
ehlo example.com
250-mailtest
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
auth plain am9obkBleGFtcGxlLmNvbQBqb2huQGV4YW1wbGUuY29tAHN1bW1lcnN1bg==
235 2.0.0 Authentication successful
quit
221 2.0.0 Bye

L'autenticazione ha funzionato.

Nota Se abbiamo impostato la password di john a qualcosa di diverso da summersun dobbiamo ricavarne l'hash Base64 in questo modo: $> perl -MMIME::Base64 -e \ 'print encode_base64("john\@example.com\0john\@example.com\0password")';

Ora possiamo testare l'invio di una mail attraverso il nostro client di posta. Per verificare il corretto funzionamento controlliamo i file di log:

# tail -f /var/log/mail.log

Dovremmo trovare qualcosa di simile:

postfix/smtpd[4032]: 1234567890: client=..., sasl_method=PLAIN, sasl_username=john@example.com
postfix/cleanup[4040]: 2EAE8379CB: message-id=<...>
postfix/qmgr[3963]: 1234567890: from=<john@example.com>, size=830, nrcpt=1 (queue active)
postfix/smtpd[4032]: disconnect from ...
postfix/smtp[4041]: 1234567890: to=<devnull@workaround.org>,
    relay=torf.workaround.org[212.12.58.129]:25, delay=6,
    delays=0.09/0.08/5.6/0.23, dsn=2.0.0, status=sent
    (250 OK id=1HsPC3-0008UJ-O5)
postfix/qmgr[3963]: 2EAE8379CB: removed

In caso di errore dovremmo invece vedere qualcosa di simile a questo:

postfix/smtpd[4032]: connect from ...[10.20.30.40]
postfix/smtpd[4032]: warning: ...[10.20.30.40]: SASL PLAIN authentication failed:
postfix/smtpd[4032]: lost connection after AUTH from ...[10.20.30.40]
postfix/smtpd[4032]: disconnect from ...[10.20.30.40]

Configurazione certificato SSL

In fase di installazione Postfix genera automaticamente un certificato SSL, ma potrebbe essere utile crearne uno personalizzato, nella stessa maniera vista in precedenza:

# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/postfix.pem \
    -keyout /etc/ssl/private/postfix.pem

L'impostazione più importante è la definizione del Common Name, dove va inserito il fully-qualified name (FQDN) del mail server.
A generazione avvenuta impostiamo i corretti permessi sul file:

# chmod o= /etc/ssl/private/postfix.pem

e comunichiamo a Postfix di utilizzare il nuovo certificato:

# postconf -e smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem
# postconf -e smtpd_tls_key_file=/etc/ssl/private/postfix.pem

Di default Postfix permette l'invio in chiaro dei dati di autenticazione SMTP, ma possiamo impostare la trasmissione crittata agendo su due parametri:

# postconf -e smtpd_use_tls=yes
# postconf -e smtpd_tls_auth_only=no

In questo modo Postfix offre (ma non richiede obbigatoriamente) la crittazione dei dati di login.
Se vogliamo proibire le connessioni SMTP non crittate, possiamo impostare le direttive smtpd_tls_security_level = encrypt o smtpd_tls_wrappermode = yes. Possiamo anche impostare smtpd_tls_security_level = may (la cosiddetta opportunistic TLS connection).
Una volta terminate le modifiche possiamo testare la corretta configurazione del nostro mail server per quanto riguarda la protezione dai tentativi di relay:

# telnet relay-test.mail-abuse.org

Con questo comando contatteremo un ottimo servizio che cercherà di inviare alcune mail attraverso il nostro server. Lasciamogli qualche minuto e aspettiamo che compaia la dicitura:

System appeared to reject relay attempts

Autenticazione di Postfix su un server SMTP remoto

Se ci fosse la necessità di impostare un relay dal nostro server di posta Postfix verso un server SMTP esterno, è possibile utilizzare questa guida:
Postfix e autenticazione su SMTP remoto

Pulizia degli HEADER per un relay mail

Se il server funziona anche da mail relay (ossia punto di inoltro via SMTP delle email generate dai nostri utenti) è necessario, per non essere marcati come spam, di pulire l'header della mail dai dati dei nostri utenti soprattutto se abbiamo abilitato la funzione DKIM o SPF.

Quindi aggiungiamo in /etc/postfix/main.cf:

header_checks = regexp:/etc/postfix/header_checks

e creiamo il file di pulizia /etc/postfix/header_checks:

/^Received:/    IGNORE
/^X-PHP-Originating-Script:/    IGNORE
/^X-Originating-IP:/    IGNORE
/^X-Mailer:/            IGNORE
#/^Mime-Version:/        IGNORE