🚀 go-pugleaf

Bonjour,

Suite � des probl�mes r�p�t�s d'e-mail de Skynet.be vers Ovh.com, je soumets
ceci � votre sagacit�.

PROBLEME:

Un utilisateur, client du FAI Skynet.be, envoie un e-mail vers plusieurs
destinataires, h�berg�s chez OVH en mutualis�. Disons 5 ou 6 destinataires
diff�rents.
Ce message reste en transit sur le serveur (relay.skynet.be) et n'arrive
jamais chez les destinataires. Apr�s 36h, retour � l'exp�diteur avec des
messages d'erreur "communication error", etc.

POURQUOI ?

D'un c�t�, OVH a mis des temporisations de 15 secondes dans le dialogue SMTP
(peut-�tre pour ralentir la d�ferlante du spam ?). Dans l'exemple ci-dessous
chaque * repr�sente une attente de 15 secondes.
  <- 220 Welcome ! You are on server 13 called ns0.ovh.net ...
 -> HELO i.am.skynet.be
 <- 250 OK
 -> MAIL From: < ... >
 <- 250 OK
 -> RCPT To: < ... >
 <- 250 OK
 -> RCPT To: < ... >
 *
 <- 250 OK
  -> RCPT To: < ... >
 *
 <- 250 OK
 -> DATA
 ... ... ...

De l'autre c�t�, Skynet a instaur� des temporisations (timers) tellement
s�v�res (10 secondes max � chaque dialogue, 60 secondes max entre HELO et
DATA) que cette communication finit bien s�r en �chec.

A qui la faute ?

Selon moi Skynet est en violation de RFC2821 (
http://www.faqs.org/rfcs/rfc2821.html )
en particulier le � 4.5.3.2 dit ceci:
- An SMTP client MUST provide a timeout mechanism.
- It MUST use per-command timeouts rather than somehow trying to time the
entire mail transaction.
- the minimum per-command timeout values SHOULD be as follows:
    ...   RCPT Command: 5 minutes   ...

J'ai donc demand� du support � Skynet.

Voici l'essentiel de la conversation, dans l'ordre chronologique.
= = =
Bonjour,

Auriez-vous l'amabilite de faire un essai de connectivite de
outmx017.isp.belgacom.be [195.238.2.116] vers mx3.ovh.net (pool de
serveurs), port 25.
OVH m'affirme ne pas avoir bloqu� quoi que ce soit. (antispam, etc)
= = =
Cher client,

Tout semble fonctionner sans probl�mes, n'h�sitez pas � nopus recontacter si
vous rencontrez en core des soucis d'envois
= = =
Pensez-vous que vos serveurs SMTP sortants echouent en erreur si dans le
dialogue SMTP il se passe plus de 60 secondes entre le HELO et le DATA ?
= = =
Cher Monsieur,

En effet une reponse de plus te 60 secondes entre le shake hand et le data
sera consider� comme time out par notre relay, cela explique le probl�me
recurrent dont vous nous faites part
= = =
Bonjour,

Selon moi ceci est en violation flagrante de RFC2821 ... (((m�me explication
que ci-dessus)))
...
Je vous remercie de votre attention (et de la correction que vous allez
apporter, je n'en doute pas)
= = =
Cher client,

effectivement notre sendmail a des timeouts sp�cifi� par ligne de commande.
Pour l'instant le HELO, MAIL et RCPT ont un timeout qui est d�fini sur 10
secondes.
Sur l'�tablissement de la connexion et le transfer des donn�es apr�s la
commande "data" les d�lais sont plus longues (30 secondes - 1 minute)

Ces valeurs ne sont pas permanentes et changent d�pendant du volume de
traffique, qui pour l'instant et tr�s �lev�.

Si le serveur de ovh force systematiquement un d�lai de 15 secondes entre
l'accept de plusieurs recipients, ca aura comme cons�quence qu'uniquement
les mails destin�s � une personne arriveront � leur destination.
= = =
Pour faire avancer le schmilblick, il faut que quelqu'un change sa
configuration.

Etant donn� que la recommandation de RFC2821 (version � jour de SMTP) est de
5 minutes, je pense que c'est plut�t � vous que � OVH qu'il faudarait
demander de faire une petite modification. Par exemple pourriez-vous mettre
les timeouts � 30 secondes au lieu de 10 secondes ?
= = =
Cher Monsieur,

malheureusement il est impossible de changer quoi que ce soit au niveau du
time out de notre pool smtp, en tant que provider vous imaginez ais�ment le
nombrer demails transitant par nos machines, si nous augmentons ne fut-ce
que d'une seconde le time out de nos servuers ce sont des heures de retard
que nous accuserons de ce fait, pour cette raison toute modification est
impossible � realiser

Nous sommes conscient du probl�me que peut vous causer dtte situation mais
ne pouvons y apporter de solution

merci de votre compr�hension
===============

Voil�. Point mort.

A mon humble avis ils ont faux tous les deux.

Skynet, qui met des timers � des valeurs compl�tement irr�alistes. S'il y a
effectivement du mail sortant qui ne sort pas � cause des timers, il reste
en queue et est resoumis toutes les heures ! Mauvaise id�e pour diminuer la
charge.

OVH, qui de son c�t� se retrouve avec beaucoup plus de connexions ouvertes,
donc plus de file descriptors, plus de sockets, etc.

Je suis pr�t � discuter de ceci en public (ici) ou en priv� (je poste ce
message avec une adresse r�elle).

Vos r�actions sont les bienvenues.

Fr�d�ric
Bruxelles