Seguridad : Cisco Email Security Appliance

¿Cómo resolver problemas porqué un mensaje no fue recibido por el ESA?

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Contenido

Contribuido por Jackie Fleming y Enrique Werner, ingenieros de Cisco TAC.

Pregunta:

¿Cómo resolver problemas porqué un mensaje no fue recibido por el ESA?

Para resolver problemas la recepción del mensaje, usted necesita conocer los IP Addresses usados para enviar el correo por la organización que envía el correo.  Generalmente, entrar en contacto al administrador del correo de la organización del remitente es la mayoría de la forma adecuada de conseguir esta información. En ausencia de esta opción, usted puede utilizar algunos otros recursos:

  • SenderBase- si usted ingresa un dominio en el rectángulo de la búsqueda en http://www.senderbase.org, usted recibirá una lista de IP de envío sabidos para ese dominio.
  • Registros del correo - Si usted ha recibido con éxito el correo del dominio en el pasado, usted puede mirar en los registros del correo para una de esas entregas exitosas. 
  • DNS -  Usted puede mirar para arriba los expedientes MX para el dominio. La mayoría de las organizaciones más pequeñas utilizan los mismos servidores entrantes y salientes.  Para organizaciones más grandes o divididas en segmentos, esta opción no revelará probablemente la información requerida.

Una vez que usted conoce los IP Addresses, usted necesitará buscar los registros del correo. La utilidad del grep es un buen para este propósito de la herramienta.  Si usted está ejecutando Windows, usted puede utilizar el hallazgo en la pista o la libreta de la palabra o descargar una utilidad del grep de Internet.  Unix y el mac OSX tienen grep incorporado y se pueden acceder de un shell. La línea de comando grep parecería esto (donde está la dirección IP '10.2.3.4' que usted está buscando para):

grep '10.2.3.4' file.log del host>

Si el servidor del remitente está conectando con éxito con su servidor, usted verá una línea similar al siguiente cuando usted busca para su IP:

Miércoles 2 de febrero 23:43:11 2008 informaciones: El nuevo host test.ironport.com dns del revés de 10.2.3.4 del direccionamiento de la administración de la interfaz S TP ICID 6 (10.0.0.1) verificó ningún

Usted puede entonces buscar para todas las líneas que implican el ICID (conexión entrante ID).  Las líneas que usted encuentra le dirán que si enviaron de la información, si enviaron a la información, y los ID del mensaje (MEDIADOS DE) conectaron a la conexión.  Búsqueda en

Otros equipan disponible para localizar averías esto son los registros del debug de la inyección.  Usted necesitará la dirección IP de los servidores de envío primero.  Una vez que usted tiene éstos, utilice los comandos del logconfig y seleccione este tipo del registro.  Una vez que se configura y está confiado el registro, usted puede tener el usuario enviar un mensaje de prueba y (si se asume que su servidor conecta con su ESA) el ESA registrará la conversación SMTP entera.  Esto permitirá que usted vea la punta de la interrupción en la comunicación.

Si todavía no hay conexiones y así ningunos mensajes recibidos, el siguiente paso es tener el administrador de envío de los servidores marcar sus registros y/o utilizar el telnet para probar manualmente el envío de un mensaje del mail server.  Esto imitará el servidor que intenta entregar a su ESA y su ESA reaccionará lo mismo como si la aplicación de servidores de envío lo enviara.

Si va la prueba a través, pero la aplicación del servidor falla cuando intenta enviar el correo, ésta indica los problemas de la salida en el servidor remoto. El administrador del servidor remoto necesitará revisar los registros para diagnosticar los errores. 

Una causa común de la recepción retrasada o fallada es que el IP de envío de los servidores no tiene DNS reverso configurado correctamente haciendo un retardo prolongado (segundos 30+) para que el ESA proporcione un anuncio SMTP.  Algunas aplicaciones del servidor alcanzarán su descanso configurado y cerrarán la sesión antes de enviar el correo debido al banner retrasado.  La solución en este caso es ampliar el descanso o implementar el DNS reverso.  La acción recomendada es implementar el DNS reverso para todos los servidores del correo que entreguen a otros servidores del correo de Internet.  Se considera etiqueta apropiada de Internet y permite que los servidores del correo confirmen la identidad del servidor en un nivel muy básico.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 118014