Dans les clichés t'as aussi le jeune commercial au sourire colgate qui ne rêve que de ne jamais entendre parler de toi et le vieux roublard avec 20 ans de carrière qui t'impose d'organiser des événements et des workshops autant que faire se peut, sans que tu n'y gagnes rien évidemment.

Je pense que ton analogie n'est pas celle la plus adaptée à la situation présentée. Ici on serait plus proche de cette situation je pense:

Tu as pleins de publicités en accès libre sur un stand. Tu prends tout sans vraiment regarder en te disant que tu regarderai plus tard puis tu te rends compte chez toi que tu as pris des documents confidentiels top secrets.

Effectivement, c'est ce que j'ai pu remarquer. Mais, ce que j'espère pour toi, c'est que tu proposes une solution plus flexible et “user-friendly” que les boîtes de presta qui ne font qu'appliquer bêtement des procédures sans aucune notion d'informatique et qui sont aux abonnés absents dès qu'il y a un problème.

Quand tu dis “on avait remplacé simplement les wallpapers”, c'est un projet sur lequel tu as contribué ?

N'hésite pas à proposer si tu souhaites poursuivre la conversation sur un autre support, je suis très curieux de voir comment on peut faire évoluer les choses dans ce domaine, car c'est une contrainte conséquente dans l'éducation …

Bienvenue à toi Nainterceptor. Très bien ton article, il sera dans les liens hebdos du Jdh.

Tcho !

Texte intégral de l'émission : https://dascritch.net/post/2018/05/18/CPU-Ex0085-Bonjour-%C3%A0-toi%2C-Enfant-du-Futur-Imm%C3%A9diat-%3A-Des-chiffres-et-des-lettres-%28le-myst%C3%A8re-Enigma%29 Pratique si vous êtes sours, malentendant ou que tout simplement vous préférez lire du texte au calme plutôt qu'écouter une radio bruyante ;)

H2 déjà utilisé. Quant à Push, certes qui semble intéressant, on va attendre un peu… d'avoir la bonne version sous OpenBSD. Et, on “testera” cela… comme toi ;) En tout cas, merci :D

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:

$ 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.

Autant supprimer les touches multimédia, de mise en veille et tout, je suis d'accord. Mais supprimer les touches F1..12, c'est pas un peu violent ? F5 est par exemple souvent utilisée ! Pareil pour “home/end/pageUp/pageDwn”, j'ai du mal à voir comment ne pas les utiliser ^^

Du coup, toi qui a quelques années de recul sans ses touches, je suppose que tu arrives toujours à t'en sortir, mais n'est-ce pas en perdant justement du temps ?

Et avec du recul, est-ce que la disposition que tu as actuellement te permet de gagner du temps ? Je suppose que oui, mais moi qui suit habitué à mon azerty, j'ai pas le recul pour me rendre compte que je pourrai aller plus vite ^^

Après, un clavier DIY doit avoir une saveur particulière (surtout quand c'est du vrai DIY et pas des “kits” où l'on a pas besoin de réfléchir ^^)

Je ne prône pas l'inclusion absolu… mais juste du bon sens pour éviter de froisser des gens alors qu'on aurait pu l'éviter simplement en changeant un mot. Ca fait plusieurs mois que j'applique ces règles, cela me demande que très peu d'effort pour y penser. En plus, cela devient vite des automatismes. Finalement, on se pose les mêmes questions, on a juste pas choisi les mêmes solutions. Il y a quelques années, j'aurais pu donner la même réponse que toi à quelques choses près. Je suis devenu plus exigeant au fur et à mesure et j'ai adapté ma façon de me comporter.

C'est dur de changer ces habitudes. Mon objectif avec cet article n'est pas que des gens appliquent l'ensemble du jour au lendemain, mais plus que ça les fasse réfléchir, que cela les inspire… et en même temps que les gens me fassent des feedbacks pour que je me remette en question aussi.

Merci pour ton retour en tout cas :)

Bonne chance à toi ! Ton avis sur https://fr.ulule.com/liberation-cahier-admin-debian/ une chance de ton côté hé hé hé ?

Tcho !

À la différence que ça pourrai être contesté par une autre plateforme (toi même si tu auto-héberges).

Youtube a fait le choix de ne jamais remettre en question les demandes.

Merci pour l'appel du pied. !

Excellent article.

De plus, pour avoir vécu les configs intouchables, la documentation inexistante et le clicodrome et les copies d'écran en guise d'explication de configuration, je préfère que l'on aille vers la dernière méthodologie que décrit la dernière partie de l'article.

Sinon, notre métier est un métier de changement… et je suis comme toi parfois étonné de la sauce marketing pour nous expliquer pourquoi nous devons passer à la dernière technologie alors que parfois certaines équipes font du copier-coller de commandes depuis un notepad dans un terminal car ils ne connaissent pas mieux pour vérifier l'exécution d'une commande.

Par contre, pas de troll ce jour car je partage complètement ton avis qui est, comme d'habitude, pertinent !

Carl il n'a pas regardé notre proposition fpart ! Je propose qu'on supprime son compte Jdh ou au minimum l'article pour fêter cette nouvelle année et notre grand pouvoir de modération ! Ok pour toi ? ;)

Pour le coup le progressive enhancement prend tout son sens. T'as Edge, Safari, Firefox, Opéra ou Chrome dans une version récente, ça marche pour toi. T'as une antiquité en guise de navigateur ? Tu pourras utiliser le site. Mais ce sera moins beau tant pis !

Merci à toi, un excellent article !

Le CSU est un parti politique allemand.

L'article cite sa source : https://www.heise.de/newsticker/meldung/LiMux-Aus-in-Muenchen-Opposition-wettert-gegen-katastrophale-Fehlentscheidung-3622848.html mais comme le problème est munichois la source est en allemand ! :-).

Soyons clair, un article ne peut rendre une telle situation dont les rebondissements et surtout les enjeux sont nombreux.

Par contre, une chance pour toi et ceux qui veulent investir dans leur compréhension de la problématique : une recherche google donne mille références intéressantes que tu peux comparer et analyser !

Pour les plus pressés cet excellent article en anglais : https://blog.documentfoundation.org/blog/2017/02/14/statement-by-the-document-foundation-about-the-upcoming-discussion-at-the-city-of-munich-to-step-back-to-windows-and-ms-office/

En français, tout frais tout chaud et remonté sur le JDH : http://linuxfr.org/users/kalenx/journaux/marque-page-reaction-de-la-document-foundation-a-la-decision-de-munich-de-repasser-sous-windows

Et pour ceux qui veulent connaître ce rapport d'Accenture qui fait tant de bruit : https://www.ris-muenchen.de/RII/RII/DOK/SITZUNGSVORLAGE/4277724.pdf (attention le document est en allemand et fait 450 pages )

Eh oui les formats courts sont à l'information ce qu'est un petit four à l'apéritif… une invitation qui peut parfois être maladroite mais qui ne présage jamais du pousse-café (Proverbe Clouguien)

Merci à toi, c'est plus un pense bête qu'un vrai article, comme bien souvent..

Très intéressant, bonne chance à toi !

D'accord avec toi pour l'OSS. Je pense que cette année peut être riche en terme de nouveauté sur les navigateurs. Mozilla fait un gros boulot là dessus, j'ai hâte de voir ce qu'ils arrivent à nous sortir. Opéra a aussi fait un beau coup avec son navigateur Néon, à voir comment les uns et les autres arrivent à intégrer les idées de ce concept !

Bugs volontaires tu penses ? La où je suis d'accord avec toi cest que oui, Apple ne permet pas d'utiliser autre chose que son webkit sur iOS et ca c'est inadmissible.