Likes: 
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
Quote
