Question :
Qu'est-ce qui peut retarder la bannière SMTP ?
En général, lorsque vous établissez une connexion Telnet avec le port 25 d'un serveur de messagerie, vous obtenez très rapidement la bannière SMTP. Voici des exemples de bannières SMTP :
220 host.example.com ESMTP
554 host.example.com
Parfois, il y a un délai et tout ce que vous obtenez est les informations de connexion dans votre écran. Voici un exemple :
host.example.com> telnet 10.92.152.18 25
Essai de 10.92.152.18...
Connecté à host.example.com.
Le caractère d'échappement est '^]'.
Notez que la bannière est manquante dans cet exemple. Au bout d'un certain temps, la bannière devrait enfin être affichée sur la ligne suivante. Cet article traite de cette situation spécifique. Nous aborderons quatre causes courantes : les problèmes DNS, l'utilisation élevée de l'UC, le mode de conservation des ressources et les pare-feu.
Problèmes DNS
La cause la plus courante du retard de la bannière SMTP est que les recherches DNS ont pris plus de temps que la normale ou ont expiré. Trois recherches sont effectuées entre la connexion et l'affichage de la bannière : une recherche DNS inverse (ou enregistrement PTR), puis une recherche directe (ou enregistrement A) du nom d'hôte indiqué dans l'enregistrement PTR, et enfin une recherche SenderBase pour obtenir le SBRS (SenderBase Reputation Score) de l'hôte connecté.
Ces recherches permettent de déterminer à quel groupe d’expéditeurs appartient l’hôte qui se connecte. Cela détermine quelle stratégie de flux de messagerie est utilisée et si les messages seront acceptés de cet hôte. Cela affecte la bannière de courrier, le cas échéant, qui sera envoyée. C'est pourquoi il est essentiel que ces recherches aient lieu avant que la bannière ne soit donnée.
Pour déterminer si le problème est lié au DNS, vous devez vous connecter à la ligne de commande (CLI) de l'ESA et utiliser la commande nslookup. Il est important de le faire à partir de l'appliance elle-même afin que vous travailliez selon sa perspective. Vous devez d'abord connaître l'adresse IP qui tente de se connecter. Vous pouvez utiliser mail_logs ou Message Tracking pour obtenir l'adresse IP.
Une fois que vous connaissez l'adresse IP, vous pouvez commencer à utiliser nslookup pour tester. Assurez-vous de compter le nombre de secondes nécessaires pour chacun de ces
Recherches DNS ! Commencez par la recherche DNS inverse :
host.example.com> nslookup 10.92.152.18
PTR= host.example.com TTL=2h 35m 43s
Effectuez ensuite une recherche sur le nom d'hôte qui est revenu lors de la recherche DNS inverse, comme suit :
host.example.com> nslookup host.example.com
A=10.92.152.18 TTL=2h 34m 16s
Si la durée totale de ces deux recherches correspond approximativement à la durée de retard de la bannière, vous avez trouvé la cause et souhaiterez examiner la situation DNS plus en détail. Les étapes suivantes peuvent inclure le test d’autres adresses IP de différents réseaux. Cela vous indiquera si le problème est isolé sur des hôtes ou des réseaux spécifiques, ou s'il existe un problème DNS plus général.
Utilisation CPU élevée
Une autre cause possible du délai de la bannière SMTP est l'utilisation très élevée de l'UC.
Lorsqu'un système est soumis à une charge importante, tout prend plus de temps. Vous pouvez le vérifier en accédant à la page System Status de l'onglet Monitor ou en utilisant la commande CLI « status detail ». Ces deux options fournissent les statistiques d'utilisation du processeur dans la section Jauges. Voici un exemple :
Utilisation du processeur
Total 67 %
MGA 16 %
CAS 46%
Antispam Brightmail 0 %
Antivirus 0 %
Déclarations 4 %
Quarantaine 0 %
Si le total est très élevé (95 % ou plus) et qu'il reste élevé pendant plusieurs minutes, l'utilisation du processeur est probablement la cause de
les délais de la bannière SMTP.
Mode Conservation des ressources
Une autre cause possible du retard de la bannière SMTP est que le système est passé en mode Conservation des ressources. Dans ce mode, le système se protège en ralentissant le flux d'acceptation du courrier. Pour ce faire, il retarde intentionnellement chaque réponse SMTP qu'il envoie. Pour déterminer si le système est en mode Conservation des ressources, accédez à la page État du système de l'onglet Moniteur ou utilisez la commande CLI « status detail ». Recherchez la ligne Conservation des ressources dans la section Jauges.
Voici un exemple :
Conservation des ressources 0
Tout nombre différent de zéro signifie que le système tente de se protéger en ralentissant les réponses SMTP. Pour en savoir plus sur la conservation des ressources, cliquez ici :
Qu'est-ce que le mode conservation ?
Pare-Feu
Les pare-feu qui prennent en charge SMTP sont la dernière cause courante des retards de bannière SMTP. Ces fonctions, telles que la correction SMTP ou l'exécution d'analyses de sécurité sur tout le contenu SMTP. Parfois, un pare-feu peut retarder la bannière pendant qu'il analyse et éventuellement modifier le contenu de la bannière SMTP. Voici un exemple de pare-feu populaire modifiant la bannière SMTP :
220
*****02***********************************************************0****0****
0 ***************2 ****** 200 **0 *********0*00