Sécurité : Appareil de sécurité de courriel Cisco

Que peut causer la bannière de SMTP d'être retardé ?

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Contribué par Jackie Fleming et des ingénieurs TAC Cisco d'Enrico Werner.

Question :

Que peut causer la bannière de SMTP d'être retardé ?

Typiquement quand vous telnet au port 25 d'un serveur de messagerie, vous obtiendrez la bannière de SMTP très rapidement. Voici les exemples des bannières de SMTP :


220 host.example.com ESMTP
554 host.example.com
Parfois il y a un retard et tout que vous obtenez est les informations de connexion dans votre affichage. Voici un exemple :
host.example.com > telnet 10.92.152.18 25
Essayant 10.92.152.18…
Connecté à host.example.com.
Le caractère d'échappement est « ^] ».

Notez que la bannière manque dans cet exemple. Après qu'une certaine heure passe, la bannière devrait finalement être affichée sur la prochaine ligne. Cet article adresse cette situation spécifique. Il y a quatre causes classiques que nous discuterons : Questions de DN, utilisation du CPU élevée, mode d'économie de ressource et Pare-feu.

Questions de DN

La plupart de cause classique de la bannière de SMTP étant retardée est que les consultations de DN ont pris plus long que normal ou chronomètrentes. Il y a trois consultations qui se produisent entre le connecter et l'affichage de bannière : une consultation inverse enregistrement de DN (ou PTR), puis enregistrement en avant (ou A) une consultation de l'adresse Internet donnée dans l'enregistrement PTR, et alors une consultation de SenderBase pour obtenir le SBRS de l'hôte se connectant (score de réputation de SenderBase).

Ces consultations sont utilisées pour déterminer à quel groupe d'expéditeur l'hôte se connectant appartient. Ceci détermine quelle stratégie de flux de courrier est utilisée et si la messagerie sera reçue de cet hôte. Ceci affecte quelle bannière de messagerie, le cas échéant, sera envoyée. C'est pourquoi il est essentiel que ces consultations se produisent avant que la bannière soit donnée.

Pour déterminer si la question est des DN associés, vous devrez se connecter dans la ligne de commande (CLI) de l'ESA et utiliser la commande nslookup. Il est important de faire ceci de l'appliance elle-même ainsi vous fonctionnez de son point de vue. D'abord vous devrez connaître l'adresse IP qui essaye de se connecter. Vous pouvez vouloir utiliser les mail_logs ou le message dépistant pour obtenir l'adresse IP.

Une fois que vous connaissez l'IP, vous pouvez commencer employant le nslookup pour tester. Soyez sûr de compter combien de secondes cela prend pour chacune de ces derniers

Consultations de DN ! D'abord la consultation inverse de DN :

host.example.com > nslookup 10.92.152.18
PTR= host.example.com TTL=2h 35m 43s

Faites alors une consultation sur l'adresse Internet qui est revenue sur la consultation inverse de DN, comme ainsi :

host.example.com > nslookup host.example.com
A=10.92.152.18 TTL=2h 34m 16s

Si le temps total pour ces deux consultations apparie approximativement combien de temps la bannière est retardée, vous avez trouvé la cause et voudrez passer en revue la situation de DN plus plus loin. Les étapes suivantes ont pu inclure tester d'autres adresses IP de différents réseaux. Ceci t'indiquera si la question est localisée dans des hôtes spécifiques ou des réseaux, ou s'il y a une question plus générale de DN.

Utilisation du CPU élevée

Une autre cause possible du retard de bannière de SMTP est utilisation du CPU très élevée.

Quand un système est sous la charge lourde, tout prend plus long pour se produire. Vous pouvez vérifier ceci en allant à la page d'état du système de l'onglet de moniteur, ou à l'aide de la commande CLI « de détail d'état ». Chacun de ceux là donneront les statistiques d'utilisation du CPU dans la section de jauges. Voici un exemple :

Utilisation du processeur
Total 67%
MGA 16%
AFFAIRE 46%
Courrier indésirable 0% de Brightmail
Antivirus 0%
Signaler 4%
Quarantaine 0%

Si le total est très élevé (95% ou plus élevé) et continue à rester élevé pendant plusieurs minutes, l'utilisation du CPU est probable la cause de

les retards de bannière de SMTP.


Mode d'économie de ressource

Une autre cause possible du retard de bannière de SMTP est que le système est entré le mode d'économie de ressource. En ce mode, le système se protège en ralentissant l'écoulement de l'acceptation de messagerie. Il fait ceci en retardant intentionnellement chaque réponse de SMTP qu'il envoie. Pour déterminer si le système est en mode d'économie de ressource, allez à la page d'état du système de l'onglet de moniteur, ou par utilisation la commande CLI « de détail d'état ». Recherchez la ligne d'économie de ressource dans la section de jauges.

Voici un exemple :

Économie 0 de ressource

Tout nombre différent de zéro signifie que le système essaye de se protéger en ralentissant des réponses de SMTP. Vous pouvez se renseigner plus sur l'économie de ressource ici :

Quel est mode d'économie de ressource ?

Pare-feu

La dernière cause classique des retards de bannière de SMTP sont des Pare-feu qui sont SMTP averti. Ceux-ci comportent comme exécuter le « fixup de SMTP » ou exécuter la Sécurité balaye sur tout le contenu de SMTP. Parfois un Pare-feu peut retarder la bannière tandis qu'il balaye et modifie probablement le contenu de la bannière de SMTP. Voici un exemple d'un Pare-feu populaire modifiant la bannière de SMTP :

220
*****02***********************************************************0****0****
0 ***************2******200**0*********0*00


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118016