Configurar Postfix amb TLS i autenticació

Configurar Postfix per enviar i rebre correu de forma segura no és una cosa que facis una sola vegada. Cada entorn té les seves pròpies restriccions, i amb els canvis constants en polítiques de proveïdors com Gmail o Outlook, coses que funcionaven l’any passat poden canviar enguany. En aquest article cobrirem la configuració de TLS i autenticació en Postfix des d’una perspectiva pràctica, centrada en el que realment convé revisar, ajustar o evitar, basat en configuracions reals i problemes habituals en producció.

Punt de partida: context de l’ entorn

Abans de tocar main.cf, convé tenir clar quin rol ha de jugar el servidor:

1. Ha de rebre correu directament des d’altres servidors? (és a dir, té MX?)
2. Ha d’ enviar correus en nom d’una aplicació? (SMTP relay)
3. És un servidor intermedi que reenvia un upstream amb autenticació?
4. Ha d’ autenticar usuaris (SMTP AUTH) per permetre’ls enviar correu sortint?

No tenir això clar porta a errors com deixar el servidor obert a relays no autoritzats o configurar TLS en mode obligatori on no ho hauria de ser.

Per a aquest article assumeixo un servidor que:

1. Rep correu directament des d’internet.
2. Accepta enviaments sortints autenticats des de clients.
3. Fa servir TLS per xifrar connexions entrants i sortints.

TLS: lo bàsic

Certificats: evita dreceres que deixen de funcionar

El primer és tenir certificats vàlids. Si fas servir Let’s Encrypt, renova automàticament i verifica que Postfix recarregui els certificats després de la renovació. Un dels errors més comuns és renovar els certificats i oblidar-se de recarregar Postfix, amb la qual cosa continua servint els expirats.

Una configuració típica en main.cf:

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.domini.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.domini.com/privkey.pem
smtpd_use_tls = yes
smtpd_tls_security_level = may

may, encrypt o verify?

1. may: accepta TLS si el client l’ofereix. És el més compatible i el que gairebé sempre s’ha de fer servir per smtpd_tls_security_level.
2. encrypt: obliga a TLS. Fes-lo servir només en connexions sortints cap a servidors que saps que el suporten (per exemple, en re-dirigir tot el correu sortint per l’SMTP del teu proveïdor).
3. verify: requereix TLS i a més a més verificació del certificat del servidor remot. No és recomanable tret que tinguis control total sobre ambdós extrems.

Evita caure en el parany d’activar encrypt o verify per “seguretat”, sense saber si els clients o servidors remots ho suporten. Molts correus legítims no es lliurarien.

Cipher suites: menys és més

Postfix es recolza en OpenSSL, així que les polítiques de xifrat venen d’aquí. Postfix modern (3.x en endavant) permet fer servir tls_high_grade sense inventar res:

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high

En sistemes on la política de xifrat és important (banca, salut, etc.), és recomanable fer servir una política de TLS en postfix-tls-policy-table específica i controlada per IP o domini destí. No té sentit forçar TLS per a tothom si pots perdre entregues legítimes.

SMTP AUTH: autenticació de clients per a enviament

Si voleu que els usuaris o les aplicacions facin servir el teu servidor per a enviar correus (per exemple des de Thunderbird o una app web), necessitaràs activar l’autenticació. Per a això Postfix es recolza en SASL.

No facis servir dovecot si no ho necessites

Tot i que molts tutorials recomanen fer servir Dovecot com a backend SASL, si el servidor no entrega correu localment (és a dir, només reenvia), és innecessari. Cyrus SASL funciona bé i és més simple de configurar en aquest cas.

Instal·la libsasl2-modules i edita /etc/postfix/sasl/smtpd.conf:

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

I activa a main.cf:

smtpd_sasl_auth_enable = yes
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

Assegura’t que saslauthd estigui corrent i configurat per a consultar el backend correcte (pam, ldap, shadow, etc.). En molts casos, un PAM simple apuntant al sistema d’usuaris funciona bé, sobretot si fas servir comptes locals amb contrasenyes segures.

Compte amb la combinació STARTTLS + AUTH

Un problema comú és que els clients intenten autenticar-se sense haver negociat TLS. Alguns clients mal configurats (o antics) fan això. Per a protegir contrasenyes en trànsit, bloqueja les autenticacions sense TLS:

smtpd_tls_auth_only = yes

Això força que l’autenticació només passi després d’establir una connexió xifrada.

Seguretat en connexions sortints (outbound SMTP)

En enviar correu des de Postfix a altres servidors, TLS continua sent important, però no és obligatori per norma. Molts servidors (sobretot mal configurats) encara accepten connexions sense TLS.

El dilema: smtp_tls_security_level = may o encrypt

Si poseu encrypt, el correu no es lliura si el servidor remot no ofereix STARTTLS. Voleu això? En producció, la resposta moltes vegades és no.

Fes servir may i activa els logs de TLS per verificar quins servidors accepten connexions xifrades:

smtp_tls_security_level = may
smtp_tls_loglevel = 1

Revisa /var/log/mail.log per a veure línies com:

postfix/smtp[12345]: Verified TLS connection established to mx.exemple.com[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384

Amb aquesta informació podeu decidir si voleu polítiques més estrictes per a determinades destinacions específiques.

Verificació de certificats sortints

Si has d’ enviar correu a través d’un smart host (per exemple, un SMTP del teu ISP o un servei com Sendgrid), aquí sí que té sentit verificar certificats:

relayhost = [smtp.sendgrid.net]:587
smtp_tls_security_level = verify
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Compte: si el relay canvia el certificat i no està signat per una CA coneguda, se’n va en orris l’enviament. Mantingueu la monitorització d’aquests casos.

Autenticació sortint (SMTP com a client)

Quan Postfix reenvia correu (per exemple, perquè el teu ISP bloqueja el port 25), necessites autenticar-te contra un relay.

Afegeix:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous

I a /etc/postfix/sasl_passwd:

[smtp.sendgrid.net]:587 usuari:clau

Després executa:

postmap /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

No oblidis reiniciar Postfix.

Errors comuns:

1. No posar els corxets a relayhost, amb la qual cosa Postfix resol DNS SRV o MX i se salta el port que volies.
2. Posar la ruta del sasl_passwd sense el hash: davant.

Alguns errors comuns

1. Correu en loop perquè el domini local està a mydestination. Això fa que Postfix pensi que ha de lliurar localment quan hauria de reenviar.
2. TLS configurat sense certificats vàlids, amb la qual cosa el client rebutja la connexió per untrusted certificate
3. Permetre AUTH sense TLS, i veure després les contrasenyes en text pla als logs de xarxa.
4. Relay sense autenticació per error a les restriccions de smtpd_recipient_restrictions. Sempre posa permit_sasl_authenticated abans que reject_unauth_destination.
5. Fer servir localhost como a hostname. Alguns clients rebutgen certificats emesos per a un domini si la connexió s’ estableix amb un hostname local.

Què revisar després de configurar

1. Que les connexions TLS s’estan establint (mail.log).
2. Que les autenticacions es registren i funcionen.
3. Que el servidor no permet relay sense autenticació (podeu provar amb swaks).
4. Que el certificat es renova automàticament (si és Let’s Encrypt).
5. Que els correus sortints no reboten per problemes de TLS.

Podeu verificar tot això amb eines com:

swaks --to test@domini.com --from user@domini.com --server mail.domini.com --auth LOGIN --auth-user user --auth-password pass --tls

O per veure si el teu servidor accepta STARTTLS correctament:

openssl s_client -connect mail.domini.com:25 -starttls smtp

Hardening: restriccions que convé aplicar

Hi ha configuracions de seguretat que són fàcils d’aplicar i no solen causar efectes secundaris, i d’altres que semblen bona idea fins que tallen entregues legítimes. Algunes recomanacions que es aplicar a servidors exposats a internet:

smtpd_recipient_restrictions: ordre i claredat

Aquesta línia es torna difícil de llegir ràpid si es va acumulant sense ordre. Recomano mantenir-la neta, ben comentada i sobretot ordenada per prioritat. Exemple funcional:

smtpd_recipient_restrictions =
permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    reject_unauth_destination,
    reject_rbl_client zen.spamhaus.org,
    permit

Explicació:

1. permit_mynetworks i permit_sasl_authenticated primer: són els que volem deixar passar.
2. reject_non_fqdn_* i reject_unknown_* ajuden a tallar spam bàsic.
3. reject_unauth_destination és essencial: evita que d’altres facin servir el teu servidor com a relay obert.
4. Una RBL (com Spamhaus) pot bloquejar connexions des d’IPs ja llistades com a emissors de spam. Fes-la servir amb precaució si no controles l’entorn de xarxa, perquè també pot tallar trànsit legítim.

Consell: no posis reject_rbl_client sense monitoritzar-ho. En entorns empresarials on els usuaris es connecten des d’IPs dinàmiques, és habitual que IPs legítimes acabin llistades.

TLS opcional però registrat

Ja hem esmentat que fer servir smtp[d]_tls_security_level = may és el més compatible. Però val la pena registrar i monitoritzar quan s’estableix TLS i quan no, perquè això et dona visibilitat real de la seguretat en trànsit:

smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1

Si voleu una política més fina (per exemple, forçar TLS només cap a certs dominis), podeu crear una taula amb smtp_tls_policy_maps, cosa que és útil si treballes amb partners específics que exigeixen TLS obligatori:

smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

Contingut típic de /etc/postfix/tls_policy:

example.com encrypt

Compte amb no propagar això sense revisar la compatibilitat.

Diagnòstic: què buscar en els logs

Postfix no sol ser sorollós sense motiu. Si alguna cosa no funciona, gairebé sempre deixa traces útils. El que convé tenir en compte:

Fallades d’ autenticació

Cerca:

SASL authentication failed; server mail.domini.com[127.0.0.1] said: 535 5.7.8 Authentication credentials invalid

O bé:

warning: SASL authentication failure: Password verification failed

Lo típic és un usuari mal escrit, una contrasenya desfasada o que el saslauthd no té accés al backend.

Consell: si estàs fent servir PAM, verifica que /etc/default/saslauthd tingui START=yes i el mecanisme correcte (PAM, shadow, etc.). Moltes vegades no és l’usuari, sinó que el servei no té permisos per consultar les contrasenyes.

Connexions STARTTLS fallides

Cerca línies com:

TLS connection established from unknown[1.2.3.4]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256

O bé errors com:

SSL_accept error from unknown[1.2.3.4]: -1

En aquest últim cas, revisar amb openssl s_client des de fora ajuda a replicar el problema.

Proves reals de lliurament i connectivitat

Més enllà del típic telnet al port 25, convé fer servir eines com swaks, openssl, o fins i tot mutt per a verificar el comportament real.

Exemple de prova completa amb autenticació i STARTTLS:

swaks --to prova@desti.com \
      --from usuari@domini.com \
      --server mail.domini.com \
      --auth LOGIN \
      --auth-user usuari \
      --auth-password clau \
      --tls

Això permet validar:

1. Que el servidor accepta STARTTLS.
2. Que l’ autenticació funciona.
3. Que el correu es lliura o és rebotat correctament.

Si el servidor està darrere d’un firewall o balancejador que talla STARTTLS, això ho revela de seguida.

També podeu fer proves d’entrega des de la línia de comandaments amb sendmail, especialment útil si estàs integrant una app que crida a sendmail o mail():

echo "Asumpte: test
De: test@domini.com
Per a: elteu@correu.com

Cos de la prova" | sendmail -v elteu@correu.com

El flag -v retorna una sortida detallada de la transacció SMTP.

Compatibilitat amb clients

Outlook: el client que sempre demana alguna cosa més

Outlook té el costum de trencar la negociació STARTTLS si el certificat no coincideix exactament amb el nom de servidor configurat. Si poseu “mail. domini.com” a Postfix, però el certificat va ser emès per a “*.domini.com”, és probable que rebutgi la connexió.

També tendeix a fallar si fas servir un certificat autosignat, fins i tot si l’usuari l’accepta manualment. En general, amb Outlook, fes servir certificats públics vàlids o accepta lidiar amb problemes eterns.

Thunderbird: més tolerant, però sensible a smtpd_tls_auth_only

Si un usuari intenta configurar el compte sense STARTTLS i smtpd_tls_auth_only = yes, Thunderbird demana reconfigurar el compte o mostra un error. Convé tenir habilitada la detecció automàtica (autodiscover), però si no, assegura’t de documentar els requeriments: STARTTLS obligatori, port 587, etc.

Verificació de configuració i reputació

Alguns serveis ajuden a comprovar que el que configures està ben vist des de fora:

1. MXToolbox permet comprovar si estàs llistat en alguna RBL i si el teu TLS està visible correctament.
2. checktls.com permet provar si el teu servidor ofereix STARTTLS i com ho veu un client extern.
3. smtp-tester.com permet veure com reacciona el teu servidor a diferents proves d’autenticació, STARTTLS, etc.

També podeu fer servir posttls-finger (inclòs a Postfix) per a verificar com negocia TLS amb un servidor específic:

posttls-dit -c -l gmail.com

Això no només valida si s’accepta TLS, sinó quins ciphers es fan servir i si hi ha verificació de certificats.

Checklist per a un servidor nou

1. Certificats vàlids i automatitzats (Let’s Encrypt + reload).
2. smtpd_tls_auth_only = yes activat per a protegir contrasenyes.
3. smtp_tls_security_level = may, tret dels relay intel·ligents.
4. Autenticació via SASL funcionant, amb proves reals (swaks).
5. Logs activats amb smtp[d]_tls_loglevel = 1.
6. Restriccions ordenades i comentades a main.cf.
7. Relay tancat amb reject_unauth_destination.
8. Monitoratge d’ errors comuns amb fail2ban o similar.
9. Test des de clients reals (Outlook, Thunderbird, app).
10. Documentació mínima per a usuaris/clients si hi ha autenticació.

Això no és una guia per a deixar “el servidor perfecte”, però sí per tenir un servidor que funcioni, que aguanti, que no es torni un colador i que no causi incidències innecessàries per errors previsibles.