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.
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 Lawless . En réponse au journal Le service messagerie Microsoft Outlook.com détruit silencieusement vos e-mails. Évalué à 10. Dernière modification le 12 juin 2020 à 11:41.
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 :
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.
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.
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.
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.
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 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.