[supersedes, grmbl]

Salut,

Vincent Ramos a écrit :
>
> Les logs d'iptables m'indiquent que des paquets RST en provenance d'un
> serveur pop3 (en l'occurrence pop.free.fr) sont bloqués. J'ai
> découvert que l'erreur se produit quand fetchmail se connecte pour
> récupérer les courriels en attente.
>
> La fin de la transaction (m'indique ethereal) se compose de la
> séquence suivante :
> moi -> pop.free.fr : 1623* > 110 (FIN ACK)
> pop.free.fr -> moi : 110 > 1623 (FIN ACK)
> moi -> pop.free.fr : 1623 > 110 (ACK)
> pop.free.fr -> moi : 110 > 1623 (ACK)
> ***pop.free.fr -> moi : 110 > 1623 (RST)***

Je viens d'essayer en telnet sous Linux et Windows 2000, et le serveur
POP de Free me renvoie aussi un RST environ 8 secondes après la
fermeture normale de la connexion par l'échange des FIN, que cette
fermeture ait été à l'initiative du client ou du serveur du point de vue
TCP (premier FIN). Par contre j'ai des variations dans le séquencement
des ACK, mais il est possible que ce soit dû aux différences entre les
piles TCP/IP des OS.

> Cependant, quand j'utilise fetchmail pour récupérer les courriels sur
> un autre serveur (ici : pop.infonie.fr), je ne reçois pas ce paquet
> RST. La séquence de fin est en effet la suivante :
> moi -> pop.infonie.fr : 4886* > 110 (FIN ACK)
> pop.infonie.fr -> moi : 110 > 4886 (FIN ACK)
> moi -> pop.infonie.fr : 4886* > 110 (ACK)
> pop.infonie.fr -> moi : 110 > 4886 (ACK)
>
> et c'est tout.

J'ai essayé avec le serveur POP de Nerim, il n'envoie pas de RST non plus.

> D'où mes interrogations :
> * est-il normal que le serveur pop3 de Free m'envoie un tel paquet ?

Non. La connexion est déjà fermée depuis plusieurs secondes par
l'échange de FIN. Je ne vois pas à quoi peut servir ce RST.

> * Est-il normal que ma machine n'y réponde pas ?

Oui. On ne doit pas répondre à un RST.

> * Est-il normal que le serveur pop3 d'Infonie (Tiscali/Libertysurf,
> etc.) n'envoie pas un tel paquet ?

Oui. Le serveur POP de Nerim n'en envoie pas non plus.

> * Faut-il que je règle fetchmail pour qu'il attende poliement cette
> séquence reset (et si oui, comment ?) ?

AMA Fetchmail n'a pas grand chose à voir là-dedans. C'est la pile TCP/IP
de l'OS qui gère les états de la connexion TCP.

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

[Note: je copie cette réponse dans fr.comp.reseaux.ip et propose d'y
rediriger la suite (fu2). Répondre dans un seul forum de préférence.]

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

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.