Pascal@plouf égrapsen en <431ca5c8$0$6548$626a14ce@news.free.fr>:

> Je viens d'essayer en telnet sous Linux et Windows 2000,
[...]

Merci pour votre réponse.

> 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.

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

Si j'essaie, toujours avec kMail, une connexion avec pop.free.fr,
c'est toujours moi qui envoie le QUIT. Bref, cela ne vient pas de
fetchmail.


> En tout cas j'ai toujours vu faire ainsi.
> Or apparemment c'est ton fetchmail qui envoie le premier FIN. C'est
> peut-être pour cela que tu as cette séquence bizarre FIN - FIN - ACK
> - ACK (les FIN étant envoyés simultanément des deux côtés) au lieu
> de l'habituel FIN - ACK/FIN - ACK.

Avec fetchmail pour pop.infonie.fr, j'ai (en partant de moi ->
pop.infonie.fr) [FIN, ACK], [FIN, ACK], [ACK], [ACK] (donc correct).
De plus, si je me sers de kMail pour pop.free.fr, j'obtiens bien un
QUIT envoyé par moi-même (comme dit plus haut) et toujours une
séquence bizarre avec un paquet RST bloqué.

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

--
apt-get moo