liberforce a écrit 4744 commentaires

Excuses acceptées (j'ai eu mon diplôme d'ingé par apprentissage).

Nan, ça c'était Allan Day. Qui a depuis (ça remonte à un bon moment) indiqué qu'il avait eu tort et que les extensions étaient une bonne chose.

Ouaip, je viens d'en faire le constat, j'ai bidouillé en parallèle. J'avais lu en diagonale, j'avais même pas fait gaffe que sa demande était spécifique à ncurses.

Au final, j'ai modifié son code pour que ça marche, et effectivement, il faut passer par get_wch, ne pas oublier le %lc pour les caractères wide, et L'é' pour définir une constante wide, sans oublier de se lier à ncursesw plutôt que ncurses, ni le setlocale.

#include <stdio.h>
#include <stdlib.h>
#include <ncursesw/ncurses.h>
#include <locale.h>
wchar_t wch = L'é';
int err;
int main (int argc, char **argv)
{
 setlocale (LC_ALL, "");
 initscr();
 raw();
 noecho();
 keypad(stdscr, TRUE);
 while(wch != KEY_F(1))
 {
 clear();
 printw("char=%lc", wch);
 refresh();
 err = get_wch(&wch);
 }
 endwin();
 return 0;
}

Et le fichier CMakeLists.txt que j'ai utilisé pour compiler:

project (CURSES)
cmake_minimum_required (VERSION 2.8)
find_package (PkgConfig REQUIRED)
pkg_check_modules (NCURSESW REQUIRED ncursesw)
include_directories (${NCURSESW_INCLUDE_DIRS})
link_directories (${NCURSESW_LIBRARY_DIRS})
add_executable (curses main.c)
add_definitions (${NCURSESW_CFLAGS_OTHER} -g -Wall)
target_link_libraries (curses ${NCURSESW_LIBRARIES})

Tu auras ce genre d'erreurs si tu sauves ton fichier dans un charset où ce caractère prend plus d'un seul caractère. En gros en ISO-8859-1, 'é' prend un octet, mais en UTF-8, 'é' prend deux octets, il ne tient donc pas dans un char !

Il faut alors définir une chaîne de caractères, et plus juste un caractère…

Si, si, c'est bien une histoire de setlocale.

http://blog.freeside.fr/post/2007/03/27/Oisiweb%3A-Comment-afficher-une-chaine-de-caracteres-avec-des-accents

Si ton caractère "é" vaut 169, c'est que tu es en ISO-8859-1, et pas en UTF-8.

Le fichier suivant enregistré en UTF-8 fonctionne chez moi (ma distrib est par défaut en UTF-8).

#include <stdio.h> /* for printf */
#include <locale.h> /* for setlocale */
int main (void)
{
 setlocale (LC_ALL, "");
 printf ("éèâ\n");
 return 0;
}

C'est ce que m'a dit le technicien. Ensuite je me suis rendu compte que le mail expédié provenait de sa boîte gandi, et je ne sais pas si le domaine associé est configurée avec -all. Du coup pas de certitude. Pourrais tu également cesser ce ton hautain, ce serait sympa. Merci.

D'après Gandi, la même manip avec une boîte Free fonctionne. Le problème survient avec SFR.

et en plus liberf0rce est capable de venir faire un journal comme quoi l'antispam de sfr il est tout pourri.

Pour l'antispam, j'utilise Thunderbird, merci. Mais je préfère avoir des spams que perdre des mails. Est-ce trop compliqué à comprendre ?

SPF ne dit pas qu'un mail qui échoue au test SPF doit être refusé. C'est ce qu'il appelle la "local policy". En gros, tu peux très bien être conforme à SPF en classant le mail dans les spams. Là le fait que SFR refuse directement le mail est ce qui pose problème.

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

First of all, realize that the SPF result is deterministic and defined by the SPF specification. You do not get any choice in the matter. However, any decision your mail software makes based on the SPF result is your choice. This advice concerns your "local policy" – how you treat SPF results.

Assuming the recipient does not whitelist forwarders, then the answer is: Yes, it does break forwarding. You (the forwarder) will have to switch from forwarding, where the envelope sender is preserved, to remailing, where the envelope sender is changed.

Du coup je vais me retrouver avec l'expéditeur changé partout ? Parce que si je vois comme expéditeur alias@relais, le redirection n'a plus aucun intérêt.

Pas crédible (tu as déjà la flemme de changer d'hébergement mail…).

Alors là, crois bien que je ne vais pas me gêner, ça fait déjà un moment que j'y pense. Le fait que les enregistrements faits avec leur box soient chiffrés pour être utilisable uniquement avec cette box donnée aide aussi.

La seule chose qu'on pourrait dire là dedans, c'est que SPF n'est pas 100% cohérent. La RFC 4408 indique:

If domain owners choose to publish SPF records, it is RECOMMENDED that they end in "-all", or redirect to other records that do, so that a definitive determination of authorization can be made.

Donc pas étonnant que des sites comme celui de steam utilisent -all. Sauf que ça pète le forwarding. Ensuite côté bonnes pratiques, SPF indique que ça doit être corrigé par le destinataire, ce qui parait logique, sinon tu pourrais avor du man-in-the-middle et te faire passer pour n'importe qui en tant que relais.

SPF édicte des bonnes pratiques, après si tout le monde pisse dessus, c'est sûr que ça risque pas de fonctionner.

Je suis sûr que si tu arrives avec le fric pour payer la gestion du projet + le dev + la maintenance du bousin, ça doit être négociable.

On ne m'a pas dit que c'était trop cher ! On m'a juste dis "c'est pas nous". Sauf que Gandi me dira que ce n'est pas eux qui refusent le mail, et que steam me dira que c'est au forwarder ou au destinataire de contourner le problème. En gros, on tue le forwarding avec SPF.

La seule solution qui ne soit pas du contournement, c'est de le faire côté destinataire. Et j'ai de toute façon déjà contacté Gandi pour voir s'ils peuvent mettre en place une solution de contournement, au cas où. Mais là encore, pourquoi serait-ce à eux d'absorber les coûts ?

Imagine toi en train de bosser pour le 3e plus gros FAI et qu'un client te demande de modifier juste pour lui ta politique de sécurité, forcément c'est pas simple.

Imagine toi être un utilisateur qui a un problème et qu'on essaie d'enfumer avec des explications vaseuses. C'est pas simple non plus. Ça ne me dérange pas que les gens ne connaissent pas la réponse, mais les procédures qualité doivent te dire où les trouver, ou vers qui transférer le dossier. Là j'ai eu droit à "je vais voir mon pote du plateau qui-s-y-connait", et 1 fois sur 3 ils bottaient en touche pour fermer directement le dossier parce qu'à mon avis le gars ne savait même pas à qui refiler le dossier.

Ensuite qu'on me dise: "trop d'impact sur la politique sécurité, won't fix", ok, ça me va comme réponse. Mais quand on essaie de t'expliquer que c'est la faute de tout le monde, mais pas la leur, alors que openspf.org dit exactement le contraire, faut pas me prendre pour un lapin de 3 semaines…

Est-ce que quelqu'un lit les liens que je donne ? Tu es en train de me dire que chaque site devrait ajouter tous les forwarders possibles à travers le monde ? Ça te paraît vraiment pertinent ? On ne parle pas juste de Gandi là, on parle du concept même de forwarding.

Quand tu déménages, tu fais une redirection de courrier, ou tu vas voir tous tes interlocuteurs le jour du déménagement pour leur dire qu'à partir de demain il faut t'écrire à une autre adresse ?

En fait les serveur SFR peut tout à fait faire sa vérification SPF de son côté. Mais il faut juste que je puisse lui dire qu'en plus de ce qu'a déclaré le site, il doit accepter mon forwarder. C'est comme faire une procuration pour un vote, tu indiques que tu fais confiance à une autre personne. Bin là je veux juste que SFR fasse confiance au courrier relayé par Gandi.

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.