Configurer l'envoi de mail avec une identification SMTP.

Le relayage

Avant de plonger dans l'authentification SMTP je veux que vous compreniez ce que le « relayage » (ndt : relay en anglais) signifie exactement. Qand Postfix reçois un mail et doit le transférer à un autre serveur, cette opération es applée « relayage ».

Les mails entrants

Quand quelqu'un envoit un mail via Internet à john@example.org un serveur quelque part sur Internet va envoyer ce courrier à votre serveur de courrier en utilisant SMTP. Postfix va vérifier qu'il est bien responsable de cette adresse mail dans le domaine example.org et accepter le mail. John peut alors utiliser POP3 ou IMAP pour récupérer son mail sur votre serveur.

Mails sortants (sans authentification)

John est quelque part sur Internet et et veut envoyer un mail à lisa@example.com. Comme votre serveur de courrier n'est pas responsable du domaine example.com il devra tranmettre ce courrier au serveur qui en est responsable. Donc votre serveur reçoit le mail de John et le tranfère (relay) ce courrier au serveur responsable de courrier destinés au domaine …@example.com. Cela semble sans danger mais votre serveur de mail va refuser ça :

Pourquoi ? Parce que n'importe qui peut prétendre être John et transformer votre serveur de mail en serveur relais. Si un attaquant (comme un spammeur) réussissait à envoyer des millions de spam depuis votre serveur, alors les autres organisations exploitant des serveurs de courrier sur Internet vous accuseraient vous de spamming. Votre serveur de mail serait ce qu'on appelle un open relay (ndt : qu'on traduit par « relais ouvert »). Ce n'est pas ce que vous voulez car l'adresse IP de votre serveur serait alors inscrite sur les listes noires (ndt : en anglais blacklisted) et vous auriez de sérieux problèmes pour de nouveau envoyer des mails. Donc sans preuve que John soit réellement John votre serveur va rejeter le mail.

Mails sortants (avec authentification)

Alors comment John va-t-il envoyer son mail ? Il doit utiliser SMTP avec authentification (ndt : en anglais authenticated SMTP). Le cas est semblable au cas précédent à la différence près que john va commencer par envoyer son nom d'utilisateur et son mot de passe.

« mynetworks »

En plus de l'authentification SMTP vous pouvez demander à Postfix de toujours relayer les mails pour certaines adresses IP. La varaible mynetworks contient la liste des réseaux IP ou des adresses IP auxquelles vous faites confiance. Généralement vous indiquez ici votre propre réseau local. La raison pour laquelle John doit s'identifier dans l'exemple précédent est qu'il n'envoit pas son mail depuis l'intérieur de votre réseau (généralement).

Activer l'authentification SMTP dans Postfix

L'authentification SMTP avec Postfix a été très pénible dans le passé. Elle se faisait à travers la bibliothèque SASL (Simple Authentication and Security Layer) qui était alors incluse dans le serveur de courrier Cyrus mail. Il était à peu près impossible à débugger et produsait des message d'erreur en charabia qui induisaient souvent en erreur. Heureusement, de nos jours nous pouvons faire en sorte que Postfix utilise le serveur Dovecot pour vérifier les noms d'utilisateur et les mots de passe. Et comme vous avez déjà configuré l'authentifiction par Dovecot c'est maintenant très facile à faire. Postfix n'a besoin que d'une petite configuration complémentaire.

postconf -e smtpd_sasl_type=dovecot
postconf -e smtpd_sasl_path=private/auth
postconf -e smtpd_sasl_auth_enable=yes
postconf -e smtpd_tls_security_level=may
postconf -e smtpd_tls_auth_only=yes
postconf -e smtpd_tls_cert_file=/etc/ssl/certs/mailserver.pem
postconf -e smtpd_tls_key_file=/etc/ssl/private/mailserver.pem
postconf -e smtpd_recipient_restrictions=" \
  permit_mynetworks \
  permit_sasl_authenticated \
  reject_unauth_destination"

smtpd_sasl_auth_enable active l'authentification SMTP en général. et smtpd_recipient_restrictions définit les règles qui seront appliquées après que l'utilisateur distant ait envoyé la ligne RCPT TO: pendant le dialogue SMTP. Dans ce cas le relayage est autorisé si :

• permit_mynetworks : l'utilisateur est dans le réseau local (mynetworks) ou ;
• permit_sasl_authenticated : l'utilisateur est authentifié ou ;
• reject_unauth_destination : le mail est destiné à un utilisateur d'un domaine qui est un domaine local ou un domaine virtuel sur ce système (mydestination ou virtual_alias_domains ou virtual_mailbox_domains).

Il existe d'autres restriction (smtpd_client_restrictions, smtpd_helo_restrictions, smtpd_sender_restrictions) qui réalisent des vérifications à différentes étapes du dialogue SMTP (IP de connexion, commande HELO/EHLO, commande MAIL FROM), mais pour l'instant nous allons mettre toutes nos restrictions dans smtpd_recipient_restrictions.

Activer le chiffrement

la variable smtpd_tls_security_level est mise à may pour activer le chiffrement TLS, lors de l'envoi d'un email, du nom d'utilisateur et surtout du mot de passe. Vous ne voulez pas que les mots de passe de vos utilisateurs transitent en clair sur Internet. Dans l'idéal vous devriez passer de may à encrypt ce qui empêcherait totalement l'envoi de ces informations en clair. Bien que ce soit tentant, cela casserait la réception de mails depuis d'autres serveurs de courrier sur Internet. Donc à moins que vous n'administriez différents serveurs de courrier pour différents domaines et utilisateurs qui ne doivent communiquer qu'entre eux vous ne devez pas utiliser encrypt. Cependant vos utilisateurs peuvent toujours ignorer le chiffrement et envoyer leurs mots de passe en clair. Nous passons donc par une autre étape.

Forcer le chiffrement pour les informations d'identification

Bien que les mails soient toujours envoyés en clair sur Internet depuis d'autres serveurs, nous devons nous assurer que nos utilisateurs n'envoient pas accidentellement (ou par ignorance) leurs mots de passe en clair sur Internet. C'est pourquoi nous forçons le chiffrement de l'authentification en utilisant smtpd_tls_auth_only=yes. Maintenant nous devrions être en sécurité.

Comment fonctionne l'authentification SMTP

Êtes-vous curieux de savoir à quoi ressemble l'authentification SMTP au niveau du protocol ? Voyons ça. Dans les versions précédentes de ce guide, nous utilisions telnet pour nous connecter sur le port TCP 25 et parler SMTP. Mais maintenant nous forçons le chiffrement et nous ne pouvons nous identifier en clair via SMTP. Essayons de nous identifier en clair :

$> 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)

Il nous envoi son salut (hello)

ehlo example.com

Postfix présente alors une liste des fonctionnalités qui sont disponibles pendant le dialogue SMTP :

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

Je vous explique birèvement la signification de ces lignes :

PIPELINING

C'est une fonctionnalité pour accélérer la communication SMTP. Normalement le système distant doit attendre une réponse à chaque commande qu'il envoit. le Pipelining (Ndt : tunnelage, utilisation d'un tunnel de processus à processus) autorise le serveur distant à envoyer des groupes de commandes sans attendre de réponse. Postfix se contente d'enregistrer ces commandes et les exécute les unes après les autres. Si vous dites à Postfix d'interdire le pipelining il va déconnecter le serveur distant quand il essayera d'envoyer des paquets de commande sans attendre de réponse du serveur. C'est principalement une fonctionnalité dirigée contre les programmes de spam qui ne s'adaptent pas à ce comportement.

SIZE 10240000

Le serveur distant est autorisé à envoyer des mails jusqu'à une taille de 10 Mo. Cela a longtemps été une taille maximale courante. De nos jours 40 Mo ou parfois plus est une taille plus courante les emails étant souvent de plus en plus gros.

Note du traducteur : dans ce cas, pour par exemple une taille de 40 Mo, il faudrait taper la commande :

postconf -e message_size_limit=40960000

VRFY

Autorise les serveurs distants à vérifier un nom ou une adresse email. Par exemple le serveur distant pourrait envoyer VRFY john et votre serveur devrait répondre 250 john Doe<john@example.org>. C'est une sorte de consultation de dictionnaire. C'est un risque pour la sécurité car cela autorise les spammeurs à extraire des adresses email valides. Du coup Postfix n'autorise cela qu'une fois que l'utilisateur distant est authentifié.

ETRN

Une commande qu'un système distant peut envoyer pour vider la file d'attente de courrier pour un des domaines qu'il gère. Elle peut être utilisée si le système distant a des problèmes techniques et ne peut recevoir de mail pendant un certain temps. Il peut alors lancer une command ETRN pour demander à votre serveur de lui envoyer d'un coup tous les mails en attente pour un de ses domaines. C'est une commande rarement utilisée (Ndt : Voyez la page consacréer à ETRN dans la documentation de Postfix).

STARTTLS

Indique au système distant qu'il doit basculer de sa connexion en clair à une connexion chiffrée en envoyant la commande STARTLS. Il commencera alors à négocier une connexion chiffrée TLS. Vous pouvez comparer cela à une connexion HTTP qui soudain bascule sur une connexion HTTPS chiffrée. L'avantage est que vous pouvez commencer le dialogue SMTP sur le port 25 TCP et n'avez pas à ouvrir un second port TCP comme 465 qui correspond au port SSMTP (SMTP sécurisé) qui n'accepte que les connexions chiffrées.

ENHANCEDSTATUSCODES

Autorise les codes de retour sur plus de trois chiffre dans diverses situations. Voyez la RFC2034 si vous êtes curieux (Ndt : ce paramètre permet d'améliorer la pertinence des DSN décrites plus bas).

8BITMIME

Dans le passé SMTP n'utilisait que des caractères sur 7 octets. Vous ne pouviez transférer des caractères comme « Ä » ou « ß » sans un encodage spécial. 8BITMIME autorise la transmission des courriels en utilisant des caractères sur 8 octets. Depuis de nombreux mails sont encodés en utilisant ISO8859-1 ou UTF-8.

DSN

Active les DSN (delivery status notification ou en français notifications de statut de distribution) qui permettent à l'envoyeur de contrôler les messages que Postfix crée quand un email ne peut être distribué de la manière attendue.

Quoi qu'il en soit une ligne importante manque ici qui autoriserait l'authentification :

250-AUTH PLAIN LOGIN

Nous avons dit à Postfix de n'autoriser l'authentification que si la connexion est chiffrée. Du coup il ne permet pas l'identification sur cette connexion en clair (vous pourriez autoriser temporairement les authentification en clair par la commande postconf -e smtpd_tls_security_level= et recommencer votre essai. Vous verriez alors cette ligne dans la liste).

Êtes-vous toujours connecté ? Alors c'est bon. Nous avons donc besoin d'une connexion chiffrée utilisant TLS. Vous pourriez envoyer la commande STARTTLS :

STARTTLS

Et le serveur alors vous répondrait :

220 2.0.0 Ready to start TLS

Cependant cela deviendrait compliqué car vous auriez à parler TLS, qui n'est pas du tout fait pour les humains. Mais nous pouvons utiliser OpenSSL à la place. Entrez QUIT pour fermer la connexion SMTP. A la place lançons :

$> openssl s_client -connect yourmailserver:25 -starttls smtp

Vous verrez alors un tas de lignes affichées. OpenSSL c'est connecté au port TCP 25 et a lancé une commande STARTLS pour basculer sur une connexion chiffrée. De la sorte, tout ce que vous taperez à partir de maintenant sera chiffré. Entrez :

ehlo example.com

Et Postfix va retourner une liste de ses possibilités ressemblant à cela :

250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Maintenant que nous utilisons une connexion chiffrée, Postfix nous offre de nous identifier. Envoyons donc une chaîne d'identification encodée en base64 du mot de passe :

AUTH PLAIN am9obkBleGFtcGxlLm9yZwBqb2huQGV4YW1wbGUub3JnAHN1bW1lcnN1bg==

Le serveur devrait accepter l'authentification :

235 2.7.0 Authentication successful

Déconnectez-vous de Postfix :

QUIT

Il vous salue :

221 2.0.0 Bye

L'authentification fonctionne, bien joué.

ATTENTION : Si vous avez mis comme mot de passe pour john autre chose que « summersun » vous devez encoder vous même ce mot de passe en base-64. Pour cela utilisez :

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

Maintenant vous pouvez tester l'envoi de mail avec l'authentification activée. Pour ne plus considérer votre propre domaine comme de confiance, vous pouvez temporairement modifier la variable mynetworks :

$> postconf -e mynetworks=

Maintenant vous serez obligé d'utiliser l'authentification SMTP même dans votre réseau local.

En cas de problèmes

Si vous avez trouvé dans votre fichier de log /var/log/mail.log le message warning: TLS library problem: 24125:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1256:SSL alert number 48: alors vous utilisez un certificat auto-signé et le client de mail refuse le certificat. Dans ce cas vous devez ajouter une exception pour faire confiance à ce certificat.

Si vous ne pouvez envoyer de mail depuis votre client de mail et obtenez la réponse Relay access denied comme message d'erreur alors c'est qu'il n'a pas envoyé le nom d'utilisateur et le mot de passe correctement. Re-vérifiez les réglages de votre client de mail.