Echec de récupération de mails via Icedove

Salut à tous,

Un compte configuré en IMAP sur Icedove a cessé d’un jour à l’autre de fonctionner correctement. Lors d’une tentative de “Relever les messages”, Icedove reste bloqué sur “Connected to XXXX.fr” (j’ai remplacé partout le nom de domaine par XXXX.fr)

J’ai donc activé le log du traffic IMAP de Icedove, et voici sa sortie :

-834668800[7f8cd65e3ac0]: ImapThreadMainLoop entering [this=cf932000] -217573600[7f8cf1e59260]: cf932000:XXXX.fr:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN -834668800[7f8cd65e3ac0]: cf932000:XXXX.fr:NA:ProcessCurrentURL: entering -834668800[7f8cd65e3ac0]: cf932000:XXXX.fr:NA:ProcessCurrentURL:imap://mon%2Enom@XXXX.fr:993/select%3E%5EINBOX: = currentUrl -834668800[7f8cd65e3ac0]: ReadNextLine [stream=c9415a10 nb=0 needmore=1] -834668800[7f8cd65e3ac0]: cf932000:XXXX.fr:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 805a1f50 -834668800[7f8cd65e3ac0]: cf932000:XXXX.fr:NA:TellThreadToDie: close socket connection -834668800[7f8cd65e3ac0]: cf932000:XXXX.fr:NA:CreateNewLineFromSocket: (null) -834668800[7f8cd65e3ac0]: cf932000:XXXX.fr:NA:ProcessCurrentURL: aborting queued urls -834668800[7f8cd65e3ac0]: ImapThreadMainLoop leaving [this=cf932000] -834668800[7f8cd65e3ac0]: ImapThreadMainLoop entering [this=c2e07000] -217573600[7f8cf1e59260]: c2e07000:XXXX.fr:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN -834668800[7f8cd65e3ac0]: c2e07000:XXXX.fr:NA:ProcessCurrentURL: entering -834668800[7f8cd65e3ac0]: c2e07000:XXxx.fr:NA:ProcessCurrentURL:imap://mon%2Enom@XXXX.fr:993/select%3E%5EINBOX: = currentUrl -834668800[7f8cd65e3ac0]: ReadNextLine [stream=c9415a10 nb=0 needmore=1] -834668800[7f8cd65e3ac0]: c2e07000:XXXX.fr:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 805a1f50 -834668800[7f8cd65e3ac0]: c2e07000:XXXX.fr:NA:TellThreadToDie: close socket connection -834668800[7f8cd65e3ac0]: c2e07000:XXXX.fr:NA:CreateNewLineFromSocket: (null) -834668800[7f8cd65e3ac0]: c2e07000:XXXX.fr:NA:ProcessCurrentURL: aborting queued urls -834668800[7f8cd65e3ac0]: ImapThreadMainLoop leaving [this=c2e07000]

J’ai tenté de comparer avec un compte IMAP fonctionnel, mais les différences sont tellement immenses que je n’arrive pas à voir ce qui est normal ou non.
Je ne sais même pas dans ce log ce qui peut être une erreur. Je suis donc preneur de toute aide quant à l’interprétation de ces messages et à la solution de mon problème.

Les autres personnes qui ont eu ce même problème avant moi l’ont eu en 2006, et l’ont résolu avec une simple mise à jour.

Merci d’avance pour votre aide :slightly_smiling:
Duna

Juste une idée. Le port 993 est le port IMAPS (IMAP avec TLS/SSL implicite, le port IMAP avec ou sans TLS/SSL explicite étant le 143), alors que l’URL commence par “imap://”. Est-ce normal ?

Tiens, je n’avais jamais remarqué ça. Mais malheureusement, c’est cette configuration qui a toujours fonctionné, et remplacer par le port 143 n’arrange rien.

Et coté serveur tu as accès aux logs ?

Malheureusement, non.

(Je sais juste que le problème vient de moi, puisque d’autres versions d’Icedove sur d’autres PC, chez d’autres personnes fonctionnent correctement.)

J’ai balancé un tcpdump pour voir ce qui circulait sur le réseau. Ça peut toujours être utile.
J’ai aussi moyen d’avoir accès aux logs (négociation, quand tu nous tiens ^^). Le serveur utilise postfix, mais je ne sais pas quels logs regarder…

23:04:47.454399 XXXX.fr.imaps > PC-Duna.YYYY.fr.37900: S 1511745390:1511745390(0) ack 97233054 win 65535 <mss 1460,nop,wscale 6,sackOK,timestamp 2337210477 2930292> 23:04:47.455390 PC-Duna.YYYY.fr.37900 > XXXX.fr.imaps: . ack 1 win 115 <nop,nop,timestamp 2930292 2337210477> (DF) 23:04:47.455640 PC-Duna.YYYY.fr.37900 > XXXX.fr.imaps: P 1:165(164) ack 1 win 115 <nop,nop,timestamp 2930292 2337210477> (DF) 23:04:47.467017 XXXX.fr.imaps > PC-Duna.YYYY.fr.37900: . 1:1449(1448) ack 165 win 1040 <nop,nop,timestamp 2337210478 2930292> 23:04:47.467018 XXXX.fr.imaps > PC-Duna.YYYY.fr.37900: P 1449:2500(1051) ack 165 win 1040 <nop,nop,timestamp 2337210478 2930292> 23:04:47.476253 PC-Duna.YYYY.fr.37900 > XXXX.fr.imaps: . ack 1449 win 137 <nop,nop,timestamp 2930297 2337210478> (DF) 23:04:47.477378 PC-Duna.YYYY.fr.37900 > XXXX.fr.imaps: . ack 2500 win 160 <nop,nop,timestamp 2930297 2337210478> (DF) 23:04:47.477752 PC-Duna.YYYY.fr.37900 > XXXX.fr.imaps: P 165:172(7) ack 2500 win 160 <nop,nop,timestamp 2930298 2337210478> (DF) 23:04:47.478127 PC-Duna.YYYY.fr.37900 > XXXX.fr.imaps: R 172:172(0) ack 2500 win 160 <nop,nop,timestamp 2930298 2337210478> (DF) 23:04:47.478395 XXXX.fr.imaps > PC-Duna.YYYY.fr.37900: F 2500:2500(0) ack 172 win 1040 <nop,nop,timestamp 2337210479 2930298> 23:04:47.479252 PC-Duna.YYYY.fr.37900 > XXXX.fr.imaps: R 97233225:97233225(0) win 0 (DF)

Postfix est un MTA, ce n’est pas lui qui fait serveur IMAP.
La seule bizarrerie que je vois dans la capture de paquets, c’est la coupure brutale (RST) qu’envoie la machine cliente juste après l’échange de données, au lieu d’une fermeture normale (FIN).

J’ai mis du temps à trouver ce qui faisait office de serveur SMTP. J’ai finalement trouvé dovecat, qui me sort un log des plus normaux quand je tente de me connecter via Icedove :

Nov 28 13:45:17 imap(mon.nom): Info: Disconnected for inactivity in=131 out=1055 Nov 28 13:45:50 imap-login: Info: Login: user=<mon.nom>, method=PLAIN, rip=193. 49.174.234, lip=193.49.175.1, mpid=30669, TLS, session=<i2Dbi43PcQDBMa7q> Nov 28 13:45:50 imap-login: Info: Login: user=<mon.nom>, method=PLAIN, rip=193. 49.174.234, lip=193.49.175.1, mpid=30670, TLS, session=<JIbbi43PcwDBMa7q> Nov 28 13:45:51 imap(mon.nom): Info: Disconnected: Logged out in=104 out=1398 Nov 28 13:45:51 imap(mon.nom): Info: Disconnected: Logged out in=112 out=1442

[quote=“Dunatotatos”]J’ai mis du temps à trouver ce qui faisait office de serveur SMTP. J’ai finalement trouvé dovecat, qui me sort un log des plus normaux quand je tente de me connecter via Icedove :

Nov 28 13:45:17 imap(mon.nom): Info: Disconnected for inactivity in=131 out=1055 Nov 28 13:45:50 imap-login: Info: Login: user=<mon.nom>, method=PLAIN, rip=193. 49.174.234, lip=193.49.175.1, mpid=30669, TLS, session=<i2Dbi43PcQDBMa7q> Nov 28 13:45:50 imap-login: Info: Login: user=<mon.nom>, method=PLAIN, rip=193. 49.174.234, lip=193.49.175.1, mpid=30670, TLS, session=<JIbbi43PcwDBMa7q> Nov 28 13:45:51 imap(mon.nom): Info: Disconnected: Logged out in=104 out=1398 Nov 28 13:45:51 imap(mon.nom): Info: Disconnected: Logged out in=112 out=1442[/quote]
Dovecot, c’est pas un chat le serveur IMAP.
Les logs sont unpeu courtes :confused: je ne voi pas trop ce qui cloche :think:
Pourrais tu faire des essais de connection avec un telnet -si possible- et donc dialogé “à la main” avec le serveur IMAP. Peut être qu’il t’en diras plus.
Exemple1 exemple2

Re,

Je ne peux malheureusement pas me connecter en telnet sur le serveur. Il n’est pas sous mon contrôle, je ne peux donc pas installer telnetd dessus. J’ai tenté de demander son installation, mais c’est hors de question.

J’ai tenté de récupérer mes mails depuis un autre réseau, avec le même résultat.
Je tente avec un autre logiciel de messagerie et vous tiens au courant.

A+

EDIT : Je viens de configurer Evolution, et il fonctionne. J’ai juste eu un message d’erreur me disant qu’un dossier n’existant pas dans la boîte de réception. Possible que l’erreur vienne de là, je creuse.

Bon explication :
– Refuser d’installer telnetd est très bien !!
– telnet client peut attaquer tout service qui répond en mode texte.

Donc il est tout a fait possible de parler avec le serveur IMAP avec un client telnet. Il suffit de dire à telnet de communiquer avec le port du serveur IMAP.

Bon si Evolution fonctionne, j’attend ton retour sur ce problème de répertoire.

Pour résoudre le problème du répertoire, je l’ai juste supprimé au sein de Evolution, et ça a suffit.
Du coup, j’ai voulu supprimer ce même dossier sur Thunderbird, mais il reste en mode “connecté à…”, sans effet.

Je retente l’utilisation de telnet. Mais pourquoi est-ce bien de refuser son installation ?

EDIT : Je pense avoir un morceau de réponse à ma dernière question. Je suppose qu’installer telnetd pourrait augmenter la quantité d’informations non cryptées qui circuleraient…

EDIT 2 : Rien à faire, je n’arrive pas à choper une connexion en telnet :

telnet> open domaine.fr 993 Trying xxx.xx.xx.xx... telnet: Unable to connect to remote host: Connection timed out
(domaine.fr représente bien sûr le domaine sur lequel j’essaie de me connecter)

Un serveur Telnet fait tout circuler en clair, login comme mot de passe, voilà pourquoi il est a bannir des serveurs.

Sinon bizarre pour la connexion, on dirais que le serveur n’est pas joiniable :confused:

Bon, je laisse tomber l’affaire et n’utilise plus que Evolution. Il convient à mon usage.

[quote=“Dunatotatos”]
EDIT 2 : Rien à faire, je n’arrive pas à choper une connexion en telnet :

telnet> open domaine.fr 993 Trying xxx.xx.xx.xx... telnet: Unable to connect to remote host: Connection timed out
(domaine.fr représente bien sûr le domaine sur lequel j’essaie de me connecter)[/quote]

il me semble que c’est normal que tu ne puisses pas faire un telnet sur le port 993 puisque le telnet de base ne connait pas SSL.

j’ai vu ça sinon
anta.net/misc/telnet-trouble … imap.shtml

telnet ne répond pas non plus sur le port 143. En fait, je crois que le serveur IMAP est configuré pour n’autoriser que les connexions en SSL/TLS…

OSEF, je pense que le problème vient juste de Thunderbird, puisque Evolution fonctionne. Evolution me paraît plus stable et moins usine à gaz que Thunderbird, du coup je conserve :slightly_smiling: