Routage de mails entre FAI

ne parviennent jamais à  ces
serveurs de destination particuliers et
parfois reviennent à  nos envoyeurs
internes.
Il faut presque 90 secondes à  la
connexion pour recevoir le message de
connexion établie « 220 ». Malheureusement, après
ce long délai, notre pare-feu a laissé tomber la
connexion à  partir de sa table interne et, par conséquent,
ignore la réponse en provenance du serveur
SMTP distant.
Nous avons déterminé cette cause à  partir des
entrées du log dans notre pare-feu et l’avons vérifiée
en déplaçant temporairement le serveur de courrier
électronique de derrière le pare-feu. Les connexions durent encore 90 secondes, mais maintenant le
serveur SMTP échange le mail après un délai de 90
secondes.
L’assistance technique de SBC et d’AOL n’ont pas
de réponse. Qu’en pensez-vous ?

Je suis impressionné par l’acuité de votre analyse et par
l’excellente description du problème. Vos renseignements
mettent en lumière une cause insidieuse et fréquente
d’établissement de connexion TCP/IP lente : des serveurs
reverse-DNS défectueux.
Il est très important que chaque adresse IP publique que
vous utilisez sur Internet ait une entrée reverse-DNS qui correspond
à  son entrée en avant. Ainsi, si votre serveur
de courrier électronique est « mail.acme.com » à  1.2.3.4,
l’exécution d’un lookup DNS sur 1.2.3.4 devrait renvoyer
« mail. acme.com ». Vous pouvez tester cela vous-même en
entrant les commandes suivantes (présentées en gras) dans
une fenêtre de commande Windows:

nslookup
>server ns1.sprintlink.net
>mail.acme.com
Address: 1.2.3.4
>1.2.3.4
[90-second delay]
*** ns1.sprintlink.net can't find
mail.acme.com: Non-existent host/domain

La solution est simple : contactez votre ISP et demandezlui
de corriger vos entrées reverse-DNS. Si vous exploitez vos
propres serveurs DNS, demandez à  un consultant ou à  un
expert maison de corriger vos reverse-DNS défaillants.