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