S'il est de plus en plus souvent chiffré pendant son transport et parfois lui-même, l'email n'est pour autant pas conçu comme très sécurisé. Spam, phishing et spoofing sont ainsi encore son quotidien, notre quotidien. Heureusement, il existe des solutions... qu'il faut pouvoir utiliser.
Le saviez-vous : n'importe qui peut envoyer un email depuis l'adresse de son choix. Il est très simple d'envoyer un email avec comme expéditeur [email protected] depuis n'importe quel ordinateur connecté à internet. Il suffit pour cela d'avoir accès à un serveur SMTP maison, ou peu regardant. L'origine de nombreux problèmes.
L'envoi sécurisé d'emails, un problème depuis près de 40 ans
SMTP est l'un de ces vieux protocoles des débuts d'Internet. Il n'a guère évolué depuis, si ce n'est pour préciser son implémentation du chiffrement TLS... en 2018. Pour lui, l'adresse de l'expéditeur (from) n'est qu'un champ de texte parmi d'autres, ne nécessitant aucune authentification ou vérification spécifique.
Et quand bien même : un serveur SMTP (ou Mail Transfer Agent, MTA) peut utiliser n'importe quelle adresse d'expéditeur. La mise en place d'une telle sécurité ne permet donc à un service que de se protéger contre les actions malveillantes de ses utilisateurs. Ainsi, lorsque vous vous connectez avec votre compte Google au SMTP de Gmail, c'est pour se protéger que l'entreprise décide que « [email protected] » sera forcément utilisée comme adresse d'expéditeur.
Mais n'importe qui pouvant expédier des emails depuis son propre MTA, comment s'assurer qu'il a le droit d'envoyer un email pour tel ou tel domaine, que cette information est fiable, que le message ou ses en-têtes n'ont pas été modifiés pendant le transport ? Ce, sans avoir à remplacer une brique logicielle telle que SMTP, créé il y a près de 40 ans, à la base de très nombreux outils et services, utilisé au quotidien et aux multiples implémentations.
Ce n'est pas la signature cryptographique des emails qui peut aider ici. Car, même si elle était massivement utilisée (ce qui n'est pas le cas), elle ne permettrait que de certifier qu'un message n'a pas été modifié et a bien été envoyé par un utilisateur détenant une clé privée. Aucune assurance qu'il est bien le propriétaire d'un domaine ou d'une adresse email.
Heureusement, des solutions ont été trouvées sous forme d'acronymes, reposant en partie sur ce bon vieux DNS : SPF, DKIM, (DM)ARC et BIMI. Vous n'en avez jamais entendu parler ? Vous n'êtes pas les seuls...
SPF : qui peut faire quoi ?
SPF a été défini il y a une quinzaine d'années pour apporter une première solution à la lutte contre l'usurpation d'identité (spoofing). Elle est donc le plus souvent mise en place par les hébergeurs et fournisseurs de services. Il reste néanmoins nécessaire de vérifier que c'est bien le cas et que la règle énoncée correspond à ce que vous désirez.
Le Sender Policy Framework (SPF) permet de déclarer quels serveurs peuvent expédier des emails pour chacun de vos domaines et quoi faire en cas d'erreur. Ainsi, lorsqu'un utilisateur recevra un email depuis l'un de vos domaines dans l'adresse de l'expéditeur, son MTA pourra très facilement vérifier qu'il vient d'un serveur autorisé et aura une indication de la marche à suivre dans le cas contraire. Il reste néanmoins maître de sa décision (nous en reparlerons).
SPF prend la forme d'un enregistrement DNS de type TXT, lisible avec une simple commande dig ou nslookup. Par exemple, pour le domaine de Stéphane Bortzmeyer, qui a analysé la RFC 7208 détaillant la procédure :
nslookup -type=txt bortzmeyer.fr
On obtient le résultat suivant :
text = "v=spf1 mx -all"
Il signifie que tous les serveurs indiqués dans les enregistrements DNS de type MX du domaine (ceux utilisés pour la réception d'emails) peuvent en envoyer. Tous les autres doivent être rejetés, un choix symbolisé par le « - ». Il se fait parmi quatre possibilités, nommées qualifieurs. Ils sont présentés ainsi par Google :
- Validé (rien ou +) : Si l'e-mail provient d'un serveur qui correspond à un mécanisme doté du qualifieur « + » (ou sans qualifieur), il est validé. Le destinataire doit accepter l'e-mail.
- Échec (-) : Si l'e-mail provient d'un serveur qui correspond à un mécanisme doté du qualifieur « - », il est mis en échec. Le destinataire doit rejeter l'e-mail.
- Échec partiel (~) : Si l'e-mail provient d'un serveur qui correspond à un mécanisme doté du qualifieur « ~ », il est validé, mais considéré comme suspect.
- Neutre (?) : Les mécanismes dotés du qualifieur « ? » n'ont pas d'incidence sur la validation de l'e-mail.
Certains domaines renvoient une réponse avec un indicateur de version différent, comme ici :
v=spf2.0/pra
Il correspond à la norme Sender ID, un temps défendue par Microsoft, mais tombée en désuétude depuis.
Attention : un seul enregistrement est toléré par domaine, mais il peut être composé de manière plus ou moins complexe, avec plusieurs IPv4 ou IPv6, domaines, etc. Il est néanmoins conseillé de garder une déclaration simple. Vous rencontrerez parfois dans la réponse le mécanisme include, comme chez OVH, Gandi ou divers services en ligne :
text = "v=spf1 include:mx.ovh.com ~all"
text = "v=spf1 include:_mailcust.gandi.net ?all"
Il signifie que les paramètres SPF à utiliser sont ceux du domaine « inclus ». Par exemple pour mx.ovh.com :
text = "v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all"
Cette solution permet aux services de transmettre un paramètre simple à leurs clients, tout en utilisant une variable plus complexe en réalité, qu'ils pourront faire évoluer quand bon leur semble, selon leurs besoins.
DKIM : la cryptographie à la rescousse
SPF est un enregistrement DNS indiquant une liste de serveur considérés comme conformes. Mais comment assurer que le message l'est également ? C'est le rôle de DomainKeys Identified Mail (DKIM).
Comme son nom l'indique, il s'agit d'une mécanique d'authentification du domaine exploitant du chiffrement asymétrique. Ce n'est pas un remplaçant de SPF, mais plutôt un complément, accompagnant tout message sortant d'une signature numérique (dans son en-tête), générée depuis un couple de clés publique/privée liées au domaine.
Cela permet non seulement de vérifier que le message a bien été envoyé depuis le domaine de l'expéditeur annoncé, mais également qu'il n'a pas été modifié pendant son transport. Une double assurance bienvenue. En complément de SPF, DKIM doit permettre aux MTA de déterminer si un message doit être considéré ou non comme du spam.
Mais il n'est presque jamais exposé à l'utilisateur, peu de clients email affichant le statut SPF ou DKIM d'un message reçu. Google le fait dans Gmail depuis quelques années. Il existe également une extension Thunderbird trop peu connue pour cela. Des services tiers existent également come Mail Tester ou MX Toolbox. Vous pouvez enfin regarder les en-têtes des emails si votre client le permet, ici Outlook (Fichier > Propriété du message) :
Si vous recevez un email d'un abonné Orange, il ne passera ni le test SPF, ni DKIM. Bienvenue en 2020 !
Une solution parfaite ? Eh bien non. Car si DKIM est entré dans les mœurs des grandes plateformes/entreprises et autres institutions, il est loin d'être généralisé, surtout chez de plus petits acteurs ou dans le service proposé au client.
(DM)ARC : que faire des mails reçus, mais mal identifiés ?
Vous savez désormais comment indiquer qu'un serveur est autorisé à envoyer des emails depuis votre domaine, comment ajouter une signature numérique dans l'en-tête de vos messages pour vérifier leur destinataire et assurer qu'ils n'ont pas été modifiés. Mais lorsque vous recevez des emails, comment prendre ces signaux en compte ?
C'est le rôle du protocole Domain-based Message Authentication, Reporting and Conformance (DMARC), permettant d'indiquer quoi faire lorsqu'un email ne passe les tests SPF et DKIM. Ou lorsque les domaines des deux tests ne sont pas « alignés » (identiques ou sous-domaine l'un de l'autre). Vous avez alors trois possibilités :
- Rejeter (
Reject) - Ne rien faire (
none) - Considérer comme suspect (
quarantine)
Précision : dans le cas de la politique none, il sera précisé que l'email n'a pas passé le test, mais aucune action n'est demandée. La suspicion n'entraîne également pas d'action systématique, tout dépendra du MTA du destinataire et de son filtre anti-spam. Seul cas où la sentence est directe, presque irrévocable : le rejet.
La diffusion de cette politique prend à nouveau la forme d'un enregistrement DNS de type TXT. Cette fois, elle correspond au sous-domaine _dmarc. du domaine concerné. Par exemple dans le cas du service d'emails de Microsoft :
nslookup -type=txt _dmarc.outlook.com
On obtient le résultat suivant :
"v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"
Comme pour SPF, on a tout d'abord un indicateur de version (DMARC1), puis un autre paramètre obligatoire (p). Les autres sont facultatifs, détaillés dans le point 6.3 de la RFC 7489. Pour ceux présents ci-dessus :
- p : politique à suivre pour le domaine principal
- sp : politique à suivre pour les sous-domaines
- pct : pourcentage d'emails concernés par l'analyse DMARC (100 par défaut)
- rua : adresse à laquelle envoyer les rapports agregés de DMARC
- ruf : adresse à laquelle envoyer les rapports d'erreur individuels
- fo : configuration du rapport DMARC
Notez la possibilité de recevoir des rapports, qui peut être intéressante pour savoir qui exploite votre domaine de manière non désirée. Même si vous avez une politique ouverte (none), c'est un élément intéressant pour agir en cas d'abus.
Pourtant et contrairement à SPF, la précision d'une politique via DMARC est encore trop rare. Elle peut d'ailleurs poser problème. Le cas AOL/Yahoo est l'un des plus connus : en 2014, l'entreprise a du jour au lendemain décidé d'indiquer que tous les emails jugés non conformes devaient être rejetés. Un choix qui n'a pas changé depuis :
"v=DMARC1; p=reject; pct=100; rua=mailto:[email protected];"
De quoi perturber de nombreux services qui recevaient des emails d'utilisateurs AOL/Yahoo, SPF et DKIM étant des solutions imparfaites. Notamment en cas de redirection ou de transmission via une liste de diffusion, qui peuvent renvoyer un résultat négatif pour SPF (expéditeur modifié) ou DKIM (message modifié). Des cas pourtant légitimes.
L'Authenticated Received Chain (ARC) a été imaginée pour répondre à ces problèmes. Il s'agit, lorsqu'un message passe par différents serveurs et intermédiaires, de préserver le résultat des tests DKIM et SPF originaux, tout en constituant une chaîne de confiance au fil des serveurs. Le MTA du destinataire recevra l'ensemble des informations, et pourra choisir s'il accepte ou non de considérer le(s) serveur(s) intermédiaire(s) comme tiers de confiance.
Pour cela, il devra se fier à trois éléments d'en-tête ajoutés à chaque « hop » et numérotés (variable « i ») :
- ARC-Authentication-Results : le statut ARC/DMARC, DKIM et SPF à réception du message
- ARC-Message-Signature : une signature du message à son expédition
- ARC-Seal : une signature des en-têtes ARC au fil de la chaîne
Concernant son support, on se retrouve dans la même situation que DKIM : cela dépendra principalement de la configuration du serveur de mail et donc de votre configuration ou de votre prestataire. Il ne reste donc plus qu'à espérer que le plus grand nombre s'y mette rapidement (plus que pour DKIM...).
BIMI : votre logo illustre vos emails
Dernière initiative en date : Brand Indicators for Message Identification (BIMI). Cette fois, il ne s'agit pas d'ajouter un élément technique invisible à l'utilisateur mais, au contraire, de faire apparaître le logo (carré, SVG) d'une entité dans les clients emails compatibles si un message est considéré comme valide. L'URL est précisée dans un enregistrement DNS.
Par exemple chez Dropbox, avec la requête suivante :
nslookup -type=txt default._bimi.dropbox.com
On obtient :
text = "v=BIMI1; l=https://cfl.dropboxstatic.com/static/images/logo_catalog/dropbox_logo_glyph_m1_bimi.svg;"
Un standard en cours de finition, déjà en cours d'implémentation ici ou là. Il doit être complété par la création de Mark Verifying Authority (MVA) délivrant des certificats (VMC) pour confirmer qu'un logo peut être utilisé par un domaine, à la manière des certificats SSL. Là aussi pour éviter toute usurpation d'identité.
Un processus dont il y a fort à parier qu'il sera payant une fois mis en place.
SPF, DKIM et (DM)ARC ne protègent pas de tout
Comme on l'a vu, les différentes solutions existantes assurent un certain niveau de protection malgré la permissivité intrinsèque de l'email. Ils permettent d'effectuer des vérifications à de nombreux niveaux : autorisation du serveur, légitimité de l'expéditeur, intégrité du message, politiques à appliquer, affichage dans le client, etc.
Pour les grandes plateformes, ils sont autant de signaux à prendre en compte. Si vous ne les fournissez pas, vous avez de grandes chances de terminer dans les spams par défaut ou même d'être rejeté. Mais à l'inverse, ce n'est pas parce que vous avez suivi l'ensemble des instructions à la lettre que vos emails seront forcément considérés comme légitimes. Ou que tous les emails que vous recevrez en tant qu'internaute seront débarrassés de tout message malveillant.
Car c'est la politique anti-spam du MTA qui fait foi. Et celle-ci peut décider de prendre en compte de nombreux autres facteurs, comme la réputation du domaine, des serveurs, des listes d'adresses IP connues pour être malveillantes ou peu regardantes, etc. Voilà pourquoi des emails envoyés par des clients de grands FAI français arriveront à bon port même sans passer les tests DKIM et SPF, alors que votre domaine personnalisé pourra être rejeté s'il n'a que du SPF.
Cela dépendra des acteurs – aucune règle globale n'a été établie, comme l'a montré le cas de la politique de rejet dure via DMARC de Yahoo – et de l'impact que cela peut avoir. Il est ainsi d'autant plus important que les fournisseurs de services d'email s'adaptent au plus vite à ces différentes procédures, en place pour certaines depuis une quinzaine d'années. De quoi réduire les risques pour tout le monde, sans les supprimer.
Car rien n'empêche un acteur malveillant de créer un faux domaine 0range.fr, avec les validations SPF/DKIM/DMARC, pour envoyer de faux formulaires à des clients du FAI et tenter de récupérer leurs identifiants. En l'état, si on ne s'appuyait que sur ces critères, il serait plus légitime qu'un email envoyé par Orange ou ses clients. Un comble !
La vigilance reste de mise, avec toujours le même triptyque :
- Méfiez-vous des emails reçus et regardez-y à deux fois avant de livrer des informations sensibles
- N'hésitez pas à signaler tout comportement malveillant détecté
- Privilégiez des services privilégiant votre sécurité
Commentaires (83)
#1
Un beau retour d’expérience avec Microsoft :https://linuxfr.org/users/lawless/journaux/le-service-messagerie-microsoft-outlo…
#2
J’ajouterai que quand cela est possible, forcer l’affichage du mail en texte dans son client : HTML dans le mail, cay mal et la plupart des mails en HTML sont en réalité en “multipart/alternative”, contenant à la fois le mail en texte simple et en HTML (avec parfois des surprises).
Sous Thunderbird, c’est dans “Affichage” / “Corps du message en” / “Texte seul”
#3
Pour ceux qui se lancent dans l’aventure, si vous êtes directement envoyés en SPAM malgré le SPF/DKIM (comme dans l’article de linuxfr dans le commentaire précédent), vous pouvez chercher à contacter l’hébergeur en question.
C’était il y a 6 ans (donc ça a pu bouger depuis) mais j’avais réussi à contacter Outlook et Gmail et j’avais pu via une procédure passer de SPAM par défaut à OK la plupart du temps.
#4
Et pour tester une config en live, un petit tour par https://www.mail-tester.com/ peut être une bonne idée !
#5
Oui, j’en parle dans le papier à venir
" />
#6
#7
Merci pour ces explications
" />
#8
#9
#10
L’article ne parle pas de la différence entre enveloppe et en-tête. Je suppose qu’elle a été trouvée trop subtile et trop difficile à pédagogiser mais elle est cruciale. Par exemple, SPF teste l’enveloppe et DKIM l’en-tête (et c’est pour ça que DKIM a des problèmes avec les listes de diffusion, mais pas SPF).
#11
En mail pro, j’ai abandonné tout espoir de comportement raisonnable des gens.
Pour mon mail perso, si les gens ne sont pas content que mes mails soient en texte pur, ils peuvent aller gentiment aller voir ailleurs si j’y suis (c’est jamais arrivé) :)
#12
Merci pour cet article !
#13
Disons que je ne l’exprime pas comme ça (dans le sens où la notion d’enveloppe pour l’email n’est pas toujours connue et peut prêter à confusion, certains pensent que ça désigne le tuyau transport par exemple).
Mais je précise bien que SPF est là pour confirmer (ou non) une autorisation du serveur d’expédition par rapport aux infos de l’expéditeur là où DKIM est une signature propre au message. SPF peut aussi avoir des soucis avec les listes de diffusion d’ailleurs, s’il y a passage par un serveur intermédiaire dans certains cas par exemple.
#14
#15
#16
Il n’est pas question de forcer les autres à n’envoyer que du texte seul, mais plutôt toi, quand tu reçois un mail en multipart/alternative, il vaut mieux lire la partie texte.
Et quand tu reçois un mail qui est uniquement en html, tu peux parfaitement y répondre en texte brut sans qu’il y ait des balises html partout pour peu que tu ais un mailer qui tient la route.
#17
#18
J’ai monté mon serveur mail perso il y a un an et demi. J’ai bien mis en place les mécanismes SPF/DKIM/DMARK avec 10⁄10 surhttps://www.mail-tester.com/ et j’ai une IP avec une bonne réputation (0 blacklistes). Je n’ai pas eu de soucis avec la plupart des acteurs mis à part Outlook et Yahoo avec lesquels il est impossible d’avoir un échange constructif avec le support (on est face à un robot avec des réponses toutes faites…).
#19
Ce sont les VPS d’OVH qui ont mauvaise réputation, mais les adresse IP d’OVH Telecom sont dans un autre AS que les VPS, donc aucun problème de ce côté-là. Le problème qu’il y a eu quelque temps, c’est que la plage d’adresses IP d’OVH Telecom était anciennement affectée à une société russe, et tous ceux avec un geoip pas à jour pensaient que tu étais russe et spammeur. Ça doit bien faire 5 ans que ça ne m’a plus causé de problème.
J’ai aussi mon mail principal qui est en mutualisé chez OVH. C’est clairement l’adresse qui me pose le moins de problèmes, que ce soit pour envoyer ou recevoir, comparé à mon adresse pro ou aux hébergeurs gratuits.
#20
Chouette article ! Je ne connaissais pas le BIMI
" />
Par contre, un truc que je ne saisie pas bien avec le SPF : il est censé “approuver” les serveurs du domaine de l’expéditeur (from), on est d’accord ?
Prenons un exemple :
Si on prend le cas d’une newsletter, c’est souvent un prestataire externe qui s’en charge (disons mailmonkey.biz), en envoyant le message comme s’il provenait du domaine concerné (from: [email protected]). En théorie, le SPF du domaine example.com n’autorise pas les serveurs de mailmonkey.biz, donc il devrait y avoir un échec. Pourtant, en pratique, ça passe, comme on peut le voir dans les entêtes :
Authentication-Results: spf=pass
Received-SPF: Pass
Bref, il ne se base pas (que) sur le domaine présent dans le champ “from” ? Autre chose ? C’est un peu obscur pour moi, je dois l’avouer…
#21
Dommage de ne pas parler du “PTR” que l’on aperçois dans une des réponses.
#22
#23
Je sais oui, mais c’est quand même mieux expliqué avec tes mots que dans une doc :)
Avant que j’ai un enregistrement PTR, ceux qui ne recevaient pas nos mails me sortait leur document de Best Practice : https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015…
Que peux utilisent en fait j’ai l’impression.
#24
Merci à toi David, ainsi qu’à toute l’équipe. Ces articles de fond sur des problématiques concrètes sont vraiment très appréciables. Super boulot.
" />
#25
Il faudrait aussi parler du Reverse DNS et de l’outil : https://mxtoolbox.com/
Et Outlook, office365 et consort classent par défaut les nouveaux domaines en spam jusqu’à ce que suffisamment de leurs utilisateurs qualifient ces domaines.
C’est très pénible et je n’ai rien trouvé à faire.
#26
C’est dans l’article ;)
#27
Toujours sympas les forums de libristes, avec dès le premier commentaire une tournure de phrase à connotation raciste.
" />
“toi relire message calmement”
>> Évalué à 10 (+29/-7) <<
Avec donc un bon nombre de personnes que ça ne dérange pas.
#28
Envoyer un mail à [email protected] est également intéressant.
#29
Exactement le même problème, les seuls chez qui j’arrive en spam sont Yahoo et Microsoft. Pourtant j’ai fait le max, spf, dkim, dmarc, 0 blacklist.
Mon serveur est chez moi et je suis chez OVH.
Si quelqu’un a une solution je suis preneur, surtout pour Microsoft (outlook, hotmail, live ça fait quand même du monde).
#30
Moi j’ai souvent le souci inverse : des emails Wanadoo/Orange où un mail MS (outlook.com) n’arrive jamais
" />
#31
#32
#33
#34
Utiliser une formulation en “petit nègre” c’est tout à fait normal, bien entendu. Pas du tout connoté, absolument nécessaire.
https://www.franceculture.fr/sciences-du-langage/le-francais-petit-negre-une-con…
#35
Désolé, mais franchement “toi relire message calmement.” ?
J’ai du mal à penser que personne n’aurait le bagage culturel pour saisir les références. C’est totalement déplacé, et visiblement ça ne choque pas grand monde. C’est quand même problématique, non ?
https://www.franceculture.fr/sciences-du-langage/le-francais-petit-negre-une-con…
#36
Au passage, le sujet de l’article n’est pas les commentaires de sites tiers, merci de ne pas dériver à répétition
" />
#37
#38
#39
#40
#41
Sorti de son contexte c’est très facile de critiquer.
Et puis il tu y voie ce que tu veux y voir, si tu as l’esprit assez tordu pour y mettre un accent quelconque c’est toi que ça regarde.
#42
Va faire un tour par ici, ça t’aidera sûrement pour Hotmail.
#43
Merci pour cet article.
Cela fait longtemps que je n’avais rien changé sur la config de mon serveur de mail.
J’ai vu que l’hébergeur avait mis en place SPF de lui même et j’ai pu activer DKIM en un clic.
Je vais attendre un peu avant de mettre en place DMARC.
#44
Pourquoi l’HTML dans les mails c’est le mal ? (mis à part les balises de tracking)
#45
Parce que les barbus ne jurent que par le texte brut, le vrai ! Il n’y a qu’à voir la tronche des RFC
" />
Plus sérieusement, je me pose la même question. Dans le contexte pro où j’évolue, rares sont ceux qui n’échangent pas des mails HTML, vraiment très pratique pour inclure des images, mettre en forme le texte (gras, souligné…), etc.
#46
Le phishing ou voir les headers facilement je suppose,
deux choses trés faciles à faire dans des mails HTMLs :
J’avoue ne pas comprendre la plus-value à suivre ce “conseil”:
#47
Ce serait surtout déjà bien que les éléments importants remontés par les headers soient rendus visibles à l’utilisateur (DKIM/SPF & co en faisant partie), tout comme l’accès à ceux-ci. Cela permettrait de facilement indiquer des éléments auxquels porter une attention en cas de doute.
#48
#49
#50
#51
Une pétition pour le markdown comme nouveau standard des emails ? Je signe !
#52
#53
C’est le moment de renforcer et unifier le standard, vite une RFC !
" />
#54
#55
Sauf que c’est la foire et ça veut dire que tu dois traiter indépendamment avec chaque fournisseur problématique (les deux cités faisant partie des cancers du mail en pratique), alors que SPF, DKIM et DMARC doivent être des solutions universelles qui doivent justement éviter de recourir à ces procédures moisies. Le pire étant Microsoft, qui répond pas toujours, ou qui te dit “oui”, et qui dans la pratique ne change rien (je crois me souvenir qu’ils disaient dans la doc du JMRP que ça garantissait pas la bonne délivrabilité, alors que le programme est justement conçu pour améliorer le truc…)
#56
Ben si ça existe. Il a toujours été comme convention (dans les mails ou dans les postes nntp (forum) ) définie dans la netiquette, que _xxx_ était un souligné, /xxx/ était un italique …etc…
Le markdown n’existait pas
#57
#58
#59
#60
#61
#62
Ce n’est pas une question de lire les entêtes (je ne les regarde que rarement, surtout que désormais le mail plus simple contient 4ko d’entêtes pour 20 octets de corps de message)
#63
On peut les voir dans les entêtes, non ? Pourtant, je ne trouve qu’un seul “from:” ou alors c’est Outlook qui ne m’affiche pas tout
" />
#64
#65
#66
Non, tu ne vois que le “contenu” de l’enveloppe (headers + message) et non les commandes SMTP qui ont été exécutées et qui constituent l’enveloppe de l’email (en l’occurence MAIL FROM et RCPT TO qui peuvent diverger des headers correspondants).
#67
Note pour David :
Merci pour ce super article instructif. Juste un petit soucis graphique sur Chrome mobile (v83.0.4103. 106 sur Android), les sorties console ne sont pas responsive, et donc dépasse la largeur de l’écran.
Correction à venir dans la v8 peut-être… :)
#68
et c’est bien connu qu’en milieu pro on utilise toujours l’outil adapté aux besoins…
" />
genre Excel pour faire des bases de données, Word pour faire des tableaux mais “avec une mise en page jolie”, et le mail pour faire des factures…
tu veux faire un bon de livraison? Tu le fais en PDF et tu l’ajoutes en pièce-jointe. l’HTML dans le mail est une fausse bonne idée qui ne sert plus qu’à mettre des pixels trackers et des images qui bouffent 10% de la bande passante mondiale.
#69
Partir de cas particuliers pour dénigrer tout un ensemble d’usage… comment dire
" /> Oui, on peut faire des trucs moches en HTML, mais ce n’est pas lié qu’aux mails !
Tu n’en as pas besoin ? je suis très heureux pour toi. D’autres l’ont. Et je vais même te dire un truc qui risque de te défriser : en plus d’être pratique dans le mail, car pas à faire un clic supplémentaire (les gens sur mobile apprécient), c’est plus sécurisé car limite le vecteur d’attaque (en n’ayant pas besoin d’ouvrir une autre application, et en évitant les failles PDF).
Le HTML c’est peut être une fausse bonne idée. En attendant, ça fait des années que c’est comme ça, ça fait au moins 10 ans que j’entends que le mail est mort, et pourtant, il est toujours là. Et à mon avis, ce n’est pas près de changer, tant les habitudes sont ancrés chez de nombreuses personnes.
#70
On n’utilise pas forcément toujours les outils que l’on veut
" />
Cela dit, c’est pareil avec Thunderbird, mais j’ai mis compris cette histoire d’enveloppe et de contenu.
#71
#72
relis ce que je dis: sans HTML, pas de pixel tracker, avec HTML, c’est possible.
je dis pas que tu le fais, je dis que cela rend possible ce genre de pratique, et pas que celle-là, et que c’est déjà largement utilisé. donc TON usage ne fais celui qui est majoritaire sur le net (parce que le spam est majoritaire)
#73
Super articleJe n’ai pas vu le MTA-STS dans l’article. :https://security.googleblog.com/2019/04/gmail-making-email-more-secure-with-mta….
Ma grande question, c’est une fois que j’ai tout mis en place. Comment je réduis le risque de phishing dans ma compagnie ?
#74
#75
Afficher les mails en format texte reste donc un mauvais conseil, vu que la plupart seront illisibles, ceux à peu près lisible seront noyé de 4ko de header que tu ne lis pas, autant afficher le HTML par défaut , et chercher dans les sources en cas de doutes.
Concernant le javascript je doute sérieusement qu’un mail avec une balise script dépasse le filtre anti-spam :)
Pour les images en BASE64 c’est plutôt une bonne manière de faire car ça évite tout doute de tracking contrairement au lien vers des sites externes qui inclus en général un id dans l’url pour accuser lecture.
#76
Afficher un courriel au format texte, n’affiche pas le header…
#77
Le format texte concerne bien le contenu du mail et pas son “code source” ;)
#78
#79
L’immense problème de MTA-STS, c’est qu’il nécessite un site web sur un domaine spécifique (mta-sts.example.com) pour servir la politique.
Transporter du mail (on est entre MTA là) ne devrait pas nécessiter d’HTTP au milieu.
Mieux que STS, il y a DANE qui est bien plus efficace, n’utilise pas d’autre protocoles que ceux déjà utilisés par le mail, mais - s’il commence à être pas mal déployé - ne l’ai pas par les ogres du mail
Sinon, SMTP s’est récemment doté d’une option pour exiger TLS (RFC 8689), mais c’est vraiment tout frais. (Je pense essayer quand il sera dispo dans Postfix :) ). Bon le problème avec cette option, c’est que je la vois mal fleurir sur les serveurs pour l’instant (trop risqué encore malheureusement)
#80
#81
#82
#83
Je n’ai pas lu le message dont tu parles, mais uniquement ton commentaire, j’y ai vu pour ma part une allusion à la façon de parler d’un homme préhistorique comme on peut le voir dans certains films