L'email pose de nombreux soucis en matière de sécurité. Et si des solutions techniques existent depuis une bonne dizaine d'années, elles ne sont pas toujours mises en œuvre par les grands hébergeurs et FAI français. Ils n'ignorent pourtant rien de ces problématiques qui les concernent directement.
Comme de nombreux internautes, vous recevez sans doute chaque jour de nombreux spams et autres tentatives de phishing. Parfois, l'email d'expéditeur affiché sera même légitime, vous induisant en erreur.
Pour limiter les risques, des protocoles ont été mis en place : SPF pour identifier les serveurs pouvant expédier un email pour un domaine donné. DKIM pour signer les messages et assurer de leur intégrité, ARC une chaîne d'échanges. DMARC pour définir la politique à suivre en cas de problème. De quoi permettre aux outils anti-spam de faire leur boulot.
Certains sont assez récents, mais les premiers datent d'une quinzaine d'années.
Ce ne sont néanmoins que des signaux techniques, chaque service décidant d'accorder ou non sa confiance à un domaine ou serveur selon le comportement de ces derniers, différents critères ou même des listes régulièrement mises à jour. Le tout de manière plus ou moins opaque selon les cas. Ce qui ne facilite pas franchement la vie des administrateurs système.
Mais si les grands fournisseurs de services d'email ne jouent pas le jeu offrant un niveau de sécurité correct tant en réception qu'à l'envoi des messages, ça ne peut pas fonctionner. Et à ce petit jeu, nombre de grands acteurs français ayant pour clients des entreprises et/ou des particuliers ne sont pas à la hauteur. Même ceux connus pour être très regardants sur les emails qu'ils acceptent de transmettre à leurs clients...
Des risques connus, documentés et identifiés
Pourtant, l'intérêt pour la question du spam, du spoofing ou du phishing ne manque pas et ces problématiques sont bien identifiées. L'ANSSI alerte dans son guide de bonne hygiène informatique : « L’administrateur de messagerie s’assurera de la mise en place des mécanismes de vérification d’authenticité et de la bonne configuration des enregistrements DNS publics liés à son infrastructure de messagerie (MX, SPF, DKIM, DMARC) ». On pense aussi à l'initiative Signal Spam.
Lors de l'édition 2019 des Journées RESeaux (JRES) organisées à Dijon par le Réseau national de télécommunications pour la technologie, l'enseignement et la recherche (Renater), Damien Mascré, David Verdin et Laurent Aublet-Cuvelier présentaient les solutions SPF, DKIM, DMARC, etc. pour « tordre le cou au phishing » :
DKIM : trop compliqué pour les hébergeurs français ?
Pourtant, nombreux sont les grands hébergeurs et FAI français à ne pas proposer de signature DKIM en complément de SPF à leurs clients. C'est le cas de Gandi, OVHCloud ou Scaleway. Le premier l'admet tranquillement dans sa documentation, évoquant en public seulement un travail en cours (depuis plusieurs années), sans « ETA ».
Lorsque Gandi a été touché par une nouvelle vague de spoofing/phishing l'été dernier, s'exprimant sur le sujet dans un billet de blog, il a dû se rendre à l'évidence : il fallait s'y mettre, ne serait-ce que pour ceux envoyés par ses propres équipes. Selon nos constatations, c'est le cas depuis septembre dernier. Les clients, eux, sont toujours sans solution.
Scaleway, signe bien ses propres emails mais c'est tout. DKIM n'est même pas évoqué dans sa documentation. OVHCloud explique comment mettre en œuvre DKIM, mais ses équipes en charge de l'offre email n'ont apparemment pas vu ce tutoriel. Le Roubaisien est d'ailleurs un cas particulier du trio.
Ses emails marketing passant par un service tiers sont signés via DKIM, mais pas ceux envoyés pour ses échanges dits transactionnels. Ainsi, les alertes de connexion à votre compte ou de notification de facture ont un statut DKIM « fail ». Leur SPF est par contre valide, ce qui explique qu'ils sont tout de même considérés comme légitimes.
Est-ce une impossibilité technique ? Interrogés, Gandi nous a dit travailler à l'implémentation de DKIM et ARC. Scaleway admet ne pas être au point sur ces questions et nous confirme « y travailler et revoir ses pratiques ». De son côté, OVHCloud nous confirme envoyer ses emails avec SPF et DKIM (nous tenterons de comprendre le raté dans notre cas) :
« OVHcloud intègre depuis plus de trois ans les protocoles SPF en application sur l’intégralité de ses services mail. La signature DKIM est actuellement disponible en application sur une partie des services, pour à terme être déployée sur l’ensemble. Ces deux protocoles, les plus matures sur le marché, sont actuellement privilégiés par OVHcloud.
Le check de ces deux protocoles est configurable uniquement par le client, à son initiative. Cette partie n’est pas intégrée nativement en raison de potentielles problématiques de redirection connues sur le marché. OVHcloud entend répondre à cette question en proposant à ses clients des redirections via SRS, à la faveur d’un SPF plus pertinent pour les clients d’OVHcloud et leurs destinataires. »
Mais ce problème est-il spécifique à ces hébergeurs ? Qu'en est-il pour d'autres acteurs ? Il suffit de traverser la frontière et d'aller en Suisse pour constater que DKIM n'est pas une impossibilité technique chez des acteurs comparables. Ainsi, Infomaniak ou ProtonMail le proposent. Ce dernier permettant un renouvellement régulier des clés depuis peu.
Aussi critiquables qu'elles soient, les grandes plateformes américaines jouent également le jeu. Certes, leur politique de réception des emails ou de gestion de SPF est parfois trop stricte. On pense à Yahoo qui s'est illustré sur le sujet il y a quelques années. Ou encore à Microsoft. Mais on ne pourra pas leur reprocher un manque de réactivité sur l'implémentation de ces standards. Outlook.com, qui ne signe plus ses emails sortant avec DKIM au profit de SPF, DMARC et de la signature de l'ensemble de la chaîne via ARC, en avait déjà fait le tour dès décembre 2012.
Les FAI ne font pas mieux (et parfois pire)
Nous avons découvert lors de nos analyses que cette absence de signature DKIM n'était pas propre aux services d'hébergement d'emails. Les FAI, tous officiellement engagés dans la lutte contre le phishing, sont aussi concernés
Lorsqu'ils passent par un service tiers ou un serveur mail dédié à leurs communications marketing, ces dernières sont parfaitement signées via DKIM, avec enregistrement SPF au minimum le plus souvent. Il en va de même pour les emails de leurs employés. Mais pas toujours pour les messages transactionnels, notifiant l'arrivée d'une facture par exemple.
L'analyse de tels emails chez Bouygues Télécom, SFR, ou Sosh ont mené au même résultat :
Pour les clients, ce n'est pas mieux. Au contraire. Car là aussi l'analyse d'emails envoyés depuis les services fournis par des FAI montre l'absence de signature DKIM, et même de SPF dans certains cas. Chez Bouygues Télécom ou SFR, seul le premier est manquant. Chez Free ou Orange, les deux paramètres sont absents.
C'est d'autant plus étonnant pour ce dernier qu'il est très regardant sur les emails que ses clients reçoivent, notamment via ses procédures de lutte anti-spam. Dans un billet alertant en 2018 sur les pratiques des fournisseurs d'email, Framasky, administrateur des services de Framasoft, n'était pas tendre avec l'agrume :
« J’avais déjà parlé dans mon précédent article de sa sale manie de ne pas accepter qu’on lui envoie trop de mails en une seule connexion. Imaginez un quidam qui refuse que son facteur lui apporte plus de trois lettres par tournée. Le facteur doit donc se représenter plusieurs fois s’il a plus de trois lettres à délivrer. C’est débile. Orange fait ça, mais pour le mail.
C’est le seul fournisseur que je connaisse qui impose ce genre de limite (qu’on ne vienne pas me dire que c’est pour lutter contre le spam : comment font les autres ? Hein ? Orange n’aurait pas les capacités financières et techniques de lutter plus proprement contre le spam ?). »
L'entreprise vante pourtant l'intérêt de SPF et DKIM via sa branche Business Services. Dès septembre 2009, Jean-François Audenard, en charge de la sensibilisation à la sécurité au sein du groupe, expliquait ainsi que leur potentiel « est intéressant mais reste limité du fait de leur faible niveau de déploiement au niveau mondial ».
Pour lui il s'agissait d'un problème « assez classique de la poule et de l'œuf », invitant chacun à « activer SPF sur vos serveurs de messagerie » et à l'intégrer « dans vos mécanismes de scoring sur vos serveurs de réception ». Et DKIM ? Seuls « les plus consciencieux complèteront leur dispositif afin d'en étendre l'adoption » expliquait-il alors. Une remarque particulièrement saignante avec le recul, au regard de la politique de l'entreprise 11 ans plus tard...
Lorsqu'un client Free ou Orange envoie un email, DKIM et SPF sont aux abonnés absents
Interrogé, Orange nous a indiqué que DKIM serait proposé d'ici la fin de l'année au sein de son projet « New MTA », SPF n'étant utilisé que pour les emails entrants. Il sera néanmoins « plus restrictif » une fois la plateforme en place nous promet-on, sans plus de détails. Aucun des trois autres grands FAI français n'a pour le moment répondu à nos questions.
À quand une réelle prise de conscience ?
Arrivés au bout de nos analyses, plusieurs questions s'imposent à nous : tout d'abord, comment des FAI de l'envergure de Free et Orange peuvent ne même pas proposer d'enregistrement SPF pour les emails de leurs clients en 2020 ?
Certes, leurs propres emails sont « bien traités » par les serveurs, parce que leurs domaines ont pignon sur rue. Mais que se passerait-il si demain de grandes plateformes se mettaient à placer tous les emails @free.fr ou @orange.fr en spam parce qu'ils ne passent pas les tests DKIM et SPF, ce qui arrive à d'autres domaines qui ne sont pas validés par une liste ?
On note au passage le manque d'égalité sur ce point, mais aussi le peu d'égards que peuvent avoir les hébergeurs. Ils ne semblent pas décidés à bouger concernant la signature DKIM des emails qu'ils fournissent, renvoyant le plus souvent ce sujet à plus tard. Comme trop souvent lorsqu'il s'agit de proposer des fonctionnalités peu visibles, bien qu'essentielles.
Comme Free, Orange ne respecte aucun des standards, mais ses serveurs sont sur une liste d'IP validées, donc ça va. Jusqu'à quand ?
Il en est de même pour des hébergeurs d'importance comme Gandi, OVHCloud ou Scaleway, qui vantent régulièrement leur amour de l'innovation ... mais n'implémentent pas DKIM. Alors que des concurrents ont déjà sauté le pas.
On regrette ainsi que l'ANSSI ou Bercy, dont dépend le numérique, ne s'activent pas un peu plus sur le sujet. Car c'est aussi de ces choix techniques que découle le manque de protection de nos entreprises, ou le fait de favoriser des acteurs « non souverains ». Les rappels bienveillants sont une chose, mais il serait peut-être temps de hausser le ton.
Espérons néanmoins qu'à force de demandes de la part de leurs utilisateurs et de la bonne information de ceux-ci, nos géants français commenceront à se préoccuper du sujet, à agir et à communiquer sur les bonnes pratiques à suivre. Car il ne suffit pas de proclamer son amour de la French Tech et du « made in France » pour convaincre.
Commentaires (57)
#1
#2
Doit-on aussi parler de l’IPv6 pour le mail?? Il me semble que le sujet n’est pas plus glorieux…
#3
#4
#5
Un problème de SPF pour les fournisseurs de mail “historique” (Free, Orange…) c’est que si ils le mettent en place pour tout le monde ça va tout péter chez tout ceux qui ne passent pas par les serveurs SMTP du FAI. Par exemple dans ma boite, pour l’imprimante/photocopieuse/scanner.
Alors ok, ils pourraient l’activer pour les nouveaux comptes, et le proposer en option pour les anciens (mais pas grand monde irait cocher l’option à mon avis).
#6
Lorsque j’avais déployé SPF/DKIM/DMARC dans une grande entreprise (jusqu’il y a 1 an), j’avais des retours des stats DMARC de tous les gros fournisseurs américains (Google, Microsoft), de petites entreprises françaises (même un CHU), mais les FAI français étaient aux abonnés absents. Donc nos clients qui avaient une adresse email chez Gmail & Co étaient protégés des phishings qui usurpaient notre domaine, ceux chez Orange et Free se faisaient bananer. Merci les FAI. Des entreprises minuscules peuvent déployer le reporting DMARC, des entreprises immenses le peuvent, mais ceux qui seraient en charge de protéger le citoyen, souvent avec des délégations de service public, laissent les gens dans la merde.
#7
Espérons néanmoins qu’à force de demandes de la part de leurs utilisateurs et de la bonne information de ceux-ci, nos géants français commenceront à se préoccuper du sujet, à agir et à communiquer sur les bonnes pratiques à suivre. Car il ne suffit pas de proclamer son amour de la French Tech et du « made in France » pour convaincre.
Le hic des FAI est que leurs clients font un peu n’importe quoi et se plaignent au moindre problème auprès du support client, surchargeant ce dernier. J’ai connu le cas d’un Internaute qui n’utilisait pas les serveurs SMTP de son FAI, mais des serveurs tiers. Le FAI ayant mis en place SPF, ses emails arrivaient systématiquement dans le dossier de “courrier indésirable” de ses interlocuteurs. Lui expliquer la source du problème et lui proposer la solution n’était pas suffisant pour le convaincre d’utiliser les serveurs SMTP officiels de son FAI.
Ceci dit, SPF, DKIM et DMARC semblent poser des problèmes d’organisation du SI de nombreuses grandes entreprises et institutions, qui ont jusqu’à l’habitude d’utiliser des noms de domaines différents, voire des domaines détenus par des tiers agissant en leur nom, sans se soucier du moindre impact sur la réputation. Ce manque de cohérence et de prévisibilité rend le phishing des banques ou des caisses d’allocations sociales d’autant plus facile à exploiter par les hameçonneurs. Tenter alors de généraliser SPF, DKIM ou DMARC, c’est mettre un peu la charrue avant les boeufs…
#8
#9
#10
#11
J’aime beaucoup cet article
Pour un retour d’expérience :
Même les informaticiens ne savent que de très loin ce qu’est le SPF, ils ne connaissent souvent que le terme et vaguement la finalité, même si j’ai l’impression que ça va de mieux en mieux. Il n’a pas été simple de se faire accompagner sur cette mise en place, qui au final n’a rien de si compliqué du moment qu’on sait ce que c’est DNS. C’est même franchement anecdotique à faire avec Internet en ressource.
J’ai l’impression que cette méconnaissance est liée au fait que le mail c’est la petite boîte noire que personne ne veut toucher, que c’est un domaine d’expertise d’une facette de l’informatique. S’il y a du vrai là-dedans, cela provoque cette situation où même quand on pourrait avoir la compétence de faire, on ne touche à rien à ce qui fonctionne, et ni la partie technique ni le client ne cherche à creuser le sujet.
Pourtant c’est super dommageable même pour les organismes/entreprises qui se retrouvent devant des situations où un mail important est passé en spam, personne sait s’il a été reçu, et ça fait perdre du temps à tout le monde ou ça impose de redescendre d’un niveau “fonctionnel” comme en devant appeler pour dire “avez-vous bien reçu mon email ?”
C’est là aussi que c’est pas étonnant que les systèmes bonnes pratiques soient en place sur du mail marketing, parce que les services marketing quand ils se retrouvent avec un taux de mise en spam de 20, 30, 50%, eux se posent réellement la question, et vont chercher les outils pour améliorer leurs scores. Notamment les services de publipostage implémentent souvent les bonnes pratiques à leur niveau.
SPF, DKIM, DMARC ne sont pas suffisant pour lutter contre le spam, mais aujourd’hui chacun fait à sa sauce pour le filtrage et tout le monde réinvente la roue de son côté. Petite mention spéciale à outlook qui laisse pas passer certains mails légitimes, sans laisser aucune trace à qui que ce soit, par contre les spam malware je les ai tous les jours. Puis derrière sur ce beau bordel des services antispam se sont construits pour faire encore plus de filtrage.
#12
#13
> Alors ok, ils pourraient l’activer pour les nouveaux comptes
Bah… non, vu que SPF se gère au niveau du domaine et pas des comptes.
#14
, l’email d’expéditeur affiché sera même légitime, vous induisant en erreur…
#15
Ah oui effectivement. Du coup ça explique pourquoi il ne le mettent pas en place à mon avis.
#16
Je confirme que pour envoyer du mail en IPv6, il ne m’a fallu que deux choses : une IPv6 chez moi, et que le serveur MX en face soit joignable en IPv6.
Peut-être qu’EmericV a pas eu de chance et a récupéré un bloc IPv6 avec une mauvaise réputation (mais ça arrive aussi avec les IPv4, j’ai déjà eu le cas avec un nouveau serveur).
#17
Étrange. En plus la clé semble être en place depuis au moins 2018. Et comme ils utilisent aussi DMARC, une erreur se verrait dans les Authentification-Results. Hmmmm
" />
#18
#19
Pareil et pourtant avec un bloc pas top niveau réputation à l’époque (qui m’a valu bien des CAPTCHA et des impossibilités d’éditer Wikipedia en IPv6) puisque d’OVH Télécom (quand l’IPv6 de la partie FAI était annoncé comme venant de l’AS OVH et non OVH Telecom)
#20
Fort possible. Mes mails OVH de ce type arrivent sur une boite ProtonMail, du coup, le transport doit être relativement propre
#21
#22
Le problème avec SPF, DKIM et DMARC, c’est que les spammeurs ont suivi. Avant on avait des DNS block list pour bloquer certains serveurs à spam ça marchait pas trop mal. Maintenant les spammeurs ouvrent des comptes gmail pour envoyer leur spam. C’est 70% du spam que je reçois, et les mails passent tous les tests. Et bien sûr, google ne fait pas grand chose.
#23
Ce qui n’a… pas de rapport avec le sujet. Parce que ça ne change strictement rien au fait qu’il faut donner accès à ces solutions au plus grand nombre, et pas qu’aux spammeurs et boites qui ont leurs propres serveur mail. Comme dit dans l’article, ce ne sont pas des protections contre tout (notamment contre un spammeur qui a son propre domaine), c’est une partie de la chaîne mais néanmoins oubliée.
Comme dit sur Twitter sur le même sujet : ce n’est pas parce qu’un gilet parre-balle n’est pas efficace contre les balles dans la tête qu’il est moins utile qu’un casque (et inversement)
#24
Les entreprises américaines (hors GAFAM) utilisent majoritairement DKIM/DMARC ?
#25
adminsys/ingé sys est un métier. Si la boite est pas assez grosse pour avoir un admin dédié messagerie, ca se couple avec de l’AD, du DNS, des filesystem, des ESX, de l’OS, ….
Si personne chez vous ne veut mettre en place le SPF c’est qu’ils sont soient tous mauvais, soient que personne n’a été embauché pour le faire.
#26
Réponse d’OVHcloud reçue, intégrée dans l’article
" />
#27
Je dis juste qu’à mon avis, c’est pour ça qu’ils ne le mettent pas en place. Pas que c’est une bonne raison.
#28
Pour avoir fait du forcing pour la mise en place chez nous c’est surtout à cause de l’historique où chacun a fait à sa sauce… “Allez on envoie la pub avec le domaine en .com, ça fait classe, oui on prend ce partenaire pour les envois massifs, il est pas cher”.
Forcément avec l’impact métier potentiel si tel ou tel prospect ne reçoit pas les mails, ça discute beaucoup rien que pour choisir entre un “-all” et un “~all”.
La solution de compromis étant de définir un domaine en .fr (ou autre) pour les envois massifs, où chacun fait ce qu’il veut faute de pouvoir avoir un minimum de décisions/gouvernance et d’être très restrictifs sur le .com
#29
Ces outils protégent les autres contre des problèmes de ton domaine. Tu travailles beaucoup pour la sécurité des autres et peu pour la tienne.
#30
Pour avoir bossé dans le domaine de l’hébergement web, c’est un vrai enfer à appliquer coté client.
En premier, des problèmes aussi simples que: le nombre de clients qui possèdent un nom de domaine acheté sur le registrar le moins cher et qui n’est pas délégué à l’hébergeur est conséquent, vient ensuite les zones DNS dites “expertes”qui nous empêchaient d’y toucher, sans parler du client casse-c qui hurle avoir un email refusé car le SPF l’empêchait d’envoyer depuis son PC en CLI (…).
Au final on appliquait seulement des signatures DKIM et dmarc sur le reste des domaines que nous gérions.
#31
#32
Je crois que mon message n’a pas été bien compris. Je ne dit pas qu’il ne faut pas utiliser DKIM et autre. Je dis juste que DKIM a changé la façon dont les spammeurs agissent. Maintenant ils passent par des gros acteurs, type gmail, qui tirent un bénéfice de SPF/DKIM/DMARC pour leurs client en imposant du DKIM sur les mails en entrant (ce qui est une très bonne chose), ou plus précisément comme le dit très bien l’article, quand ça n’impacte pas trop leurs client (ce qui est déjà beaucoup moins bien). Par contre dans l’autre sens ils peuvent se permettre d’émettre du spam signé DKIM sans que ça les dérange.
En tant que particulier ou petit acteur, il n’y a plus de contrôle possible, il est difficile de mettre gmail sur une liste de blocage. Ces gros acteurs ont donc maintenant un rôle essentiel dans la prévention du spam, mais pas sûr que ce soit leur priorité, pourtant ils en ont les moyens.
#33
#34
Qu’en est-il des emails en “gouv.fr” ?
Aux US, il y a désormais obligation d’un DMARC strict en “reject” pour tout ce qui est en .gov (donc je pense que SPF & DKIM doit être actif également) :
https://cyber.dhs.gov/bod/18-01/#introduction-to-email-authentication
#35
Un problème que je rencontre au boulot, c’est Orange et son SMTP ouvert à tous vents pour les clients (ledit SMTP expédie tous les mails qu’on lui présente sans aucun contrôles à priori).
Du coup beaucoup de boites ont pris cette habitude , et beaucoup de presta info aussi : “Je conseilles une ADSL orange et je configure tous les clients mails de la boite avec un seul SMTP, celui de orange , en omettant bien sur toute forme d’authentification.
J’ai même vu pire : Un logiciel métier qui, pour envoyer des mails ne permet pas de choisir ses propres paramètres, mais oblige a choisir dans une liste pré-définie de 2⁄3 serveurs mails connus (gmail, hotmail…. et bien sur , orange).
Du coup , on va dire que le principe de DKIM & tout, dans ce genre de TPE qui utilisent ce genre de logiciels ; ben…..
#36
C’est pas pour prendre sa défense, mais pourquoi l’obliger à passer par les serveurs du FAI ? Vu que les mails ne sont pas chiffrés, c’est le FAI qui peux regarder ce qu’il veux de ses communications.
Donc je partage sont avis, ce n’est pas une solution convenable d’un point de vue vie privé.
Après le SPF se fait au niveau du NDD, qui devait appartenir au client, du coup j’ai du mal a comprendre le soucis.
#37
Il suffit de repartir au point de départ : SMTP est conçu de telle manière que n’importe qui peut usurper ton email et ceux de ton domaine. SPF permet d’éviter que l’on puisse usurper ton domaine, ou en tous cas de permettre à des tiers de savoir quand il y a un usage légitime ou non (ce qui vient en complément d’autres éléments de sécurité).
Après en tant qu’administrateur de service de mail tu peux demander une auth sur SMTP (ce que font à peu près tous), ou pas (comme certains FAI tant que tu es sur leur réseau vu qu’ils peuvent remonter le header en cas de souci).
Et si tu ne veux pas qu’on puisse lire tes emails : chiffre-les. Parce que si ce n’est pas ton FAI qui verra passer le contenu, c’est tous les serveurs intermédiaire de toi au MUA du destinataire, et ça peut faire du monde ;)
#38
#39
#40
Facile, ben voyons.
Déjà, il te faut comprendre la syntaxe obscure. Au lieu de faire lisible et simple, les inventeurs de la norme se sont éclatés avec du -, du ~, et autres conneries. Pourquoi utiliser des mots clés simples quand on peut faire du 1337 sp3ak ?
Tu dois ensuite avoir des notions de chiffrement : générer un certificat, l’appliquer.
C’est pas a la portée de madame michu. Facile, non. Faisable pour un passionné, oui.
Après tu te heurtés a des soucis en boucle :
Syntaxe obscure d’openssl pour générer ton certificat avec une tonne de normes qui t’oblige quasi a copier/coller depuis Google le mec qui a fini par comprendre tous ces formats de merde et ces encodages a la con.
Ensuite, la syntaxe de la conf de ton SMTP. J’ai jamais rien vu de plus imbitable que la config de postfix. Vraiment.
Enfin, le plus gros écueil pour moi est que le reverse dns doit pointer sur ton domaine. Ben bonne chance. Vraiment. Ou alors tu te résignes a utiliser le standard de ton serveur. Ça pue, on s’en fout.
Alors oui je suis pas un admin linux chevronné, oui il y a 10000x meilleur que moi, mais franchement, un serveur de mail parfaitement authentifié, c’est deux jours de boulot mini. Et encore, je suis gentil.
Donc facile, bon…
Cela n’excuse en rien l’absence de ces normes chez OVH, orange, et free. Si j’ai réussi (et pas encore fini d’ailleurs), eux, 10000x meilleurs que moi, y arriveront.
Mais faire passer ça pour facile, non, faut arrêter :)
#41
SPF n’a rien à voir avec ce que tu décris (à part ce qui concerne la gestion du TXT et son contenu, mais regarde 2⁄3 configs existantes, tu verras que ce n’est jamais rien de sorcier).
Après pour la mise en place de DKIM on parle de mail hein. Donc de gens qui se tapent une configuration de postfix chez des FAI/hébergeurs. Comme je le dis souvent, le mail c’est un métier. Tout de suite, la notion de simplicité en prend un coup 😉 Après que tu trouves ça compliqué pour ton serveur perso, c’est autre chose.
Et comme rappelé juste au-dessus : 15 ans !
#42
Comme je le disais dans le sujet sur DKIM/SPF hier c’est pour cela que j’ai quitté OVH et son offre Exchange. J’ai voulu privilégier un hébergeur français pour l’hébergement des mes emails mais pour un hébergeur digne de ce nom, ne pas proposer DKIM et le fait que la moitié des emails soit tagguée [SPAM] m’a fait migrer vers Microsoft365 (datacenter en France mais boite US…). Microsoft propose DKIM et avec un 10⁄10 sur mail-tester, je n’ai quasiment plus de soucis.
" />
Mais bon pour le client lambda, c’est pas très glamour et vendeur de proposer DKIM, bien moins que le “Super-Wifi”.
#43
#44
#45
#46
Il faut mieux écrire un commentaire sur NXI pour t’avoir que t’envoyer un email on dirait 
" /> NXI a un problème de SPF ? 
" />
Si tu relis mon message, oui, un admin email saura le faire. Je réagissais sur le côté faussement simple de la chose, la discussion évoquait les PME, les quidams, les smtp orange utilisés par des newbies.
Je mettais DKIM et SPF dans le même message évidemment (je suis en plein dedans là d’ailleurs).
PS : L’interface web mobile a pas enregistré le fait que je répondais à Methio d’ailleurs.
#47
Aucune idée. Je travaillais pour une banque de détail. Nos clients avaient donc en majorité des adresses chez un GAFAM ou chez un FAI français, et je ne me souviens pas avoir vu passer des adresses pro issues de boites américaines.
Cela m’énervait au plus haut point de voir que les FAI français ne faisaient pas le taf. Surtout que l’intérêt principal de DMARC n’est pas seulement d’appliquer une politique antispam, mais aussi de faire du reporting vers le propriétaire du domaine usurpé : on obtient des stats agrégées de qui envoie quel volume de mail en notre nom, et on obtient des copie des emails frauduleux en même temps que les clients les reçoivent. Le premier permet d’identifier plein de shadow IT. Le second permet de recevoir des échantillons des mails de phishing, et donc lancer un takedown sur un site de phishing quelques minutes après que le fraudeur a lancé son mailing de masse. Le pied !
#48
#49
Super article :)
Ce qui est énervant c’est que même avec un serveur bien configuré la plupart de ces services refusent quand même tes mails ou les mettent en spam… Grrr.
Sinon c’est quoi le service de validation dans la dernière capture ?
#50
#51
Tiens, je ne sais pas si c’est une conséquence de votre sujet mais j’ai reçu un mail d’OVH ce matin disant qu’ils allaient me migrer car je fais du spoofing (ok, j’envoie des mails d’un alias de mon domaine à partir du compte postmaster).
#52
Merci @David_L ! :)
#53
#54
#55
Dans le lot des informaticiens, tu as aussi
" />
celui qui sait changer le toner de l’imprimante
celui qui sait mettre une formule dans une cellule de tableur
celui qui sait brancher dans le bon sens la clé usb du premier coup
#56
#57
celui qui sait brancher dans le bon sens la clé usb du premier coup