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

Comment est-ce que je dépanne pourquoi un message n'a pas été reçu par l'ESA ?

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

Contenu

Contribué par Jackie Fleming et Enrico Werner, ingénieurs TAC Cisco.

Question :

Comment est-ce que je dépanne pourquoi un message n'a pas été reçu par l'ESA ?

Pour dépanner la réception de message, vous devez connaître les adresses IP utilisées pour envoyer la messagerie par l'organisation envoyant la messagerie.  Habituellement, contacter l'administrateur de la messagerie de l'organisation d'expéditeur est la manière la plus précise d'obtenir ces informations. Faute de cette option, vous pouvez utiliser quelques autres ressources :

  • SenderBase- si vous entrez dans un domaine dans la fenêtre de recherche chez http://www.senderbase.org, vous recevrez une liste d'IPS de envoi connu pour ce domaine.
  • Logs de messagerie - Si vous avez avec succès reçu la messagerie du domaine dans le passé, vous pouvez regarder dans des logs de messagerie pour une de ces livraisons réussies. 
  • DN -  Vous pouvez consultation que le MX enregistre pour le domaine. La plupart des plus petits organismes utilisent les mêmes serveurs d'arrivée et sortants.  Pour de plus grands ou plus segmentés organismes, cette option n'indiquera pas vraisemblablement l'information nécessaire.

Une fois que vous connaissez les adresses IP, vous devrez rechercher les logs de messagerie. L'utilitaire de grep est un bon outil à cet effet.  Si vous exécutez Windows, vous pouvez utiliser la découverte dans la protection ou le Notepad de Word ou télécharger un utilitaire de grep de l'Internet.  Unix et le MacOSX ont le grep incorporé et peuvent être accédés à d'un shell. La ligne de commande de grep ressemblerait à ceci (où '10.2.3.4' est l'adresse IP que vous recherchez) :

grep '10.2.3.4' file.log de host>

Si le serveur de l'expéditeur se connecte avec succès à votre serveur, vous verrez une ligne semblable au suivant quand vous recherchez leur IP :

Mercredi 2 février 23:43:11 les 2008 informations : Le nouvel hôte test.ironport.com de dn d'inverse de 10.2.3.4 d'adresse de Gestion d'interface du SMTP ICID 6 (10.0.0.1) a vérifié l'aucun

Vous pouvez alors rechercher toutes les lignes impliquant l'ICID (ID de connexion entrante).  Les lignes que vous trouvez t'indiqueront que si elles envoyaient des informations, si elles envoyaient aux informations, et les id de message (MID) joignaient avec la connexion.  Rechercher sur les MID t'affichera si le message était reçu par le système, les résultats de balayage, et si la livraison a été tentée.

Des autres usinent disponible pour dépanner ceci sont les logs de debug d'injection.  Vous aurez besoin de l'adresse IP des serveurs de envoi d'abord.  Une fois que vous avez ces derniers, utilisez les commandes de logconfig et sélectionnez ce type de log.  Le log est configuré et une fois commis, vous pouvez faire envoyer à l'utilisateur un message-test et (assumer leur serveur se connecte à votre ESA) l'ESA se connectera la conversation entière de SMTP.  Ceci te permettra pour voir le point de répartition dans la transmission.

S'il ne restent aucune connexion et ainsi aucun messages reçus, l'étape suivante est de faire employer aux serveurs de envoi administrateur vérifier leurs logs et/ou le telnet pour tester manuellement envoyer un message du serveur de messagerie.  Ceci imitera le serveur tentant de livrer à votre ESA et votre ESA réagira la même chose comme si l'application de serveurs de envoi l'a envoyé.

Si le test intervient, mais le serveur d'application échoue quand il essaye d'envoyer la messagerie, ceci indique des questions de la livraison sur le serveur distant. L'administrateur de serveur distant devra passer en revue les logs pour diagnostiquer les erreurs. 

Une cause classique de la réception retardée ou défectueuse est que les serveurs de envoi IP ne fait pas configurer les DN inverses correctement entraînant un long délai d'attente (secondes 30+) pour que l'ESA fournisse une bannière de SMTP.  Quelques serveurs d'application atteindront leur délai d'attente configuré et clôtureront la session avant d'envoyer la messagerie en raison de la bannière retardée.  La solution est dans ce cas d'étendre le délai d'attente ou d'implémenter les DN inverses.  L'action recommandée est d'implémenter les DN inverses pour tous les serveurs de messagerie qui livrent à d'autres serveurs d'Internet Mail.  C'est considéré étiquette appropriée d'Internet et permet à des serveurs de messagerie pour confirmer l'identité du serveur très à un niveau de base.


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: 118014