A qui la faute ? SKYNET.BE ou OVH.COM ? ou les deux ?
6 réponses
Frederic
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).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Xavier Roche
Frederic wrote:
Pour l'instant le HELO, MAIL et RCPT ont un timeout qui est défini sur 10 secondes.
Cela me semble délirant. J'ai des exemples où les MAIL FROM sont lookupés (DNS), ce qui peut amener 30 secondes de delais selon l'état des serveurs de messagerie.
10 secondes, AMHA c'est du pur délire. Un hack pour tenter de résorber un problème de configuration ou de domensionnement.
OVH n'y est pour rien là dedans.
Frederic wrote:
Pour l'instant le HELO, MAIL et RCPT ont un timeout qui est défini sur 10
secondes.
Cela me semble délirant. J'ai des exemples où les MAIL FROM sont
lookupés (DNS), ce qui peut amener 30 secondes de delais selon l'état
des serveurs de messagerie.
10 secondes, AMHA c'est du pur délire. Un hack pour tenter de résorber
un problème de configuration ou de domensionnement.
Pour l'instant le HELO, MAIL et RCPT ont un timeout qui est défini sur 10 secondes.
Cela me semble délirant. J'ai des exemples où les MAIL FROM sont lookupés (DNS), ce qui peut amener 30 secondes de delais selon l'état des serveurs de messagerie.
10 secondes, AMHA c'est du pur délire. Un hack pour tenter de résorber un problème de configuration ou de domensionnement.
OVH n'y est pour rien là dedans.
Kenny
qui pour l'instant et très élevé
Si c'est un copier collé de chez eux bravo le service client qui confond encore le verbe être avec et...
qui pour l'instant et très élevé
Si c'est un copier collé de chez eux bravo le service client qui confond
encore le verbe être avec et...
Si c'est un copier collé de chez eux bravo le service client qui confond encore le verbe être avec et...
Frederic
Merci à Xavier pour le commentaire. Merci à Kenny pour la réponse HS. Oui j'ai copié-collé. Je n'ai pas inclus le nom de mon interlocuteur.
Je continue la discussion avec le support Skynet, probablement liront-ils cette réponse en diagonale, car ils doivent en avoir assez de m'entendre ? ;-)
Voici ce que je leur demande: = = = = = = = Conclusion:
Si j'ai bien compris, vos administrateurs système savent qu'ils violent les standards de l'Internet, et dans une mesure importante.
Que la solution choisie (mettre des timers à un trentième de la valeur recommandée par les experts) ne sera pas revue, et qu'ils ne veulent pas se remettre en question.
La solution choisie n'est probablement pas la bonne. Elle ne diminue pas la charge sur vos serveurs. Je m'explique: faire échouer des connexions sortantes de vos propres clients (on parle de OUT-MX ici) à destination de serveurs plus lents est assurément une MAUVAISE IDEE. - on n'est pas en milieu hostile (sauf si vous considérez que vos propres clients sont hostiles) - les mails à transporter ne sont pas du spam et sont des messages légitimes de vos clients - un mail qui échoue se retrouve en queue (et donc les queues grandissent au lieu de se vider) - un mail en queue est ré-essayé pendant 36 heures toutes les 30 minutes, ou toutes les heures (ce qui augmente la charge sur vos serveurs et votre infrastructure) - et finalement vos clients sont insatisfaits (même si les messages d'erreurs pourraient faire croire à un utilisateur pas ou peu initié, que le problème ne provient pas de skynet)
Savez-vous qu'un grand nombre de serveurs SMTP fait des validations DNS sur les domaines qui apparaissent dans les adresses e-mail ? Des délais de 5, 10, 15, 20 secondes pour valider une adresse FROM ou RCPT sont à considérer comme acceptables.
Je vous remercie de votre attention et espère ne plus recevoir de réponse telle que <<il est impossible de changer quoi que ce soit>>.
Ou bien ayez l'amabilité de porter mon message aux bonnes personnes.
Cordialement, (signé)
Merci à Xavier pour le commentaire.
Merci à Kenny pour la réponse HS. Oui j'ai copié-collé. Je n'ai pas inclus
le nom de mon interlocuteur.
Je continue la discussion avec le support Skynet, probablement liront-ils
cette réponse en diagonale, car ils doivent en avoir assez de m'entendre ?
;-)
Voici ce que je leur demande:
= = = = = = = Conclusion:
Si j'ai bien compris, vos administrateurs système savent qu'ils violent les
standards de l'Internet, et dans une mesure importante.
Que la solution choisie (mettre des timers à un trentième de la valeur
recommandée par les experts) ne sera pas revue, et qu'ils ne veulent pas se
remettre en question.
La solution choisie n'est probablement pas la bonne. Elle ne diminue pas la
charge sur vos serveurs. Je m'explique: faire échouer des connexions
sortantes de vos propres clients (on parle de OUT-MX ici) à destination de
serveurs plus lents est assurément une MAUVAISE IDEE.
- on n'est pas en milieu hostile (sauf si vous considérez que vos propres
clients sont hostiles)
- les mails à transporter ne sont pas du spam et sont des messages légitimes
de vos clients
- un mail qui échoue se retrouve en queue (et donc les queues grandissent au
lieu de se vider)
- un mail en queue est ré-essayé pendant 36 heures toutes les 30 minutes, ou
toutes les heures (ce qui augmente la charge sur vos serveurs et votre
infrastructure)
- et finalement vos clients sont insatisfaits (même si les messages
d'erreurs pourraient faire croire à un utilisateur pas ou peu initié, que le
problème ne provient pas de skynet)
Savez-vous qu'un grand nombre de serveurs SMTP fait des validations DNS sur
les domaines qui apparaissent dans les adresses e-mail ? Des délais de 5,
10, 15, 20 secondes pour valider une adresse FROM ou RCPT sont à considérer
comme acceptables.
Je vous remercie de votre attention et espère ne plus recevoir de réponse
telle que <<il est impossible de changer quoi que ce soit>>.
Ou bien ayez l'amabilité de porter mon message aux bonnes personnes.
Merci à Xavier pour le commentaire. Merci à Kenny pour la réponse HS. Oui j'ai copié-collé. Je n'ai pas inclus le nom de mon interlocuteur.
Je continue la discussion avec le support Skynet, probablement liront-ils cette réponse en diagonale, car ils doivent en avoir assez de m'entendre ? ;-)
Voici ce que je leur demande: = = = = = = = Conclusion:
Si j'ai bien compris, vos administrateurs système savent qu'ils violent les standards de l'Internet, et dans une mesure importante.
Que la solution choisie (mettre des timers à un trentième de la valeur recommandée par les experts) ne sera pas revue, et qu'ils ne veulent pas se remettre en question.
La solution choisie n'est probablement pas la bonne. Elle ne diminue pas la charge sur vos serveurs. Je m'explique: faire échouer des connexions sortantes de vos propres clients (on parle de OUT-MX ici) à destination de serveurs plus lents est assurément une MAUVAISE IDEE. - on n'est pas en milieu hostile (sauf si vous considérez que vos propres clients sont hostiles) - les mails à transporter ne sont pas du spam et sont des messages légitimes de vos clients - un mail qui échoue se retrouve en queue (et donc les queues grandissent au lieu de se vider) - un mail en queue est ré-essayé pendant 36 heures toutes les 30 minutes, ou toutes les heures (ce qui augmente la charge sur vos serveurs et votre infrastructure) - et finalement vos clients sont insatisfaits (même si les messages d'erreurs pourraient faire croire à un utilisateur pas ou peu initié, que le problème ne provient pas de skynet)
Savez-vous qu'un grand nombre de serveurs SMTP fait des validations DNS sur les domaines qui apparaissent dans les adresses e-mail ? Des délais de 5, 10, 15, 20 secondes pour valider une adresse FROM ou RCPT sont à considérer comme acceptables.
Je vous remercie de votre attention et espère ne plus recevoir de réponse telle que <<il est impossible de changer quoi que ce soit>>.
Ou bien ayez l'amabilité de porter mon message aux bonnes personnes.
Cordialement, (signé)
Xavier Roche
Frederic wrote:
Ou bien ayez l'amabilité de porter mon message aux bonnes personnes.
Tu veux dire, aux personnes compétentes chez Skynet.be.
Hum.. non, rien.
Frederic wrote:
Ou bien ayez l'amabilité de porter mon message aux bonnes personnes.
Tu veux dire, aux personnes compétentes chez Skynet.be.
Ou bien ayez l'amabilité de porter mon message aux bonnes personnes.
Tu veux dire, aux personnes compétentes chez Skynet.be.
Hum.. non, rien.
Frederic
----- Original Message from: "Xavier Roche"
Frederic wrote:
Ou bien ayez l'amabilité de porter mon message aux bonnes personnes.
Tu veux dire, aux personnes compétentes chez Skynet.be.
En effet. Voici leur réponse. L'Internet est cassé, mais ce n'est pas nous. = = = = Cher Monsieur,
Nous avons pris bonne reception de votre message, il n'y à pas de "bonne personne" a qui transmettre ce message, nous avons fait part du problème à nos ingenieurs qui vont analyser la situation mais à l'heure actuelle aucune modification n'est planifiée, ovh ainsi que certains autres client ont decidés d'implementer un software crééant ce problème au niveau de leurs serveurs mail (non pas qu'ils soient responsables....) suite à ce changement l'échange de mail ne fonctionne plus, nul n'est obligé d''installer ou de ne pas installer un tel système
nous ne pouvons vous apporter satisfaction à l'heure actuelle
bien à vous, <snip> belgacom technicline
----- Original Message from: "Xavier Roche" <xroche@free.fr.NOSPAM.invalid>
Frederic wrote:
Ou bien ayez l'amabilité de porter mon message aux bonnes personnes.
Tu veux dire, aux personnes compétentes chez Skynet.be.
En effet.
Voici leur réponse. L'Internet est cassé, mais ce n'est pas nous.
= = = = Cher Monsieur,
Nous avons pris bonne reception de votre message, il n'y à pas de "bonne
personne" a qui transmettre ce message, nous avons fait part du problème à
nos ingenieurs qui vont analyser la situation mais à l'heure actuelle aucune
modification n'est planifiée, ovh ainsi que certains autres client ont
decidés d'implementer un software crééant ce problème au niveau de leurs
serveurs mail (non pas qu'ils soient responsables....) suite à ce
changement l'échange de mail ne fonctionne plus, nul n'est obligé
d''installer ou de ne pas installer un tel système
nous ne pouvons vous apporter satisfaction à l'heure actuelle
Ou bien ayez l'amabilité de porter mon message aux bonnes personnes.
Tu veux dire, aux personnes compétentes chez Skynet.be.
En effet. Voici leur réponse. L'Internet est cassé, mais ce n'est pas nous. = = = = Cher Monsieur,
Nous avons pris bonne reception de votre message, il n'y à pas de "bonne personne" a qui transmettre ce message, nous avons fait part du problème à nos ingenieurs qui vont analyser la situation mais à l'heure actuelle aucune modification n'est planifiée, ovh ainsi que certains autres client ont decidés d'implementer un software crééant ce problème au niveau de leurs serveurs mail (non pas qu'ils soient responsables....) suite à ce changement l'échange de mail ne fonctionne plus, nul n'est obligé d''installer ou de ne pas installer un tel système
nous ne pouvons vous apporter satisfaction à l'heure actuelle
bien à vous, <snip> belgacom technicline
Xavier Roche
Frederic wrote:
decidés d'implementer un software crééant ce problème au niveau de leurs serveurs mail
Demandez-leur d'installer "RFC" sur leur serveur (la version 2821 - attention, la version 1149 est buggée et laisse plein de traces blanches sur les serveurs)
.. Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:
RCPT Command: 5 minutes A longer timeout is required if processing of mailing lists and aliases is not deferred until after the message was accepted. ..
Bien sur, c'est un "should". Mais le "should" suggère 300 secondes, et choisir une valeur 30 fois inférieure est aux risques et périls de l'envoyeur. En cas de non livraison, ils pourraient être tenus responables.
Frederic wrote:
decidés d'implementer un software crééant ce problème au niveau de leurs
serveurs mail
Demandez-leur d'installer "RFC" sur leur serveur (la version 2821 -
attention, la version 1149 est buggée et laisse plein de traces blanches
sur les serveurs)
..
Based on extensive experience with busy mail-relay hosts, the minimum
per-command timeout values SHOULD be as follows:
RCPT Command: 5 minutes
A longer timeout is required if processing of mailing lists and
aliases is not deferred until after the message was accepted.
..
Bien sur, c'est un "should". Mais le "should" suggère 300 secondes, et
choisir une valeur 30 fois inférieure est aux risques et périls de
l'envoyeur.
En cas de non livraison, ils pourraient être tenus responables.
decidés d'implementer un software crééant ce problème au niveau de leurs serveurs mail
Demandez-leur d'installer "RFC" sur leur serveur (la version 2821 - attention, la version 1149 est buggée et laisse plein de traces blanches sur les serveurs)
.. Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:
RCPT Command: 5 minutes A longer timeout is required if processing of mailing lists and aliases is not deferred until after the message was accepted. ..
Bien sur, c'est un "should". Mais le "should" suggère 300 secondes, et choisir une valeur 30 fois inférieure est aux risques et périls de l'envoyeur. En cas de non livraison, ils pourraient être tenus responables.
