Envoyer des mails depuis une adresse Picasoft

SASL est un ensemble de normes permettant de s’authentifier, la plus connue étant plain : on envoie un nom d’utilisateur et un mot de passe au serveur.

Dans cette page, nous allons détailler comment Postfix vérifie si des noms d’utilisateur et des mots de passe sont corrects.

Postfix peut avoir plusieurs sources, c’est-à-dire des bases de donnée permettant d’obtenir une liste d’utilisateurs et de vérifier leurs mots de passe. Dans l’infra Picasoft, nous utilisons des binds LDAP. On peut faire des requêtes au serveur pour vérifier si des utilisateurs existent, lire leurs attributs, ou encore comparer des hash de mot de passe.

Le remplissage des fichiers de config est automatisé avec les dockerfiles, mais il peut être intéressant de les inspecter à la main. On détaille ici les paramètres importants pour saslauthd.

Sous debian, le fichier de config saslauthd pour postfix est dans

/etc/postfix/sasl/smtpd.conf

On indique dans le main de Postfix un lien vers ce fichier de config de Cyrus:

#/etc/postfix/main.cf:
smtpd_sasl_path = smtpd

Il est important que smtpd porte le même nom que le fichier de config Cyrus (sans le .conf).

Ce démon crée un socket UNIX et attend qu’on lui demande de valider des authentifications. La config par défaut de saslauthd veut que ce démon soit dans :

/var/run/saslauthd

Cependant, Postfix est chrooted pour des raisons de sécurité (il n’a accès qu’à une partie de l’arborescence du système de fichiers). Par conséquent, il ne peut accéder à /var/run. Debian recommande de créer des processus saslauthd séparés et spécifiques (nous en créons donc un pour postfix). Pour plus de détails, voir cette page du wiki Debian. Il y a certaines manips à réaliser pour que Postfix puisse accéder au socket de saslauthd, notamment mettre l’utilisateur postfix dans le groupe sasl. Le socket de saslauthd-post sera finalement dans

/var/spool/postfix/var/run/saslauthd

, à l’intérieur du répertoire de travail de Postfix.

Pour donner à Postfix l’ordre de contacter saslauthd en tant que démon de vérification de mot de passe, on modifie smtpd.conf (sous debian, dans /etc/postfix/sasl/smtpd.conf, à créer sur une install fraîche):

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

. On voit que le login est transmis en PLAIN, c’est dû au protocole SMTP. Il faut rajouter une couche de chiffrement pour que ce soit sécurisé. Sur une prod, il faut interdire l’auth PLAIN sur du SMTP non sécurisé. (En revanche, une connexion sans authentification peut se faire en SMTP non sécurisé (typiquement pour de la réception de mails du reste du monde)).

On crée un processus saslauthd spécifique qui ne sera accessible qu’à Postfix. Pour cela, on copie le processus par défaut et on l’édite:

~# cp /etc/default/saslauthd /etc/default/saslauthd-postfix

START=yes
DESC="SASL Auth. Daemon for Postfix"
NAME="saslauthd-postf"      # max. 15 char.
# Option -m sets working dir for saslauthd (contains socket)
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"        # postfix/smtp in chroot()

(repris du Wiki debian). Il faut faire d’autres modifications en fonction de la source d’information qui permettra de valider les logins entrés. On va couvrir 3 cas: PAM (framework d’authentification sous UNIX), LDAP (service d’annuaire en TCP), IMAP (service de boîte mail en TCP).

Rien de plus simple, la config par défaut de saslauthd sous debian le fait. Il suffit d’un:

MECHANISMS="pam"

Éventuellement, on peut créer un fragment PAM, qui portera le nom de smtp. Ceci est hors sujet, voir la doc de PAM.

MECHANISMS="ldap"

Il faut également modifier /etc/saslauthd.conf (à créer sur une install fraîche):

ldap_servers: <ldap uri>
ldap_search_base: <search base>
ldap_filter: <filter>
etc...

Pour la configuration du bind LDAP, voir plus bas.

MECHANISMS="rimap"
MECH_OPTIONS="nom-hôte-serveur-imap/port"

Le nom d’hôte peut aussi être une adresse IPv4. Le /port peut être omis. saslauthd tentera de faire un AUTH IMAP standard, et dès qu’il a une réponse il se déconnecte.

Si on choisit la solution LDAP, il faut configurer des binds au niveau du serveur. Ces binds sont préalables au challenge SASL: d’abord on vérifie si un utilisateur existe, ensuite on vérifie son mot de passe. Cette configuration se fait dans /etc/saslauthd.conf:

ldap_servers: ldap://ldap.test.picasoft.net:389
ldap_bind_dn: cn=nss,dc=picasoft,dc=net
ldap_bind_pw: rdonly
ldap_search_base: dc=picasoft,dc=net
ldap_filter: cn=%u

• ldap_servers : On peut en mettre plusieurs, séparés par des virgules. Le SSL est supporté.
• ldap_bind_dn et ldap_bind_pw : Configure les modalités de la connexion entre saslauthd et le serveur ldap. Ici, on ne peut faire que du readonly (voir la doc LDAP et demander à l’adminsys de picasoft pour plus de détails).
• ldap_search_base : permet de spécifier un étage de l’arborescence à partir duquel on va commencer à fouiller pour voir si l’utilisateur demandé existe et vérifie les critères demandés.
• ldap_filter : Permet de mettre certains critères, aussi bien sur l’utilisateur que sur les groupes auxquels il appartient.

Si LDAPS est utilisé, on veillera à ce :

• Le certificat soit signé par une autorité de certification installée sur le système (pour Let’s Encrypt, installer ca-certificates suffit)
• Ou que ldap_tls_cacert_file point vers le certificat du serveur LDAP.

Ceci parce que saslauthd, le démon qui se charge de l’authentification, impose que le certificat soit vérifié.