Preguntas y respuestas sobre ExchangeProtocolos de correo electrónico seguros, correo electrónico no deseado de origen desconocido y mucho más

Nino Bilic and Scott Landry

Esta columna se basa en parte en una versión preliminar de Windows Server 2008. Por lo tanto, todos los detalles de este documento están sujetos a cambios.

P Deseo usar SMTP seguro, ¿cómo consigo que Exchange Server escuche SMTP en el puerto 465?

R Lo siento, pero esto no se puede hacer. Sí, puede hacer que cualquier servidor virtual SMTP o conector de recepción se escuche en el puerto 465, pero de este modo no conseguirá su objetivo de SMTP seguro (SMTPS).

¿Por qué? Bien, retrocedamos un poco y veamos el porqué. Hay dos tipos de SSL: explícito e implícito. Inicialmente, la mayor parte del SSL era implícito, lo cual implicaba el uso de un puerto dedicado para SSL. Por ejemplo, HTTP está en el puerto 80 de forma predeterminada, pero HTTPS (HTTP con SSL) está en el puerto 443. Hace varios años, la comunidad de Internet decidió que no fuera necesario un puerto dedicado para SSL. De este modo surgió el SSL explícito.

Netscape ya había elegido 465 como el puerto SMTPS, pero Exchange Server no tenía funcionalidad SSL en SMTP. Sin embargo, el equipo de Exchange observó la ventaja que ofrecía el SSL explícito, que se podría usar igualmente tanto por clientes como por servidores y eligió ser compatible con SSL explícito para SMTP.

En el caso de SMTP, el SSL explícito usa el comando STARTTLS ESMTP para señalar que el socket existente está a punto de ser protegido. La mayoría del resto de los servidores SMTP y proveedores de cliente han implementado también el comando STARTTLS, por lo que nunca hubo necesidad de ser compatible con el puerto 465, el cual, de todos modos, no constituía un estándar oficial de Internet.

Hasta el momento, ninguna versión de Exchange Server es compatible con SSL implícito para SMTP. Comunicar a un conector de recepción de Exchange o servidor virtual SMTP que escuche en el puerto 465 no cambia este hecho. Por lo tanto, necesita usar un cliente que sea compatible con STARTTLS en el puerto 25. Si no puede usar el puerto 25, la siguiente elección lógica es el 587, que es el puerto estándar para envíos SMTP de cliente. No hay muchos clientes actuales que no sean compatibles con STARTTLS en el 25, así que el agregar compatibilidad con SSL implícito no ha sido necesario.

A propósito, los protocolos POP3 e IMAP4 de Exchange siempre han sido compatibles con SSL implícito. Pero Exchange Server 2007 cuenta ahora también con compatibilidad añadida para SSL explícito para estos dos protocolos. No obstante, puesto que no muchos clientes son compatibles aún con este estándar más nuevo, SSL implícito todavía funcionará durante bastante tiempo.

P Tengo una gran cantidad de correo en la cola para diversos dominios y ninguno de mis usuarios ha enviado ninguno de los mensajes de correo. ¿Qué es lo que ocurre y qué puedo hacer para evitarlo?

R No se preocupe, no es el único. Cualquier persona que tenga un servidor en Internet puede encontrarse con este problema. Básicamente, hay dos causas posibles. La primera es que de algún modo usted mismo se ha abierto a las retransmisiones (consulte support.microsoft.com/kb/304897). Pero, por supuesto, usted no lo haría conscientemente, ¿verdad? (Las retransmisiones abiertas se han deshabilitado de manera predeterminada desde Exchange Server 2000). Así que lo más probable es que esté viendo lo que se denomina correo electrónico no deseado de informe de no entrega (NDR). En el proceso de envío de correo electrónico comercial no solicitado (UCE), los remitentes de correo electrónico no deseado con frecuencia realizan envíos a direcciones inexistentes de su dominio. El servidor intenta notificar al remitente de correo electrónico no deseado que los usuarios no existen, pero por supuesto, el remitente de correo electrónico no deseado ha suplantado el remite. El remitente de correo electrónico no deseado puede estar suplantando una dirección no válida (en cuyo caso el NDR queda pendiente cierto tiempo hasta que se agota el tiempo) o puede estar intentando que su servidor envíe correo electrónico no deseado a otro dominio en su propio beneficio, como un archivo adjunto del NDR que su servidor ha generado.

Podría deshabilitar los NDR, pero, en ese caso, si un usuario legítimo escribe mal una dirección por error, el servidor nunca le permitirá saber a este usuario que el correo electrónico no se envió y que los mensajes podrían haberse perdido. Le presentamos una solución mejor.

En primer lugar, asegúrese de que no se encuentra abierto a retransmisiones. (Tenía que decirlo). A continuación, active algún tipo de filtro contra correo electrónico no deseado, como el filtro inteligente de mensajes (FMI) o el filtro de contenido de Exchange Server 2007, además de unas cuantas Listas de bloqueados en tiempo real (RBL). Esto puede ser tanto en la función de Transporte perimetral como en la función de Transporte de concentradores, pero debe realizarse en primer enlace, ya que normalmente el 90 por ciento del volumen de correo tiende a ser correo electrónico no deseado y no es deseable mantener los servidores ocupados con esta clase de correo).

En último lugar, habilite el filtrado de destinatarios en el primer Exchange Server que acepte correo en su entorno. Esto permite al servidor rechazar un mensaje antes de que entre en su red. Si la dirección es legítima pero se ha escrito mal, ésta obtendrá el NDR, pero éste se generará a partir del servidor del remitente.

P Tenía un servidor que ejecutaba Exchange Server 2000 y otro que ejecutaba Exchange Server 2003, ambos podían enviar correo electrónico correctamente a Internet. Después instalé Exchange Server 2007 y ahora los buzones de correo de cada servidor no pueden enviar correo.

R Si en el pasado sólo ha tenido un Exchange Server, puede que no esté muy familiarizado con el concepto de los conectores. Los conectores de Exchange son objetos lógicos de configuración de enrutamiento que comunican a Exchange dónde dirigir el correo electrónico. Al introducir Exchange Server 2007 en una organización existente, con el objeto de enrutar el correo, necesariamente debe tener conectores de grupo de enrutamiento y un conector SMTP.

Necesitará dos conectores de grupo de enrutamiento, uno de ellos desde el grupo de enrutamiento de Exchange Server 2007 al grupo de enrutamiento de Exchange Server 2003 y viceversa. Puede configurar esto como parte del proceso de instalación, pero si lo lleva a cabo inadecuadamente o no está seguro, puede comprobarlo mediante el shell de administración de Exchange y corregir allí el problema. Si no lo hace, no podrá enviar correo electrónico entre los servidores. Los mensajes acabarán en colas de destino inalcanzables.

Para enrutar correo electrónico de Internet sólo necesita un conector SMTP, también conocido como conector de envío en Exchange Server 2007. Debe tener uno en Exchange Server 2000 y Exchange Server 2003, pero puede que hasta ahora haya funcionado sin el mismo. El espacio de direcciones debe ser SMTP:* para todos los dominios y puede especificar tanto el uso de un host inteligente como el DNS para la entrega de correo. Puede elegir si desea el servidor Exchange Server 2007 o el servidor más antiguo para administrar el correo saliente de Internet, o bien puede crear uno en ambos grupos de enrutamiento si desea que cada servidor administre el suyo propio. Puede crear también uno de estos como parte del proceso Edgesync si tiene instalada la función de servidor de Transporte perimetral.

Si puso previamente un host inteligente en el servidor virtual SMTP, ahora es un buen momento para quitarlo. Sólo debe estar en el conector SMTP, nunca en el servidor virtual puesto que así interrumpiría al conector del grupo de enrutamiento.

Debe saber también que los correos electrónicos entrantes se controlan a través del registro MX o la IP a la cual realiza el reenvío el firewall. No hay mucho que configurar en Exchange, pero este documento puede ser de ayuda si aún persisten los problemas: msexchangeteam.com/archive/2006/11/17/431555.aspx.

P ¿Por qué obtengo varios informes de diarios del mismo mensaje en Exchange Server 2007?

R El agente de diario de transporte de Exchange Server 2007 realizará el registro de los mensajes tras la categorización. El categorizador tiene muchas razones por las que bifurcar un mensaje (es decir, copia el cuerpo del mensaje y coloca distintos destinatarios de sobre en las distintas copias). Por ejemplo: puesto que los registros en diario tienen ahora la capacidad de decirle quiénes eran los miembros de un grupo de distribución en el momento en el cual se envió el mensaje, un caso en el cual podría obtener varios informes es el de un grupo de distribución anidado.

Tener más posibilidades en los medios de generación de informes implica que puede obtener unas pocas copias del mismo mensaje, cada una con un informe único. No existe una manera garantizada de saber si han llegado todos los informes para un mensaje, pero si está realizando tareas de archivado, deseará trabajar con su proveedor de archivo para asegurarse de que conoce los cambios.

P ¿Dónde se encuentra la característica de reenvío de mensajes no resueltos al host en Exchange Server 2007? ¿Qué debo hacer ahora?

R El perro se lo comió.

Realmente, esta característica específica nunca funcionó especialmente bien en las situaciones en las que se disponía de más de un Exchange Server. No obstante, Exchange ya tenía otro método para llevar a cabo la misma tarea y ese método era mucho más eficaz. Específicamente, el usuario tiene la posibilidad de compartir dominios SMTP individuales con otros sistemas. Así que la característica "reenvío no resuelto" se eliminó y el concepto de dominio de uso compartido se amplió y simplificó. En Exchange Server 2007, simplemente vaya a Organización | Transporte de concentradores | Dominios aceptados y cambie el tipo de dominio de Autoritativo a Retransmisión interna. Para algunos entornos es un poco más complicado, por lo que estamos trabajando en actualizar parte de la documentación. Aunque esto debe servir de ayuda mientras tanto.

P Estoy intentando preparar mi dominio raíz para la instalación de Exchange Server 2007. El servidor desde el que estoy intentando ejecutar la instalación de Exchange Server 2007 tiene instalado el Administrador del sistema de Exchange (ESM) de Exchange Server 2003 y la instalación presenta errores. ¿Cuál es el problema?

R Brevemente, no es compatible ejecutar cualquier parte de la instalación de Exchange Server 2007 en un equipo que tiene instalado algún componente de Exchange Server 2000 ó 2003. Puesto que está instalado el ESM de Exchange Server 2003, la instalación de Exchange Server 2007 lo advertirá y la comprobación de requisitos previos de la instalación no será correcta, por lo que se le comunicará lo siguiente, "Ya hay instalada una versión de Exchange Server en este equipo. Ejecute la instalación de Exchange Server 2007 desde un equipo diferente o quite la versión anterior de Exchange Server".

Probablemente la manera más sencilla de solucionar este problema es ejecutar la instalación de Exchange Server 2007 desde otro servidor en el dominio raíz y preparar el dominio de este modo. Si eso no es posible, tendrá que desinstalar el componente de Exchange Server 2003 antes de poder continuar con la instalación de Exchange Server 2007.

Recuerde que puede usar la versión de 32 bits de Exchange Server 2007 para preparar el dominio, por lo que puede usar cualquier servidor de 32 bits del dominio raíz. Para obtener más información sobre este tema, consulte technet.microsoft.com/library/bb232170.aspx.

A propósito, esto implica que no es posible instalar el ESM de Exchange Server 2003 y la Consola de administración de Exchange de Exchange Server 2007 en el mismo equipo, puesto que la coexistencia de las herramientas de administración de Exchange Server 2003 y Exchange Server 2007 en el mismo equipo no es compatible. Exchange Server 2007 bloqueará la instalación si intenta instalarlo en un equipo que tenga instalado algún componente de Exchange Server 2000 o Exchange Server 2003.

Finalmente, tenga en cuenta que no debe intentar instalar las herramientas de administración de Exchange Server 2007 en primer lugar y, a continuación, seguir con las herramientas de Exchange Server 2003 en el mismo equipo. Este enfoque le colocará en una configuración que no ha sido probada y que podría ofrecerle resultados inesperados al tratar de administrar los servidores. Si necesita administrar ambas versiones de servidor desde un solo equipo, podría usar el escritorio remoto para conectarse a una versión, o usar un equipo virtual para hospedar una versión diferente de las herramientas de administración en un entorno aislado.

P ¿Cuándo podré por fin ejecutar las herramientas de administración de Exchange Server 2007 en la estación de trabajo de Windows Vista®?

R La compatibilidad oficial de las herramientas de administración de Exchange Server 2007 con Windows Vista será posible con el lanzamiento de Exchange Server 2007 SP1. Estará disponible para la descarga un paquete con las herramientas de administración de Exchange Server 2007 SP1 una vez esté disponible la versión de Exchange Server 2007 SP1.

Q ¿Qué ocurre con el ESM de Exchange Server 2003 en Windows Vista o Windows Server 2008? ¿Podré ejecutar eso también?

R No, desgraciadamente esto no es posible. Las herramientas de administración para cualquier versión de Exchange Server anterior a Exchange Server 2007 SP1 no serán compatibles ni en Windows Vista ni en Windows Server 2008. Esto significa que incluso después de los lanzamientos de Windows Server 2008, la instalación del ESM de Exchange Server 2003 en el mismo no será compatible. La administración de los servidores de Exchange Server 2003 tendrá que realizarse desde estaciones de trabajo de Windows Server 2003 o de Windows XP; también puede usar la conexión a Escritorio remoto desde cualquier sistema operativo.

P Tengo varios servidores Exchange Server 2003 ejecutándose en mi dominio. ¿Podré actualizar mis controladores de dominio a los controladores de dominio de Windows Server 2008?

R Sí claro, ejecutar Exchange Server 2003 SP2 en el dominio que tiene controladores de dominio de Windows Server 2008 es compatible. Tenga en cuenta que Exchange Server no puede usar controladores de dominio de sólo lectura (RODC) de Windows Server 2008 ni servidores de catálogo global de sólo lectura (ROGC). Especificar manualmente (codificar) a Exchange Server para que use RODC/ROGC de Windows Server 2008 puede provocar un comportamiento inesperado.

Nino Bilic Administrador de programas de compatibilidad para Exchange Server, emplea su tiempo libre descubriendo la belleza de la comunicación de servidor a servidor leyendo una tonelada de trazas de Netmon antes de ir a dormir cada noche.

Scott LandryIngeniero de escala de soporte técnico para Exchange Server, no va a ningún sitio sin su toalla, una copia de la Guía y su confiable teléfono Windows Mobile.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.