Authentification SMTP avec Postfix

La configuration présentée peut être mise en place dans presque toutes les distributions GNU/Linux. Néanmoins je me concentrerai plutôt sur une utilisation sous Debian « Etch » avec Postfix. Nous utiliserons également des fonctions de cryptage, donc vous devrez avoir OpenSSL et un certificat adéquat sous la main. L'article « Migrating a Mail Server to Postfix/Cyrus/OpenLDAP » du n°124 de la Gazette vous montre comment préparer Postfix pour l'utilisation du cryptage. Votre installation de Postfix devra donc supporter TLS (« Transport Layer Security », protocole de sécurisation des échanges). Sous Debian, vous pouvez activer TLS en installant le paquet postfix-tls.

Quand on aborde la messagerie électronique, on parle de deux composantes distinctes :

J'utilise mutt comme MUA. L'avantage paradoxal d'utiliser mutt est qu'il transmet les courriers à envoyer à un MTA sur la machine locale.

Nous aurons besoin d'un source pour l'information d'authentification. Le moyen le plus simple est d'utiliser l'environnement SASL (« Simple Authentication and Security Layer »), qui nous permet d'utiliser des sources variés via un unique mécanisme. Les paquets sasl2-bin et libsasl2-modules sont requis pour cela. sasl2-bin contient les utilitaires permettant de gérer et d'interroger la base de données des utilisateurs et les mots de passe et est seulement utile au MTA qui utilise l'authentification SMTP. libsasl2-modules est nécessaire des deux côtés. Certains MUA intègrent déjà le support de l'authentification SASL.

Postfix utilise le démon d'authentification SASL saslauthd pour décider si l'authentification est correcte ou non. La demande est faite via le slot Unix (« socket ») de saslauthd, ordinairement présent dans /var/run/saslauthd/mux. C'est problématique puisque Postfix fonctionne dans son propre environnement racine (« chroot »), /var/spool/postfix/, et ne peut pas accéder au slot. Vous avez donc maintenant deux choix possibles, soit abandonner l'éxécution « chroot » de Postfix, soit déplacer le socket de saslauthd ailleurs. Heureusement, cette dernière option est facile à réaliser en éditant le fichier /etc/default/saslauthd :

# Cela doit être décommenté avant que saslauthd soit lancé automatiquement
START=yes

# Vous devez indiquer quels mécanismes d'authentification vous souhaitez employer.
# "pam" est indiqué par défaut pour le support PAM support, mais il peut aussi inclure 
# "shadow" ou "sasldb", comme ceci:
# MECHANISMS="pam shadow"

MECHANISMS="sasldb"
PARAMS="-m /var/spool/postfix/var/run/saslauthd"

Nous avons changé MECHANISMS pour utiliser la base de données SASL (nous ne voulons pas utiliser de comptes systèmes pour l'authentification SMTP) et nous avons déplacé le socket de saslauthd dans l'environnement « chroot » de Postfix en utilisant l'option -m. Nous devons encore vérifier que le chemin du slot existe :

antigone:~# mkdir -p /var/spool/postfix/var/run/saslauthd

Nous pouvons maintenant nous concentrer sur la configuration de Postfix. Doivent être précisées l'utilisation de l'authentification SASL et les options à accepter. Nous créons d'abord un répertoire et un fichier contenant les options :

antigone:~# mkdir /etc/postfix/sasl/
antigone:~# cat > /etc/postfix/sasl/smtpd.conf
pwcheck_method: saslauthd
auxprop_plugin: sasldb
saslauthd_path: /var/run/saslauthd/mux
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5
^D
antigone:~# 

smtpd.conf configure Postfix pour qu'il interroge la base utilisateurs de saslauthd pour obtenir le chemin du slot et les options d'authentification autorisées. PLAIN et LOGIN sont de simples méthodes d'authentification par texte en clair (non crypté). Laissez-les au cas où votre MTA ne supporte pas le cryptage. LOGIN n'est plus d'actualité, vous n'en aurez pas l'utilité ; je le mentionne juste à titre d'exemple. CRAM-MD5 et DIGEST-MD5 sont basées respectivement sur l'échange d'informations (« challenge-response ») et le condensé (« digest »). La plupart des clients MUA modernes les supportent, et il est bon de les autoriser dans cette configuration.

La dernière chose que vous devez faire est d'ajouter les directives pour l'authentification dans le fichier principal de configuration de Postfix /etc/postfix/main.cf :

smtpd_sasl_auth_enable      = yes
smtpd_sasl_security_options = noanonymous,noplaintext
smtpd_sasl_application_name = smtpd
smtpd_sasl_local_domain     = $mydomain
broken_sasl_auth_clients    = no

La première ligne active l'authentification SASL. Les options de sécurité définissent ce que l'on doit accepter. Il est très important de mentionner noanonymous, sinon l'authentification permet de relayer n'importe quel courriel entrant, ce qui ne correspond pas à ce que vous et moi souhaitons ! Faites attention, contrôlez que noanonymous est bien présent ! smtpd_sasl_application_name renseigne Postfix sur le nom à utiliser lors de l'initialisation du serveur SASL. Cela correspond à notre fichier smtpd.conf, qui contient les options que nous souhaitons utiliser. Le domaine local SASL (smtpd_sasl_local_domain) spécifie le domaine à utiliser lors de l'authentification. Chaque utilisateur a un nom, un domaine et un mot de passe. Ordinairement, le domaine correspond à celui dont votre serveur est membre. La dernière option correspond aux besoins spécifiques de certains MUA. Positionnez cette option à yes si Microsoft Outlook Express Version 4 et Microsoft Exchange server Version 5.0 utilisent votre serveur Postfix comme relai authentifié de messagerie. Sinon il est prudent de mettre no.

Il nous reste encore à préciser à Postfix que les clients authentifiés sont acceptables. Vous pouvez configurer cela avec la directive smtpd_recipient_restrictions :

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unlisted_recipient,
    check_recipient_access hash:/etc/postfix/rcpt_blacklist,
    check_helo_access hash:/etc/postfix/helo,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_rbl_client realtimeblacklist.example.net,
    check_policy_service inet:127.0.0.1:60000,
    permit

Nous avons ajouté un droit permit_sasl_authenticated avant les contrôles des listes noire et grise. Assurez-vous que vous acceptez les connections authentifiées dés que possible, mais n'omettez pas les contrôles importants pour le cas où quelque chose se passe mal au niveau du MUA. Les fichiers rcpt_blacklist et helo sont les fichiers personnalisés contenant les adresses en liste noire et les noms indésirables échangés lors du dialogue de connection HELO/EHLO. Vous pouvez les ignorer si vous ne connaissez pas les données associées. Même chose pour la liste noire en temps réel (realtimeblacklist). Elle n'est pas obligatoire.

Nous avons presque terminé. Il nous manque un compte utilisateur avec nom et mot de passe. Vous pouvez ajouter des utilisateurs avec la commande saslpasswd2.

antigone:~# saslpasswd2 -u votre_domaine nom_utilisateur

Cet outil vous demande deux fois le mot de passe. Maintenant tout est prêt. Rechargez ou redémarrez saslauthd et Postfix. Assurez-vous que le slot Unix a été créé dans l'environnement « chroot » de Postfix. Contrôlez avec telnet la bannière d'authentification SMTP.

lynx@agamemnon:~ $ telnet antigone.luchs.at 25
Trying 127.0.0.1...
Connected to antigone.luchs.at.
Escape character is '^]'.
220 antigone.luchs.at ESMTP ready
EHLO client.example.net
250-antigone.luchs.at
250-PIPELINING
250-SIZE 10380902
250-ETRN
250-STARTTLS
250-AUTH DIGEST-MD5 CRAM-MD5
250 8BITMIME
QUIT
221 Bye
Connection closed by foreign host.
lynx@agamemnon:~ $ 

Si tout marche bien, vous devez voir la chaîne 250-AUTH DIGEST-MD5 CRAM-MD5 après la commande HELO/EHLO.

Puisque j'utilise mutt, celui-ci gère les échanges SMTP via mon serveur Postfix local. Ce logiciel ne connait pas l'authentification SMTP pour l'instant mais nous devons ajouter deux options supplémentaires dans le fichier main.cf :

smtp_sasl_auth_enable   = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

La première directive active l'authentification SMTP dans le module client SMTP de Postfix. La seconde précise quel nom d'utilisateur et quel mot de passe utiliser avec chaque serveur. Un exemple de fichier sasl_passwd ressemble à ceci :

smtp.example.net        username:seckrit
192.168.1.1             username2:geheim

N'oubliez pas de créer le condensé (« hash ») de ce fichier en utilisant la commande postmap /etc/postfix/sasl_passwd. Maintenant faites correspondre votre variable relayhost avec l'un des serveurs listés dans sasl_passwd et rechargez la configuration de Postfix. Le relai de courrier doit maintenant utiliser l'authentification SMTP. Si la connection échoue, contrôlez la présence du paquet libsasl2-modules. Sans lui, Postfix va essayer d'utiliser l'authentification, mais va échouer car aucune méthode d'authentification ne sera disponible.