C'est est une question de sensibilité, je comprends la réaction de certains même si je ne la cautionne pas.
Cependant, là où tu as pleinement ta part de responsabilité est dans ta gestion de la controverse et de la souffrance que tu provoques. Je ne sais pas si tu t'en rends compte à quels point dans tes réponses les mots que tu emploies et les accusations que tu portes sont extrêmement violentes.
Un exemple provenant des commentaires ici et ceux pris sur l'article en question:
“La nature de la relation la Quadrature du Net aux GAFAM est de même nature que celle du militant antinucléaire au nucléaire. Elle est existentielle ! A chacun son business plan.”
Tu réduis le choix d'utiliser les GAFAM à un business plan. C'est cynique et de mauvaise foi quand on sait qu'il n'y a pas d'alternatives à eux pour toucher le grand publique. Le militant anti nucléaire peut utiliser une énergie verte, par contre, est-ce qu'il va influencer les autres, pas vraiment.
“Tu fais partie du comité de censure ?”
Dire cela de quelqu'un équivaut à dire qu'il menace l'une de tes libertés fondamentales à savoir la liberté d'expression. Je suis d'accord que le message initial n'invite pas à la retenue mais c'est de ta responsabilité d'élever le niveau.
“Pauvre garçon !”
“C’est ça. Maintenant, il faut aller se coucher les enfants ! ;+)”
“Tes injonctions, je n’en ai rien à faire. Pour tout te dire, je n’ai pas pris le temps de lire tous ces galimatias. J’ai autre chose à faire. ”
Quel mépris incroyable quand tu vois la longueur du message qu'à fait Elzen pour te répondre et le temps qu'il a du prendre pour l'écrire.
Je vais m'arrêter là.
N'attends pas qu'autrui fasse preuvent de retenu, de mesure, de considération et de bienveillance à ton égard si tu n'en a pas pour lui.
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. :-)
C'est le même dilemme pour Firefox qui dénonce les DRM puis fini par les embrasser, pour Gitlab qui s'hebergait sur GitHub, etc.
Tout le monde ne peut pas s'offrir le luxe de la radicalité comme Stallman au risque de se retrouver bien seul et caricaturé.
Après, je pense que ce qui fait mal c'est de faire passé LQDN pour des opportunistes après tout les combats qu'il ont menés. Ça me semble un peu irrespectueux.
D'un autre côté des gens qui abordent la dégooglisation et compagnie il y en a pas mal… des gens qui vont frontalement en justice contre ça… bha il n'y a pas grand monde sorti de LQDN.
Ils ont fait le choix d'alerter les gens sur les plateformes où se trouvent les gens, ils n'ont pas fait le choix de pousser directement les alternatives car ils ont estimés que d'autres organismes s'en chargeaient suffisamment bien.
Beaucoup de membres de LQDN participent également à d'autres initiatives comme framasoft, la FFDN … qui elles poussent la vulgarisation et la pédagogie.
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.
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:
$ dig lord.re txt +short
“v=spf1 a ip4:62.210.201.160/32 a ip4:195.154.97.5 -all”
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.
J'avais fait ça une fois pour un client qui voulait une station de travail KDE neon en RAID 1. Vu que le disque d'install de cette distrib ne propose pas de RAID, je m'en suis sorti comme ça.
J'en ai conclu qu'il valait mieux une approche différente, comme par exemple transformer une Ubuntu Serveur (avec le RAID dans l'installateur) en KDE neon. Et si t'as une machine déjà installée, il vaut mieux partir sur une install fraîche.
je dois fixer un bug dans mon projet Django/Neo4j et commencer à communiquer dessus.
le rachat de Github par Microsoft va forcément entraîner l'écriture d'un billet sur mon blog carlchenet.com
continuer à remplir les archives du Courrier du hacker avec les numéros manquants. C'est tellement laborieux que j'avance lentement. Heureusement tout le reste est automatisé.
Je finalise mon outil de statistique relative à la fréquentation de mon blog basé sur les logs du serveur web. J'ai quelques graphiques des données qu'il me semble importante pour moi.
nombre de pages vue par mois / jour
classement des pages les plus vues par mois / jour
liste des sites sources pour le mois / jour
Avec une très grosse attention sur le caractère personnelle des données. Faut que je regarde si la donnée du referer n'en est pas une. Pas si simple car certains referer peuvent être des sites personnels du genre madamemichu.fr ; Bien que super utile pour connaître un peu son audience et décrouvrir des mines d'or en site, il y a de fortes chance qu'elle passe à la trappe.
oui… en fait, cette histoire me fait plus chier pour Atom que pour Github :/
C'est est une question de sensibilité, je comprends la réaction de certains même si je ne la cautionne pas.
Cependant, là où tu as pleinement ta part de responsabilité est dans ta gestion de la controverse et de la souffrance que tu provoques. Je ne sais pas si tu t'en rends compte à quels point dans tes réponses les mots que tu emploies et les accusations que tu portes sont extrêmement violentes.
Un exemple provenant des commentaires ici et ceux pris sur l'article en question:
“La nature de la relation la Quadrature du Net aux GAFAM est de même nature que celle du militant antinucléaire au nucléaire. Elle est existentielle ! A chacun son business plan.”
Tu réduis le choix d'utiliser les GAFAM à un business plan. C'est cynique et de mauvaise foi quand on sait qu'il n'y a pas d'alternatives à eux pour toucher le grand publique. Le militant anti nucléaire peut utiliser une énergie verte, par contre, est-ce qu'il va influencer les autres, pas vraiment.
“Tu fais partie du comité de censure ?” Dire cela de quelqu'un équivaut à dire qu'il menace l'une de tes libertés fondamentales à savoir la liberté d'expression. Je suis d'accord que le message initial n'invite pas à la retenue mais c'est de ta responsabilité d'élever le niveau.
“Pauvre garçon !”
“C’est ça. Maintenant, il faut aller se coucher les enfants ! ;+)”
“Tes injonctions, je n’en ai rien à faire. Pour tout te dire, je n’ai pas pris le temps de lire tous ces galimatias. J’ai autre chose à faire. ” Quel mépris incroyable quand tu vois la longueur du message qu'à fait Elzen pour te répondre et le temps qu'il a du prendre pour l'écrire.
Je vais m'arrêter là.
N'attends pas qu'autrui fasse preuvent de retenu, de mesure, de considération et de bienveillance à ton égard si tu n'en a pas pour lui.
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 pense que le troll est réussi ;)
C'est le même dilemme pour Firefox qui dénonce les DRM puis fini par les embrasser, pour Gitlab qui s'hebergait sur GitHub, etc.
Tout le monde ne peut pas s'offrir le luxe de la radicalité comme Stallman au risque de se retrouver bien seul et caricaturé.
Après, je pense que ce qui fait mal c'est de faire passé LQDN pour des opportunistes après tout les combats qu'il ont menés. Ça me semble un peu irrespectueux.
Sinon, Twitter n'est pas vraiment un GAFAM.
D'un autre côté des gens qui abordent la dégooglisation et compagnie il y en a pas mal… des gens qui vont frontalement en justice contre ça… bha il n'y a pas grand monde sorti de LQDN.
Ils ont fait le choix d'alerter les gens sur les plateformes où se trouvent les gens, ils n'ont pas fait le choix de pousser directement les alternatives car ils ont estimés que d'autres organismes s'en chargeaient suffisamment bien.
Beaucoup de membres de LQDN participent également à d'autres initiatives comme framasoft, la FFDN … qui elles poussent la vulgarisation et la pédagogie.
Un outil = une fonction
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 ;-)
Conclusion : chat échaudé craint la charrue avant la peau de l'ours.
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.
J'avais fait ça une fois pour un client qui voulait une station de travail KDE neon en RAID 1. Vu que le disque d'install de cette distrib ne propose pas de RAID, je m'en suis sorti comme ça.
https://blog.microlinux.fr/raid1/
J'en ai conclu qu'il valait mieux une approche différente, comme par exemple transformer une Ubuntu Serveur (avec le RAID dans l'installateur) en KDE neon. Et si t'as une machine déjà installée, il vaut mieux partir sur une install fraîche.
ah très bonne remarque, je vais faire ça, merci !
J'ai écrit cinq articles de blog (un à paufiner avant de publier) et du coup ça résume pas mal ce que j'ai foutu cette semaine ;-)
D'ailleurs à au sujet des archives, mettre une date sur la page ouaib ça serait top ;-)
J'ai corrigé, merci ;)
Tcho !
Heuuu Atom c'est du made in Github enfin Made in Microsoft maintenant ;-)
Lennart est sur le coup ! Systemd aura désormais un systeme git intégré !
Ce sera intéressant de voir les décisions des “gros” genre MariaDB, Ansible, systemd, etc.
Tcho !
Du coup, ils vont fusionner VSCode et Atom ? :-)
Je finalise mon outil de statistique relative à la fréquentation de mon blog basé sur les logs du serveur web. J'ai quelques graphiques des données qu'il me semble importante pour moi.
Avec une très grosse attention sur le caractère personnelle des données. Faut que je regarde si la donnée du referer n'en est pas une. Pas si simple car certains referer peuvent être des sites personnels du genre madamemichu.fr ; Bien que super utile pour connaître un peu son audience et décrouvrir des mines d'or en site, il y a de fortes chance qu'elle passe à la trappe.