SPF/DMARC, évolution du serveur SMTP et port 25 : Free renforce sa politique d’email
Le 05 février 2021 à 09h02
3 min
Internet
Internet
Hasard du calendrier, quelques minutes avant la mise en ligne de notre article sur le respect des standards de l'email en matière de sécurité, les équipes de Free faisaient une annonce sur la mailing dédiée au sujet.
La société y confirmait ce que nous avions constaté, à savoir que « depuis décembre dernier, les serveurs de messagerie ajoutent une signature DKIM (domaines free.fr/online.fr) aux mails sortants ».
Elle précise que cela concerne les messages envoyés depuis le webmail et le serveur SMTP maison. « Dans les deux cas, la signature n'est ajoutée que si l'authentification se fait sur le même compte que l'expéditeur du mail ».
C'est l'autre grande annonce : « le service smtp.free.fr supporte désormais l'authentification sur l'ensemble des comptes et des domaines » via les ports 587/465 (SSL). Cela ne sera donc plus une option, celle-ci devant disparaître des interfaces.
Précision supplémentaire : « l'authentification par simple login (sans le domaine) fonctionne toujours pour les comptes free.fr/online.fr mais n'est plus supportée officiellement et pourra disparaître éventuellement ».
En plus de DKIM, SPF et DMARC vont être implémentés « prochainement » via des enregistrements DNS. La politique DMARC sera dans un premier temps non contraignante, mais « nous souhaitons avoir la possibilité de les rendre à terme contraignants si cela devait s'avérer nécessaire ».
Cette décision n'est pas sans conséquences, elle implique « la fin du support du port 25 sur les serveurs smtp.free.fr concernant les comptes sur les domaines free.fr et online.fr. Le service continuera de fonctionner mais seuls les ports 465 et 587 sont censés être utilisés avec de l'authentification par compte sur ces domaines ».
L'équipe invite donc ses clients « à vérifier que vos logiciels de messagerie sont correctement configurés pour utiliser un de ces deux ports et que le compte d'authentification correspond bien à l'adresse mail. Si votre configuration est bonne, une signature DKIM devrait figurer dans les entêtes des mails que vous envoyez ».
Le 05 février 2021 à 09h02
Commentaires (11)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 05/02/2021 à 10h40
Il était temps… Personnellement, j’ai arrêté mes deux comptes il y a plus d’un an, ceux-ci étaient bloqués de manière régulière, et après contact avec le support de free, la raison était…
Que j’utilisais un VPN !!
Le 05/02/2021 à 11h30
Ha! Je comprends mieux. Pareil, en 4 mois d’écart. Par contre, j’ai rattaché mes @mails à mon compte Free et maintenant je peux débloquer manuellement.
J’en ai profité pour tester Proton Mail et Mailo.
Le 05/02/2021 à 11h08
On est en 2021… Ça fait quand même bizarre de voir ce genre d’annonce qui aurait dû dater d’il y a 10 ans.
Une belle équipe de bras cassés.
Le 05/02/2021 à 12h44
Par contre, il est tout à fait possible de faire le STARTTLS sur le port 25 (pareil pour l’IMAP sur le port 143). Si tout le monde basculait dans cette direction, ça éviterait d’avoir à ce souvenir quels serveurs utilisent quels ports…
Le 05/02/2021 à 13h54
Est-ce que cela signifie que free/online va envoyer des rapports Dmark ?
Cela ne semble toujours pas être le cas. (comme tous les autres opérateurs Français)
Le 05/02/2021 à 16h32
oui la différence c’est qui a un journal (NxI) qui non seulement en parle, mais leur pose des question après (sous entendant qu’il va pas laché le morceau) du coup ils ont une raison de bougé.
Le 05/02/2021 à 19h55
Je pense que le fait que l’ANSSI ait bougé l’année dernière a aussi pas mal joué. Après la série d’articles à la même période a sans doute renforcé l’intérêt à faire remonter le sujet au dessus de la pile chez certains
Le 06/02/2021 à 16h42
Orange seraient aussi des bras cassés, selon l’article du 6⁄02 cité ?
“Commençons par l’acteur le plus important de l’hexagone, « opérateur historique » et pourtant le moins bien doté en la matière : Orange. Ce dernier n’appliquait aucun des standards que nous avions évoqués dans notre dossier.”
Le 07/02/2021 à 05h17
Ne confondons pas tout.
Ces ports sont définis par RFC… et le sort du TCP/465 ayant changé au cours du temps, s’ensuivant une certaine confusion quant à sa définition et son usage, il est à éviter car dorénavant redondant (et depuis longtemps).
La raison derrière la séparation de port est une forme de séparation contrôle/données :
La lutte contre le courriel indésirable n’en est que facilitée.
Si tu gères ton propre MTA n’implémentant pas la séparation SMTP/Submission, et si tu surveilles attentivement les tentatives d’authentification, tu remarqueras beaucoup de bruit sur le TCP/25…
Le 07/02/2021 à 05h31
(Désolé pour la seconde réponse, trop tard pour éditer la précédente)
Pour la partie STARTTLS, cela revient au débat sur le protocole associé à chaque port : le chiffrement TLS doit-il être obligatoire ? La négociation TLS arrivant avant le protocole sous-jacent, il n’était originellement pas possible de mixer les 2.
TCP/465 fut un temps spécifié pour SMTPS, ie SMTP/SSL. Le problème étant que SMTP (TCP/25) n’implique pas de chiffrement, imposer le chiffrement sur ce port aurait introduit un bris de compatibilité ascendante.
STARTTLS permet, en partie, de résoudre le problème en permettant à la fois le protocole non-chiffré ainsi que se version chiffrée de cohabiter.
Sauf que… si un attaquant (MitM) souhaite écouter la communication, il peut simplement filtrer toute tentative d’un client de démarrer une session chiffrée en supprimant les messages de contrôle STARTTLS, forçant ainsi le canal à ne pas être chiffré.
Cette faiblesse de STARTTLS est structurelle ; la seule manière de s’assurer qu’une négociation de session chiffrée se fasse est de forcer la négocitation TLS, donc de l’effectuer en premier… et donc si un protocole est spécifié sans cette obligation, séparer les usages avec un nouveau port. Cela a, depuis l’otigine, était fait pour HTTP, avec TCP/80 & TCP/443.
Retour dans le cauchemar des TCP/25 & TCP/465.
Aujourd’hui, un opérateur peut faire ce qu’il veut avec son TCP/587, et s’il veut forcer le chiffrement ,ce sera aux client ne bien être configurés.
Il peut aussi “recycler” TCP/465 s’il veut permettre aux usagers d’utiliser TCP/587 de manière non-chiffrée.
L’idée est en tous cas : quelques soient les choix effectués, cela n’impactera pas la communication avec les autres MTA sur TCP/25 : le standard des communications inter-MTA étant respecté, la communication avec le reste du monde est assurée (sur un protocole spécifié comme n’étant pas chiffré, il faut donc chiffrer le contenu).
Le 12/02/2021 à 06h45
J’espère quand même que le port 25 ne sera pas bloqué comme chez Orange (d’ailleurs non contractuel). Sinon impossible d’héberger son propre serveur mail sans passer par un relay.