Impossible d'envoyer ou de recevoir les messages

[denisab]

Impossible d'envoyer ou de recevoir les messages pour le compte Sfr. Le téléchargement des en-têtes du dossier 'Boîte de réception' n'est pas termImpossible d'envoyer ou de recevoir les messages pour le compte Sfr. Le téléchargement des en-têtes du dossier 'Boîte de réception' n'est pas terminé. Réponse du serveur : Votre commande IMAP n'a pas été envoyée au serveur en raison d'erreurs non liées au réseau. Ceci signale peut-être un manque de mémoire de votre système.
Serveur : 'IMAP.sfr.fr' Numéro d'erreur Windows Live Mail : 0x800CCC0F
Protocole : IMAP Port : 993 Sécurisé (SSL) : Non

Edit CM : Votre sujet a été déplacé car il n'était pas dans la bonne catégorie. L'intitulé de votre message a été modifié pour une meilleure compréhension. Vous recevrez bientôt une réponse de la Communauté. Bonne journée !

[utilisateur_supprimé]

Bonjour,

Port 993 et SSL = non, ça ne fonctionne pas.

Essayez SSL = oui et port 993 (recommandé)

Autre couple qui fonctionne SSL = non et port 143 (non recommandé)

Vous n'avez pas besoin d'indiquer le port, le fait de cocher ou non la case SSL positionne correctement le port (même sur un vieux WLM obsolète)

[Ryry]

Hello @utilisateur_supprimé 

Tu ne mentionnes que 2 cas possibles sur 3 concernant la config au serveur IMAP :

---

Essayez SSL = oui et port 993 (recommandé)

Autre couple qui fonctionne SSL = non et port 143 (non recommandé)

---

En effet, SSL/TLS n'a jamais été conçu pour fonctionner sur le port 143.

D'ailleurs je pense que désormais SFR n'accepte plus du tout le cas que tu indiques comme "non recommandé".

Par contre ne pas oublier (le cas échéant) qu'il y a une combinaison sécurisée parfaitement recommandée sur le porte 143

• StartTLS : oui, et port : 143 qui est aussi une solution recommandable techniquement.

Souvent, les serveurs qui acceptent SSL/TLS sur le port 993, acceptent aussi StartTLS sur le port 143.

À+

[utilisateur_supprimé]

Salut @Ryry ,

J'ai lu un truc sur StartTLS il y a quelques temps.

StartTLS déclenche le dialogue pour trouver la meilleure sécurisation entre le serveur et le client... mais, si aucune méthode de chiffrage n'est commune au serveur et au client, la connexion passe en non sécurisée sans avertissement.

Je n'avais jamais pensé à ce cas de figure.

Avec SSL/TLS, si aucune méthode de chiffrage n'est commune au client et au serveur, la connexion n'aboutit pas.

Avec WLM la question ne se pose pas, il ne reconnait pas StartTlS.

[Ryry]

Hello @utilisateur_supprimé 

---

J'ai lu un truc sur StartTLS il y a quelques temps.

StartTLS déclenche le dialogue pour trouver la meilleure sécurisation entre le serveur et le client... mais, si aucune méthode de chiffrage n'est commune au serveur et au client, la connexion passe en non sécurisée sans avertissement.

---

Oui et non, je ne pense pas que tu puisses généraliser cette affirmation.

Même si, encore aujourd'hui, StartTLS consiste bien à amorcer la communication dans un canal en clair, je me demande si tu ne confonds avec un ancien libellé "approximatif et trompeur" des premières versions de Thunderbird qui mélangeait un peu le sens de SSL/TLS d'une part, et StartTLS d'autre part :

• lire paragraphe "dénomination incorrecte" ICI
• Cette fameuse dénomination "TLS si possible" est aussi évoquée dans cette article ICI, qui du coup en effet pousse à choisir l'autre port pour éviter le doute.

Mais je ne pense pas que ce comportement "si possible" soit la norme (et caché à l'utilisateur en ne précisant même pas "si possible") et j'ai tendance à penser que si Thunderbird a enlevé cette dénomination "si possible" c'est sans doute parce qu'il n'a plus ce comportement "si possible".

(Si tu trouves d'autres articles, ou doc d'assistance en ligne sur le comportement de Thunderbird avec StartTLS, ça m'intéresse car tu viens de me donner un affreux doute, mais chez nous au travail, la DSI préconise StartTLS depuis bien longtemps).

J'en restais à la différence entre SSL/TLS et StartTLS de fond qui est d'utiliser SSL ou TLS (TLS dans les 2 cas aujourd'hui) d'une manière différente comme j'ai pu le détailler dans d'autres discussions :

• SSL/TLS = transmission en clair dans un canal chiffré
• StartTLS = transmission chiffrée dans un canal en clair

Le reste de l'article que je donne en lien est très bien pour décrire tout ça à mon sens.

À+

[utilisateur_supprimé]

@Ryry ,

J'ai eu du mal à retrouver ce truc qui trainait au fond de ma mémoire, mais je l'ai eu !

https://www.altospam.com/glossaire/starttls.php

Extrait

StartTLS (ou TLS opportuniste) permet, sur un port unique, l'élévation d'une connexion non-sécurisée en sécurisée : Lors d'un premier échange en clair, client et serveur communiquent sur leurs capacités respectives de chiffrement et s'accordent pour établir ce canal sécurisé, après quoi le reste de la communication est chiffrée. Si aucune méthode de chiffrement compatible n'est trouvée, la communication peut tout de même continuer, en clair. C'est donc une solution d'interopérabilité qui permet à un maximum d'équipements disparates de communiquer dans les meilleures conditions.

[Ryry]

Hello @utilisateur_supprimé 

---

Si aucune méthode de chiffrement compatible n'est trouvée, la communication peut tout de même continuer, en clair. C'est donc une solution d'interopérabilité qui permet à un maximum d'équipements disparates de communiquer dans les meilleures conditions.

---

Oui.

Je ne discute pas de la "possibilité technique" de poursuivre.

Je discute le fait que les outils actuels, Thunderbird par exemple, choisissent cette stratégie (ou au contraire refusent d'aller plus loin comme on le comprend de prime abord dans ce message d'erreur de Thunderbird qui demande à l'utilisateur de décocher StartTLS puisqu'il constate que le serveur au bout ne le supporte pas, lire ICI)

C'est ce point que je voudrais tirer au clair :

1. Thunderbird profite-t-il de cette faisabilité... pour le faire ?
2. ou se refuse-t-il à continuer pour me respecter son option qui n'est plus libellée "TSL si possible" afin d'éviter tout malentendu pour l'utilisateur ?

Jusqu'à présent j'étais résolument convaincu du cas 2, car le cas 1 me parait une ergonomie logicielle déraisonnable.

à+

P.S. Ce distingo entre les 2 modes de sécurisation d'IMAP selon 2 approches sur 2 ports différents me fait penser au distingo entre FTPS et SFTP :

• un peu comme StartTLS, FTPS ne fait qu'augmenter les possibilités du FTP standard et "peut" passer en chiffer et "peut" exisger des certificatfs des participants. Mais rien ne t'interdit de lancer FTPS avec les options qui disent que tu ne veux surtout pas fonctionner autrement qu'en chiffré
• SFTP, un peu comme SSL/TLS, change tout et dès le départ on y parle en chiffré

Cela dit, dans un cas comme dans l'autre (à part avec ma box SFR sur mon réseau local 🤣) je refuse de lancer une connexion "de type FTP" sans forcer un niveau de sécurisation, ne serait-ce que pour un transit de mot de passe pas bidon.

[utilisateur_supprimé]

@Ryry ,

Je n'ai pas tout lu (ce que je vais écrire est peut-être déjà dans ton lien)

Quand la négociation SMTP commence le serveur indique les options qu'il gère.

Si le serveur  ne gère pas STARTTLS, Thunderbird est bien embêté.

Exemple avec SFR 

220 msfrf2631.sfr.fr ESMTP ABO **************************

EHLO moi (EHLO est la commande ESMTP pour se présenter au serveur)

250-msfrf2631.sfr.fr

250-PIPELINING

250-SIZE 20971520 (taille maxi d'un mail)

250-ETRN

250-STARTTLS

250-AUTH LOGIN PLAIN

250-AUTH=LOGIN PLAIN (j'ai cru que le serveur bafouillait mais non il y a une différence avec le précédent)

250-ENHANCEDSTATUSCODES

250 8BITMIME

SFR gère STARTTLS, on peut le paramétrer dans Thunderbird

Contrairement au SMTP d'Orange

220 mwinf5d29 ME ESMTP server ready

EHLO moi

250-mwinf5d29 hello [x.x.x.x], pleased to meet you

250-HELP

250-AUTH LOGIN PLAIN

250-SIZE 44000000

250-ENHANCEDSTATUSCODES

250-8BITMIME

Avec Orange utilisation de SSL/TLS nécessaire (Thunderbird ne pourra pas utiliser StartTLS)

Maintenant je vais aller lire ton lien 😀