liberforce a écrit 4730 commentaires

La liste blanche gérée par l'utilisateur, c'est la solution optimale. Mais ne serait-ce que permettre à l'utilisateur d'avoir les mails qui échouent au test SPF serait un grand pas en avant. J'irai les chercher dans les spams, mais au moins je les recevrai.

http://www.openspf.org/Best_Practices/Forwarding :

Even a large ISP can do it. They might complain that they do not know what forwarders their users have set up. Maybe so, but they can:

• provide a web-based configuration page to list forwarders.
• default to not reject messages that fail SPF for users who have not configured their forwarders (but still add the "Received-SPF" header).
• give users who have configured their forwarders the option of rejecting messages that fail SPF.

Personnellement, je n'ouvre jamais de boite chez mon FAI, celui-ci pouvant changer.

C'était la raison de l'alias mail ;-)

Et merci pour imapsync, la migration des mails existants est une des raisons qui faisait que j'avais la flemme de changer…

Oui, ils m'ont fait aussi le coup de l'ip de ma box blacklistée par spamhaus.org, jusqu'à ce que je leur apprenne (sic) que les mails envoyés ne transitent pas par ma box. Il y avait clairement indiqué sur le site que l'adresse est par défaut considérée comme émettrice de spam parce qu'elle est dynamique. Il y a alors un lien à suivre pour demander à être mis sur liste blanche.

Non, pas normal. Oui, c'est un comportement connu, et explicable simplement par SPF, j'ai bien compris. Mais pas normal dans le sens où ce n'est pas le comportement souhaité par SPF, qui indique noir sur blanc que le serveur final doit prendre en compte le forwarding.

Faudrait que SFR whiteliste Gandi comme "infra sérieuse qui ne me ment pas".

La solution c'est une interface web où l'utilisateur peut rentrer son forwarder. SFR n'a pas à whitelister Gandi pour tout le monde.

http://www.openspf.org/Best_Practices/Forwarding

http://www.openspf.org/FAQ/Forwarding:

Does SPF break forwarding?

Yes, but only if the receiver checks SPF without understanding their mail receiving architecture. If receivers are going to check SPF, they should whitelist forwarders that do not rewrite the sender address from SPF checks.

[…]
Assuming the recipient does not whitelist forwarders, then the answer is: Yes, it does break forwarding.

C'est au destinataire de permettre d'ajouter le serveur de forarding dans une liste blanche. L'expéditeur est incapable de savoir quel serveur j'utilise.

Voir aussi: http://www.openspf.org/Best_Practices/Forwarding

J'étais chez Tele2, ils se sont fait racheter, et l'inertie aidant…

Parce que j'essaie d'être constructif et de faire avancer le monde qui m'entoure. Et pour la même raison que quand je trouve un bug dans un logiciel libre, je le remonte: pour que les autres qui ont le même problème que moi mais moins de connaissances techniques puissent s'en sortir. Parce que ce genre de fonctionnalités ne devraient pas être réservées à une élite.

Accessoirement, cela m'intéressait de voir jusqu'où on pouvait monter au niveau hotline technique. Note qu'on m'a dit que ce n'était pas possible techniquement, ou qu'ils n'y pouvaient rien, pas que cela représentait un investissement trop important en temps et/ou argent, et que c'était donc un choix délibéré (ce que j'aurais trouvé parfaitement recevable).

Sinon, je n'avais pas stocké mes mails chez gandi parce que j'hésitais à changer de prestataire pour mon hébergement, du coup je me contentais de la redirection.

Et pour mon départ de chez SFR, j'y pense depuis un bon moment, là ça ne va qu'accélérer les choses.

J'ai bien compris que c'est le but du SPF. Le soucis c'est que contrairement aux bonnes pratiques SPF édictées sur openspf.org, SFR ne me permet pas de mettre mon forwarder (ici, Gandi) sur liste blanche.

Ce qui fait que tous les mails provenant de sites qui ont une configuration SPF correcte (steampowered.com, mobile.free.fr, digiposte.fr par exemple) se retrouvent refusés. Je ne les ai donc même pas dans mes spams, impossible de les récupérer ! Et évidemment, le premier mail reçu est toujours celui de confirmation d'incription, avec un lien à cliquer. Du coup, c'est la galère, car il y a rarement un moyen de le ré-expédier.

Je viens de voir que je ne suis pas le seul à avoir des problème de réception de mails avec SFR et SPF. Cela confirme bien que le problème est l'impossibilité de whitelister un forwarder, et que SFR n'a en rien envie de corriger ce problème.

Est-ce que des gens ont fait le test avec Free ? Car ma résiliation n'est plus loin.

Mais C++ est un langage de haut niveau avec une de bonnes bibliothèques.

Tout comme C est un bon langage avec de bonnes bibliothèques. Entre écrire du code en C de base et du C avec la GLib, il y a un monde.

Un ver dont j'ai oublié le nom s'était massivement répandu, les ordinateurs tombaient comme des mouches, les gens réinstallaient, configuraient Internet pour télécharger/mettre à jour l'antivirus et les pilotes, et avant même la fin étaient de nouveau infectés. Bref, il suffisait de prendre ses précautions avant de le connecter, mais c'était hors de portée de l'utilisateur moyen.

Blaster, Sasser ?

Cela fait un moment que des gens tentent de l'intégrer, Rodrigo Moya avait blogué plein de choses sur ses tentatives d'intégration de DBus au kernel:
http://blogs.gnome.org/rodrigo/tag/dbus/

Le gros soucis de Vala: c'est un langage nouveau, et spécifique à GObject. Du coup les gens qui veulent coder sur ta plateforme doivent apprendre un nouveau langage. Cela élève encore un peu plus la barrière à la contribution, et restreint encore un peu plus le nombre de gens intéressés.

Enfin personnellement, pour une petite appli qui va se loger dans le systray pour m'indiquer un truc ou un autre de temps en temps, je préfère que ce soit écris dans un langage plutôt concis et plus maintenable ou plus facilement hackable qu'en C avec des risques de fuites mémoire entre autre.

Là je ne suis pas trop d'accord, j'ai encore le souvenir d'applets perl de notification réseau ou des mises à jour me bouffant 50Mo de RAM juste parce que c'était les seuls trucs en perl lancés. Pour un truc résident, je préfère un truc en C qui consomme peu de mémoire, et qu'on corrige les fuites.

Le but n'est pas d'empêcher le développeur de faire une connerie, mais juste de l'empêcher de se plaindre. En C aussi tu peux aler taper dans des membres privés si tu veux vraiment. En python c'est aussi au bon vouloir. Mais le gars qui tape dans des membres privés et se plaint que l'implémentation a changé et que ça lui pète son code, il se fait rire au nez, à juste raison.

Ça a commencé avec l’idée de démarrer de zéro un projet juste parce que la licence de KDE ne leur plaisait pas a l’époque (oui, je ne suis pas tout jeune…).

Pas la licence de KDE, la licence de Qt, qui était proprio à l'époque.

Développer tout en C pour une raison dont je ne me rappelle plus.

Faux. Dès les premières versions de GNOME, tout un tas de langages étaient utilisés. GNOME a toujours été "langage-agnostic", c'est à dire que des applis de tous langages sont acceptés. Si des applications étaient en C, c'est parce que c'est le langage qu'ont choisi les développeurs desdites applications. Ç'aurait pu être un autre. En revanche, les bibliothèques sont en C, car la génération de bindings vers d'autres langages est plus facile à partir du C que du C++ (de ce que j'en ai entendu).

On va copier la base de registre de Windows.

GConf/Dconf n'est pas la base de registre. Ces sytèmes fournissent des valeurs par défaut pour les clés, documentent chaque clé, et servent en gros de base de configuration avancée et centralisée. En quoi est-ce mal ?

Oh et puis non on va faire du .NET, à une époque ou Mono donne encore l'impression d’être un projet loin d’être mur et très en retard sur .NET.

C'est Miguel de Icaza qui est parti sur Mono, et bien que co-fondateur de GNOME, il n'est plus actif dans la communauté GNOME depuis des années. GNOME a officiellement une application en mono, Tomboy. Les autres sont des applications pour GNOME (comme Banshee par exemple), ce qui est différent.

On enlève tout ce qui dépasse sur l'interface graphique, moins l'utilisateur peut en faire mieux c'est.

La configuration se découpe en 3 étages. Les paramètres les plus fréquemment modifiés sont accessibles dans l'interface de GNOME. Ceux un peu moins courants, ou pour lesquels il n'y a pas encore d'interface graphique sont dans gnome-tweak-tool. Enfin, tous ces paramètres, + les autres paramètres avancés sont dans dconf, accessible graphiquement avec dconf-editor et en ligne de commande avec gsettings.

Une interface (ou ce qui en reste) qui regarde fort du coté des écrans tactiles alors que pratiquement personne ne l'utilise sur ce type de matos.

Donc ta logique c'est que GNOME ne doit faire de tactile parce que les périphériques tactiles n'utilisent pas GNOME ? C'est imparable. C'est sûr que s'ils ne bossent pas pour être tactiles, ça va être dur d'être utilisé.

Au passage, tu as quand même des technos prometteuses qui arrivent, comme Leap Motion, et toi ce que tu proposes, c'est de rester avec sa bonne vieille souris dans la main ? Il faut bien à un moment miser sur le futur, non ?

Et maintenant javascript, qui on va dire n'a pas la réputation d’être un langage utilisé pour des softs complexes et de qualité.

C'est à peu près le seul point sur lequel on est d'accord.

Il ne se "passent pas" de l'énorme bibliothèque en python, Javascript devient juste le langage conseillé pour un nouveau projet. Mais tous les autres langages restent supportés, c'est juste qu'il y en a un mis en avant. Le but n'est pas de porter toutes les applications, mais si de nouvelles applications doivent être écrites, le js sera conseillé, c'est tout. C'était le seul moyen pour fournir un SDK: mettre un langage en avant.

rejete car entre en concurrence avec Gnome pour certaines briques… Si ca c'est pas une raison bidon!

C'est sûr, un des gars a porté les bindings python pour le passage a GObject-introspection dit sûrement des conneries en disant que Javascript est une bonne décision !

C'est clair que c'est une décision qu'on peut trouver complètement idiote. Javascript est un langage tout pourri. Les différents moteurs gjs ou seed déjà utilisé sous GNOME utilisent même des dialectes incompatibles entre eux. Javascript en tant que tel laisse l'impression d'être un gros hack. Et pourtant, dans cette histoire, la force de javascript, c'est sa pauvreté. En python, on peut effectivement hésiter entre utiliser les API intégrées de base dans le langage, ou utiliser les équivalents GObject, GLib.

En javascript, le langage est tellement à poil de base, qu'en fournissant les API GObject, il n'y a pas 50 manières de coder un truc. C'est clair que le temps d'avoir quelque chose de vraiment mieux foutu, ça va prendre du temps, que le portage vers ECMAScript 6 va être long, mais en attendant, il sera possible de fournir un SDK pour GNOME, et abaisser le niveau requis pour commencer à contribuer. J'aurais aussi préféré python. Mais je comprends pourquoi Javascript a été choisi. L'avenir nous dira si cela aura été un choix judicieux.

Quant au retard de GTK, la fusion de Clutter et GTK est prévue pour GTK 4. Cela permettra de mutualiser les ressources, et de faire passer GTK à un modèle scène/acteur comme celui de Clutter.

ou des trolleurs comme Lennart PÖTRING.

Déjà, ça s'écrit "Lennart Poettering", et le qualifier de trolleur est un peu limite. Décrié, contesté, mais il n'est pas plus trolleur que Linus.

Nos bugs d'aujourd'hui sont nos emplois de demain

Et pour le reste, un bon tuto bash:
http://abs.traduc.org/abs-5.3-fr/ (français)
http://www.tldp.org/LDP/abs/html/ (anglais)

Tu vas rire, mais je pensais vraiment être en train de lire un journal et pas une dépêche !

En fait aucune des boîtes associées ne proposait de choses intéressantes pour moi. Du coup j'ai préféré finir d'écrire mon "résumé" anglais pour essayer de trouver un vrai job. Merci de donner les problèmes, ils n'étaient pas accessibles sur leur site si on arrivait trop tard.

Les journaux sont des espaces personnels mutualisés d'expression libre ayant rapport ou pas avec Linux ou le monde du Logiciel libre.

Bon -10.