Configurer l'envoi de mail avec une identification SMTP.

Il est important de comprendre ce que signifie le « relaying » et pourquoi les « open relays » sont un gros problème sur Internet. En général Postfix n'accepte un mail que s'il correspond à un des critères suivants :

• L'adresse du destinataire correspond à un utilisateur de votre serveur de courrier
  
• l'expéditeur se trouve dans votre réseau local (défini par l'option de configuration "mynetworks")
  
• l'expéditeur est authentifié (SMTP supporte l'authentification par nom d'utilisateur et mot de passe).
  

Pour des raisons de sécurité les autres mails ne doivent pas être acceptés :

S'il en était autrement un spammeur pourrait utiliser abusivement votre système pour envoyer des millions d'emails non sollicités. Cela saturerait votre bande passante, causerait des désagréments à de nombreuses personnes et conduirait votre serveur à être rapidement « blacklisté ». Un tel relais qui accepte des courriers sans contrôle est appelé un « open relay » (relais ouvert). Heureusement avec Postfix il est difficile de devenir un relais ouvert. Configurer le droit de smtpd_recipient_restrictions (comme expliqué ci-dessus) est très important.

Généralement vous pouvez définir les réseaux qui sont autorisés à être relayés par votre serveur de mail en configurant les paramètres de mynetworks dans votre fichier main.cf. Habituellement vous configurez votre réseau local de telle façon que les utilisateurs n'aient pas besoin de s'authentifier :

 $> postconf -e mynetworks=192.168.50.0/24 

Mais il existe un cas, dans la « vraie vie », où pouvoir relayer de l'extérieur de votre réseau est important. Imaginez que vous ayez un utilisateur qui n'est actuellement pas connecté à votre réseau, mais qui veut envoyer un courrier sur Internet en utilisant votre serveur de mail. Selon les règles ci-dessus l'utilisateur ne pourra pas le faire parce qu'il n'est pas sur votre réseau, et qu'il n'envoie pas non plus un mail sur un des domaines gérés par votre serveur. Il faut que vous trouviez un moyen de faire reconnaître votre utilisateur distant par votre serveur de mail. L'utilisateur devra envoyer son nom d'utilisateur et son mot de passe, pour que vous sachiez que le relais est autorisé. C'est là l'utilité de l'authentification SMTP. Et tout client de mail décent possède cette fonctionnalité de manière native.

L'authentification avec Postfix a toujours été source de soucis. Elle était réalisée via la bibliothèque SASL (Simple Authentication and Security Layer, soit "couche d'authentification simple et de sécurité") qui faisait partie du serveur mail Cyrus. C'était presque impossible à débugger et envoyait des messages d'erreur en charabia et trompeurs. Heureusement avec Postfix 2.3 il est possible de faire en sorte que Postfix demande au serveur Dovecot de vérifier les noms d'utilisateur et les mots de passe. Et comme vous avez déjà configuré Dovecot cela va être très facile. Postfix a juste besoin de quelques configurations supplémentaires :

$> postconf -e smtpd_sasl_type=dovecot
$> postconf -e smtpd_sasl_path=private/auth
$> postconf -e smtpd_sasl_auth_enable=yes
$> postconf -e smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination

smtpd_sasl_auth_enable autorise l'authentification SMTP. Et smtpd_recipient_restrictions définit des règles qui sont vérifiées après que l'utilisateur distant a envoyé la ligne RCPT TO: lors du dialogue SMTP. Dans ce cas le relay est autorisé si :

• permit_mynetworks : L'utilisateur est sur le réseau local (mynetworks) ou bien si
• permit_sasl_authenticated : l'utilisateur est authentifié ou bien si
• reject_unauth_destination : le mail est destiné à un utilisateur d'un domaine qui est local ou un domaine vrituel configuré sur le système (mydestination, virtual_alias_domains ou virtual_mailbox_domains).

Il existe d'autres restrictions (smtpd_client_restrictions, smtpd_helo_restrictions, smtpd_sender_restrictions) qui sont vérifiées suivant les différentes étapes du dialogue du protocole SMTP (IP de connexion, commande HELO/EHLO, commande MAIL FROM) mais pour l'instant vous devriez mettre toutes les restrictions dans la directive smtpd_recipient_restrictions.

Essayons de nous identifier pendant une session SMTP

$> telnet localhost smtp

Le serveur va nous laisser entrer :

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailtest ESMTP Postfix (Debian/GNU)

Envoyez la commande bonjour :

ehlo example.com

Postfix va présenter une liste de fonctionnalités utilisables pendant le dialogue SMTP :

250-mailtest
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Envoyons la chaîne d'authentification avec un mot de passe encodé en Base-64 :

auth plain am9obkBleGFtcGxlLmNvbQBqb2huQGV4YW1wbGUuY29tAHN1bW1lcnN1bg==

Le serveur devrait accepter l'authentification :

235 2.0.0 Authentication successful

Déconnectons nous de Postfix :

quit

Goodbye:
221 2.0.0 Bye

L'authentification fonctionne, bien joué.

Si vous avez utilisé un autre mot de passe que 'summersun' vous devrez vous-même l'encoder en Base-64. Utilisez :

$> perl -MMIME::Base64 -e 
     'print encode_base64("john\@example.com\0john\@example.com\0password")';

Maintenant vous pouvez essayer d'envoyer un mail avec l'authentification activée. Pour que votre réseau local ne soit temporairement plus considéré comme de confiance vous pouvez lancer les commandes :

$> postconf -e mynetworks=
$> postfix reload

Redémarez Postfix (/etc/init.d/postfix restart). Activez votre client de mail et regardez votre fichier mail.log (tail -f /var/log/mail.log) pendant que vous envoyez un mail sur un domaine d'Internet. Je vous recommande d'envoyer un mail à devnull@workaround.org qui est une adresse mail qui va juste passer votre mail à la poubelle. Si tout s'est passé correctement, votre fichier de log devra montrer :

postfix/smtpd[4032]: 1234567890: client=..., sasl_method=PLAIN, sasl_username=john@example.com
postfix/cleanup[4040]: 2EAE8379CB: message-id=<...>
postfix/qmgr[3963]: 1234567890: from=

Autrement, en cas d'erreur, votre fichier de log pourrait ressembler à ceci :

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]

N'oubliez pas de rétablir votre réseau dans la directive mynetworks :

$> postconf -e mynetworks=192.168.50.0/24
$> postfix reload

Il est possible que votre programme de courrier vous ait averti de ce que le serveur utilisait un certificat SSL qui n'était pas de confiance. Quand vous avez installé Postfix, Debian a créé pour vous automatiquement un certificat SSL auto-signé. Le certificat par défaut est suffisant pour les tests, mais comme vous l'avez fait pour Dovecot, vous pouvez créer un certificat SSL personnalisé. Le certificat par défaut est stocké dans /etc/ssl/certs/ssl-cert-snakeoil.pem et la clé privée par défaut dans /etc/ssl/private/ssl-cert-snakeoil.key. Cette commande va créer un nouveau certificat avec sa paire de clés :

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

Même procédure qu'au dessus quand vous avez créé votre certificat pour Dovecot. Souvenez-vous seulement de configurer le "Common Name" avec le nom de domaine pleinement qualifié. Vous pourriez tout aussi bien utiliser le même certificat que celui créé pour Dovecot si le nom de serveur est le même. Dans ce cas utilisez simplement les fichiers /etc/ssl/certs/dovecot.pem et /etc/ssl/private/dovecot.pem dans les commandes plus bas.

N'oubliez pas de fixer les permissions sur la clé privée pour que des personnes non autorisées ne puissent la lire :

$> chmod o= /etc/ssl/private/postfix.pem

Il vous faut indiquer à Postfix où trouver votre certificat et la clé privée :

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

Quand vous utiliserez de nouveau Postfix comme relais vous n'aurez plus d'alerte de certificat.

Par défaut Postfix autorise que les données d'identification SMTP soient envoyées en text simple. Il est préférable de n'accepter que des transmissions chiffrées des identifiants en configurant ces paramètres :

$> postconf -e smtpd_use_tls=yes
$> postconf -e smtpd_tls_auth_only=no

Le rôle de ces paramètres est d'offrir (pas d'exiger) l'utilisation du chiffrement pour l'authentification SASL de telle manière que si vous utilisez les méthodes PLAIN ou LOGIN SASL vos mots de passe ne soient pas transmis en clair. Quand le client s'identifie sur le serveur, la commande AUTH n'est pas proposée par le serveur. Si le client lance la commande STARTTLS et réussit à négocier la connexion TLS, le client lance la commande EHLO une seconde fois et cette fois le serveur propose la commande AUTH. Ceci ne requière aucune sorte de chiffrement de la part des clients qui n'ont pas besoin d'authentification (soit les serveurs qui se connectent pour envoyer des mails à des domaines dont votre serveur est la destination finale, par opposition à vos utilisateurs finaux qui tentent de relayer un mail, via votre serveur, vers un domaine externe).

Si vous désirez réellement empêcher les connexions SMTP non chiffrées (Je fais cela sur les ports 587 et 465), vous devrez utilser soit smtpd_tls_security_level = encrypt (pour STARTTLS, généralement sur le port 587) ou smtpd_tls_wrappermode = yes (pour le chiffrement SSL depuis la première connexion, généralement sur le port 465). Vous pouvez aussi configurer smtpd_tls_security_level = may de telle manière que le chiffrement TLS soit offerte sans que cela soit obligatoire (ceci est également appelé opportunistic TLS).

Une fois que cela est fait vous devriez tester si votre serveur de mail est configuré de manière sécurisée pour éviter des tentatives de relais illégales. Dans un shell root tapez :

$> telnet relay-test.mail-abuse.org

Cette commande contacte un service très bien fait sur Internet qui tente de faire relayer des mails à votre serveur. Laissez lui un moment pour qu'il vérifie votre serveur. Si à la fin vous obtenez un message du type System appeared to reject relay attempts c'est que tout va bien.