Vincent Ramos a écrit :
> Pascal@plouf égrapsen en <431ca5c8$0$6548$626a14ce@news.free.fr> :
>
>>Par contre il y a un détail qui ne me semble pas terrible, mais ça
>>n'a peut-être pas d'importance. Tu écris dans tes messages publiés
>>dans fr.comp.securite que fetchmail termine la communication POP par
>>une commande QUIT. Il me semble que dans ce cas, c'est le serveur
>>qui doit mettre fin à la connexion TCP en envoyant le premier FIN
>>après le message de fin.
>
> Cette requête QUIT prend place dans la séquence POP3 ; j'obtiens la
> même chose avec le serveur pop.infonie.fr : fetchmail envoie un [ACK]
> puis un [QUIT] pour clore la session POP3.

Oui, j'entends bien. Le fait curieux que je signalais était que
fetchmail semble fermer la connexion TCP avec un paquet FIN
immédiatement après avoir envoyé la commande QUIT et reçu la réponse +OK
du serveur, au lieu d'attendre que ce soit le serveur POP qui ferme la
connexion. Je me serais attendu à cette séquence que j'observe quand je
me connecte à un serveur POP avec telnet :

client -> serveur : "QUIT"
serveur -> client : "+OK blablabla"
serveur -> client : [FIN]
client -> serveur : [FIN]

> Si j'utilise un MUA comme kMail, c'est le serveur POP3 qui envoie la
> requête QUIT.

Là, j'ai un gros doute. Jusqu'à nouvel ordre c'est toujours le client
(par définition) qui envoie les commandes au serveur.

Avec kmail, quel côté envoie le premier FIN ?

[...]
> Dois-je en conclure que le comportement étrange vient de pop.free.fr ?

Si tu fais allusion au RST, oui, c'est ce que je disais dans ma réponse
précédente.