Voyons un peu ce qu'il se passe quand on envoi un mail, les différentes étapes.
Ça passe par pas mal de logiciels différents et sur pleins de logiciels…
Voyons un peu ce qu'il se passe quand on envoi un mail, les différentes étapes.
Ça passe par pas mal de logiciels différents et sur pleins de logiciels…
Cet article est selon moi une référence ! Si quelqu'un ne connait pas le fonctionnement du mail, il lit attentivement cet article, et il devrait avoir tout compris :)
Merci beaucoup ;-)
on envoi –> envoie.
Tcho !
Erf je la fait absolument partout celle-là ;-)
Une alternative peut sans doute être un NAS pour héberger sans rentrer jusqu'au bout dans le technique, par contre sur des marques comme Synology ou Qnap ça reste quand même propriétaire. C'est un peu ouvert pour que des libristent jettent un oeil au code ou pas du tout ? Vous en pensez quoi ? A titre perso pour le moment je tends à supprimer de Google et passer petit à petit sur ce type de support, même si c'est pas l'idéal c'est à la maison. Edit : j'ai lu deux articles dans la foulée, celui ci et celui sur les maux des Gafam, ce qui explique ma réaction un peu “déconnectée” des purs emails ;)
Hmmm je déconseille de s'auto-héberger au niveau mail si on est pas prêt à s'y mettre vraiment sérieusement et pour des années…
Par contre il existe pas mal de gentils hébergeurs de mails à commencer par les chatons, la ffdn, ou certains hébergeurs commerciaux reconnus (fastmail/tutanota/protonmail/…).
T'es un grand foufou ! Je savais pas que tu auto-hebergeais tes mails !! Je “galère” déjà à faire tourner ca a peu près correctement sur un dédié, mais en local …. je sais pas si je dois dire “chapeau” et “t'es mazo !” (j'opte pour la 1ière, vu ton super article). Et sinon, tes mails arrivent chez @hotmail.; @outlook. et consort de MS(hit) ?
@+ !
Ma boîte la plus chargée (abonnement à de grosses mailing-lists, au hasard la FRnOG et la FRsAG, qui doivent être mes plus grosses sources de mail) tourne sur un raspberryppi@home, derrière une Livebox. C'est pas si difficile, mais tout le monde ne sais pas le faire (ou n'as le courage de le faire).
Perso, je sais pas si j'arrive chez Hotmail, mais j'ai tout bien configuré (SPF, DKIM, TLS autant que possible), et mon score sur certains testeurs est proche de la perfection (les SMTP relai Orange sont blacklistés, je peux rien y faire…).
Avant c'était à la maison, maintenant c'est sur un dédié mais où je passe par un tunnel. Mon IP@home ne me permet pas de m'auto-héberger (port bloqué et ip listée en tant que connexion résidentielle donc blacklister un peu partout). Mais ce n'est pas plus compliqué à la maison ou sur un dédié c'est pareil.
Je comprends pour le blacklisté, pas pour le port. Orange (Livebox = Orange) est le seul à FAI à bloquer le port 25 sans proposer de l'ouvrir de quelque façon que ce soit si on est pas pro. Ça m'empêche pas de m'auto-héberger. Ok, mes mails sortants passent tous sur les serveurs Orange. Mais dans la masse…
Ouai mais j'ai justement pas envie de passer par les smtp orange ;-) et j'ai de toute façon besoin d'un serveur dédié pour d'autres utilisations.
Bonsoir !
Sympa ton article sur “les dessous du mail”, la démarche est tout à fait louable et les explications assez claires, mais je voulais te signaler quelques oublis ou erreurs. Ne prends pas mal la chose, c'est strictement dans un but d'amélioration.
1) dans les paragraphes 1 et 2, tu évoques ce que le mail peut transporter (texte, html, pièces jointes, etc.) mais tu ne parles pas du tout du format MIME. C'est peut-être dans un but de simplification (ou ça fera l'objet d'un autre article ?), mais en tout cas ça va de pair avec l'encodage base64 que tu évoques pour les pièces jointes…
2) dans le paragraphe 5 et le paragraphe 9.2, tu évoques DKIM et tu dis qu'il permet d'authentifier le serveur et le domaine d'émission d'un message, mais ce n'est pas la seule fonction: DKIM permet aussi d'assurer l'intégrité d'un message et permet de vérifier qu'il n'a pas été altéré entre le serveur d'émission (là où il est signé) et le serveur du destinataire et/ou son outil de messagerie (où il est vérifié). L'intégrité du message est calculée sur la base du corps du message ainsi que de certains en-têtes (qui peuvent par exemple être le Subject, le Message-id, et aussi le From, tout ça se configure). Bon, on est d'accord, contrairement à GPG, la signature n'est pas réalisée dès le départ mais uniquement sur le serveur d'expédition, cela dit ça protège quand-même le mail en intégrité sur la portion la plus “à risque” du trajet (le grand méchant Internet ;-) )…
3) Dans le paragraphe 7.1, tu parles du greylisting et d'un temps d'attente de 5 minutes. D'expérience, je peux te dire que peu de serveurs utilisant cette technique te permettent de retenter un envoi au bout de 5 minutes. En règle générale on cale le délai à 25 minutes, car la majorité des serveurs de mail sont configurés pour traiter la queue de mails non envoyés toutes les ½ heures. Du coup, un serveur “légitime” qui retentera au bout de 30 minutes pourra envoyer son mail, en revanche un spammeur un peu trop pressé qui va insister comme un gros relou toutes les 5 minutes va se faire tèj. J'ajoute que le greylisting est de moins en moins employé car certains FAI le pénalisent, notamment en allongeant énormément les délais de délivrance: en effet, si je mets du greylisting chez moi, que je suis un gros site qui reçoit un volume de mail important, et que des FAI essaient de m'en envoyer, la 1ère fois ils vont de faire jeter de toute façon, donc en quelque sorte, je reporte chez eux une certaine charge (les mails qui restent en queue chez eux). Du coup, Orange, par exemple, ne retentait la délivrance qu'au bout de 24 heures à une époque (je ne sais pas ce qu'il en est maintenant). Chez Free, c'était pire: on avait parfois droit à un code 5xx, qui signale une erreur permanente et provoque le renvoi du mail à l'expéditeur ! Ca peut paraître débile d'augmenter la durée de rétention du message, puisque ça augmente encore le nombre de messages à retenir dans le spool, mais à mon avis c'est clairement une stratégie à plus long terme, pour décourager l'utilisation du greylisting, justement. Et toujours d'expérience, même si je suis d'accord avec toi quand tu dis que le mail ne garantit pas la délivrance en un temps défini, dans les faits, tes utilisateurs râlent très vite quand ça traîne, donc le greylisting, moi, j'ai abandonné (comme plein d'autres).
4) dans le paragraphe 7.2, qui parle des vérifications effectuées par le serveur mail de réception, tu dis que les serveurs DNSBL vérifient ton nom de domaine et l'IP du serveur de réception. Je pense qu'il s'agit d'une erreur, puisque c'est justement le serveur de réception qui interroge les DNSBL, inutile donc de faire une requête sur sa propre IP ! :-) En revanche, ce qui est vérifié, c'est l'adresse IP du serveur d'émission (et pas son nom de domaine car le mécanisme de DNSBL est mis en oeuvre avant la transmission de cette info). On fait donc une requête DNS vers un serveur DNSBL, concernant l'IP du serveur d'émission et on réagit en fonction de la réponse. Ce sont les seules infos échangées… Il n'y a aucune fuite d'info puisque de toute façon, l'IP du serveur d'émission est connue du serveur de réception puisqu'il s'y connecte… ;-)
5) tu places la vérif SPF en paragraphe 9, après le 8 (logique jusque là ;-) ) qui parle de la fin d'émission du courrier. Or, SPF est mis en oeuvre juste au début du dialogue SMTP, après la vérif DNSBL, et surtout, avant l'envoi du corps du message, donc tu aurais peut-être dû en parler juste après le paragraphe sur les DNSBL, justement. Toujours à propos de SPF, tu parles d'une potentielle fuite d'infos là aussi, en disant: “Le serveur DNS peut donc deviner que votre domaine à envoyer un mail à tel autre domaine”. Ta conclusion est erronée: il n'y a pas de fuite d'info là non plus, si ce n'est la liste des serveurs autorisés à émettre un mail pour le domaine considéré. Si je prends par exemple ton domaine:
Je vois que seules les machines 62.210.201.160 (le /32 est inutile, d'ailleurs) et 195.154.97.5 sont autorisées à véhiculer des mails en @lord.re, mais je ne peux pas pour autant savoir à qui tu as envoyé des mails depuis ce domaine ! ;-)
6) dans le paragraphe 9.3, tu inclus sous la dénomination “antispam bayésien” tout un tas de techniques (vérification de la date, de certains autres en-têtes, etc.). Or, le filtrage bayésien concerne exclusivement le calcul de la note de “spamitude” d'un message, basée sur la probabilité d'occurrence des mots du message testé, dans un message de type spam ou de type ham. Je ne suis pas en train de dire que les autres techniques ne sont pas utilisées, mais elles n'entrent pas dans la catégorie “bayésienne”. Concernant la sous-traitance de cette fonctionnalité d'antispam: c'est de plus en plus le cas… Quelques sociétés se sont positionnées sur le créneau, mais en règle générale, cela ne concerne que l'antispam en entrée, donc de toute façon, comme il s'agit déjà de mails provenant de l'extérieur, on ne peut pas considérer qu'ils soient réellement confidentiels (ou alors si c'est le cas, il faut les chiffrer !).
7) dans le paragraphe 12, où tu récapitules le trajet d'un mail entre 2 MUA, tu en “remets une couche” concernant des supposées fuites de données via le DNS, mais honnêtement, encore une fois, je ne vois pas vraiment ce qui peut fuiter à ce niveau… Je suis prêt à en discuter, bien entendu, comme d'ailleurs de tout le reste de mes affirmations.
Voilà. Encore une fois, je parais très critique, mais c'est du perfectionnisme, en fait. La base de ton article est bonne il faut juste préciser ou corriger certains trucs, et surtout, il y a trop peu de gens qui prennent la peine de tenter de transmettre leurs connaissances… ;-)
Bonne soirée, je reste à ta disposition pour discuter de toutes mes remarques au besoin.
Wow que dire !?
Tout d'abord merci d'avoir lu avec autant d'attention et merci de me remonter autant de commentaires !
1) J'ai pas parlé de MIME pour simplifier l'article qui était déjà trop long. Je l'ai supprimmé du premier brouillon à vrai dire.
2) C'est complètement vrai, je pense éditer l'article pour évoquer l'intégrité qu'apporte dkim. Excellente idée.
3) J'ai l'impression que le greylisting était en perte de vitesse mais qu'il est revenu à la mode ces derniers temps et même des mails depuis orange arrivent relavitement vite sur mes installs. (pas testé depuis free). J'ai insisté sur la non-garantie de vitesse des mails pour justement que les gens arrêtent de penser que l'instantannéité est normale (j'ai le droit de rêver).
4) Effectivement c'est l'adresse IP du serveur d'émission (et non de réception qui est transmise. Et tu as également raison sur le fait que le domaine n'est pas envoyé, je vais rectifier ça également. Par contre si, j'estime qu'il y a une fuite d'info possible : un hébergeur de DNSBL va voir une requête en provenance de a.b.c.d pour savoir si b.c.d.e est autorisé à envoyer du mail, donc potentiellement le DNSBL sait que ces deux machines (tentent) de s'échanger des mails. Celui qui contrôle le DNS peut voir des infos (floues certes). La fuite n'est pas auprès du serveur de réception qui comme tu le dis est au courant légitimement.
5) Pour l'ordre de placement de SPF je suis pas spécialement d'accord mais en vrai ça va dépendre de l'implémentation du serveur de réception. SPF pourrait être vérifié dès réception du MAIL FROM au niveau SMTP mais ce n'est pas le cas pour postfix en tout cas. Et encore une fois la fuite de données est bien présente, le serveur DNS sera au courant que la personne émettant la requête DNS reçoit un mail depuis tel domaine. Ça peut permettre au serveur DNS de savoir que lord.re a envoyé un mail à a.b.c.d. Donc encore une fois si a.b.c.d n'est pas un gros fournisseur de mail à la gmail/hotmail mais un ptit serveur d'une ptite entreprise, une asso, un mail auto-hébergé… bref il y a un potentiel assez élevé de faire un lien.
6) Ouai là j'ai complètement merdé. J'ai zappé le filtre bayesien et j'ai parlé que des analyses antispam classiques, je vais rajouter un paragraphe et réorganiser un peu ce point.
Bon ma réponse est bien plus courte ;-)
Re :-)
Alors tout d'abord, merci d'avoir pris certaines de mes remarques en compte !
Pour les fuites de données, ok, je n'avais pas compris que tu te plaçais au niveau du serveur DNSBL ou du serveur DNS sur lequel se trouve l'enregistrement SPF, et là en effet tu as raison, ce serveur peut savoir qui cause avec qui. Dans le 2e cas, on peut limiter la casse en s'auto-hébergeant aussi pour la partie DNS (c'est le cas de pas mal de boîtes), mais pour le listing DNSBL, là, c'est mort en effet.
Pour le greylisting: il y a peut-être eu du mieux récemment, mais pour moi, c'est définitivement un truc dans lequel je n'ai plus confiance, vu les entourloupes que les serveurs m'ont faites par le passé… :-)
Et pour le SPF, ce type de filtrage n'a vraiment de sens que si tu le fais dès le départ, avant que le mail soit envoyé: tu as toutes les infos à ce moment-là, inutile d'attendre plus longtemps pour prendre une décision… Et je peux t'assurer que même sur postfix, ça le fait, en tout cas avec “postfix-policyd-spf-python”, qui est le filtre SPF que j'utilise. Tu te fais virer dès le “RCPT TO:” (oui, il attend de savoir à qui le mail est destiné pour savoir s'il y a des règles particulières genre exceptions pour certains destinataires qui seraient moins regardants), mais c'est clair qu'avec ce filtre, tu n'atteins pas le “DATA”…
Qu'est-ce que tu utilises, de ton côté ? Je trouve extrêmement bizarre qu'une implémentation d'un filtre SPF attende d'avoir reçu tout le message avant de décider quoi en faire, c'est un non-sens. :-)
Bonne soirée !
Je n'utilise pas policyd, je suis sur : postfix/postscreen/rspamd/sisyphus.
Du coup la vérif SPF est faite pas rspamd en même temps que le dkim, bayesien et compagnie. Mais effectivement au niveau de policyd ça permet de virer au plus tôt.
Globalement celui qui a la main sur les résolveur du serveur de réception aura possibilité de récupérer pas mal d'infos concernant les mails tout en étant “transparent”.
Ok pour rspamd et sisyphus… Mais c'est zarbi comme implémentation. La logique voudrait que les tests (et les refus éventuels qui en résultent) soient faits dès que possible, et de préférence avant la phase DATA, ce qui permet d'une part d'économiser des ressources, et d'autre part de refuser le mail d'emblée, au lieu de l'accepter d'abord puis d'envoyer une DSN ensuite, surtout que dans le cas des virus ou de spams, l'expéditeur est systématiquement faux, donc une DSN a toutes les chances d'aboutir chez quelqu'un qui n'a rien demandé…
Les contrôles protocolaires (par exemple sur HELO/EHLO, MAIL FROM:, RCPT TO:, etc.), ainsi que DNSBL et SPF peuvent avoir lieu avant la phase DATA, pourquoi s'en priver ? :-)
Après, que quelqu'un ait la main sur le résolveur du serveur de réception, ça m'inquiète moins. Normalement, ce sont les mêmes que ceux qui gèrent le serveur lui-même… :-)
Postscreen écrème déjà la très grande majorité du spam avec ses différents tests et son greylisting avant même tout traitement donc j'ai toujours trouvé policyd un poil overkill à moins d'avoir une installation vraiment très conséquente avec une grosse quantité de mail.
C'est clairement intéressant de faire ce genre de test avant de passer au bayesien et lda dès lors que la volumétrie est importante.