Incident mail Neuf Télécom

11 réponses

Auteur	Message
caaptusss \| Membre Inscrit le : 25/09/2007	# Le 20/02/2009 à 18:46 Bonjour, Pour ceux qui ne seraient pas abonnés aux listes d'OVH ou dont ça ne serait pas leur métier, OVH a lancé un message cet après midi concernant un incident de réception de mail sur Neuf télécom. Au lieu de faire un long discours, je vous propose de lire le mail. Il est technique mais plutôt bien expliqué, la majorité d'entre vous devraient comprendre de quoi on parle ici : Bonjour, Certains clients, surtout les clients serveurs dédiés, nous remontent les problèmes d'envoi des emails vers @neuf.fr. En effet, le serveur SMTP QMAIL n'arrive pas à trouver les serveurs MX en face chez @neuf.fr. Le problème est dû à la taille de la repose DNS de la zone "neuf.fr". La réponse dépasse 512 bytes (583 bytes) et donc elle ne se fait pas en UDP. Elle se fait en TCP. Or QMAIL, en respectant les RFC, ne gère pas les requêtes DNS en TCP. Et donc il ne trouve pas les serveurs MX de @neuf. Voilà pour l'histoire. D'après les auteurs de Qmail, une zone > à 512 ne respectent pas les RFC et donc il n'y a pas de patchs ni de correctifs à appliquer sur le Qmail puisque Qmail respectent les RFC. Nous allons publier un patch pour QMAIL afin que nos clients puissent résoudre ce problème. Mais sachant qu'on a presque 50'000 serveurs dédiés chez Ovh et QMAIL est installé sur plusieurs millions de serveurs dans le monde, le plus simple serait de corriger la zone "neuf.fr" afin de réduire la taille de la réponse et résoudre ce problème rapidement et avec minimum de travail. C'est tout simple, il suffit de réduire la taille de noms de serveurs: au lieu de neuf-infra-smtp-in-sp604010av.neufgp.fr. mettre un truc plus court genre n-i-s-i-sp604010av.neufgp.fr. Ceci permettrait de réduire la taille de la réponse de 583 bytes à moins de 512 bytes. Merci d'avance à ceux qui transmettront l'email au bon décideur. Amicalement Octave $ dig neuf.fr any @ns2.9services.com ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.3.4 <<>> neuf.fr any @ns2.9services.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3071 ;; flags: qr aa rd; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;neuf.fr. IN ANY ;; ANSWER SECTION: neuf.fr. 3600 IN A 212.30.118.74 neuf.fr. 3600 IN NS ns2.9services.com. neuf.fr. 3600 IN NS dns2.gaoland.net. neuf.fr. 3600 IN NS ns01.sitadelle.com. neuf.fr. 3600 IN NS hazzi.hittite.isp.9tel.net. neuf.fr. 3600 IN NS nanni.hittite.isp.9tel.net. neuf.fr. 3600 IN NS ns1.9services.com. neuf.fr. 3600 IN SOA nanni.hittite.isp.9tel.net. hostmaster.isp.9tel.net. 2009020402 21600 3600 1209600 3600 neuf.fr. 900 IN MX 20 neuf-infra-smtp-in-sp604010av.neufgp.fr. neuf.fr. 900 IN MX 20 neuf-infra-smtp-in-sp604013av.neufgp.fr. neuf.fr. 900 IN MX 20 neuf-infra-smtp-in-sp604014av.neufgp.fr. neuf.fr. 900 IN MX 20 neuf-infra-smtp-in-sp604008av.neufgp.fr. neuf.fr. 900 IN MX 20 neuf-infra-smtp-in-sp604009av.neufgp.fr. neuf.fr. 3600 IN TXT "v=spf1 ip4:84.96.92.0/24 ip4:93.17.128.0/24 ?all" ;; ADDITIONAL SECTION: ns2.9services.com. 3600 IN A 84.96.147.1 ns1.9services.com. 3600 IN A 84.96.72.129 ;; Query time: 2 msec ;; SERVER: 84.96.147.1#53(84.96.147.1) ;; WHEN: Fri Feb 20 15:16:37 2009 ;; MSG SIZE rcvd: 583 ^^^^ ^^^^ la taille de la reponse: 583 bytes au lieu de 512 bytes. Inutile de dire que ça fait du bruit auprès des opérateurs, et notamment de la liste FRnOG, qui regroupe les principaux responsables et directeurs techniques des opérateurs Français. Neuf telecom a annoncé prendre en considération le problème mais devrait laisser ainsi pour les semaines à venir. Ils vont en effet migrer sur le domaine sfr.fr, en renommant la majorité des reverses et noms de réseaux. Autrement dit, si vous êtes sur qmail, attendez vous à avoir des moments difficiles avec Neuf.fr ! FirstHeberg.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 20/02/2009 à 18:54 Si ça peut aider : 3 méthodes de "correction" http://www.lifewithqmail.org/lwq.html#dns-patches Et deux remarques : - Neuf a toujours été chiant avec ses emails - quelle idée d'utiliser encore Qmail franchement... daevel : infogérance et conseil \|\| moi
SquawK \| Blabla Modérateur Inscrit le : 09/05/2005	# Le 20/02/2009 à 19:22 J'ai enfin compris pourquoi tous les mails de neuf m'étaient revenus en erreur cette semaine... Comparatif pc portable
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 20/02/2009 à 20:41 Apparemment, le problème a été remonté à la DSI de Neuf qui n'était pas au courant on dirait (c'est plus fort que le roquefort cette histoire !) D'après un mec sur la liste, le problème sera corrigé lundi (Hé oui, Vendredi Inside). FirstHeberg.com
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 20/02/2009 à 23:08 dob +1, effectivement, j'ai regardé et avec Google Apps, je suis entre 350 et 400 bytes. Enfin perso, je ne pourrais plus me séparer de Google Apps, ça simplifie tellement l'administration serveur (les mails c'est bien le truc le plus complexe et chiant à gérer), sans compter le webmail accessible partout, Google Docs, etc. Franchement, c'est un rêve ce service
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 20/02/2009 à 23:33 humf... je viens de vérifier chez un client je suis à près de 900 octets même. Plusieurs MX, SPF, SenderID, et le tour est joué... Heureusement pour DomainKeys ils ont eu la bonne idée de mettre ça sur un sous domaine. daevel : infogérance et conseil \|\| moi
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 20/02/2009 à 23:43 En même temps j'ai du mal à trouver quoi que ce soit concernant une RFC interdisant les paquets de plus de 512 octets pour les emails... Et sur le forum OVH je trouve une explication bien plus plausible (message de ktp) : Le problème vient du fait que qmail utilise un query de type ANY sur le domaine (réponse longue), puis analyser la réponse et ne prendre que les enregistrements de type CNAME pour déterminer les MX, au lieu de ne faire qu'un query de type CNAME directement (réponse courte) suite à un bug de BIND 4 (1996). Le problème est connu depuis 2006, voir cet article : http://www.faqts.com/knowledge_base/...html?aid=28... La solution est de patcher qmail, car comme indique l'article il y a de plus en plus de domaines qui retournent plus de 512 octets (par exemple aol.com ou microsoft.com, voir ci-dessous). On n'a pas de prise sur ces domaines et on ne peut pas dépendre du bon vouloir des détenteurs de ces domaines. C'est un peu le problème quand on utilise un soft qui n'est plus maintenu depuis plus de 10 ans (juin 98 !!!)... en informatique, c'est une antiquité. Vous supportez encore IE 4 sur vos sites vous ? De plus la première version de ce document date de février 2004... ça fait 5 ans que le site "qmail.org" aurait annoncé ce bug de QMail. daevel : infogérance et conseil \|\| moi
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 21/02/2009 à 00:00 Hop, et dans la RFC 1035 (DNS) , qui date de 1987 : The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can beused for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance. Zone refresh activities must use virtual circuits because of the need for reliable transfer. Y a même la RFC 3226 (2001) qui parle de l'augmentation de la taille des paquets à cause d'IPv6 et DNSSEC. Bref, UDP (limitation à 512 octet) et TCP (limitation à 65535 octets) sont autorisé, et il est juste indiqué qu'UDP est préféré pour des raisons de performances... d'ailleurs si j'ai bien compris QMail obtient la réponse en TCP également, c'est juste que son buffer est bridé à 512 octets. C'est moi ou bien ça sent le baratinage d'OVH ? Et ils font comment pour contacter les gens d'AOL et autres ? Edit : une dernière et j'arrête. Je suis tombé sur un message de juin 1999 évoquant le problème, et ils parlent là aussi de patcher Qmail, et qu'AOL dépassait déjà les 512 octets. (Message édité le 21-02-2009 à 00h22 par Bool) daevel : infogérance et conseil \|\| moi
Akarys \| Thierry Membre Inscrit le : 19/01/2008	# Le 21/02/2009 à 03:39 Bool a dit : ... et qu'AOL dépassait déjà les 512 octets. dépassait ?? sd1 pri $ dig any aol.com \| grep SIZE ;; MSG SIZE rcvd: 200 sd1 pri $ dig any microsoft.com \| grep SIZE ;; MSG SIZE rcvd: 279 et à priori Neuf semble avoir "déjà" corrigé... ou tronqué... sd1 pri $ dig any neuf.fr \| grep SIZE ;; MSG SIZE rcvd: 511
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 21/02/2009 à 12:44 Akarys : quand tu n'interroges pas directement le NS autoritaire, les TXT ne sont pas indiqués. C'est d'ailleurs pour ça qu'une des solutions indiquées est d'utiliser un cache local. kioob@luuna:~$ dig @dns-01.ns.aol.com aol.com any \| grep SIZE ;; MSG SIZE rcvd: 1101 kioob@luuna:~$ dig @ns1.9services.com neuf.fr ANY \| grep SIZE ;; MSG SIZE rcvd: 583 daevel : infogérance et conseil \|\| moi
Akarys \| Thierry Membre Inscrit le : 19/01/2008	# Le 22/02/2009 à 02:53 Bool a dit : Akarys : quand tu n'interroges pas directement le NS autoritaire, les TXT ne sont pas indiqués. Tiens ? J'aurais encore appris quelque chose aujourd'hui Merci
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 22/02/2009 à 03:06 Je n'ai pas cherché d'où ça pouvait venir, je l'ai simplement constaté dans ce test (c'est d'ailleur pour cela que tatave indique bien le NS utilisé). Il me semble avoir lu aussi une remarque à ce sujet dans la doc PHP. Bref, une requête "ANY" ne retourne pas forcément tous les enregistrements. Maintenant faire tourner un serveur de mail sans cache DNS, ça me semble étonnant... je crois qu'il n'y a pas plus gourmand en requête DNS. daevel : infogérance et conseil \|\| moi

Auteur

Message

Inscrit le : 25/09/2007

# Le 20/02/2009 à 18:46

Bonjour,

Pour ceux qui ne seraient pas abonnés aux listes d'OVH ou dont ça ne serait pas leur métier, OVH a lancé un message cet après midi concernant un incident de réception de mail sur Neuf télécom.
Au lieu de faire un long discours, je vous propose de lire le mail. Il est technique mais plutôt bien expliqué, la majorité d'entre vous devraient comprendre de quoi on parle ici :

Bonjour,
Certains clients, surtout les clients serveurs dédiés, nous remontent
les problèmes d'envoi des emails vers @neuf.fr. En effet, le serveur
SMTP QMAIL n'arrive pas à trouver les serveurs MX en face chez @neuf.fr.
Le problème est dû à la taille de la repose DNS de la zone "neuf.fr".
La réponse dépasse 512 bytes (583 bytes) et donc elle ne se fait pas
en UDP. Elle se fait en TCP. Or QMAIL, en respectant les RFC, ne gère
pas les requêtes DNS en TCP. Et donc il ne trouve pas les serveurs MX
de @neuf. Voilà pour l'histoire.

D'après les auteurs de Qmail, une zone > à 512 ne respectent pas les
RFC et donc il n'y a pas de patchs ni de correctifs à appliquer sur le
Qmail puisque Qmail respectent les RFC.

Nous allons publier un patch pour QMAIL afin que nos clients puissent
résoudre ce problème. Mais sachant qu'on a presque 50'000 serveurs dédiés
chez Ovh et QMAIL est installé sur plusieurs millions de serveurs dans
le monde, le plus simple serait de corriger la zone "neuf.fr" afin de
réduire la taille de la réponse et résoudre ce problème rapidement
et avec minimum de travail. C'est tout simple, il suffit de réduire la
taille de noms de serveurs: au lieu de neuf-infra-smtp-in-sp604010av.neufgp.fr.
mettre un truc plus court genre n-i-s-i-sp604010av.neufgp.fr. Ceci permettrait
de réduire la taille de la réponse de 583 bytes à moins de 512 bytes.

Merci d'avance à ceux qui transmettront l'email au bon décideur.

Amicalement
Octave

$ dig neuf.fr any @ns2.9services.com
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.4 <<>> neuf.fr any @ns2.9services.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3071
;; flags: qr aa rd; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;neuf.fr. IN ANY

;; ANSWER SECTION:
neuf.fr. 3600 IN A 212.30.118.74
neuf.fr. 3600 IN NS ns2.9services.com.
neuf.fr. 3600 IN NS dns2.gaoland.net.
neuf.fr. 3600 IN NS ns01.sitadelle.com.
neuf.fr. 3600 IN NS hazzi.hittite.isp.9tel.net.
neuf.fr. 3600 IN NS nanni.hittite.isp.9tel.net.
neuf.fr. 3600 IN NS ns1.9services.com.
neuf.fr. 3600 IN SOA nanni.hittite.isp.9tel.net. hostmaster.isp.9tel.net. 2009020402 21600 3600 1209600 3600
neuf.fr. 900 IN MX 20 neuf-infra-smtp-in-sp604010av.neufgp.fr.
neuf.fr. 900 IN MX 20 neuf-infra-smtp-in-sp604013av.neufgp.fr.
neuf.fr. 900 IN MX 20 neuf-infra-smtp-in-sp604014av.neufgp.fr.
neuf.fr. 900 IN MX 20 neuf-infra-smtp-in-sp604008av.neufgp.fr.
neuf.fr. 900 IN MX 20 neuf-infra-smtp-in-sp604009av.neufgp.fr.
neuf.fr. 3600 IN TXT "v=spf1 ip4:84.96.92.0/24 ip4:93.17.128.0/24 ?all"

;; ADDITIONAL SECTION:
ns2.9services.com. 3600 IN A 84.96.147.1
ns1.9services.com. 3600 IN A 84.96.72.129

;; Query time: 2 msec
;; SERVER: 84.96.147.1#53(84.96.147.1)
;; WHEN: Fri Feb 20 15:16:37 2009
;; MSG SIZE rcvd: 583
^^^^ ^^^^
la taille de la reponse: 583 bytes au lieu de 512 bytes.

Inutile de dire que ça fait du bruit auprès des opérateurs, et notamment de la liste FRnOG, qui regroupe les principaux responsables et directeurs techniques des opérateurs Français.
Neuf telecom a annoncé prendre en considération le problème mais devrait laisser ainsi pour les semaines à venir. Ils vont en effet migrer sur le domaine sfr.fr, en renommant la majorité des reverses et noms de réseaux. Autrement dit, si vous êtes sur qmail, attendez vous à avoir des moments difficiles avec Neuf.fr !

FirstHeberg.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 20/02/2009 à 18:54

Si ça peut aider : 3 méthodes de "correction" http://www.lifewithqmail.org/lwq.html#dns-patches

Et deux remarques :
- Neuf a toujours été chiant avec ses emails
- quelle idée d'utiliser encore Qmail franchement...

daevel : infogérance et conseil || moi

SquawK | Blabla
Modérateur

Inscrit le : 09/05/2005

# Le 20/02/2009 à 19:22

J'ai enfin compris pourquoi tous les mails de neuf m'étaient revenus en erreur cette semaine...

Comparatif pc portable

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 20/02/2009 à 20:41

Apparemment, le problème a été remonté à la DSI de Neuf qui n'était pas au courant on dirait (c'est plus fort que le roquefort cette histoire !)
D'après un mec sur la liste, le problème sera corrigé lundi (Hé oui, Vendredi Inside).

FirstHeberg.com

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 20/02/2009 à 23:08

dob +1, effectivement, j'ai regardé et avec Google Apps, je suis entre 350 et 400 bytes.

Enfin perso, je ne pourrais plus me séparer de Google Apps, ça simplifie tellement l'administration serveur (les mails c'est bien le truc le plus complexe et chiant à gérer), sans compter le webmail accessible partout, Google Docs, etc. Franchement, c'est un rêve ce service

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 20/02/2009 à 23:33

humf... je viens de vérifier chez un client je suis à près de 900 octets même. Plusieurs MX, SPF, SenderID, et le tour est joué... Heureusement pour DomainKeys ils ont eu la bonne idée de mettre ça sur un sous domaine.

daevel : infogérance et conseil || moi

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 20/02/2009 à 23:43

En même temps j'ai du mal à trouver quoi que ce soit concernant une RFC interdisant les paquets de plus de 512 octets pour les emails... Et sur le forum OVH je trouve une explication bien plus plausible (message de ktp) :

Le problème vient du fait que qmail utilise un query de type ANY sur le domaine (réponse longue), puis
analyser la réponse et ne prendre que les enregistrements de type CNAME pour déterminer les MX,
au lieu de ne faire qu'un query de type CNAME directement (réponse courte) suite à un bug de BIND 4 (1996).

Le problème est connu depuis 2006, voir cet article :
http://www.faqts.com/knowledge_base/...html?aid=28...

La solution est de patcher qmail, car comme indique l'article il y a de plus en plus de domaines
qui retournent plus de 512 octets (par exemple aol.com ou microsoft.com, voir ci-dessous).
On n'a pas de prise sur ces domaines et on ne peut pas dépendre
du bon vouloir des détenteurs de ces domaines.

C'est un peu le problème quand on utilise un soft qui n'est plus maintenu depuis plus de 10 ans (juin 98 !!!)... en informatique, c'est une antiquité. Vous supportez encore IE 4 sur vos sites vous ?

De plus la première version de ce document date de février 2004... ça fait 5 ans que le site "qmail.org" aurait annoncé ce bug de QMail.

daevel : infogérance et conseil || moi

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 21/02/2009 à 00:00

Hop, et dans la RFC 1035 (DNS) , qui date de 1987 :

The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can beused for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance. Zone refresh activities must use virtual circuits because of the need for reliable transfer.

Y a même la RFC 3226

(2001) qui parle de l'augmentation de la taille des paquets à cause d'IPv6 et DNSSEC.

Bref, UDP (limitation à 512 octet) et TCP (limitation à 65535 octets) sont autorisé, et il est juste indiqué qu'UDP est préféré pour des raisons de performances... d'ailleurs si j'ai bien compris QMail obtient la réponse en TCP également, c'est juste que son buffer est bridé à 512 octets.

C'est moi ou bien ça sent le baratinage d'OVH ? Et ils font comment pour contacter les gens d'AOL et autres ?

Edit : une dernière et j'arrête. Je suis tombé sur un message de juin 1999

évoquant le problème, et ils parlent là aussi de patcher Qmail, et qu'AOL dépassait déjà les 512 octets.

(Message édité le 21-02-2009 à 00h22 par Bool)

daevel : infogérance et conseil || moi

Akarys | Thierry
Membre

Inscrit le : 19/01/2008

# Le 21/02/2009 à 03:39

Bool a dit :
... et qu'AOL dépassait déjà les 512 octets.

dépassait ??

sd1 pri $ dig any aol.com | grep SIZE

;; MSG SIZE  rcvd: 200

sd1 pri $ dig any microsoft.com | grep SIZE

;; MSG SIZE  rcvd: 279

et à priori Neuf semble avoir "déjà" corrigé... ou tronqué...

sd1 pri $ dig any neuf.fr | grep SIZE

;; MSG SIZE  rcvd: 511

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 21/02/2009 à 12:44

Akarys : quand tu n'interroges pas directement le NS autoritaire, les TXT ne sont pas indiqués. C'est d'ailleurs pour ça qu'une des solutions indiquées est d'utiliser un cache local.

kioob@luuna:~$ dig @dns-01.ns.aol.com aol.com any | grep SIZE
;; MSG SIZE rcvd: 1101

kioob@luuna:~$ dig @ns1.9services.com neuf.fr ANY | grep SIZE
;; MSG SIZE rcvd: 583

daevel : infogérance et conseil || moi

Akarys | Thierry
Membre

Inscrit le : 19/01/2008

# Le 22/02/2009 à 02:53

Bool a dit :
Akarys : quand tu n'interroges pas directement le NS autoritaire, les TXT ne sont pas indiqués.

Tiens ? J'aurais encore appris quelque chose aujourd'hui

Merci

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 22/02/2009 à 03:06

Je n'ai pas cherché d'où ça pouvait venir, je l'ai simplement constaté dans ce test (c'est d'ailleur pour cela que tatave indique bien le NS utilisé). Il me semble avoir lu aussi une remarque à ce sujet dans la doc PHP. Bref, une requête "ANY" ne retourne pas forcément tous les enregistrements.

Maintenant faire tourner un serveur de mail sans cache DNS, ça me semble étonnant... je crois qu'il n'y a pas plus gourmand en requête DNS.

daevel : infogérance et conseil || moi

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.