Je plussoie parce que je comprends bien le problème. Mais si un message cryptique adressé à tous pourrait générer de la confusion, il pourrait y avoir dans l'interface de la box un message d'avertissement et un lien vers une interface avec un endroit où spécifier un moyen d'être prévenu (une adresse électronique, quoi). En opt-in, donc. Ça ne toucherait que la minorité qui utilise le service de redirection de ports de la box. Juste une idée comme ça; il y a peut-être mieux ou plus simple.
D'ailleurs j'ai déjà configuré une adresse pour recevoir les messages du répondeur (super option, ça !). J'ai juste besoin d'une case à cocher "être prévenu par courriel si jamais l'IP change".
Quand-même, avec le développement des NAS qui hébergent des serveurs pour partager les photos en ligne, le problème commence à toucher un public plus large, non ?
J'administre (co-administre) un serveur dédié courriel (Postfix + Dovecot) + mailing-lists (Mailman) personnel. Rien de folichon, quelques utilisateurs et des listes faible débit à max 100 inscrits.
Il m'arrive de regretter la période où j'étais en mutualisé et tout marchait tout seul… Ça marche assez bien tout seul, heureusement, mais aujourd'hui j'ai moins voire plus du tout de temps à y consacrer alors le peu que ça demande, ça m'emmerde. Et je parle pas des migration de distro (Jessie -> Stretch).
L'effort à produire pour l'administration est trop important pour le service rendu. C'était bien de le faire parce que j'ai appris des choses, mais franchement, ça vaut pas le coût. Sans parler dans ton cas du coût environnemental de faire tourner un serveur physique juste pour cette liste.
Si tu as des problèmes avec ta liste aujourd'hui, comme ont dit les autres, je suis pas sûr que ça marchera mieux si tu le fais. C'est plutôt lié aux utilisateurs ou aux fournisseurs de leurs boîtes, et ces fournisseurs seront sans doute encore plus tatillons avec les messages de ton serveur perso qu'avec ceux d'OVH. Donc commence par régler ça puis réévalue le besoin. Si vraiment ça va pas chez OVH, cherche à faire héberger ta liste ailleurs (hébergement associatif, peut-être).
Pour la distro, Debian ça va bien, c'est stable, difficile à casser. Mais la config du serveur de courriel est pas triviale du tout, il y a plein de détails à prendre en compte pour que ça marche bien (c'est pas le tout que les messages partent, si c'est mal configuré les messages peuvent être refusés par le serveur d'arrivée) et des erreurs à pas faire pour pas être relais de spam (ça encore c'est pas trop difficile, surtout dans ton cas où ça hébergerait juste un serveur de listes). Je ne connais pas de distro/logiciel avec une config assistée toute faite. Attention aussi à l'enregistrement DNS.
Des fois les messages n'arrivent pas chez Gmail ou ailleurs et tu finis par découvrir que c'est parce que tu as pas mis en place une mesure de sécurité (enregistrement SPF,…). Ça dérange personne sauf Gmail ou Hotmail et après 3 mois tu finis par découvrir que tous les inscrits à la liste qui sont chez eux ne reçoivent plus les messages et personne s'en était rendu compte. Super.
Quant à "transmettre la connaissance par la suite", c'est peut-être le point le plus utopique. Tu risques de devoir te traîner le truc à gérer jusqu'à ce que tu en puisses plus. Et le successeur créera un Yahoo group ou mieux une page Facebook pour communiquer avec tout le monde…
Si je comprends bien, le site mets à disposition des photos qu'on peut visualiser mais pas télécharger sous forme d'archive, les parents peuvent télécharger les photos une par une mais c'est fastidieux.
Si ton script permet de télécharger toutes les photos d'un coup sans s'embêter, je ne vois pas le problème. Il ne met pas à disposition un contenu interdit, il permet juste d'avoir un accès plus commode à un contenu autorisé.
Leur réponse, c'est un peu n'importe quoi. Je sais pas si c'est fait exprès pour noyer le poisson ou pas. Effectivement, si les parents peuvent télécharger les photos, ils sont moins tentés d'acheter le livre, donc ça n'arrange pas les vendeurs du site.
Franchement, si la situation est bien celle-ci, je ne me retiendrais pas de partager le script.
(Et puis je doute que beaucoup de parents sachent choper le truc sur github, installer python, etc… donc la portée devrait être assez limitée pour que ça passe inaperçu.)
Pareil, j'ai regardé qqs trucs et j'ai finir par coder mon script shell, et comme je passais un temps fou à chercher comment faire des choses simples en shell, j'ai fini par le faire en python.
J'utilise la notion de submodule de git pour introduire des modules plugins vim eux aussi disponible via git.
Sauf erreur, quand tu leur achètes (ou transfères) un nom de domaine, tu as inclus quelques adresses (5, je crois) et des redirections (alias) en quantité.
Comme webmail, il y a au moins Roundcube, et peut-être autre chose depuis (Sogo ?), à vérifier.
Et il y a les scripts sieve côté serveur si j'en crois cette annonce :
Le principe c'est que si le montant n'est pas atteint, la campagne est annulée et les participants sont remboursés.
En pratique, on peut imaginer que les porteurs de projet se gardent une marge pour faire l'appoint au dernier moment s'il manque pas grand-chose. Ils laisseraient pas tomber le projet pour un pouillème du montant nécessaire.
Et je pense que ça ne fait que l'authentification, mais que ça ne brasse pas directement du pognon. A mon avis, il voulait parler de racket au nom de domaine : je l'achète quand il est libre et le revend à Atos assez cher parce qu'ils en ont besoin.
Ce point n'était pas clair pour moi, et effectivement la page WP de 3D-Secure ne parlait pas d'Atos mais il me semblait comprendre que toutes les banques (l'essentiel des françaises du moins) étaient affectées. Dans l'ignorance, j'ai donc courageusement utilisé cette formulation (le système "3D Secure" opéré par Atos wordline) qui, si je l'interprète avec un peu de mauvaise foi, peut laisser entendre que d'éventuels systèmes 3D Secure opérés par d'autres boîtes n'ont pas connu cette panne.
Merci pour la précision.
(D'après ZDNet, CIC - Crédit Mutuel utilise un autre nom de domaine et n'a pas été affecté.)
C'est intéressant pour donner/retirer des droits sur une machine sans partager le mot de passe admin, mais au quotidien, je préfère faire su une bonne fois pour toutes et avoir un terminal "admin" que d'alterner commandes normales et commandes sudo de le même terminal.
Je ne sais pas si la Nef est toujours adossée au Crédit Coopératif pour fournir un compte courant et une CB
En effet, la Nef ne fournit toujours pas de compte courant pour les personnes physiques. Seulement les personnes morales.
Sur le plan "éthique", je crois que la Nef l'emporte un peu sur le Crédit Coop (transparence totale des prêts accordés, écarts de salaire plus faible il me semble,…).
J'ai pas vu passer de dépêche ou journal ici concernant cette conf. Quel site / liste de discussion me conseillez-vous de suivre pour être averti plus tôt et envisager de présenter lors d'un évènement comme ça ?
La question vaut pour les autres confs Python. Je crois que pour les PyCon, l'info est diffusée ici avant le bouclage du programme.
Au boulot, j'ai installé Redmine et Gitolite. Et dans Redmine je peux afficher les dépôts, fermer les demandes selon les messages de commit, etc.
Ça reste moins sympa que Github/Gitlab mais ça marche. Et ça me permet d'avoir des projets Redmine sans dépôt associé, pour des projets qui ne sont pas du code, pour utiliser jute la gestion de tickets, roadmap et tout. Je sais pas si c'est possible dans Gitlab. J'imagine qu'on peut toujours ne pas utiliser le dépôt, mais c'est peut-être pas naturel à présenter à un partenaire non développeur, question interface.
Et Gitolite et Redmine sont dans Jessie alors que pour Gitlab, il faut attendre Stretch pour avoir un paquet.
Si je devais faire le choix aujourd'hui et si Gitlab était dans Debian stable, je pense que je prendrais Gitlab.
Posté par jihele .
En réponse à la dépêche Cheky.
Évalué à 2.
Il faudrait un juriste pour dépatouiller ce qui est applicable dans leurs conditions d'utilisation et statuer sur le cas d'un service - même gratuit - en ligne qui récupère le contenu (perso, j'utilise celui-ci : https://lbc2rss.superfetatoire.com/).
Dans le cas de Checky, je ne pense pas qu'on puisse embêter quelqu'un qui diffuse un code source qui permet de le faire. Et je ne pense pas qu'on aille embêter un individu qui utilise ça chez lui pour son compte.
Mais merci de rappeler que LBC n'aime pas trop ça (ce qui explique pourquoi il n'y a pas d'API pour le faire proprement).
Tu peux aussi interdire à root de se connecter en SSH (c'est interdit par défaut, il me semble), et alors tu dois te connecter d'abord avec ton utilisateur, puis faire su.
L'essentiel des attaques à l'aveugle se concentre sur root, faute de connaître les utilisateurs du système.
Et en pratique, le risque n'est pas le même selon qu'on est une boîte qui gère des projets industriels importants, voire secret-défense, ou bien qu'on est une PME qui cherche à protéger sa PI face à ses concurrents directs.
Google est curieux et à la solde du gouvernement US, OK, mais mes projets, ça l'intéresse pas trop. D'où la difficulté à faire passer le message en interne dans ma boîte et à faire utiliser des solutions internes plutôt que cloud.
si les informations transitent en clair par e-mail, la question du prestataire fournissant la boite e-mail parait assez accessoire. Et si les infos sont chiffrées, le fait que ça soit gmail ou un autre est sans incidence.
Je vais peut-être dire une bêtise, mais tu sembles poser qu'il n'existe que deux cas,
le "tout en clair sur tout le canal" (le fournisseur d'accès peut lire le contenu, les autres utilisateurs du wifi aussi)
le "tout chiffré même le message" (PGP à fond)
Le fonctionnement courant, je crois, est de dialoguer avec le serveur de messagerie en connexion chiffrée (SSL) mais d'échanger des messages non chiffrés (pas de PGP de gros barbus). Dans ce cas, la question du prestataire n'est pas accessoire. C'est pas pareil si c'est chez Google ou dans le serveur mail de la boîte.
[^] # Re: Free : RAS
Posté par jihele . En réponse au journal Bouygues et IP fixe... qui change (où l'on parle aussi de fake MX). Évalué à 5. Dernière modification le 02 octobre 2017 à 11:15.
Je plussoie parce que je comprends bien le problème. Mais si un message cryptique adressé à tous pourrait générer de la confusion, il pourrait y avoir dans l'interface de la box un message d'avertissement et un lien vers une interface avec un endroit où spécifier un moyen d'être prévenu (une adresse électronique, quoi). En opt-in, donc. Ça ne toucherait que la minorité qui utilise le service de redirection de ports de la box. Juste une idée comme ça; il y a peut-être mieux ou plus simple.
D'ailleurs j'ai déjà configuré une adresse pour recevoir les messages du répondeur (super option, ça !). J'ai juste besoin d'une case à cocher "être prévenu par courriel si jamais l'IP change".
Quand-même, avec le développement des NAS qui hébergent des serveurs pour partager les photos en ligne, le problème commence à toucher un public plus large, non ?
[^] # Re: merci
Posté par jihele . En réponse au message serveur et mailing list. Évalué à 4.
J'administre (co-administre) un serveur dédié courriel (Postfix + Dovecot) + mailing-lists (Mailman) personnel. Rien de folichon, quelques utilisateurs et des listes faible débit à max 100 inscrits.
Il m'arrive de regretter la période où j'étais en mutualisé et tout marchait tout seul… Ça marche assez bien tout seul, heureusement, mais aujourd'hui j'ai moins voire plus du tout de temps à y consacrer alors le peu que ça demande, ça m'emmerde. Et je parle pas des migration de distro (Jessie -> Stretch).
L'effort à produire pour l'administration est trop important pour le service rendu. C'était bien de le faire parce que j'ai appris des choses, mais franchement, ça vaut pas le coût. Sans parler dans ton cas du coût environnemental de faire tourner un serveur physique juste pour cette liste.
Si tu as des problèmes avec ta liste aujourd'hui, comme ont dit les autres, je suis pas sûr que ça marchera mieux si tu le fais. C'est plutôt lié aux utilisateurs ou aux fournisseurs de leurs boîtes, et ces fournisseurs seront sans doute encore plus tatillons avec les messages de ton serveur perso qu'avec ceux d'OVH. Donc commence par régler ça puis réévalue le besoin. Si vraiment ça va pas chez OVH, cherche à faire héberger ta liste ailleurs (hébergement associatif, peut-être).
Pour la distro, Debian ça va bien, c'est stable, difficile à casser. Mais la config du serveur de courriel est pas triviale du tout, il y a plein de détails à prendre en compte pour que ça marche bien (c'est pas le tout que les messages partent, si c'est mal configuré les messages peuvent être refusés par le serveur d'arrivée) et des erreurs à pas faire pour pas être relais de spam (ça encore c'est pas trop difficile, surtout dans ton cas où ça hébergerait juste un serveur de listes). Je ne connais pas de distro/logiciel avec une config assistée toute faite. Attention aussi à l'enregistrement DNS.
Des fois les messages n'arrivent pas chez Gmail ou ailleurs et tu finis par découvrir que c'est parce que tu as pas mis en place une mesure de sécurité (enregistrement SPF,…). Ça dérange personne sauf Gmail ou Hotmail et après 3 mois tu finis par découvrir que tous les inscrits à la liste qui sont chez eux ne reçoivent plus les messages et personne s'en était rendu compte. Super.
Quant à "transmettre la connaissance par la suite", c'est peut-être le point le plus utopique. Tu risques de devoir te traîner le truc à gérer jusqu'à ce que tu en puisses plus. Et le successeur créera un Yahoo group ou mieux une page Facebook pour communiquer avec tout le monde…
C'était la minute optimiste.
# Pas de problème
Posté par jihele . En réponse au message Scraping de sites web : aspects légaux. Évalué à 4.
Si je comprends bien, le site mets à disposition des photos qu'on peut visualiser mais pas télécharger sous forme d'archive, les parents peuvent télécharger les photos une par une mais c'est fastidieux.
Si ton script permet de télécharger toutes les photos d'un coup sans s'embêter, je ne vois pas le problème. Il ne met pas à disposition un contenu interdit, il permet juste d'avoir un accès plus commode à un contenu autorisé.
Leur réponse, c'est un peu n'importe quoi. Je sais pas si c'est fait exprès pour noyer le poisson ou pas. Effectivement, si les parents peuvent télécharger les photos, ils sont moins tentés d'acheter le livre, donc ça n'arrange pas les vendeurs du site.
Franchement, si la situation est bien celle-ci, je ne me retiendrais pas de partager le script.
(Et puis je doute que beaucoup de parents sachent choper le truc sur github, installer python, etc… donc la portée devrait être assez limitée pour que ça passe inaperçu.)
[^] # Re: Etre disruptif
Posté par jihele . En réponse au journal Attention, ça va secouer !. Évalué à 3.
Concernant l'atelier sur l'économie disruptive de l'université d'été du MEDEF :
https://www.franceinter.fr/emissions/le-moment-meurice/le-moment-meurice-30-aout-2017
[^] # Re: atop
Posté par jihele . En réponse au message Identification responsable d'une forte charge sur un serveur. Évalué à 2.
Merci ! Je connaissais pas, j'avais fait un script à la main pour faire ça.
[^] # Re: Git + ansible + liens symboliques
Posté par jihele . En réponse au journal kyrbeis: un outil basique de gestion de dotfiles. Évalué à 3.
Pareil, j'ai regardé qqs trucs et j'ai finir par coder mon script shell, et comme je passais un temps fou à chercher comment faire des choses simples en shell, j'ai fini par le faire en python.
J'utilise la notion de submodule de git pour introduire des modules plugins vim eux aussi disponible via git.
[^] # Re: Gandi
Posté par jihele . En réponse au message Hébergement mail ?. Évalué à 2.
Qqs infos dans la newsletter d'août : https://news.gandi.net/fr/2017/08/nouveautes-gandi-mail
# Gandi
Posté par jihele . En réponse au message Hébergement mail ?. Évalué à 4.
Sauf erreur, quand tu leur achètes (ou transfères) un nom de domaine, tu as inclus quelques adresses (5, je crois) et des redirections (alias) en quantité.
Comme webmail, il y a au moins Roundcube, et peut-être autre chose depuis (Sogo ?), à vérifier.
Et il y a les scripts sieve côté serveur si j'en crois cette annonce :
https://www.gandi.net/news/en/2017-03-09/11028-sieve_server_rules_activated_on_gandi_mail/
[^] # Re: Moi aussi !!
Posté par jihele . En réponse au message Recherche de boulot en temps partiel voir mi-temps. Évalué à 2.
Pour les cadres au forfait jour, je pense pas que ce soit évident d'avoir des demi-journées de temps partiel.
[^] # Re: tout ou rien ?
Posté par jihele . En réponse au journal Diskiopi démarre un kick. Évalué à 4.
Le principe c'est que si le montant n'est pas atteint, la campagne est annulée et les participants sont remboursés.
En pratique, on peut imaginer que les porteurs de projet se gardent une marge pour faire l'appoint au dernier moment s'il manque pas grand-chose. Ils laisseraient pas tomber le projet pour un pouillème du montant nécessaire.
[^] # Re: Tu as eu peur ?
Posté par jihele . En réponse au message --== GUIDE DE L'ADMINISTRATEUR LINUX ==--. Évalué à 4.
A quand un procédure pour promouvoir les entrées de forum en journal ?…
[^] # Re: la plupart du temps je sais ce que je fais…
Posté par jihele . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 2.
Je connais pas bien svn. En l'occurrence c'était un dépôt partagé, mais j'y ai laissé la branche que j'avais pas encore poussée. C'est déjà pas mal.
[^] # Re: la plupart du temps je sais ce que je fais…
Posté par jihele . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 3.
Un peu rien à voir mais bon, pour l'anecdote.
J'utilise git pour mon code, donc j'ai peur de rien.
L'autre jour, j'ai raté un
find . [...] -delete
Y compris le répertoire .git…
[^] # Re: au moins, ils se sont pas fait piquer le DN
Posté par jihele . En réponse au journal Panne du système 3D Secure… pour cause de non renouvellement de nom de domaine. Évalué à 10.
Et je pense que ça ne fait que l'authentification, mais que ça ne brasse pas directement du pognon. A mon avis, il voulait parler de racket au nom de domaine : je l'achète quand il est libre et le revend à Atos assez cher parce qu'ils en ont besoin.
[^] # Re: 3D Secure opéré par Atos ? Ou pas...
Posté par jihele . En réponse au journal Panne du système 3D Secure… pour cause de non renouvellement de nom de domaine. Évalué à 7. Dernière modification le 15 juin 2017 à 23:36.
Ce point n'était pas clair pour moi, et effectivement la page WP de 3D-Secure ne parlait pas d'Atos mais il me semblait comprendre que toutes les banques (l'essentiel des françaises du moins) étaient affectées. Dans l'ignorance, j'ai donc courageusement utilisé cette formulation (le système "3D Secure" opéré par Atos wordline) qui, si je l'interprète avec un peu de mauvaise foi, peut laisser entendre que d'éventuels systèmes 3D Secure opérés par d'autres boîtes n'ont pas connu cette panne.
Merci pour la précision.
(D'après ZDNet, CIC - Crédit Mutuel utilise un autre nom de domaine et n'a pas été affecté.)
[^] # Re: Ouf
Posté par jihele . En réponse au journal VITE ! Mettez à jour votre distrib !. Évalué à 4.
C'est intéressant pour donner/retirer des droits sur une machine sans partager le mot de passe admin, mais au quotidien, je préfère faire su une bonne fois pour toutes et avoir un terminal "admin" que d'alterner commandes normales et commandes sudo de le même terminal.
[^] # Re: Quel genre de réponse attends-tu ?
Posté par jihele . En réponse au journal Boursorama n’aime pas qu’on bloque des choses. Évalué à 8.
En effet, la Nef ne fournit toujours pas de compte courant pour les personnes physiques. Seulement les personnes morales.
Sur le plan "éthique", je crois que la Nef l'emporte un peu sur le Crédit Coop (transparence totale des prêts accordés, écarts de salaire plus faible il me semble,…).
Voir cette synthèse de l'étude d'Attac et des Amis de la Terre :
http://www.amisdelaterre.org/IMG/pdf/synthese_rapport_banques_2011.pdf
[^] # Re: Participer
Posté par jihele . En réponse à la dépêche PyParis 2017 — fin des inscriptions dans 10 jours. Évalué à 2.
Ah oui, je me souvenais pas. Merci.
Je peux donc continuer sereinement à utiliser linuxfr comme seule source d'information
sur l'informatique.# Participer
Posté par jihele . En réponse à la dépêche PyParis 2017 — fin des inscriptions dans 10 jours. Évalué à 2.
Merci pour l'info. Le contenu est intéressant.
J'ai pas vu passer de dépêche ou journal ici concernant cette conf. Quel site / liste de discussion me conseillez-vous de suivre pour être averti plus tôt et envisager de présenter lors d'un évènement comme ça ?
La question vaut pour les autres confs Python. Je crois que pour les PyCon, l'info est diffusée ici avant le bouclage du programme.
[^] # Re: étape suivante: gitlab
Posté par jihele . En réponse au journal Serveur Git avec Gitolite. Évalué à 3.
Au boulot, j'ai installé Redmine et Gitolite. Et dans Redmine je peux afficher les dépôts, fermer les demandes selon les messages de commit, etc.
Ça reste moins sympa que Github/Gitlab mais ça marche. Et ça me permet d'avoir des projets Redmine sans dépôt associé, pour des projets qui ne sont pas du code, pour utiliser jute la gestion de tickets, roadmap et tout. Je sais pas si c'est possible dans Gitlab. J'imagine qu'on peut toujours ne pas utiliser le dépôt, mais c'est peut-être pas naturel à présenter à un partenaire non développeur, question interface.
Et Gitolite et Redmine sont dans Jessie alors que pour Gitlab, il faut attendre Stretch pour avoir un paquet.
Si je devais faire le choix aujourd'hui et si Gitlab était dans Debian stable, je pense que je prendrais Gitlab.
[^] # Re: conformité aux CGU
Posté par jihele . En réponse à la dépêche Cheky. Évalué à 2.
Il faudrait un juriste pour dépatouiller ce qui est applicable dans leurs conditions d'utilisation et statuer sur le cas d'un service - même gratuit - en ligne qui récupère le contenu (perso, j'utilise celui-ci : https://lbc2rss.superfetatoire.com/).
Dans le cas de Checky, je ne pense pas qu'on puisse embêter quelqu'un qui diffuse un code source qui permet de le faire. Et je ne pense pas qu'on aille embêter un individu qui utilise ça chez lui pour son compte.
Mais merci de rappeler que LBC n'aime pas trop ça (ce qui explique pourquoi il n'y a pas d'API pour le faire proprement).
[^] # Re: Connexion par clef chiffrée
Posté par jihele . En réponse au message SECURITE | ssh et connexion sans mot de passe. Évalué à 2.
Tu peux aussi interdire à root de se connecter en SSH (c'est interdit par défaut, il me semble), et alors tu dois te connecter d'abord avec ton utilisateur, puis faire su.
L'essentiel des attaques à l'aveugle se concentre sur root, faute de connaître les utilisateurs du système.
[^] # Re: Je cherche maintenant à faire connaître cette chaîne, petit à petit …
Posté par jihele . En réponse au message Jeux vidéos sur GNU/Linux et Youtube. Évalué à 8.
Oui, un journal qui parle de Linux, ça ferait du bien.
[^] # Re: Pratique vs théorique
Posté par jihele . En réponse au message Confidentialité des communications professionnelles et utilisation de Gmail. Évalué à 4.
Et en pratique, le risque n'est pas le même selon qu'on est une boîte qui gère des projets industriels importants, voire secret-défense, ou bien qu'on est une PME qui cherche à protéger sa PI face à ses concurrents directs.
Google est curieux et à la solde du gouvernement US, OK, mais mes projets, ça l'intéresse pas trop. D'où la difficulté à faire passer le message en interne dans ma boîte et à faire utiliser des solutions internes plutôt que cloud.
[^] # Re: je dirais que non
Posté par jihele . En réponse au message Confidentialité des communications professionnelles et utilisation de Gmail. Évalué à 2.
Je vais peut-être dire une bêtise, mais tu sembles poser qu'il n'existe que deux cas,
le "tout en clair sur tout le canal" (le fournisseur d'accès peut lire le contenu, les autres utilisateurs du wifi aussi)
le "tout chiffré même le message" (PGP à fond)
Le fonctionnement courant, je crois, est de dialoguer avec le serveur de messagerie en connexion chiffrée (SSL) mais d'échanger des messages non chiffrés (pas de PGP de gros barbus). Dans ce cas, la question du prestataire n'est pas accessoire. C'est pas pareil si c'est chez Google ou dans le serveur mail de la boîte.
Non ?