Cher journal,
la prose qui suit est le récit de ma bataille contre la hotline de SFR. Au risque de vous spoiler: cette dernière a gagné (ou perdu - un client - au choix).
Commençons du début: mon problème concerne la réception de mail. Parfois, certains mails se perdent, je ne les reçois jamais. J'ai une configuration un peu exotique pour le péquin moyen, mais rien de bien extraordinaire non plus: j'ai acheté mon nom domaine chez gandi.net, et j'utilise chez eux un alias mail, qui redirige le courrier qui y est expédié vers ma boîte mail SFR.
Après m'être inscrit sur différents sites (mobile.free.fr, steampowered.com, et plus récemment, digiposte.fr), je me suis rendu compte qu'en donnant mon alias mail comme adresse pour ces sites, je ne recevais jamais leur courrier. Le première fois, j'ai appelé Free, pour leur signaler le problème (et le hotliner s'en foutait pas mal, ne voyait pas l'intérêt de remonter le fait que d'autres clients auraient sans doute le même problème que moi). La seconde fois, j'ai contacté gandi. Eux ont été bien plus efficaces, me donnant les logs du serveur SMTP, en me disant que le serveur SMTP de SFR était le responsable. Ci dessous:
J'ai pu mettre la main sur la trace d'un mail provenant de noreply@steampowered.com envoyé à 12:23. Ce mail est passé par notre anti-virus/anti-spam, et a été correctement relayé au serveur de SFR (voir la ligne suivante indiquant relay=smtp-in.sfr.fr):
Feb 20 12:23:47 10.0.21.100 postfix/smtp[17888]: 7F3FF41C0A7: to=xxxxxxxx@sfr.fr, relay=smtp-in.sfr.fr[93.17.128.16]:25, delay=1.7,
delays=0.29/0/0.03/1.3, dsn=5.7.1, status=bounced (host smtp-in.sfr.fr[93.17.128.16] said: 554 5.7.1 noreply@steampowered.com: Sender address rejected: Please%see%http://spf.pobox.com/why.html?sender=noreply%40steampowered.com&ip=217.70.183.197&receiver=msfrf2207 : Reason: mechanism (in reply to MAIL FROM command))SFR a cependant refusé le mail comme vous pouvez le voir ci-dessus (Sender address rejected….)
Le problème vient donc de SFR.
Le lien donné dans la réponse du serveur SMTP de SFR m'a donné l'information essentielle: le serveur a rejeté le message parce que celui ci a échoué au test SPF.
http://www.openspf.org/Why?id=noreply%40steampowered.com&ip=217.70.183.197&receiver=msfrf2207
Je suis ingé info, mais pas ingé réseau… J'ai regardé un peu comment fonctionnait SPF, mais de ce que j'en ai compris:
- dans le cadre de SPF, l'expéditeur indique par quels serveurs transitent les emails qu'il envoie
- le serveur de l'expéditeur envoie son mail sur mon alias
- le serveur SMTP gandi relaie le mail vers la bonne boîte mail, chez SFR
- le serveur SMTP SFR indique le mail échoue au test SPF, parce que l'expéditeur dit envoyer des emails via un domaine (steampowered.com dans mon exemple) mais que le mail provient d'un autre serveur (gandi.net, qui a relayé le mail).
Et voilà le soucis: le serveur SMTP SFR refuse le mail car il a échoué au test SPF. Du coup, impossible pour moi de créer un compte sur ces sites, car je ne reçois jamais le mail avec le lien de confirmation ! Ce problème est connu, et documenté dans les bonnes pratiques SPF. En gros, SFR devrait permettre à l'utilisateur (moi) de mettre le serveur qui fait le forwarding sur une liste blanche.
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.
Forwarders are generally set up by the mail recipient – and thus are the responsibility of the mail recipient. Mail senders publishing SPF records should not have to worry about 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.If tracking forwarders is simply not possible, then the ISP should not reject emails only because of SPF fail. But they can still use the MAIL FROM domain and SPF result for reputation. For example, the reputation of "example.com:PASS" may be quite different from "example.com:FAIL", and if the reputation of "example.com:FAIL" is bad enough, and ISP may start rejecting - just as they do for IP addresses with bad reputation now.
Le serveur SFR interprète donc (à tort) de manière brutale le résultat du test SPF et rejete des emails légitimes. Ils n'apparaîtront donc même pas en spam, le mail est perdu !
Oui mais. Allez expliquer cela à la hotline SFR, à des techniciens qui n'ont pas été formés pour cela.
Comment expliquer cela un techos qui n'a pas été formé pour des problèmes aussi spécifiques, et qui n'a personne de plus compétent à vous passer au bout du fil ? Les questions et réponses que j'ai eues en décrivant mon problème:
- c'est parce que votre adresse ip a été classée comme spammeuse (quel rapport ? le serveur SMTP n'est pas derrière ma box)
- le problème concerne une adresse mail qui n'appartient pas à SFR (bin si, l'adresse finale)
- ajoutez l'adresse en liste blanche sur le webmail (et comment deviner à l'avance l'adresse à ajouter pour la réception d'un mail automatique ? noreply@machin ? En plus le mail est refusé et pas classé en spam…)
La première technicienne que j'ai eu ne comprenait rien. Mais rien du tout. Du coup en faisait du téléphone arabe avec des collègues, difficile de poser une question correcte sur un problème qu'on a pas compris. Le ticket correspondant qu'elle a laissé portait au final la mention "problème de client mail".
Après en avoir eu marre qu'elle me raconte n'importe quoi, elle a enfin craqué et m'a passé le chef de plateau. Évidemment la fille lui avait raconté tout autre chose que mon problème. Lui voulait que je cherche des paramètres dans la box (j'avais un doute, mais je sais que Free a des fonctions qui s'activent à distance comme ça), mais il n'y avait rien, et il m'a passé un "expert".
L'"expert" a eu l'air de mieux comprendre mon problème mais n'a rien fait apparaître sur ma fiche d'intervention pour le suivi. J'ai dû tout redétailler par la suite (facile 1h de parlotte à chaque fois que je retombe sur un hotliner, j'en suis à 5). Quand je lui ai parlé de gandi, l'expert m'a demandé si c'était un truc comme dyndns -_-. Pour info Gandi est 3ème plus gros vendeur d'adresses en .fr, 2ème français derrière OVH (chiffres 2011, source http://www.prodomaines.com/classement-registrar-noms-domaine-fr-afnic-2011). Il devait me rappeler, et ne l'a jamais fait.
Le service qualité m'appelle la semaine dernière, pour comprendre pourquoi j'ai laissé une note déplorable sur leur formulaire de satisfaction en ligne. Ils me demandent si mon problème subsiste, parce que chez eux, le problème est à "résolu". On devait me rappeler un jour à 13h. À 14h, sans nouvelles, je me décide à rappeler. C'est là j'ai eu droit après 45min de discussion à "cette adresse n'est pas une adresse SFR, je ne peux rien pour vous", ce qui m'a un poil mis à cran.
J'ai ensuite rappelé et tenté ma chance avec quelqu'un d'autre. Ce dernier interlocuteur ne comprenait pas non plus mon problème, mais est parti se renseigner, avec son bâton de pélerin… J'ai encore eu droit à mon adresse ip de ma box qui était classée comme spammeuse (sur spamhaus.org d'après eux), mais je n'héberge pas de serveur SMTP chez moi, je m'en fous un peu. En fait c'est juste une précaution parce que mon ip est sur une plage d'adresses dynamique et donc classée comme spam par défaut sur ce site (c'était d'ailleurs écrit en toute lettres sur le lien que SFR m'a envoyé).
Au final, ma demande a atteint par deux fois le niveau de support le plus haut, dans l'équipe solutions produits, et les prétendus "experts" ont été infoutus de comprendre mon problème, malgré les liens, citations, et même traduction des passages intéressants. La dernière explication d'un de ces "experts", c'est que la déclaration SPF du serveur qui envoie le mail est erronée parce qu'elle n'indique pas le serveur de Gandi -_-'.
J'ai aussi découvert qu'au moins une autre personne a des problèmes de mails refusé à cause d'une mauvaise configuration SPF par SFR.
Ayant parlé à tous les interlocuteurs possibles (la dernière fois que j'ai eu le service technique, c'est via le service résiliations), je peux donc vous dire qu'à part si le PDG de SFR ou Dieu le Père passent par là, le problème n'est pas près d'être résolu.
Si vous avez des retours d'expérience avec d'autres FAI (Free en particulier), n'hésitez pas à m'en faire part, ma lettre de résiliation chauffe dans l'enveloppe…
# Mauvais hébergeur d'email -> changer d'hébergeur d'email
Posté par dinomasque . Évalué à 10.
Gandi a l'air de faire ça très bien (en tout cas mieux que SFR).
BeOS le faisait il y a 20 ans !
# Tu cherches les ennuis quand même
Posté par kursus_hc . Évalué à 10.
Pourquoi utilises-tu une boîte mail sfr ?!
[^] # Re: Tu cherches les ennuis quand même
Posté par liberforce (site web personnel) . Évalué à 3.
J'étais chez Tele2, ils se sont fait racheter, et l'inertie aidant…
[^] # Re: Tu cherches les ennuis quand même
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Ouvre chez gandi une boite mail au lieu d'un alias. Un coup de imapsync pour copier tes mails de ta boite SFR vers ta boite Gandi. Et voilà :-)
Personnellement, je n'ouvre jamais de boite chez mon FAI, celui-ci pouvant changer.
[^] # Re: Tu cherches les ennuis quand même
Posté par liberforce (site web personnel) . Évalué à 4.
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…
# Je ne suis pas un spécialiste mais....
Posté par _Tof_ . Évalué à 8.
Pour moi, ce comportement est tout à fait normal.
Ce que fait SFR, c'est vérifier le champ SPF pour le domaine que tu utilises, à savoir "steampowered.com".
Si l'IP de ton serveur qui fait la redirection n'apparait pas dans cette liste, le message est refusé, et c'est tout à fait normal, le but étant justement d'éviter que n'importe qui utilise ce domaine à partir de n'importe quel serveur de mail.
Pour moi, ce n'est pas à SFR d’accepter ton adresse, mais à steampowered.com de rajouter ton IP dans la liste des serveurs autorisés. Ou alors de mettre "~all" au lieu de "-all" pour que ton serveur soit noté comme "non-autorisé", ou plutôt comme "probablement pas autorisé", mais que ton mail passe quand même.
Si SFR se met à autoriser tous les serveurs indépendamment du champ SPF, alors, autant ne pas vérifier ce dernier.
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par liberforce (site web personnel) . Évalué à 2.
http://www.openspf.org/FAQ/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
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par _Tof_ . Évalué à 2.
Donc, SFR vérifie le SPF et ça casse le forwarding. Comportement normal.
Maintenant, ce que tu voudrais, c'est que SFR gère une listes blanches d'adresses autorisées à passer outre cette vérification SPF. Dans ce cas, très clairement, autant ne pas utiliser SPF du tout.
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par liberforce (site web personnel) . Évalué à 2.
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 :
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par _Tof_ . Évalué à 4.
Là encore, c'est une configuration SPF de steammachin :
Dans le SPF, il y a marqué "-all". Autrement dit, steamtruc n'admet pas qu'un autre serveur que les siens utilisent leur domaine. Je me répète,mais SFR fait son boulot en refusant un mail qui ne vient pas des serveurs autorisés. C'est steambidule qui est configuré trop dur.
Si SFR doit passer outre la configuration SPF voulue par steamchouette, alors autant ne pas utiliser SPF du tout.
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par benja . Évalué à 1.
Vous prennez le problème dans le mauvais sens, je penses : c'est bien le destinataire (i.e. free ou gandi dans ce cas) qui peut se prémunir, totalement (du moins c'est l'objectif tel qu'il est considéré, en admettant que tous les serveurs émetteurs disposent d'enregistrements SPF), d'un email impersonnifié, en utilisant SPF. C.-à-d. c'est le récepteur qui met en oeuvre, de manière à faire force, le contrôle SPF. Là preuve est qu'un serveur émetteurs disposant d'informations SPF souhaite toujours pouvoir envoyer un message à un serveur même si ce récepteur n'est pas capable de vérifier SPF; et ceci pour les simples et bonnes raisons qu'il n'est pas possible de savoir, à priori, si un serveur récepteur (voir une passerelle, gandi en l'occurence) implémente SPF et que SPF ne peut se déployer que d'une manière graduelle, c.-à-d. que SPF ne doit être mis en oeuvre que si les 2 parties, soit émetteur/récepteur ou émetteur/passerelle, le mettent en oeuvre (la justification de cette dernière raison tombe sous le sens).
De ce point de vue là, il est souhaitable que free implémente une whitelist. Aussi que gandi vérifie à sa place les enregistrements SPF (pour ne pas perdre de fonctionnalité).
PS: merci de ne pas me tenir rigueur pour les erreurs, imprécisions et termes trop approximatifs; vous corrigerez volontier.
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par liberforce (site web personnel) . Évalué à 0.
D'après Gandi, la même manip avec une boîte Free fonctionne. Le problème survient avec SFR.
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par Zenitram (site web personnel) . Évalué à 2.
Bravo, tu viens de découvrir que Free n'utilise pas SPF comme élément éliminant.
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par liberforce (site web personnel) . Évalué à 1.
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.
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par _Tof_ . Évalué à 4.
Double réponse…
Si je gère le domaine "tartempion.com" et que je décide que seuls mes serveurs sont autorisés à envoyer des mails avec le domaine en question, non seulement, ce n'est pas la faute de SFR s'ils refusent un mail venant d'un autre serveur, mais plus encore, ça n'aurait alors servi à rien que je me fasse chier à configurer mon SPF !!
Donc, j'en reviens à ce que je disais, ce n'est pas à SFR d'autoriser ton serveur de mail, mais à "steampowered.com" de changer sa configuration pour que tu puisses utiliser le forwarding.
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par woopla . Évalué à 5.
En fait, dans le cas de liberforce, s'il demande à avoir le serveur Gandi dans une whitelist SFR pour son compte uniquement, c'est que c'est Gandi qui fait les vérifications SPF avant de forwarder le mail sur l'adresse SFR.
Donc non, SPF est toujours utile, c'est juste que c'est Gandi qui fait le "proxy" SPF pour SFR. Il ne demande pas que les serveurs Gandi soient whitelistés pour tous les clients SFR, juste pour lui.
[^] # Re: Je ne suis pas un spécialiste mais....
Posté par liberforce (site web personnel) . Évalué à 2.
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.
# de la perversité des indicateurs
Posté par palm123 (site web personnel) . Évalué à 7.
Je suppose que le management de SFR est fan d'"indicateurs". Et un problème doit être résolu rapidement (car SFR a le personnel le plus compétent qui soit, c'est évident, comme Free, Orange et les autres FAI…).
Donc je me dépêche de passer le problème à "résolu", pour que mon chef ne m'allume pas.
Ca me rappelle une anecdote d'un copain ayant travaillé sur une coproduction en Egypte. L'ingénieur qualité avait bien compris son travail, tamponner tous les bordereaux comme quoi le matériel était "conforme" et de qualité irréprochable, même des matériels refusés d'un simple coup d'oeil, sans test approfondi.
ウィズコロナ
# .
Posté par Sufflope (site web personnel) . Évalué à 5.
C'est pas si simple que ça, j'ai l'impression. Du point de vue SFR, qui leur garantit que Gandi ne ment pas concernant le serveur d'origine ?
Si je cite ton lien:
Pour moi il faut lire recipient au sens infrastructure (donc SFR au final) et pas personne (toi). Et ce n'est pas SFR qui a mis en place du forwarding.
Leur "SPF doesn't break forwarding" n'est vrai que s'il n'y a que deux acteurs en jeu. Auquel cas le forwarding est effectivement "sûr": soit il est fait au départ et alors l'infra expéditrice peut faire ce qu'il faut pour se mettre en conformité SPF, soit il est fait dans l'infra d'arrivée et alors effectivement elle peut se faire confiance à elle-même.
Mais dans ton cas il y a trois acteurs et là SPF casse le truc.
Pour citer le lien (http://www.openspf.org/FAQ/Forwarding) cité par la personne sur le forum SFR que tu cites (ça se complique :D) :
Faudrait que SFR whiteliste Gandi comme "infra sérieuse qui ne me ment pas".
Ou alors tu ajoutes du DKIM pour assurer la véracité des entêtes (en supposant que SFR fait confiance à du SPF forwardé si les entêtes sont garantis par DKIM :-D)
[^] # Re: .
Posté par liberforce (site web personnel) . Évalué à 8.
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
[^] # Re: .
Posté par _Tof_ . Évalué à -4.
T'imagines ???
J'inscris mon petit serveur de mail comme forwarder dans la liste blanche, et je peux de fait me permettre d'envoyer à SFR n'importe quel SPAM avec des vrai morceaux de domaines dedans !!
Génial !!
Perso, je suis contre. C'est à toi de configurer ton forwarder pour qu'il n'utilise pas un nom de domaine qui ne lui appartient pas.
[^] # Re: .
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Ça ne marcherait pas dans ce sens-là : chaque utilisateur rentrerait une liste de relais personnels.
[^] # Re: .
Posté par allcolor (site web personnel) . Évalué à 6.
Oui mais tu ne pourras te les envoyer qu'a toi-même… c'est super comme fonctionnalité dis donc. Il ne demande pas de whitelister gandi pour tout SFR, mais de whitelister gandi pour son email SFR seulement.
[^] # Re: .
Posté par groumly . Évalué à 5.
Ben quand tu reflechis deux minutes, ca revient a desactiver completement SPF dans son cas.
Tout le traffic qu'il recoit vient de gandi, gandi est whiteliste et passe au travers du filtre, donc SPF est en pratique desactive.
Il tourne quand meme, les resources qu'il est cense economise (disque + réseau) sont bouffées, et en plus liberf0rce est capable de venir faire un journal comme quoi l'antispam de sfr il est tout pourri.
La position de SFR sur le sujet se tient, ce qui est questionable c'est le choix de SPF, mais ca c'est une autre question.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: .
Posté par allcolor (site web personnel) . Évalué à 5.
C'est son choix, c'est quand même sa boite mail non ?
Aussi, Gandi fait peut-être (je n'en sais rien) la vérification SPF, donc que SFR en fasse une en plus est inutile.
Ça dépend si le fait de mettre une whitelist par user chez eux est compliqué ou non, si ça ne l'est pas, ça ne se tient pas trop. Enfin, si Gandi implémentait SRS ça passerait aussi sans problème.
Je trouve que le choix le plus questionnable est d'utiliser sa boite mail SFR. Gandi ne propose-t-il pas un service mail ?
[^] # Re: .
Posté par groumly . Évalué à 1.
Non, c'est pas sa boite mail, c'est la boite de SFR, sur laquelle il redirige son traffic.
Ca, SFR n'en sait rien, donc ca change pas grand chose du point de vue de SFR.
Ca va plus loin que ça, tout le spam qui est envoye a sa boite chez gandi va passer comme une lettre a la poste et se retrouver sur les serveurs. SFR a potentiellement un probleme avec ça, sinon ils se seraient pas fait chier a deployer SPF.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: .
Posté par allcolor (site web personnel) . Évalué à -1.
Donc il ne paye rien ? ou bien si c'est comme tu dis la boite SFR, SFR peut donc lire ses emails ?
Je crois que non, je pense bien qu'il paye pour ce service et que sa boite email lui appartient. Je veux bien que l'infrastructure appartienne à SFR, mais sa boite mail non. Maintenant que SFR ne puisse pas implémenter cette whitelist par boite mail ok, mais ça ne change pas pour autant la propriété de celle-ci.
On doit rire ?
[^] # Re: .
Posté par groumly . Évalué à 4.
Bon, je vais reformuler puisqu'on a des gros malins qui jouent sur les mots: il paye SFR pour s'occuper de l'infrastructure email, ce que SFR fait comme bon lui chante. S'il a un probleme avec la facon dont SFR gere son infrastructure, ben qu'il aille voir ailleurs ou monte son propre serveur de mails.
Apres si vraiment tu veux enculer les mouches, il paye pour un acces a internet et SFR lui offre gracieusement une adresse email, donc non, il ne paye pas pour ca, et il ne peut pas avoir liberf0rce@sfr.fr sans prendre un accces SFR, donc on peut discuter le fait que le mail lui "appartient".
Ben je sais pas, on apparemment un gros paquet d'experts qui n'ont pas l'air d'avoir calculé que whitelister gandi == rendre SPF ineffectif tout en rajoutant l'overhead de SPF, donc je suis pas sur que ceux qui vont rigoler sont ceux que tu pense.
Moi ce qui me fait rigoler c'est des phrases du genre "Gandi en fait peut etre un de check SPF alors celui de SFR ne sert a rien".
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: .
Posté par liberforce (site web personnel) . Évalué à 3.
Pour l'antispam, j'utilise Thunderbird, merci. Mais je préfère avoir des spams que perdre des mails. Est-ce trop compliqué à comprendre ?
[^] # Re: .
Posté par Zenitram (site web personnel) . Évalué à 2.
On a 2 personnes (physique ou morale) non d'accord sur comment gérer des spams potentiels.
Aucune de ces deux personne n'est obligée de rester dans ce couple, mais l'un veut rester en disant que l'autre est nul alors qu'il ne fait pas de faute, juste que l'autre a une autre façon de voir.
Est-ce trop compliqué à comprendre qu'il suffit de divorcer (et ça coûte pas cher, et on peut divorcer que du mail sans rien changer au reste du contrat) si ça ne convient pas, plutôt que de cracher dessus en restant?
[^] # Re: .
Posté par Zenitram (site web personnel) . Évalué à 6.
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.
En attendant, SFR ne va pas se faire chier à développer un truc pour 2 perdus qui font du forward, SPF est plus important.
C'est tout. Ca tombe bien, tu es libre de changer simplement et rapidement ta façon de faire pour les mails sans rien perdre plutôt que d'aller bourriner à changer de FAI "pour ça" (ce que tu ne fera pas, car changer de FAI est plus chiant encore que de changer de boite mail).
Bref :
Pas crédible (tu as déjà la flemme de changer d'hébergement mail…). Une menace, c'est utile si c'est crédible. Et pas légitime (SFR respecte la spec SPF, contrairement à ce que laisse entendre le sujet du journal).
[^] # Re: .
Posté par liberforce (site web personnel) . Évalué à 2.
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:
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.
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 ?
[^] # Re: .
Posté par Zenitram (site web personnel) . Évalué à 2.
Même pas cap'.
Après, si c'est un élément déclencheur d'une autre insatisfaction… tu serais quand même parti, donc toujours pas rentable pour eux. La menace est bof.
Tu as une offre "low cost", sans support hyper cher, tu t'attendais à quoi?
La, on vient à la critique du niveau de compétence du support, ok… Sujet différent auquel on répondra que tu as le niveau que tu payes.
Yep. Mais la encore, c'est un autre sujet (étant utilisateur de forwarding, ça m'interesse, mais la teneur du journal était plus une attaque contre le support que sur ça, donc bon, du coup on peut pas débattre sereinement de la problématique).
Ils peuvent aussi t'envoyer chier. Il n'y a aucun coût à absorber, juste trouver quelqu'un qui veut bien payer.
# Faut d'abord comprendre
Posté par fcartegnie . Évalué à 10.
Sauf qu'il a raison…
Si tu pouvais changer la chaîne de validation de SPF, juste en mettant un serveur relais, ça foutrait en l'air tout l'intérêt.
Si tu mets un relais, c'est à toi de gérer l'authenticité derrière ce relais.
ICI tu passes le relais à SFR, qui se base sur la déclaration SPF (qui liste explicitement les serveurs autorisés à émettre le mail pour le compte de l'émetteur), et donc rejette tout ce qui passe pas ton serveur: normal.
[^] # Re: Faut d'abord comprendre
Posté par liberforce (site web personnel) . Évalué à -1.
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.
[^] # Re: Faut d'abord comprendre
Posté par MTux . Évalué à 1. Dernière modification le 26 mars 2013 à 14:46.
Réaction tout à fait normale, c'est le but du SPF.
Et la solution consisterai à demander à Steam d'ajouter l'IP des serveurs Gandi dans leur enregistrements SPF.
Pour moi SFR n'a rien à voir là dedans.
Par contre pebkac pour l’incompétence des experts, mais c'est un autre sujet. La hotline et le helpdesk c'est pas simple. 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.
[^] # Re: Faut d'abord comprendre
Posté par liberforce (site web personnel) . Évalué à 2.
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 ?
[^] # Re: Faut d'abord comprendre
Posté par _Tof_ . Évalué à 2.
Mais bon sang de bois, est ce que tu lis les explications qu'on te donne ??? Oui SPF casse la notion de forwarding !!! Dire à SFR qu'il faut autoriser tel ou tel serveur à faire ce que bon lui semble, c'est juste utopiste ! J'en reviens toujours au même point, dans ce cas là, autant ne pas utiliser SPF !!
Si steampowered configure son SPF pour que seuls ses serveurs soient autorisés à utiliser leur domaine, pourquoi SFR se ferait chier à interroger leur champ SPF, et à ne pas l'utiliser ensuite ???
[^] # Re: Faut d'abord comprendre
Posté par liberforce (site web personnel) . Évalué à 3.
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 :
[^] # Re: Faut d'abord comprendre
Posté par Sufflope (site web personnel) . Évalué à 3.
Oui enfin il est quand même assez logique qu'avec un -all ça aille dans /dev/null. Je verrais plutôt le classement en spam pour un ~all.
[^] # Re: Faut d'abord comprendre
Posté par Julien L. . Évalué à 1.
Idem, ça me semble être un comportement logique et qui permet au détenteur du domaine d'avoir une petit peu la "main" sur la politique qu'il veut voir appliquer.
C'est juste dommage que l'on est pas un fonctionnement, par défaut, des clients emails "à la façon" du SSL niveau navigateur et qui pourrait vérifier que le serveur expéditeur est bien un serveur autorisé et authentifié via un code couleur (via DKIM et non SPF du coup).
[^] # Re: Faut d'abord comprendre
Posté par Zenitram (site web personnel) . Évalué à 5.
Quel problème? "is your choice". Le choix de SFR est valide. Après, il peut ne pas te plaire, c'est une autre histoire… Si tu n'aimes pas les choix de SFR, libre à toi de changer! Les autres resteront car ça élimine déjà pas mal de spam, et ça leur plait (ils n'utilisent pas de forward, ils s'en foutent de ce détail).
[^] # Re: Faut d'abord comprendre
Posté par liberforce (site web personnel) . Évalué à 1.
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…
[^] # Re: Faut d'abord comprendre
Posté par kursus_hc . Évalué à 2.
Bienvenue sur la planète Terre.
[^] # Re: Faut d'abord comprendre
Posté par Littleboy . Évalué à 10.
C'est pas qu'ils essayent de t'enfumer, c'est qu'il n'ont pas la moindre idee de ce que tu demandes. Le service client il est la pour aider les gens qui ont oublie de brancher la box sur la prise electrique ou pour faire des tickets pour le service technique au cas ou le probleme n'est pas du cote du client. Ta demande est tellement en dehors de ce qu'ils font en general que tu n'as aucune chance d'avoir une reponse potable sans passer par plein d'etapes pour parler a quelqu'un d'un peu plus technique.
La procedure QA, c'est de ranger ton dossier dans /dev/null. Tres serieusement.
Si tu veux du support technique avec des gens qui savent de quoi ils parlent et accessible directement, tu te trompes de fournisseur. Si tu es pret a payer le prix necessaire, tu n'auras aucun mal a trouver un fournisseur de mail avec un support technique qualifie qui te reponds en quelques heures.
Pour ca, il faudrait que ton dossier remonte jusqu'au gens qui s'occupent de la politique de securite. Et qu'ils prennent le temps de regarder ce qui se passe (soit au minimum une heure de leur temps juste pour regarder sans rien faire). Quelque chose me dit qu'ils ont autre chose a faire qu'un truc super specifique pour un unique client. Surtout que tout ce que tu payes a SFR pendant un an serait probablement englouti juste au temps passe pour resoudre ton probleme. Pas rentable, en plus de ne pas etre une bonne idee niveau securite.
# DUL et auto-hébergement
Posté par ®om (site web personnel) . Évalué à 2.
Il y a aussi certains serveurs qui rejettent les serveurs mail en DUL.
Par exemple, je suis chez Free (donc en DUL), mon serveur mail derrière ma box, et quand j'essaie d'envoyer un mail à certains (c'est rare, mais ça arrive), MAILER-DAEMON n'est pas content:
Exemple avec une IP au hasard de chez Free:
https://ers.trendmicro.com/reputations/index?ip_address=78.236.0.1
Je clique donc sur Request to be removed from the global blocked list, et je reçois cette réponse:
Bon, encore une étape, il faut que je contacte Free.
blog.rom1v.com
[^] # Re: DUL et auto-hébergement
Posté par ®om (site web personnel) . Évalué à 2.
Ah mais je n'avais pas vu ce bout de phrase :
Ça tombe bien, c'est moi ;-)
blog.rom1v.com
[^] # Re: DUL et auto-hébergement
Posté par liberforce (site web personnel) . Évalué à 1.
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.
[^] # Re: DUL et auto-hébergement
Posté par Sufflope (site web personnel) . Évalué à 1.
C'est balo d'avoir laissé l'IP dans l'URL…
Et sinon je pense qu'ils parlent du whois du bloc d'IP, pas de ton domaine, hein…
[^] # Re: DUL et auto-hébergement
Posté par ®om (site web personnel) . Évalué à 5. Dernière modification le 26 mars 2013 à 14:38.
Ce n'est pas la mienne ;-) J'ai mis la première IP de 78.236.x.x.
De toute façon, mon adresse IPv4 n'est pas secrète ;-)
blog.rom1v.com
[^] # Re: DUL et auto-hébergement
Posté par gnumdk (site web personnel) . Évalué à 2.
Moi, j'ai le problème sur les ml yahoo et google…
Du jour au lendemain, les mails envoyés sur ces listes avec mon @ gmail via mon serveur SMTP perso n'arrivaient jamais à destination (pas d'erreur).
Il a fallut que je passe par mon @ perso sur ces listes pour être tranquille…
Et là je me rend compte que la dernière asso ou je me suis inscrit, j'ai mis mon email gmail, boulet@inside :-(
# Question de béotien
Posté par netsurfeur . Évalué à 9.
Si j'ai bien compris, on a 3 domaines (origine, relais et destination) et trois adresses (expediteur@origine, alias@relais et destinataire@destination).
Le serveur d'origine envoie le message avec les entêtes:
Le serveur relais les redirige avec les entêtes:
Le SMTP de destination le refuse parce que le serveur relais n'est pas autorisé dans le SPF d'origine.
Si le relais avait redirigé avec les entêtes:
Tout ce serait bien passé, non ?
Après tout, si le serveur relais renvoie ce message, c'est à la demande de alias@relais.
[^] # Re: Question de béotien
Posté par liberforce (site web personnel) . Évalué à -2.
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.
[^] # Re: Question de béotien
Posté par netsurfeur . Évalué à 10. Dernière modification le 26 mars 2013 à 15:55.
Ce n'est que l'expéditeur défini dans l'enveloppe SMTP (entête MAIL FROM:).
L'expéditeur qu'affiche ton lecteur de courriel est celui défini dans l'entête
Il n'y a aucune obligation pour que l'expéditeur dans les deux entêtes soit identique.
[^] # Re: Question de béotien
Posté par _Tof_ . Évalué à 7.
Voilà un commentaire TRES pertinent. C'est effectivement au forwarder d'utiliser les bons en-têtes pour ne pas utiliser les domaines avec des SPF.
[^] # Re: Question de béotien
Posté par plouf2123 . Évalué à 4.
le modifier comme ça, ça casse les bounce.
http://www.openspf.org/SRS
[^] # Re: Question de béotien
Posté par netsurfeur . Évalué à 3.
Comme je l'indiquais, c'était une «question de béotien»; je ne suis pas expert SMTP.
Ton lien indique quand même qu'il y a une solution basée sur la réécriture de l'adresse de l'expéditeur qui permet à la fois de résoudre le blocage SPF et le problème de bounce.
Je constate aussi que la solution est à mettre en place au niveau du relais et non de destinataire.
[^] # Re: Question de béotien
Posté par plouf2123 . Évalué à -2. Dernière modification le 26 mars 2013 à 18:15.
quoi ? ma réponse serait trop seche ?
j'ai juste répondu. je ne me suis pas permis de te juger ou de juger la question…
[^] # Re: Question de béotien
Posté par netsurfeur . Évalué à 4.
Non, pas du tout.
Je voulais simplement dire qu'en tant que béotien je n'avais pas appréhendé les aspects négatifs de ma suggestion.
Merci pour ce complément d'information.
[^] # Re: Question de béotien
Posté par siegfried . Évalué à 3. Dernière modification le 26 mars 2013 à 18:27.
C'est un problème connu de longue date, j'avais posté sur le topic d'opensmtpd pour savoir si la réécriture était possible (réponse négative, mais en cours de coding).
Postfix -> il faut installer pfix-srsd et c'est limité à un domaine, en clair tu risques de réécrire tous tes mails sur ton serveur
Exim -> quelqu'un a dit sur le topic d'opensmtpd que c'était possible dessus. Sans vouloir troller Exim c'est une grosse faille tous les 3 mois donc je ne regarderai meme pas si c'est vrai.
Opensmtpd -> Va falloir attendre
Les autres: aucune idée
C'est la triste réalité.
Mais pour SFR, ils ne font là que protéger leurs clients.. Et l'erreur est du coté de ton relay.
# Shibbol33t !
Posté par jihele . Évalué à 10.
Mais ne le répétez pas.
[^] # Re: Shibbol33t !
Posté par reynum (site web personnel) . Évalué à 1.
Si seulement ça pouvait exister [rêve en restant pensif]
Sinon j'ai bossé pour une boite qui avait comme client principal SFR et selon les admins réseaux à part (peut être) les écuries d'augias il n'existe rien de plus crade que l'architecture, l'infrastructure et la gestion du réseau chez SFR, les pauvres (collègues) ils pleuraient des larmes de sang à chaque fois qu'ils devaient écrire un ticket ou faire une amélioration sur le réseau SFR.
kentoc'h mervel eget bezan saotred
[^] # Re: Shibbol33t !
Posté par Zenitram (site web personnel) . Évalué à 0.
Règle d'or : en réseau ou en développement, ce qu'a fait l'autre est toujours à pleurer, et celui qui parle aurait fait le réseau ou code parfait, évidement.
[^] # Re: Shibbol33t !
Posté par Sufflope (site web personnel) . Évalué à 6.
Oui enfin dans le cas de SFR, ils ont quand même un workflow d'activation de compte client avec des puits de potentiels où tu peux rester coincé ad vitam. Du genre si tu as l'idée folle d'avoir un accent dans ton nom de rue, paf trou noir.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.