Traduction de la page https://workaround.org/ispmail/jessie/relaying-smtp-authentication

Relayage

Votre serveur de courrier est presque prêt à l'utilisation. Mais il manque une pièce du puzzle. Vos utilisateurs peuvent déjà récupérer leurs mails, mais il faut également qu'ils puissent en envoyer. Votre serveur de mail sait comment envoyer un mail vers un autre serveur, en utilisant les enregistrements MX. Les clients de mail sont sensés envoyer les mails d'abord à leur serveur de mail, qui ensuite le distribue sur Internet. Quand Postfix reçoit un mail d'un utilisateur, son renvoi vers un autre serveur est ce qu'on appelle « relayage ».

Même si le client de mail savait utiliser les enregistrements MX il ne serait pas capable d'envoyer un mail. Les utilisateurs sont souvent chez eux derrière une ligne DSL. Et ce type d'IP du réseau est généralement bloquée, pour l'envoi de mails, par les services appelés « real-time blacklists » (« listes noires en temps réel »).

Je vais trop vite ? D'accord, passons les différents scénarios en revue un à un.

Les mails entrants

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

Les mails sortants (sans identification)

John est quelque part sur Internet et veut envoyer un mail à lisa@example.com. Votre serveur de mail n'est pas responsable du domaine example.com, il reçoit le mail et le transfère (relaye) vers le serveur qui est responsable des adresse de type …@example.com. Cela peut sembler un scénario sans danger, pourtant votre serveur doit interdire ça :

Pourquoi ? Parce que n'importe qui peut se faire passer pour John et demander à votre serveur de relayer un mail. Si un attaquant (comme un spammer) voulait envoyer des millions de mails de spam au nom de John via votre serveur, alors les autres responsables de serveur vous accuseraient d'être vous même un spammeur. Votre serveur deviendrait ce qu'on appelle un relais ouvert (« open relay »). Ce n'est pas ce que vous voulez, parce qu'alors votre serveur se retrouverait sur toutes les listes noires et vous ne pourriez envoyer de mail à pratiquement plus aucun autre serveur. Donc sans preuve que John est réellement John votre serveur doit rejeter ses mails.

Courrier électronique sortant (avec identification)

Donc, comment John prouve-t-il son identité ? Il doit utiliser le SMTP authentifié. C'est semblable au cas précédent mais le programme de courrier électronique de John enverra aussi son nom d'utilisateur et son mot de passe.

Bien entendu il faut s'assurer que cette identification se fasse via une connexion chiffrée.

mynetworks

En plus de l'utilisation de l'identification SMTP vous pouvez dire à Postfix de toujours relayer les mails pour certaines adresses IP. L'option de configuration mynetworks contient la liste des réseaux IP ou des adresses auxquelles vous faites confiance. Généralement c'est là que vous déclarez votre propre réseau local. La raison pour laquelle John doit s'identifier dans l'exemple ci-dessus est parce qu'il n'envoit pas son mail depuis votre réseau local.

Si vos utilisateurs utilisent l'interface webmail tournant sur votre serveur de mail ils n'ont pas besoin de s'identifier. Roundcube envoit les mails à « localhost » qui est considéré comme étant de confiance dans la configuration de mynetworks.

Faites en sorte que Postfix utilise Dovecot pour l'identification

L'identification SMTP avec Postfix a été par le passé une vraie plaie. Elle était réalisée au travers de la bibliothèque SASL (Simple Authentication and Security Layer) qui faisait partie du serveur mail Cyrus. Et contrairement à ce que semble indiquer son nom ce n'était pas « simple » du tout. C'était quasi impossible à déboguer et envoyait des messages d'erreur en charabia et induisant en erreur. Heureusement de nos jours nous pouvons faire en sorte que Postfix demande au serveur Dovect de vérifier les noms d'utilisateur et mots de passe. Et comme vous avez déjà configuré la partie identification de Dovecot, vous n'avez plus qu'à faire communiquer Postfix et Dovecot. Postfix a juste besoin d'une configuration supplémentaire :

postconf smtpd_sasl_type=dovecot
postconf smtpd_sasl_path=private/auth
postconf smtpd_sasl_auth_enable=yes

Ceci active l'identification SMTP et dit à Postfix qu'il peut parler à Dovecot via un fichier de socket situé à /var/spool/postfix/private/auth. Vous souvenez-vous que Postfix tourne dans un répertoire transformé en bac à sable avec chroot ? C'est à dire /var/spool/postfix. Pour cela nous avons configuré Dovecot pour qu'il place un socket dans ce répertoire pour pouvoir communiquer avec Postfix.

Activez le chiffrement

La configuration qui suit active le chiffrement, définit la clé et le certificat et oblige à faire passer l'identification par une connexion chiffrée :

postconf smtpd_tls_security_level=may
postconf smtpd_tls_auth_only=yes
postconf smtpd_tls_cert_file=/etc/ssl/certs/mailserver.pem
postconf smtpd_tls_key_file=/etc/ssl/private/mailserver.pem

Dans les versions précédentes de ce guide vous aviez également besoin de définir le paramètre smtpd_recipient_restrictions pour limiter le relayage aux utilisateus authentifiés. Par chance la nouvelle version de Postfix dans Jessie (2.11) a une meilleure configuration par défaut. Postfix propose un nouveau paramètre appellé smtpd_relay_restrictions qui a trait aux demandes de relayage dans la phase RCPT TO du dialogue SMTP.

En gros il fonctionne comme la restriction smtpd_recipient_restrictions mais est vérifié avant. Et comme cette restriction smtpd_relay_restrictions a une configuration par défaut tout à fait raisonnable, nous n'avons rien à ajouter pour faire fonctionner l'identification pour le relayage.

Du coup Postfix 2.10 a modifié le comportement de toutes les restrictions smtpd_*_restrictions. Si une restriction oblige Postfix à rejeter un email, il attendra jusqu'après la ligne RCPT TO. Voyez la documentation de Postifx pour un exposé des raisons de ce changement.

Le paramètre smtpd_tls_security_level est défini à « may » (ndt : c'est à dire possible) pour permettre les connexions chiffrées quand Postfix reçoit un mail. Cela ne s'applique pas seulement aux utilisateurs envoyant des mails, mais aussi aux serveurs de mail distants quand ils vous envoient des mails. Il serait tentant de modifer cela pour mettre « encryt » ce qui forcerait le chiffrement et rejetterait toute tentative de création d'une connexion SMTP non chiffrée. Mais hélas il reste dans le monde des serveurs de mail qui ne peuvent chiffrer et qui, du coup, ne pourraient vous envoyer de mails. Donc « may » est la valeur appropriée.

Bien que des mails puissent toujours vous être envoyés non chiffrés depuis d'autres serveurs il nous faut nous assurer que les utilisateurs, que ce soit par accident ou par ignorance, ne puissent en aucun cas envoyer leurs mots de passe en clair sur Internet. C'est pourquoi nous forçons l'utilisation du chiffrement pour l'identification par smtpd_tls_auth_only=yes. Nous devrions maintenant être tranquilles.

Comment l'identification SMTP fonctionne-t-elle ?

Êtes-vous curieux de voir comment fonctionne l'identification SMTP dans le détail du protocole ? Regardons comment cela se passe. Dans les versions précédentes de ce guide nous utilisions telnet pour nous connecter au port 25 TCP et parler SMTP. Mais maintenant nous forçons l'utlisation du chiffrement et nous ne pouvons réaliser d'identification SMTP non chiffrée. Voyons déjà la première partie en clair :

telnet localhost smtp

Le serveur vous laisse vous connecter :

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

Envoyez-lui un « hello »

ehlo example.com

Postfix présente une liste des options disponibles durant le dialogue SMTP :

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

Laissez-moi vous expliquer brièvement ce que signifient ces lignes :

PIPELINING

Il s'agit d'une fonctionnalité destinée à accélérer la connexion SMTP. Normalement un système distant doit attendre une réponse à chaque commande qu'il envoit. Le pipelining autorise le serveur distant à envoyer des paquets de commandes sans attendre la réponse. Postfix va juste mettre ces commandes en attente et les exécuter une à une. Si vous dites à Postfix d'interdire le pipelining il déconnectera le serveur distant quand il essayera d'envoyer des paquets de commandes sans attendre la réponse appropriée. C'est essentiellement une fonction orientée contre les programmes de spam qui ne se comportent pas comme le demande le protocole.

SIZE 10240000

Le serveur est autorisé à envoyer des mails jusqu'à une taille de 10 MB. Cette taille a été pendant longtemps une taille maximale courante. Cependant de nos jours 40 MB ou même davantage sont des tailles courantes parce que les tailles de mails n'ont cessé d'augmenter.

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 mail. Par exemple le serveur distant pourrait envoyer une commande VRFY john et votre serveur pourrait répondre 250 John Doe <john@example.org>”. Cela sert à vérifier si une adresse mail accepte du courrier.

ETRN

Une commande qu'un serveur distant peut envoyer pour vider la file d'attente de Postfix pour un domaine donné. Elle sert si le système distant a eu des problèmes techniques et n'a pas pu recevoir de mails pendant un assez long délais. A la remise en service il peut lancer une commande ETRN pour demander que votre serveur commence à envoyer les mails en attente pour les domaines qu'il gère. C'est une commande qui n'est pas couramment utilisée.

STARTTLS

Informe le serveur distant qu'il doit passer de sa connexion en clair à une connexion chiffrée lorsqu'il reçoit cette commande STARTTLS. Il commencera alors à négocier une connexion TLS chiffrée. Vous pouvez comparer cela à une connexion HTTP qui soudain bascule sur une connexion chiffrée HTTPS. L'avantage est que vous pouvez initier une connexion en SMTP sur le port 25 TCP et n'avez pas à ouvrir un deuxième port comme 465 qui est le port SSMTP (secure SMTP) qui n'accepte que les connexions chiffrées.

ENHANCEDSTATUSCODES

Ceci active davantage de codes de retour à trois chiffres liés à différentes situations. Voyez la RFC2034 si vous êtes curieux.

8BITMIME

Dans ses débuts SMTP ne traitait que des caractères codés sur 7 octets. Vous ne pouviez transmettre des caractères comme « Ä » ou « ß » sans utiliser un encodage spécial. 8BITMIME autorise la transmission de mails utilisant des caractères codés sur 8 octets. Encore de nos jours de nombreux mails sont spécifiquement encodés en ISO8859-1 ou en UTF-8.

DSN

Active les DSNs (delivery status notifications ou 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é comme prévu.

Cependant il manque ici une ligne importante qui nous autoriserait à envoyer notre nom d'utilisateur et notre mot de passe :

250-AUTH PLAIN LOGIN

Nous avons dit à Postfix de ne permettre l'identification que quand la connexion est chiffrée. C'est pourquoi nous ne proposons pas d'identification lors de cette connexion en clair.

Vous suivez toujours ? C'est bien. Maintenant nous avons besoin d'une connexion chiffrée utilisant TLS. Vous pouvez lancer STARTTLS :

STARTTLS

Et le serveur devrait répondre :

220 2.0.0 Ready to start TLS

Cependant à partir de maintenant les choses se compliquent car il faudrait parler en langage chiffré TLS, qui n'est pas un langage que peuvent parler les humains. Mais nous pouvons utiliser OpenSSL pour nous aider dans le déchiffrement. Fermez la connexion SMTP et lancez la commande :

openssl s_client -connect localhost:25 -starttls smtp

Vous allez voir beaucoup de lignes s'afficher à l'écran. OpenSSL s'est connecté sur le port 25 TCP et a lancé une commande STARTTLS pour basculer dans une connexion chiffrée. Du coup, tout ce que vous taperez maintenant sera chiffré. Entrez :

ehlo example.com

Postfix va envoyer une liste d'options possibles qui va ressembler à ça :

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 propose une méthode d'identification. Du coup envoyons une chaîne d'identification avec un mot de passe encodé en Base64 :

AUTH PLAIN am9obkBleGFtcGxlLm9yZwBqb2huQGV4YW1wbGUub3JnAHN1bW1lcnN1bg==

Le serveur devrait accepter cette identification :

235 2.7.0 Authentication successful

Déconnectons-nous de Postfix :

QUIT

Au revoir :

221 2.0.0 Bye

L'identification fonctionne, bien joué.

Encodage en Base64 des mots de passe

Vous pouvez vous demander où j'ai pris cette longue chaîne incompréhensible qui apparemment contenait l'adresse mail de John et son mot de passe. C'est juste une version encodée (et non chiffrée) en Base64 de la chaîne :
« john@example.org<NULL-BYTE>john@example.org<NULL-BYTE>summersun ».

Une façon de créer cette chaîne est d'utiliser Perl :

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

Une façon plus simple est d'utiliser la commande base64 du shell :

$ echo -n 'john@example.org john@example.org summersun' | base64
am9obkBleGFtcGxlLm9yZyBqb2huQGV4YW1wbGUub3JnIHN1bW1lcnN1bg==

Le port d'envoi

Bien que j'aie toujours mentionné le port 25 comme port SMTP pour relayer les mails il existe une meilleure solution en utilisant le port d'envoi (submission port) sur le port 587 TCP (comme décrit dans la RFC4409). L'idée est d'utiliser le port 25 pour le transport des mails (MTA) de serveur à serveur et le port 587 pour l'envoi de mails (MSA) d'un utilisateur à un serveur. Comme de nombreux utilisateurs utilisent toujours le port SMTP par défaut, il y a de grandes chances pour que vous deviez utiliser les deux ports.

Éditez votre fichier /etc/postfix/master.cf et ajoutez un service pour le port d'envoi comme ceci (n'oubliez pas l'indentation à partir de la deuxième ligne). N'utilisez pas les commandes suggérées en commentaire dans le fichier master.cf, contentez vous de les ignorer.

submission inet n - - - - smtpd
 -o syslog_name=postfix/submission
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_sasl_type=dovecot
 -o smtpd_sasl_path=private/auth
 -o smtpd_sasl_security_options=noanonymous
 -o smtpd_sender_login_maps=mysql:/etc/postfix/mysql-email2email.cf
 -o smtpd_sender_restrictions=reject_sender_login_mismatch
 -o smtpd_sasl_local_domain=$myhostname
 -o smtpd_client_restrictions=permit_sasl_authenticated,reject
 -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject

Essentiellement ce nouveau service utilise le démon smtpd qui est la brique logicielle qui répond si vous ouvrez une connexion SMTP sur le port TCP 25. Mais avec quelques options supplémentaires…

• Il indique dans le fichier /var/log/mail.log les connexions au port d'envoi sous l'appellation « postfix/submission/smtpd » (syslog) ;
• rend obligatoire le chiffrement sur ce port (security level) ;
• rend obligatoire l'authetification (sasl) ;
• s'assure qu'un utilisateur identifié ne puisse envoyer de mails que sous son propre nom (sender_login_maps).

Redémarrez le serveur Postfix :

service postfix restart

Vos utilisateurs peuvent maintenant utiliser le port d'envoi (submission port) pour envoyer leurs mails.

Protection contre les adresses d'expéditeur contrefaites

Attendez une minute. Nous pouvons nous assurer qu'un utilisateur ne peut envoyer de mails qu'en utilisant sa propre adresse. C'est bien, mais comment cela fonctionne-t-il ? Jetons un oeil sur cette ligne que nous venons d'ajouter lorsque nous avons ajouté le port d'envoi :

smtpd_sender_login_maps=mysql:/etc/postfix/mysql-email2email.cf

L'option smtpd_sender_login_maps est un « mapping » Postfix avec deux colonnes :

1. L'adresse email que l'utilisateur veut utiliser pour envoyer son mails ;
2. Le nom d'utilisateur qu'il a utilisé lors de son identification auprès du serveur de mail.

La raison pour laquelle j'utilise le mapping /etc/postfix/mysql-email2email.cf est qu'il convient ici parfaitement. Ce mapping lie l'adresse à elle-même si elle existe. Cela vous trouble ? Regardez la requête SQL qu'utilise le mapping « email2email » :

SELECT email FROM virtual_users WHERE email='%s'

De la sorte, lorsqu'un utilisateur veut faire relayer un mail, Postfix interroge la table virtual_users à la recherche de l'adresse de l'utilisateur. Disons que John veut envoyer un mail depuis son adresse « john@example.org ». Postfix recherchera sans la table virtual_users pour voir si il y a une ligne avec un champ « email » qui contienne cette adresse. Il va en trouver une et récupérer la valeur du champ « email », qui n'est autre, rappelons-le, que l'adresse mail. Postfix s'attend à récupérer comme nom d'utilisateur celui qui a été utilisé pour la connexion. Comme nous utilisons l'adresse email en guise de nom d'utilisateur pour la connexion, ce mapping fonctionne. Si John voulait utiliser une autre adresse d'expéditeur, alors Postfix verrait qu'elle ne correspond pas à ce compte et rejetterait le mail. Votre fichier mail.log comporterait une ligne dans ce genre :

NOQUEUE: reject: RCPT from foo.bar[…]: 553 5.7.1 <forged@email.address>: Sender address rejected: not owned by user john@example.org; from=<forged@email.address> to=<…>

A vous de choisir si vous désirez utiliser l'option smtpd_sender_restrictions de cette façon.