- Marquer comme nouveau
- Ajouter aux favoris
- S'abonner à ce post
- S'abonner au fil RSS de ce post
- Imprimer
- Signaler
- Marquer comme nouveau
- Ajouter aux favoris
- S'abonner à ce post
- S'abonner au fil RSS de ce post
- Imprimer
- Signaler
Bonjour @Heffgé ,
Essayez port 587 sans sécurisation à la place du port 25 qui n'est plus le bienvenu depuis 2006 (port préféré des spammeurs)
- Marquer comme nouveau
- Ajouter aux favoris
- S'abonner à ce post
- S'abonner au fil RSS de ce post
- Imprimer
- Signaler
Bonjour à tous,
La lecture de la notice
indique
Lorsqu’une application spécifie WINHTTP_OPTION_SECURE_PROTOCOLS, le système vérifie l’entrée du Registre DefaultSecureProtocols et, s’il est présent, remplace les protocoles par défaut spécifiés par WINHTTP_OPTION_SECURE_PROTOCOLS avec les protocoles spécifiés dans l’entrée de Registre. Si l’entrée de Registre n’est pas présente, WinHTTP utilise les valeurs par défaut du système d’exploitation existant pour Windows WINHTTP_OPTION_SECURE_PROTOCOLS HTTP. Ces valeurs par défaut WinHTTP suivent les règles de priorité existantes et sont rejetées par les protocoles et protocoles désactivés SCHANNEL définies par application par WinHttpSetOption.
Ceci signifie que cela aura un impact pour les applications qui utilisent l'indication d'option WINHTTP_OPTION_SECURE_PROTOCOLS. donc à vérifier pour les 2 applications mentionnées (Windows Mail et EmClient)
Remarque Le programme d’installation de correctifs correctifs n’ajoute pas la valeur DefaultSecureProtocols. L’administrateur doit ajouter manuellement l’entrée après avoir déterminé les protocoles de remplacement. Vous pouvez également installer l’application «Correctif simple» pour ajouter l’entrée automatiquement.
Ceci signifie que le correctif simple ajoute les entrées automatiquement suivantes (donc ils y ont un peu penser 😉 )
L’entrée de Registre SecureProtocols qui présente des 0xA80 de valeur permettant d’activer TLS 1.1 et 1.2 sera ajoutée dans les chemins d’accès suivants :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
L'entrée manuelle permet un meilleur contrôle du protocole admis (1.1, 1.2 , les deux ou plus)
En règle générale une clé Wow6432Node s'accompagne de la même clé sans le Wow6432Node afin d'avoir la définition pour les applis 64 bits et celles en 32 bits.
ex:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.2
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.2
Ma modeste contribution au débat.
L'adresse du correctif est la suivante
qui fera :
L’entrée de Registre SecureProtocols qui présente des 0xA80 de valeur permettant d’activer TLS 1.1 et 1.2 sera ajoutée dans les chemins d’accès suivants :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
- Marquer comme nouveau
- Ajouter aux favoris
- S'abonner à ce post
- S'abonner au fil RSS de ce post
- Imprimer
- Signaler
Bonjour @Heffgé
Pour windows Mail 2012, la seule option viable (façon de parler), c'est d'utiliser
imap.sfr.fr port 143 non sécurisé
et
smtp.sfr.fr port 587 non sécurisé
Les clés TSL du registre ne changeront rien au comportement de cette antiquité
Viable jusqu'à ce que les connexions non sécurisées soient bannies...ou qu'un piratage vous mette à terre
- Marquer comme nouveau
- Ajouter aux favoris
- S'abonner à ce post
- S'abonner au fil RSS de ce post
- Imprimer
- Signaler
Moi, le correctif a fonctionné pour WLM 2012 , aussi antique soit-il.
Je suis donc en TLS 1.2 et ça fonctionne parfaitement en chiffré.
- Marquer comme nouveau
- Ajouter aux favoris
- S'abonner à ce post
- S'abonner au fil RSS de ce post
- Imprimer
- Signaler
Bien vu TagadaTsoinTsoin. Avec le port 587 je peux aussi envoyer. Donc à condition de rester en mode sécurisé j'ai une solution en attendant que le problème puisse être résolu.
SGDA, j'ai effectué les modifs indiquées dans le registre si ce n'est que j'ai mis A00. Sur ma machine de test tout baigne. La vétusté de Windows Mail n'est donc pas en cause puisque le problème ne se manifeste que sur mon ordinateur habituel.
Je vous remercie tous pour vos interventions et je reste à l'écoute de toute suggestion.
- Marquer comme nouveau
- Ajouter aux favoris
- S'abonner à ce post
- S'abonner au fil RSS de ce post
- Imprimer
- Signaler
Bonjour @Heffgé
Bien vu TagadaTsoinTsoin. Avec le port 587 je peux aussi envoyer. Donc à condition de rester en mode sécurisé j'ai une solution en attendant que le problème puisse être résolu.
Oui tu as abouti à une solution qui fonctionne.
Mais je ne dirai pas qu'elle est forcément sécurisée :
- 587 c'est le port standard pour essayer STARTTLS... qui peut aboutir à une non sécurisation si la réponse de l'échange entre les 2 parties est "je ne sais pas faire du TLS comme demandé"... Donc ça pourrait ne pas être chiffré, ce qui serait donc très peu sécurisé (quoique fonctionnel)... (et pour moi ça devrait même désormais être banni 😎)
- alors que sur le port 465 c'est obligatoirement chiffré.
À+
Digiclient NC → parti de sa planète disparue, pour une nouvelle terre d'accueil ♥
LaBox THD 4K (V3) - Connexion FttLA à 1000↓↑40 Mbit/s
- Marquer comme nouveau
- Ajouter aux favoris
- S'abonner à ce post
- S'abonner au fil RSS de ce post
- Imprimer
- Signaler
Le serveur smtp.sfr.fr répond les caractéristiques suivantes à la commande EHLO sur le port 587
ehlo smtp.sfr.fr
250-msfrf2623.sfr.fr
250-PIPELINING
250-SIZE 20971520
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 8BITMIME
pas eu le temps d'aller plus loin pour avoir la version de TLS
Version 1.2