Autrefois, tout était simple, tout serveur
SMTP relayait le courrier de n'importe qui vers n'importe
qui. Cette possibilité ayant été largement abusée par les spammeurs, les serveurs bien gérés n'acceptent
désormais de relayer que pour leur réseau local. Mais cela laisse
ouvert le problème des utilisateurs distants. Une des solutions est
d'authentifier leurs connexions avec un mot de passe.
Le fait obligation aux serveurs SMTP
d'authentifier les soumissions de courrier (section
4.3. Require Authentication). Il existe plusieurs
méthodes pour cela :
TLS, qui nécessite un
certificat sur chaque client.SASL qui va utiliser un mot de passe qui
peut être transmis en clair (il faudra alors chiffrer la
communication, par exemple en utilisant TLS,
cette fois pour la confidentialité) ou bien utilisé dans un système de
défi/réponse.
Le choix va dépendre de :
Si vous avez envie de gérer une PKI pour
authentifier avec TLS.Du type de clients humains que vous avez (mettre en place une
solution de sécurité va vous faire passer du temps au téléphone, avec
les utilisateurs).Des logiciels qu'utilisent vos clients.Des bases de données d'utilisateurs que vous avez (si vous
comptez les réutiliser avec SASL).
Par exemple, je détaille ici la configuration du
MTAPostfix sur une
Debian. Un bon HOWTO est Postfix/SASL/TLS HowTo for Debian. (Pour TLS seul, un autre article décrit sa configuration pour Postfix.)
D'abord, je sépare le service de réception normal du courrier (sur
le port 25) et le service de soumission de
courrier par les utilisateurs authentifiés (cette séparation est dans
la logique du ). Dans
master.cf, je mets :
smtp inet n - - - - smtpd
# smtpd_sasl_authenticated_header appeared only in Postfix 2.3
submission inet n - - - - smtpd -o smtpd_etrn_restrictions=reject -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_authenticated_header=yes
Ensuite, je dis à Postfix d'autoriser le relais de courrier pour
les utilisateurs authentifiés en SASL. Dans
main.cf, je mets :
smtpd_recipient_restrictions = permit_sasl_authenticated, ...
# SASL options: only secure methods, without plain text
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_local_domain = $myhostname
Avant de recharger Postfix (postfix reload),
j'installe les logiciels nécessaires :
% sudo aptitude install postfix-tls libsasl2-modules sasl2-bin
Il reste à indiquer à SASL où trouver la base des
utilisateurs. Dans sasl/smtpd.conf :
pwcheck_method: auxprop
mech_list: digest-md5 cram-md5
lui dit d'utiliser sa propre base (/etc/sasldb2)
et de ne publier que les méthodes d'authentification à base de
défi/réponse. On remplit ensuite la base :
sudo saslpasswd2 -u mail.bortzmeyer.org -c stephane
sudo sasldblistusers2 # Pour vérifier
Faites attention au domaine donné par l'option
-u : il doit coïncider avec la variable
myhostname de Postfix. Sinon, on obtiendra des messages du genre no secret in database.
Attention également au chroot : comme le
paquetageDebian de
Postfix utilise chroot, il faudra copier la
base des utilisateurs dans la chroot (sudo cp /etc/sasldb2
/var/spool/postfix/etc, cela n'est pas fait
automatiquement (sauf par cron, de temps en temps), on risque donc des No such file or directory très déroutants dans le journal de Postfix).
On peut ensuite tester avec un client SASL. Cela peut être un
Postfix mais je trouve msmtp plus simple pour des
tests. Avec cette configuration :
account bortzmeyer
host mail.bortzmeyer.org
port 587
from stephane@bortzmeyer.org
auth on
user stephane
password VRAIMENTSECRET
ma machine se connecte au port de soumission et s'authentifie. Postfix
logue :
Jul 25 10:57:14 ariane postfix/submission[31542]: 25DFE240814: client=batilda.nic.fr[192.134.4.69], sasl_method=DIGEST-MD5, sasl_username=stephane@mail.bortzmeyer.org
Si on veut utiliser mutt, il peut parler directement à un tel serveur
SMTP, en mettant dans le .muttrc :
set smtp_url="smtp://stephane@mail.bortzmeyer.org:587/
Avec Thunderbird, cela serait Secure
Authentication: yes et Connection Security: STARTTLS.
Autre façon de tester, depuis un programme
Python, comme expliqué en .
Pour terminer de mettre en œuvre complètement le , il faudrait aussi, idéalement :
Ne pas toucher aux en-têtes du message sur le port 25 mais
seulement sur le 587, le port de soumission. Ce n'est pas
évident avec Postfix (voir aussi ).Loguer différemment les accès aux deux ports. Il n'existe
malheureusement pas de moyen propre pour cela.
Merci beaucoup à Noel Jones pour son aide et ses explications.
Comme conclusion pessimiste, notons que, dans la réalité de
l'Internet, il y aura toujours un logiciel bogué pour mettre en cause
les plus belles configurations. Par exemple, Eudora sur MS-Windows a bien une option "Use
port 587" mais, qu'elle soit cochée ou pas, Eudora utilise toujours le
port 25 :-(. Heureusement, Thunderbird n'a pas ce problème.