Toujours aussi méchant ce "peer"! Pour moi le log est clair c'est bien le client distant qui a envoyé un ordre de fermeture, on est pas sur un timeout ou une erreur ssl / tls avec des ciphers trop récents et client trop vieux. Si une grosse partie des boites d'une même entreprise ont des soucis en même temps, ça serait pas une maj de leur client email qui aurait été poussé chez tout le monde chez eux sauf les quelques qui n'étaient pas connecté à ce moment là? Ca y ressemble pas mal je trouve. Le 10/11/2022 à 16:31, David Ponzone a écrit :

Dovecotien,

J’ai un truc bizarre avec Dovecot. 3 mailbox qui génèrent en permanence des logs du type:

Nov 9 15:28:41 hosting dovecot: pop3(utilisateur@domaineclient.fr)<8812><l67/eArt+di5ZqEI>: Connection closed: read(size=2038) failed: Connection reset by peer top=0/0, retr=1/273369, del=0/1554, size=339085049

J’aurais tendance à incriminer la connexion cliente mais il y a 50 boites emails, presque tous au même endroit, et surtout un utilisateur a une mailbox qui a ce problème et l’autre pas.

Je penche donc pour une sorte de corruption côté Dovecot mais je trouve pas grand chose sur le sujet. J’ai tenté un index, un force-sync, ça change rien.

Donc si qqun a déjà vu ça….

Merci

David

_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/

Bonsoir, Wallace <wallace@morkitu.org> :

Toujours aussi méchant ce "peer"!

Oui, toujours la même politique.

Pour moi le log est clair c'est bien le client distant qui a envoyé un ordre de fermeture, on est pas sur un timeout ou une erreur ssl / tls avec des ciphers trop récents et client trop vieux.

"Connection reset by peer" correspond à une rupture de connexion TCP cohérente avec les lignes 100 à 105 de l'extrait de code dovecot ci-dessous: $ cat -n src/lib/istream-file.c | less +/read.size= [...] 87 if (unlikely(ret < 0)) { 88 if ((errno == EINTR || errno == EAGAIN) && 89 !stream->istream.blocking) { 90 ret = 0; 91 } else { 92 i_assert(errno != 0); 93 /* if we get EBADF for a valid fd, it means something's 94 really wrong and we'd better just crash. */ 95 i_assert(errno != EBADF); 96 if (fstream->file) { 97 io_stream_set_error(&stream->iostream, 98 "pread(size=%zu offset=%"PRIuUOFF_T") failed: %m", 99 size, offset); 100 } else { 101 io_stream_set_error(&stream->iostream, 102 "read(size=%zu) failed: %m", 103 size); 104 } 105 stream->istream.stream_errno = errno; 106 return -1; 107 } 108 } -> 'fstream->file' est faux pour un flux de type de type socket et "Connection reset by peer" vient d'errno. L'errno kivabien correspond à un ECONNRESET (cf 'man 3 errno') $ errno ECONNRESET ECONNRESET 104 Connection reset by peer (un grand merci au paquetage 'moreutils' pour sa collaboration) Un timeout de keepalive produirait un ETIMEDOUT mais je n'exclurais pas d'entrée de jeu qu'un hors-temps ou un échec de handshake TLS ne déclenche l'envoi d'un RST par un dispositif distant. En tout cas il ne devrait pas s'agir d'une connexion qui s'achève avec un échange de FIN bien équilibré.

Si une grosse partie des boites d'une même entreprise ont des soucis en même temps, ça serait pas une maj de leur client email qui aurait été poussé chez tout le monde chez eux sauf les quelques qui n'étaient pas connecté à ce moment là?

Hopopop, pas de conclusion hative :o) [...]

Le 10/11/2022 à 16:31, David Ponzone a écrit :

...

Dovecotien,

J’ai un truc bizarre avec Dovecot. 3 mailbox qui génèrent en permanence des logs du type:

Nov 9 15:28:41 hosting dovecot: pop3(utilisateur@domaineclient.fr)<8812><l67/eArt+di5ZqEI>: Connection closed: read(size=2038) failed: Connection reset by peer top=0/0, retr=1/273369, del=0/1554, size=339085049

La taille de la boite aux lettres et le nombre de messages sont-ils du même ordre de grandeur que les autres boites ?

...

J’aurais tendance à incriminer la connexion cliente mais il y a 50 boites emails, presque tous au même endroit, et surtout un utilisateur a une mailbox qui a ce problème et l’autre pas. Je penche donc pour une sorte de corruption côté Dovecot mais je trouve pas grand chose sur le sujet.

Genre RST émis par le client suite à son croutage sur réception d'une chiotte émise par le serveur ? Pourquoi pas mais la différence réside peut-être réellement dans le seul poste client (ou dans son chemin d'accès au serveur).

...

J’ai tenté un index, un force-sync, ça change rien.

Peut-être que caractériser les connexions rompues suggèrera quelque chose: <pavlov> - wireshark/tcpdump associé à une recherche de paquets RST (en priorité) - ss -tenia '( dport = :pop3 or dport = :whatever )' à la recherche de hors-temps (keepalive, ack, etc.) qui ne se résorbent pas </pavlov> HTH. -- Ueimor