Journal Le service messagerie Microsoft Outlook.com détruit silencieusement vos e-mails

Posté par  . Licence CC By‑SA.
58
12
juin
2020

Le service de messagerie Outlook.com (anciennement connu sous les noms MSN Hotmail puis Windows Live Hotmail) efface silencieusement des e-mails sans en avertir les expéditeurs ni les destinataires.

C'est un problème récurant que nous avons constaté chez plusieurs de nos clients ces dernières années et encore hier, un client nous a averti que plusieurs e-mails valides, envoyés depuis un mois, vers des comptes gratuits et payants du service de messagerie Outlook.com de Microsoft sont tous simplement détruits sans aucun avertissement.

Pour faire simple lawless@self-hosting.org écrit à bill@hotmail.com :
- le serveur Microsoft répond bien le code SMTP 250 avec un message texte comme quoi le courriel a été mis en file d'attente pour la distribution ;
- le message n'arrive jamais dans la boîte de réception de l’utilisateur bill@hotmail.com ;
- le message n'arrive jamais non plus dans le dossier « indésirable » de l’utilisateur bill@hotmail.com ;
- le serveur Microsoft n'envoie jamais de notification de type mailer daemon à lawless@self-hosting.org pour l'avertir que le message n'a pas été remis.

Le courriel a été détruit silencieusement, et si bill@hotmail.com ne s'inquiète pas qu'il n'a pas reçu son e-mail, lawless@self-hosting.org ne le saura jamais.

Plus fort si bill@hotmail.com écrit à lawless@self-hosting.org et que ce dernier répond à l'e-mail (en pressant le bouton « Répondre ») alors l'e-mail arrive bien dans la boîte bill@hotmail.com ! Par contre si tout de suite après lawless@self-hosting.org envoi un nouveau e-mail à bill@hotmail.com (un nouveau e-mail, sans cliquer sur le bouton « Répondre » du précédent) alors l'e-mail sera de nouveau détruit silencieusement. Dans les deux cas le serveur Microsoft répond bien le même code SMTP 250 avec un message texte comme quoi le courriel a été mis en file d'attente pour la distribution ! On est en droit de s'interroger sur la pertinence du code SMTP 250 chez Microsoft qui dans un cas achemine bien le courriel dans la boîte de réception de bill@hotmail.com et dans le deuxième cas supprime le courriel silencieusement.

Microsoft semble maintenir son propre DNS Black Listing interne qui n'est pas incluse dans des outils comme MxToolbox et le seul fait de changer l'adresse IP du serveur émetteur sans toucher à la configuration du Mail Transfer Agent résout le problème, le serveur Microsoft répond toujours le même code SMTP 250, mais le message arrive enfin dans la boîte de réception de l’utilisateur bill@hotmail.com.

Sauf erreur de ma part, Microsoft va à l'encontre des standards SMTP qui veut que le serveur de réception avertisse le serveur émetteur que le message ne sera pas remis, pour cause de mise sur liste noire ou tout autre problème.

Ce problème que Outlook.com détruit silencieusement les e-mails est connu, on peut trouver des commentaires un peu partout sur le web, comme celui de Server Fault, Mails sent to mail.protection.outlook.com are not being received qui dit justement :

Microsoft n'utilise pas les méthodes standard de rejet du courrier indésirable : au lieu de cela, ils l'acceptent et le jettent dans un trou noir, de sorte que les diagnostics normaux ne fonctionnent pas correctement.

On est en droit de s'interroger sur la fiabilité de la messagerie Microsoft Outlook.com qui se veut professionnelle tout en effaçant silencieusement les e-mails de ses utilisateurs…

  • # Source?

    Posté par  (site Web personnel) . Évalué à -10 (+10/-79).

    Sauf erreur de ma part, Microsoft va à l'encontre des standards SMTP qui veut que le serveur de réception avertisse le serveur émetteur que le message ne sera pas remis, pour cause de mise sur liste noire ou tout autre problème.

    Un peu facile le "Sauf erreur de ma part" ici… alors que c'est la raison principale de ton journal. Un peu de sérieux…

    On est en droit de s'interroger sur la fiabilité de la messagerie Microsoft Outlook.com qui se veut professionnelle tout en effaçant silencieusement les e-mails de ses utilisateurs…

    Perso j'attends de mon fournisseur de mail qu'il trashe complètement dans une trou noir les spams, sans qu'il ne m'avertisse (et je me fous un peu qu'il avertisse le spammeur, ou plutôt je comprend : vaut mieux ne pas aider le spammer en lui disant que sont test ne marche pas).

    Alors oui il peut y avoir des faux positifs… Rien n'est simple, mais l'accusation que tu fais est elle bien simpliste, comme si il n'y avait aucun problème avec le spam.

    Bref, tout n'est pas parfait mais se plaindre en essayant de mettre un standard de son côté pour un truc qui est après la réception du mail sans vérifier avant, perso je trouverai la méthode cavalière.

    Note que les utilisateurs peuvent considérer l'inverse de toi, que c'est agréable de ne pas avoir de spam et que le prix à payer (quelques mails qui n'arrivent pas) et que c'est ton problème si tu n'arrive pas à envoyer. Ta vision est un peu trop centrée sur toi-même.

    et le seul fait de changer l'adresse IP du serveur émetteur sans toucher à la configuration du Mail Transfer Agent résout le problème

    En fait, tu connais la source du problème (adresse IP blacklistée), le journal se résume donc à : Microsoft fait comme les autres à blacklister des IP sans avertissement (3 niveaux habituellement : OK, spam potentiel mis dans le dossier spam, spam évident trashé sans avertissement) mais ne publie pas sa liste.

    PS : il est amusant que tu en appelles aux standards "pas respectés" sans être sûr, quand toi-même tu les ignores, en effet lawless @ self-hosting.org est invalide, la RFC 2606 indique example.org pour ce propos. Hôpital, Charité…

    • [^] # Re: Source?

      Posté par  . Évalué à 10 (+29/-7).

      toi relire message calmement. pas une seule fois il ne parle de spam

    • [^] # Re: Source?

      Posté par  . Évalué à 10 (+42/-2). Dernière modification le 12/06/20 à 11:41.

      Un peu facile le "Sauf erreur de ma part" ici… alors que c'est la raison principale de ton journal. Un peu de sérieux…

      Ce journal est totalement sérieux, contrairement à ta réponse en mode troll excité, mais tu as le droit puisqu'on est vendredi après tout. Vu que j'ai un peu de temps je vais essayer de jouer aux échecs avec un pigeon.

      La RFC Simple Mail Transfer Protocol stipule :

      If accepted, the SMTP server returns a "250 OK" reply. If the mailbox specification is not acceptable for some reason, the server MUST return a reply indicating whether the failure is permanent (i.e., will occur again if the client tries to send the same address again) or temporary (i.e., the address might be accepted if the client tries again later). Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies.

      Donc si le serveur de Microsoft répond avec un code 250 il doit soit remettre le message dans la boîte soit reporter le problème par la suite. Si le message n'est pas accepté pendant la transaction SMTP le serveur doit répondre avec un autre code en indiquant si l'échec est temporaire ou permanent.

      Perso j'attends de mon fournisseur de mail qu'il trashe complètement dans une trou noir les spams, sans qu'il ne m'avertisse (et je me fous un peu qu'il avertisse le spammeur, ou plutôt je comprend : vaut mieux ne pas aider le spammer en lui disant que sont test ne marche pas).

      Ce que tu attends pour ta petite boîte de messagerie personnelle n'est pas forcément ce qu'attendent les professionnels pour leurs messageries et ce qu'attendent aussi les personnes qui ont écrits les RFC. Si des codes SMTP d'échec existent, c'est qu'ils ont bien une utilité et ne sont pas là pas juste pour décorer une RFC.

      Alors oui il peut y avoir des faux positifs… Rien n'est simple, mais l'accusation que tu fais est elle bien simpliste, comme si il n'y avait aucun problème avec le spam.

      La détection du spam n'est pas une science exacte et il y aura toujours des faux positifs ou des faux négatifs, alors autant faire les choses correctement et respecter les standards soit refuser l'e-mail avec le bon code SMTP ou alors accepter le courriel et le classer dans le dossier « pourriel » ce qui sont deux solutions acceptables pouvant gérer les faux positifs, contrairement à détruire silencieusement le courriel comme le fait Microsoft.

      Note que les utilisateurs peuvent considérer l'inverse de toi, que c'est agréable de ne pas avoir de spam et que le prix à payer (quelques mails qui n'arrivent pas) et que c'est ton problème si tu n'arrive pas à envoyer. Ta vision est un peu trop centrée sur toi-même.

      Dans mon cas les utilisateurs sont nos clients qui aimeraient que des messages arrivent normalement. Il peut y avoir des problèmes, mais si Microsoft respectait les standards on pourrait corriger le tir. Ma vision est centrée sur le respect des standards et faire fonctionner les choses.

      En fait, tu connais la source du problème (adresse IP blacklistée), le journal se résume donc à : Microsoft fait comme les autres à blacklister des IP sans avertissement (3 niveaux habituellement : OK, spam potentiel mis dans le dossier spam, spam évident trashé sans avertissement) mais ne publie pas sa liste.

      Encore une fois que l'adresse IP soit sur liste noire, cela ne me dérange pas, mais Microsoft devrait respecter la RFC et avertir que l'e-mail ne sera pas remis. Où as-tu vu cette information comme quoi Microsoft place une adresse IP sur liste noire au bout de trois avertissements, as-tu vérifié tes sources ? Ce n'est pas très sérieux…

      il est amusant que tu en appelles aux standards "pas respectés" sans être sûr, quand toi-même tu les ignores, en effet lawless @ self-hosting.org est invalide, la RFC 2606 indique example.org pour ce propos. Hôpital, Charité…

      Il est encore plus amusant que ta soif de troller ait dépassé ta curiosité et ton intelligence et que t'aies pas toi même vérifié la RFC avant de poster ton commentaire et surtout que tu n'aies pas compris ces adresses étaient juste des exemples et que toute ressemblance avec des adresses électroniques existantes ou ayant existé est purement fortuite.

      • [^] # Re: Source?

        Posté par  (site Web personnel) . Évalué à 5 (+5/-2).

        En parlant de standard, la gestion du spam ne l'est pas, à ma connaissance, et reste à la discrétion du fournisseur de service. Si celui-ci est absolument certain qu'un mail reçu - et accepté dans un premier temps - est après analyse du spam (à tord ou à raison) c'est son droit le plus strict de le supprimer purement et simplement.

        J'ai moi-même eu à configurer des serveurs de mail en environnement pro et, outre les premiers filtres à base de DNSBLs publiques qui refusaient le mail, j'avais configuré spamassassin pour tout envoyer dans /dev/null au delà d'un certain score (assez élevé, certes). En deçà, ça tombait dans la boîte à spam.

      • [^] # Re: Source?

        Posté par  . Évalué à -4 (+2/-8).

        Le fait que l'email arrive après coup si le receveur envoit un email à l'envoyeur originel, c'est signe que le serveur smtp de microsoft suit le standard du protocole. Il a bien reçu le mail. Le fait que celui-ci n'atterrisse pas dans la boite de l'utilisateur se fait derrière, après le serveur SMTP.

        Le protocole SMTP ne gère que l'échange, ce qui se passe après, c'est chacun sa cuisine.

        • [^] # Re: Source?

          Posté par  (site Web personnel) . Évalué à 10 (+18/-1).

          Le protocole SMTP ne gère que l'échange, ce qui se passe après, c'est chacun sa cuisine.

          Non. Le standard SMTP dit clairement que lorsque le serveur répond 250 à une soumission de message, il s’engage à délivrer ce message dans la boîte du destinataire, ou à signaler à l’émetteur que la délivrance n’a pas été possible le cas échéant.

          Accepter un message en disant « tout va bien » alors qu’on l’envoie direct à la poubelle, sans aucune possibilité¹ pour le destinataire d’en prendre connaissance et sans jamais avertir l’émetteur, est une violation flagrante du protocole.


          ¹ Délivrer un message accepté dans une boîte « spam » à part, plutôt que dans la boîte de réception » normale » du destinataire, reste acceptable.

          • [^] # Re: Source?

            Posté par  . Évalué à -8 (+1/-11).

            Accepter un message en disant « tout va bien » alors qu’on l’envoie direct à la poubelle, sans aucune possibilité¹ pour le destinataire d’en prendre connaissance et sans jamais avertir l’émetteur, est une violation flagrante du protocole.

            Manifestement il n'est pas à la poubelle puisqu'il peut dans certaines conditions arriver dans l'inbox de l'utilisateur. Le code 250 c'est :

            250 Requested mail action okay, completed

            Ça ne stipule en aucun cas dans quelle boite/dossier/buffer ça atterrit (et heureusement, ce n'est pas à l'envoyeur de décider si ton mail va finir à la poubelle ou pas). Ce qui se passe après, ça se décide entre le client et le provider mais d'un point de vue transfert, c'est terminé.

            • [^] # Re: Source?

              Posté par  (site Web personnel) . Évalué à 10 (+10/-1).

              Trouve-moi dans le standard le passage qui dit que le serveur qui a répondu 250 est autorisé à ne délivrer le message que si certaines conditions supplémentaires, au bon vouloir du serveur, sont remplies — et à ne pas prévenir l’émetteur si le serveur décide que non, finalement il ne délivrera pas le message.

              Ça ne stipule en aucun cas dans quelle boite/dossier/buffer ça atterrit

              Où ai-je-dit le contraire ? J’ai explicitement dit que délivrer le message dans une boîte spam était acceptable.

              • [^] # Re: Source?

                Posté par  . Évalué à -10 (+1/-19).

                Ben tu l'as ta boite spam.

                • [^] # Re: Source?

                  Posté par  (site Web personnel) . Évalué à 10 (+20/-1). Dernière modification le 12/06/20 à 14:21.

                  Oh fais pas semblant de pas comprendre. Je parle d’une boîte spam auquel le destinataire a accès, bien évidemment — dans laquelle il peut vérifier la présence d’éventuels faux-positifs.

                  Ce n’est pas ce qui se passe dans le cas reporté dans le journal, qui mentionne clairement que les messages concernés n’arrivent ni dans la boîte de réception normale, ni dans la boîte « courriers indésirables ».

                  Il faut une grosse dose de mauvaise foi pour affirmer qu’un message dont le destinataire n’a aucun moyen de prendre connaissance, même en allant consulter le dossier « courriers indésirables », a bien été « délivré ».

                  • [^] # Re: Source?

                    Posté par  . Évalué à -8 (+2/-12). Dernière modification le 12/06/20 à 14:35.

                    Ça c'est de l'ordre du contrat entre client et provider. Je n'ai d'adresse chez eux alors j'ignore quelles sont les conditions d'utilisations de outlook.com mais si le destinataire ne veut pas avoir de spam dans une quelconque boite c'est pas vraiment ton problème mais le sien.

                    Comme dit plus haut dans un autre commentaire, il n'y a aucun standard qui impose que le spam aille dans telle ou telle boite.

                    • [^] # Re: Source?

                      Posté par  (site Web personnel) . Évalué à 10 (+13/-1).

                      Je n'ai d'adresse chez eux alors j'ignore quelles sont les conditions d'utilisations de outlook.com

                      Il se trouve que j’en ai une (créée à l’époque où ça s’appelait encore Hotmail, et toujours active).

                      Et je te le donne en mille : il n’y a aucune option accessible à l’utilisateur permettant de désactiver le filtrage des spams. La seule action possible est de whitelister certains émetteurs, pour dire « s’il te plaît, n’envoie pas les e-mails de cette personne dans la boîte indésirable ».

                      En particulier, il n’est pas possible pour l’utilisateur de dire « je veux pouvoir tout voir, n’envoie jamais un message qui m’est destiné dans un trou noir sans que j’ai une chance d’en prendre connaissance ».

                      il n'y a aucun standard qui impose que le spam aille dans telle ou telle boite.

                      Il y a un standard qui dit qu’un serveur s’engageant à délivrer un message doit le délivrer.

                      Sur ce, j’abandonne, même pour un vendredi il y a des limites.

                      • [^] # Re: Source?

                        Posté par  . Évalué à -10 (+1/-15).

                        Oui mais est-ce qu'elles stipulent que tu acceptes que tu leur délègues la gestion du spam ? Si le message est délivré mais que tu leurs dis qu'ils peuvent se torcher le cul avec ce n'est pas une question de respecter ou non les standards.

                        • [^] # Re: Source?

                          Posté par  (site Web personnel) . Évalué à 10 (+13/-1).

                          Oui mais est-ce qu'elles stipulent que tu acceptes que tu leur délègues la gestion du spam ?

                          Tu as du temps à perdre, vérifie toi-même.

                          (Spoiler alert: Non. Nulle part ce document ne dit que l’utilisateur accepte que le fournisseur de service peut bien faire ce que bon lui semble des messages qui lui sont normalement destinés.)

          • [^] # Re: Source?

            Posté par  . Évalué à 2 (+1/-1).

            Accepter un message en disant « tout va bien » alors qu’on l’envoie direct à la poubelle, sans aucune possibilité¹ pour le destinataire d’en prendre connaissance et sans jamais avertir l’émetteur, est une violation flagrante du protocole.

            Si tu savais à quel point c'est la norme (en pratique) au niveau en-dessous, sur IP, où un retour en ICMP est théoriquement obligatoire en cas de problème, blocage ou échec, et dans la norme (officielle et théorique)… J'espère que cette mauvaise pratique ne se répandra pas dans l'e-mail, ni dans IPv6 qui est légèrement plus épargné, mais c'est pas la joie non plus.

      • [^] # Re: Source?

        Posté par  (site Web personnel) . Évalué à -2 (+7/-11).

        Il est encore plus amusant que ta soif de troller ait dépassé ta curiosité et ton intelligence et que t'aies pas toi même vérifié la RFC avant de poster ton commentaire et surtout que tu n'aies pas compris ces adresses étaient juste des exemples et que toute ressemblance avec des adresses électroniques existantes ou ayant existé est purement fortuite.

        Hé bien justement, là c'est toi qui n'a pas compris le principe de cette RFC. Comme ton exemple est "juste un exemple", tu dois utiliser example.org ou .example. Là tu pourris potentiellement la boîte du pauvre gars qui possède self-hosting.org, ou qui la possédera à l'avenir.

        • [^] # Re: Source?

          Posté par  (site Web personnel) . Évalué à 8 (+8/-2).

          On peut aussi lire la RFC au lieu de tous essayer de raconter des trucs de mémoire qui ont de bonnes chances d’être faux :

          The Internet Assigned Numbers Authority (IANA) also currently has the following second level domain names reserved which can be used as examples.

          • example.com
          • example.net
          • example.org

          source

          Je mets en avant le bout important :

          domain names reserved which can be used as examples

          Donc on a en effet à disposition des domaines qui sont réservés à cette utilisation. Mais rien dans la RFC n’impose leur utilisation. Et heureusement d’ailleurs, ce n’est pas dans son rôle d’imposer ce genre de chose.

          • [^] # Re: Source?

            Posté par  (site Web personnel) . Évalué à 5 (+5/-2).

            Oui je l’ai relue bien sûr, mais j’ai été trop vite sur le can qui n’est en effet pas un must. J’étais trop focalisé sur l’objectif de cette RFC, qui ne peut en effet pas imposer la politesse aux autres.

            Car la raison pour laquelle Zenitram invoquait cette RFC est la raison d’être de cette RFC, qui a pour but d’expliciter les adresses d’exemple, de documentation et de test, et d’éviter la pollution de noms qui n’étant pas réservés peuvent être attribués à d’autres. C’est particulièrement sensible dans le cas de cette discussion, causée par la lutte contre le spam.

            Certes Lawless a le droit de pourrir le domaine qu’il cite en exemple, et de se contre-carrer des conséquences (pourtant indirectement objet de son journal). Mais le faire en insultant l’intelligence de Zenitram, tout en ne comprenant pas lui-même l’objectif de la RFC et donc l’argument de Zenitram, ça mérite une remarque.

            • [^] # Re: Source?

              Posté par  . Évalué à 1 (+3/-4).

              C'est raccrochage aux branches ou je ne m'y connais pas :)

              Mais vous lisez toujours pas les RFC c'est drôle :D

            • [^] # Re: Source?

              Posté par  . Évalué à 6 (+8/-3). Dernière modification le 16/06/20 à 09:43.

              Certes Lawless a le droit de pourrir le domaine qu’il cite en exemple, et de se contre-carrer des conséquences (pourtant indirectement objet de son journal). Mais le faire en insultant l’intelligence de Zenitram, tout en ne comprenant pas lui-même l’objectif de la RFC et donc l’argument de Zenitram, ça mérite une remarque.

              Je n'insulte pas l'intelligence de Zenitram, je dis juste que sa soif de troller a dépassé sa curiosité et son intelligence, intelligence qui est certainement bien supérieure à la moyenne, sinon il n'aurait pas de compte sur LinuxFr.org. ;-) En fait j'avais répondu un peu vite à sa phrase sans voir qu'il mentionnait la RFC 2606, RFC dont j'ignorais l’existence. Mais effectivement cela aurait plus propre d'utiliser l'adresse lawless@example.org en exemple, même si la RFC en question le propose comme un conseil et non comme une obligation.

              Comme le laisse entendre mon journal je ne suis pas un spécialiste des RFC, mais les différents commentaires que j'ai lu m'ont persuadé que Microsoft ne respectait pas les RFC en acceptant et en détruisant l'e-mail silencieusement.

              En fait ce qui est amusant est que Zenitram me reproche de ne pas respecter la RFC 2606, RFC qu'il a eu la curiosité de lire (mais mal comprise puisque c'est un conseil et non une obligation) mais que Zenitram n'ait pas eu la curiosité de lire les autres RFC pour se rendre compte que Microsoft ne respectait pas les RFC en détruisant des e-mails silencieusement, tout en me rejetant la faute et en donnant raison à Microsoft.

    • [^] # Re: Source?

      Posté par  . Évalué à 10 (+11/-0). Dernière modification le 12/06/20 à 11:48.

      En fait, tu connais la source du problème (adresse IP blacklistée), le journal se résume donc à : Microsoft fait comme les autres à blacklister des IP sans avertissement (3 niveaux habituellement : OK, spam potentiel mis dans le dossier spam, spam évident trashé sans avertissement) mais ne publie pas sa liste.

      Je dirais que « faire comme les autres », c'est d'envoyer un rejet, et non pas dropper silencieusement. Certains smtp sympas te pointent même vers une url avec les actions à suivre pour ne plus être rejeté (reverse dns, dkim, spf, inscription de ton ip chez eux, rate, etc.) dans le message de rejet. De mémoire c'est ce que fait gmail.

      Au vu de la difficulté à correctement cocher toutes les cases pour que gmail accepte de délivrer les mails en provenance de ton smtp perso, si dropper était une bonne pratique, je pense que gmail l'appliquerait ;) (et les admins deviendraient fous, car sans rejet, impossible de trouver la source de l'erreur).

      Maintenant, je n'ai pas eu cette expérience de drop avec hotmail ou office365. Chez hotmail la dernière fois que j'ai eu le pb (il y a un an), j'ai bien eu un rejet avec un code d'erreur microsoft, à entrer dans son moteur de recherche préféré pour tomber sur la bonne entrée du knowledge base, elle-même pointant vers un vieux formulaire du fin fond du web sur lequel il fallait inscrire son ip (v4, je crois bien que le formulaire n'acceptait pas les v6). Sur office365 je n'ai eu aucun pb jusqu'à présent (croisons les doigts, de plus en plus de gens s'y mettent).

      Mais mon expérience n'est pas forcément représentative, je n'ai que très peu de mails sortants (max une dizaine par mois)… Tant que ça délivre chez gmail et yahoo…

      gmail a par contre des comportements assez pénibles. Genre depuis mon serveur, il accepte de délivrer le même mail à 5 contacts gmails en destinataires, mais pas 10. Et puis la semaine d'après ça passe sans rien faire de plus. Je pense que c'est lié à des algos de réputation, où, malheureusement, le petit ne peut rien faire car il n'a pas assez de volume sortant pour se faire une bonne réputation.

    • [^] # Re: Source?

      Posté par  . Évalué à 10 (+11/-1).

      Salut,

      Perso j'attends de mon fournisseur de mail qu'il trashe complètement dans une trou noir les spams, sans qu'il ne m'avertisse

      Chacun son truc. Moi, je veux qu'il ne fasse rien. C'est mon problème, pas le sien !

    • [^] # Re: Source?

      Posté par  (site Web personnel) . Évalué à 10 (+30/-2). Dernière modification le 12/06/20 à 16:16.

      Perso j'attends de mon fournisseur de mail qu'il trashe complètement dans une trou noir les spams, sans qu'il ne m'avertisse

      Ce n’est pas le sujet du journal.

      vaut mieux ne pas aider le spammer en lui disant que sont test ne marche pas

      Ah en fait tu sais quel est le sujet du journal, mais tu ne connais pas ce sujet et tu dis juste des bêtises.

      Il y a une règle de civisme de base qui est : tu dois prendre soin des gens honnêtes, pas des gens malhonnêtes.
      Ça signifie que tu écris les lois, les protocoles, etc. pour les gens honnêtes.

      Si tu fais le contraire, tu arrives à des situations ubuesques où il est plus difficile pour une personne honnête de faire les chose honnêtement qu’une personne malhonnête de faire des chose malhonnêtement. Un bon exemple dont on a souvent parlé sur LinuxFr sont les protections anti-piratages et autres DRM qui rendent la vie impossible à ceux qui voudraient consulter une œuvre légalement, quand le pirate moyen télécharge la même œuvre en deux clics chez son dealer préféré.

      On dit la même chose des clauses abusives dans certaines licences, et c’est la même raison qui fait qu’une licence libre n’interdisent pas l’usage aux « méchants », d’une part ce n’est pas son rôle de faire la police, de deux, quand quelqu’un veut faire quelque chose de malhonnête, il ne se souciera pas de la licence de toute façon… autant ne pas emmerder les personnes honnêtes en mettant des contraintes pour celui qui ne lira même pas la licence…

      Il y a une dernière chose que tu oublies, les bonnes pratiques recommandées par les hébergeurs de mail pour ne pas être considéré comme spammeur sont grosso modo des pratiques qui t’obligent à avoir pignon sur rue, à farmer la réputation de ta pile logiciel de traitement de mail ainsi que la réputation de ton adresse IP.

      Pour simplifier, pour ne pas être un spammeur il faut dire « promis, je n’enverrai mes mails dans le futur que de cette manière là que tu me demandes, je suis hébergé là, ou là, ou là, et pas ailleurs, je n’utiliserai que cette IP là et pas une autre, et si ça doit changer je te le dirai systématiquement, etc. ».

      C’est à dire que le spammeur, pour être whitelisté, doit prendre tous les moyens qui permettent au destinataire de le blacklister le plus efficacement possible en cas d’impair. Une fois que le spammeur a fait tout ce qui est demandé, l’hébergeur destinataire (ici, GMail, Hotmail, etc.) n’aurait même pas besoin d’analyser le contenu des mails avec des heuristiques compliquées : au premier rapport de spam manuel d’un client, l’hébergeur peut te mettre en liste noire, y compris tes autres serveurs que tu as annoncé mais qui n’ont pas encore envoyé de spam, et ceux que tu annonceras dans le futur.

      Bref, tu n’as aucun risque à dire au spammeur comment être whitelisté, le spammeur n’a aucun intérêt à mettre en place les bonnes pratiques pour être whitelisté.

      Le seul moyen d’envoyer du spam en étant whitelisté et mettant en œuvre toutes les bonnes pratiques est de devenir un « too big too fail » en mêlant un certain ratio de spam à du mail légitime. Typiquement si tu es un gros fournisseur qui héberge des millions de boîtes ou un fournisseur de publipostage par mail avec des milliers de clients, tu peux essayer d’être joueur en tolérant un petit pourcentage de spammeurs en mode parrain de mafia.

      Mais globalement les méthodes à la SPF, DKIM et autres ont aussi été créées pour démanteler la méthode du « parrain de mafia », où il suffisait d’utiliser le SMTP de son fournisseur d’accès pour envoyer du lourd. Le rôle d’un SMTP de fournisseur d’accès n’aurait jamais dû être celui de whitelister les mails de ses clients en mode « tu peux pas me blacklister ou tu blacklist tout un pays ». Je ne vois aucune raison pour qu’un fournisseur d’accès fournisse un relai ouvert, autre que contourner l’incompétence des entreprises en mode « je ne veux pas acquérir de compétence et je veux que mon photocopieur envoie des mails en renseignant simplement une IP sinon cétrokompliké ».

      Bref, tout ça me donne l’impression que tu ne sais pas de quoi tu parles. As-tu déjà mis en œuvre des services mails (réception et émission de mails…) avec les contraintes actuelles ou bien tu parles dans le vent ? As-tu déjà mis en œuvre SPF, DKIM, DMARC, etc? As-tu déjà retiré une IP de la liste noire de Hotmail (évoquée dans le journal) ? As-tu déjà fait face à des fournisseurs de liste noire qui te demande de payer en bitcoin pour être retiré alors que l’IP en question a été mise en liste noire quand elle appartenait à quelqu’un d’autre quelques années plus tôt, quand bien même ça fait des années que tu as pu prouver que tu es clean (il y a clairement un marché de scam, là) ? As-tu déjà lu dans les logs de ton serveur les recommandations que Google te fait pour éviter de te faire limiter ton débit de mail ou supprimer des mails ? Normalement, si tu essaies d’autohéberger du mail, de mettre en place un service de mailing-list ou de publipostage, et autres services de ce genre, et tu rencontreras ces problématiques dès le premier jour.

      Si tout cela ne t’es jamais arrivé, alors tais-toi, tu emmerdes juste les gens avec ton besoin de donner ton avis que bizarrement tu considères être pertinent sur des sujets que tu ne connais pas. Tu ne peux pas donner ton avis sur tout, ou bien tu supposes que ta personne serait incroyablement supérieure aux autres pour que même sur les sujets que tu ne connais pas, ton avis compte. De plus, as-tu déjà entendu parler de l’effet Effet Dunning-Kruger?

      Si tu as besoin d’exister, va et rencontre des gens qui seront intéressés par ton avis ou qui sont à ton niveau sur les sujets qui sont les tiens. Là tu agis comme un enfant qui interrompt des discussions de grandes personnes pour donner son avis sans voir qu’il est un enfant et qu’il ne comprend pas de quoi les adultes parlent. Les adultes bienveillants laisseront l’enfant donner son avis de temps en temps afin de lui apprendre certaines formes comme le fait de ne pas couper la parole, mais à un moment ils demanderont à l’enfant de sortir jouer avec les enfants du voisinage parler de sujets qui sont les siens, pour pouvoir traiter du fond entre grandes personnes sur des sujets de grande personne.

      ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Source?

      Posté par  . Évalué à 10 (+14/-0).

      Perso j'attends de mon fournisseur de mail qu'il trashe complètement dans une trou noir les spams, sans qu'il ne m'avertisse (et je me fous un peu qu'il avertisse le spammeur, ou plutôt je comprend : vaut mieux ne pas aider le spammer en lui disant que sont test ne marche pas).

      Parce que le spammeur ne peut pas créer une boîte sur outlook pour vérifier si ses mails passent de base ? Et franchement, vu tout les spams que je recois sur mes boites hotmails, leur méthodologie a pas l'air tellement plus efficace que chez les autres fournisseurs qui respectent les RFC.

      Opera le fait depuis 10 ans.

  • # Les recommandations de Microsoft

    Posté par  (site Web personnel) . Évalué à 10 (+26/-0).

    Si tu est motivé, tu peux essayer de suivre toutes les recommandations de Microsoft pour assurer la délivrance des messages, comme participer au Junk Email Reporting Program ou t’inscrire au Smart Network Data Services.

    D’expérience, ça aide un peu mais ça n’est pas suffisant. Je soupçonne fortement que la silver bullet qui garantira que tous tes messages arrivent est de payer pour la certification Return Path (dont le prix ne semble plus être disponible en ligne, mais à l’époque où j’avais vérifié je crois que c’était de l’ordre de $250 par an).

    (Je ne mettrais pas de lien vers Return Path parce que je ne cautionne pas cette pratique qui me semble ouvertement mafieuse — « c’est un joli serveur mail que vous avez là, ce serait dommage que ses messages se perdent. »)

    • [^] # Re: Les recommandations de Microsoft

      Posté par  (site Web personnel) . Évalué à 10 (+12/-0).

      Il y a aussi le cas de la liste noire «spamrl» qui pourrit la vie de pas mal d'admins de serveur mail.

      On ne peut pas les contacter, et il est impossible de s'en faire retirer.

      J'ai un serveur mail qui se trouve dedans, et qui est par ailleurs complètement clean par rapport aux listes classiques.

      Bien que de fort mauvaise réputation, je retrouve régulièrement spamrl associée aux serveurs Exchange de certains prestataires de services mail.

      J'ai contacté plusieurs de ces prestataires.
      Aucun n'a pu ou n'a voulu me dire d'où sortait cette liste.
      Au mieux, je suis whitelisté sur le serveur concerné, ce qui ne fait que contourner le problème.

      En faisant quelques recherches supplémentaires, je suis tombé sur des accointances assez louches.
      Je n'arrive pas à retrouver l'enquête très complète sur le sujet (un blog allemand il me semble, mais écrit en anglais). Je garde donc mes soupçons pour moi.

      Ce qui est certain pour ma part, c'est que cette liste ne se rencontre que dans la config de serveurs Exchange.

  • # Microsoft n'est pas le seul à supprimer des messages sans prévenir

    Posté par  . Évalué à 8 (+9/-1). Dernière modification le 12/06/20 à 11:48.

    Bon nombre de prestataires (gratuits ou payants) effacent les messages sans prévenir ni l'expéditeur ni le destinataire. Je l'ai constaté depuis longtemps avec free.fr, La Poste et Orange et avec quelques hébergeurs mutualisés.
    Ils utilisent des filtres antispam sur lesquels on n'a pas la main et qu'on ne peut pas toujours contourner, même en ajoutant des règles de filtrage de ce type : http://humeurs.pub.blog.free.fr/index.php?post/2015/08/16/Comment-d%C3%A9sactiver-l-antispam-laposte.net

    À ce problème d'antispam s'ajoute le problème de synchronisation entre le serveur et le client mail pour afficher tous les dossiers.
    Par exemple, si on récupère les messages en POP, le dossier SPAM/INDESIRABLE/QUARANTAINE (le nom change suivant le fournisseur) qui est sur le serveur ne correspondra pas forcément au dossier local Antispam si on n'a pas bien paramétré la correspondance des dossiers sur le serveur et des dossiers locaux. Du coup, on a régulièrement des mails qui restent bloqués sur le serveur et qui sont effacés automatiquement au bout de x jours.
    Si on récupère les messages en IMAP, la synchronisation ne fait pas non plus apparaître tous les dossiers existants sur le serveur, à moins de faire une configuration spécifique du compte dans le client mail. Par exemple, dans Thunderbird, il faut décocher l'option très bien cachée "Afficher uniquement les dossier avec abonnement". Je vous souhaite bonne chance pour la trouver. Et là, miracle, vous retrouverez pleins de vieux mails qui traînent sur le serveur, y compris des faux positifs.

    La meilleure solution, c'est l'auto-hébergement, géré par soi-même ou sous-traité par un prestataire compétent et ouvert d'esprit.

  • # Un bon récurage

    Posté par  . Évalué à 10 (+17/-1).

    C'est un problème récurant

    Oui, ça nettoie efficacement la boite de réception.

    Et ça élimine du coup les problèmes récurrents de spam.

    M'en bati sieu nissart

  • # Pas nouveau ça

    Posté par  (site Web personnel) . Évalué à 10 (+22/-0).

    Ce n'est vraiment pas nouveau, ça. Microsoft doivent être le plus problématique des grands hébergeurs de courrier électronique, et devoir gérer des problèmes avec eux est un grand classique de l'auto-hébergement.

    Il est d'ailleurs toujours un peu amusant de leur signaler un problème, et de se voir répondre qu'il faut contacter son administrateur de courrier électronique. Mais c'est moi, mon administrateur, bandes de baltringues !

    • [^] # Re: Pas nouveau ça

      Posté par  . Évalué à 5 (+3/-0). Dernière modification le 12/06/20 à 17:15.

      Salut,

      Ce n'est vraiment pas nouveau, ça. Microsoft doivent être le plus problématique des grands hébergeurs de courrier électronique

      Oulala, non, t'inquiète : gmail et yahoo sont toujours dans la course, et probablement d'autres :)

      Je fais un petit bout de hors-sujet, si vous me le permettez (on est 'dredi !).

      Il est d'ailleurs toujours un peu amusant de leur signaler un problème

      Quand tu y arrive ! Je me souviens d'un éditeur d'antivirus qui n'avait aucun moyen de contact direct quand j'ai cherché à les avoir. Donc impossible en tant qu'éditeur de logiciel de leur signaler un faux positif (alors qu'un test montrait que tous leurs concurrents ne trouvaient rien, et que nous non plus, on n'avait rien trouvé non plus).

      Mais là, t'es dans une situations assez "gag" (enfin, j'en ris maintenant, mais sur le moment, c'est pas très drôle). La personne avait fait l'achat de nouveau matériel informatique, sa licence pour le produit que nous commercialisions était définitivement valide, mais non. Impossible de tuer le machin autre que temporairement. Ni de remonter d'info rapidement. C'est hyper pénible quand tu peux rien pour ton client ;)

  • # https://sendersupport.olc.protection.outlook.com/snds/

    Posté par  . Évalué à -8 (+4/-14).

    As-tu ouvert un compte sur SNDS, ajouté tes IPs ou demander d'en avoir le droit si tu en est pas propriétaire et regardé ce qu'il en est.

    Outlook est l'un des rares à avoir ce type d'outils permettant d'avoir une vue d'ensemble de l'états tes IPs chez eux.

    Je dirais même qu'un tel journal n'a rien à faire ici sans une analyse sur leur outil. Au pire, ça vaut une entrée dans le forum.

    • [^] # Re: https://sendersupport.olc.protection.outlook.com/snds/

      Posté par  . Évalué à 10 (+10/-0).

      Par curiosité, je viens d'aller voir.

      To access SNDS, please log in with a Microsoft Account and then request access to the IPs for which you are responsible. You'll be taken through a simple authorization process, and then you'll soon have access to a wealth of information about those IPs.

      Non merci!

      • [^] # Re: https://sendersupport.olc.protection.outlook.com/snds/

        Posté par  (site Web personnel) . Évalué à 6 (+3/-0).

        Oui, il faut créer un compte hotmail (ou autre compte passeport) pour pouvoir se faire dé-blacklister. Bon, en même temps tu as besoin d’une boîte mail chez eux pour tester que tes mails ne sont pas supprimés silencieusement.

        ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: https://sendersupport.olc.protection.outlook.com/snds/

        Posté par  . Évalué à 10 (+15/-1). Dernière modification le 13/06/20 à 10:02.

        Perso, je me suis demandé si je n'allais pas utiliser une adresse email Microsoft pour relayer mes mails à destination des boites mails Microsoft, avec un entête Reply-To et peut-être Sender (pas From) vers ma bonne addresse.

        Je dirais même qu'un tel journal n'a rien à faire ici sans une analyse sur leur outil. Au pire, ça vaut une entrée dans le forum.

        Franchement, s'il fallait déployer la même énergie pour tous les fournisseurs de mails pour finalement zéro résultat, ce serait ingérable. J'héberge mes mails depuis 2016, j'arrive toujours systématiquement dans les spams de mes destinataires Outlook et dans la boite de réception (à deux trois exceptions près) des autres.

        Et puis ce n'est pas comme si leurs outils étaient facile à utiliser (pour l'avoir fait) :

        • leurs pages web sont pas à jour, il y a des liens cassés partout
        • la navigation est super compliquée, avec des pages qui se renvoient la balle entre elles
        • très difficile de trouver comment contacter leur support.
        • leur support, d'ailleurs, répond souvent de manière générique, sans vraiment lire les mails. Ils te demandent de vérifier qu'on gère bien les inscriptions aux mailing lists qu'on gèrerait, tout ça tout ça. Je venais de leur dire que je ne fais qu'envoyer deux trois mails perso par si par là avec mon serveur mail.
        • on est considérés comme du spam même vers les destinataires habituels, qui nous écrivent, depuis des années. La seule solution c'est qu'ils nous placent comme "expéditeur de confiance". Et d'expérience, les gens ne prennent pas forcément la peine de le faire même quand on leur dit.
        • ils te disent qu'ils ne maitrisent pas ce que fait leur propre solution antispam, SmartScreen. Mais écoutez, si votre propre solution antispam est merdique, je n'y peux rien, moi, ce n'est pas moi qui l'ai codée, choisie, mise en place ! Je ne peux pas entendre que vous ne maîtrisez pas votre propre outil ! C'est smart comme mes pieds, oui.

        En fait, ils s'en foutent, c'est tout. Le truc qui marcherait peut-être serait que l'auto hébergement se répande massivement, ou que le nombre de gens utilisant des tout petit hébergeurs devienne significatif. Bon courage pour ça (la route est longue mais le chemin est libre ?)

        Alors non, je ne suis pas d'accord qu'un tel journal n'a rien à faire ici sans une analyse sur leurs outils. À ce stade, autant faire beaucoup de bruit et ne pas louper une occasion de décourager les gens d'ouvrir des boites mails Outlook, ou de les encourager à migrer. Microsoft est tout simplement un mauvais acteur dans le domaine des mails.

        En fait, j'ai compris qu'il faut envoyer une quantité minimale de mails vers leurs serveurs pour qu'ils puissent avoir des stats suffisantes sur nos mails pour voir qu'on ne fait pas du spam… mais bordel, si j'envoie 3 mails par mois voire moins vers une adresse habituelle qui m'envoie aussi des mails, ce n'est pas du spam ! Je n'atteindrai jamais le volume requis. Un comble ! il faut envoyer beaucoup de mails pour ne plus être considéré comme spam.

        Bref, je rejoins la personne ici qui trouve qu'ils ont des pratiques mafieuses avec leur partenariat avec Return-Path, dont je n'ai jamais entendu parler autrement que sur les sites de Microsoft, en cherchant des solutions contre les mails qui arrivent dans les spams sur les boites Microsoft.

        Je n'ai jamais eu de si gros soucis avec aucun autre fournisseur de mail. De très rares fois, un mail arrive en spam vers une adresse Gmail, souvent des messages qui contiennent un lien et peu de texte. C'est malheureux mais au moins on sent que le problème est certainement causé par un filtre sur le contenu un minimum compréhensible.

        • [^] # Re: https://sendersupport.olc.protection.outlook.com/snds/

          Posté par  . Évalué à 7 (+5/-1).

          En fait, ils s'en foutent, c'est tout. Le truc qui marcherait peut-être serait que l'auto hébergement se répande massivement, ou que le nombre de gens utilisant des tout petit hébergeurs devienne significatif. Bon courage pour ça (la route est longue mais le chemin est libre ?)

          Tu paries combien qu'au lieu de corriger le problème, tu recevrais une réponse automatique:

          "Votre serveur email est mal configuré, nous ne pouvons acheminer l'email ci-dessous vers le destinataire. Veuillez contacter votre administrateur.
          La configuration d'un serveur email pour qu'il soit de confiance et sécurisé est une tache très complexe. Si vous avez besoin d'aide, nous vous recommandons la solution d'hébergement d'emails Microsoft Outloook!"

          Et tu t'amuseras bien à expliquer à tes utilisateurs que ce sont des foutaises.

    • [^] # Re: https://sendersupport.olc.protection.outlook.com/snds/

      Posté par  . Évalué à 10 (+13/-3). Dernière modification le 13/06/20 à 10:30.

      > Je dirais même qu'un tel journal n'a rien à faire ici sans une analyse sur leur outil. Au pire, ça vaut une entrée dans le forum.

      Le fait d'être obligé de créer un compte chez l'hébergeur destinataire d'un de tes mails pour vérifier qu'il n'a pas de comportements indu mérite, à mon humble avis, un journal. En revanche, ton commentaire un peu cassant mérite juste un moinssage.

  • # Parcours du combattant

    Posté par  . Évalué à 9 (+10/-1).

    Cela fait des années que j'ai ce problème.

    J'ai ouvert des tickets, vérifié les records SPF/DMARC/DKIM, vérifié la réputation de mes domaines, ajouté l'IP de ma machine sur leur portail Smart Network Data Service. J'ai fait du tweet shaming et j'ai même téléphoné! Rien.

    Ma conclusion c'est qu'il faut payer une société de solution anti-spam (que je ne vais pas citer ici) pour améliorer sa réputation, sinon rien ne change pour les domaines avec un petit trafic.

  • # Citation par NextINpact

    Posté par  . Évalué à 4 (+2/-0).

    Bravo, ce journal a été cité par NextINpact : https://www.nextinpact.com/news/109077-protection-contre-phishing-et-spoofing-demail-via-spf-et-dkim-faillite-francaise.htm

    Aussi critiquables qu'elles soient, les grandes plateformes américaines jouent également le jeu [de DKIM]. Certes, leur politique de réception des emails ou de gestion de SPF est parfois trop stricte. On pense à Yahoo qui s'est illustré sur le sujet il y a quelques années. Ou encore à Microsoft. Mais on ne pourra pas leur reprocher un manque de réactivité sur l'implémentation de ces standards. Outlook.com, qui ne signe plus ses emails sortant avec DKIM au profit de SPF, DMARC et de la signature de l'ensemble de la chaîne via ARC, en avait déjà fait le tour dès décembre 2012.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.