Revista Informática

Relay en Exchange 2013

Publicado el 21 abril 2015 por Aprendiendoexchange

En esta entrada vamos a ver en que casos es necesario habilitar el relay de correo y cuales son las opciones en Exchange 2013. En adición, vamos a hacer foco sobre 3 escenarios específicos:

  1. Aplicaciones o dispositivos que envían correo a destinatarios internos

  2. Aplicaciones o dispositivos que envían correo externo y tienen la posibilidad de autenticarse con Exchange

  3. Aplicaciones o dispositivos que envían correo externo y no pueden autenticarse con Exchange

Introducción

Una necesidad frecuente es la de habilitar que dispositivos (impresoras, scanners, etc) o aplicaciones puedan enviar correo a través de Exchange.

En general, dentro de este contexto encontramos 2 tipos de requerimientos; uno donde se requiere que un dispositivo o aplicación pueda enviar correo a destinatarios internos ( relay interno) y otro donde es necesario que pueda hacerlo hacia destinatarios externos ( relay externo). Un destinatario interno sería cualquiera que tenga una dirección de correo de uno de los dominios aceptados de la organización.

En definitiva, cuando nos plantean el requerimiento de que un dispositivo o aplicación pueda enviar correo debemos tener en claro lo siguiente:

  • Requiere enviar correo a destinatarios internos o externos (o ambos)?

  • El dispositivo o aplicación tiene la posibilidad de autenticarse con un usuario y contraseña o se debe habilitar anónimamente para la IP específica?

  • Debe utilizar un puerto en particular?

Contando con esta información estaríamos en condiciones de evaluar los escenarios manejados en este artículo.

Escenario 1 - La aplicación o dispositivo envía correo a destinatarios internos

Si las aplicaciones o dispositivos envían correo únicamente a destinatarios internos de la organización, el rol de Acceso de Clientes ( CAS) de Exchange 2013 viene con un conector de recepción ya habilitado para recibir correo anónimo ( si no tenemos un servidor de o similar, es el conector que en general publicaríamos hacia Internet ).

El conector de recepción predeterminado escucha en el puerto 25 y se llama Default Frontend (servidor):

Relay en Exchange 2013

En este caso ya sea que se configure el dispositivo / aplicación mediante DNS o directamente a la IP del CAS, sería suficiente para enviar correo. Claro que en este escenario si se intenta hacer relay hacia un destinatario externo se recibiría un error (de lo contrario estaríamos en un estado de "").

Si probamos enviar correo a un usuario externo con telnet nos tendríamos que encontrar con el siguiente error:

550 5.7.1 Unable to relay

Relay en Exchange 2013

Escenario 2 - La aplicación o dispositivo puede autenticarse

Si la aplicación o dispositivo tiene la posibilidad de utilizar un usuario y contraseña (recomendado), en el rol de CAS se incluye un conector orientado a clientes que permite a un usuario autenticado enviar correo externo. Este conector es el Client Frontend (servidor) y escucha en el puerto 587.

Relay en Exchange 2013

En este caso tendríamos que configurar la aplicación o dispositivo para enviar correo utilizando el puerto 587 en lugar del 25 (opcionalmente se puede crear un conector dedicado y que escuche en el 25).

Escenario 3 - La aplicación o dispositivo no puede autenticarse y debe poder enviar correo hacia fuera de la organización

En este caso hay que habilitar el relay anónimo para las direcciones IP específicas. La desventaja de esto es que al habilitarse por IP, cualquier aplicación instalada en ese servidor potencialmente podría hacer relay. De cualquier modo, este es uno de los escenarios más comunes.

OPCIÓN 1

Para habilitar el relay anónimo para una o más direcciones IP debemos abrir el shell de Exchange ( EMS) y ejecutar lo siguiente:

New-ReceiveConnector -Name "AppRelayAnon" -TransportRole Frontend -Bindings 0.0.0.0:26 -Usage Custom -RemoteIPRanges 192.168.1.170 -Server EX2013 -Banner "220 Conector para relay anonimo" -PermissionGroups Anonymous

Relay en Exchange 2013

En este punto tenemos creado un conector con las siguientes características:

  • Asociado al rol de transporte de Frontend ( este servicio corre en el CAS)

  • Escucha en todas las direcciones IP en el puerto 26. Esto es opcional, podríamos configurarlo para que escuche en una IP específica si tiene más de una o en un puerto diferente (incluso en el 25)

  • Opcionalmente en este caso se configuró un "Banner" para que cuando se hagan pruebas de conectividad aparezca el Banner específico de relay anónimo.

  • Habilita únicamente a que se conecte la dirección IP 192.168.1.170 (este sería el dispositivo o servidor donde se encuentra alojada la aplicación que requiere enviar correo)

El conector creado aun no permitiría el envío de correo hacia internet, para esto falta ejecutar otro comando que otorgue los permisos correspondientes:

Get-ReceiveConnector AppRelayAnon | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "MS-Exch-SMTP-Accept-Any-Recipient"

Relay en Exchange 2013

Para validar que este funcionando correctamente, podemos ir al equipo que habilitamos en la configuración del conector de recepción, en este caso el que tiene la IP 192.168.1.170 y utilizando telnet ejecutamos lo siguiente:

Telnet servidor 26

helo

Mail From: [email protected]

Rcpt To: [email protected]

Relay en Exchange 2013

Si el relay esta funcionando, luego de ingresar el destinatario externo tendría que devolver un Recipient OK, de lo contrario "unable to relay".

En el caso del ejemplo estoy agregando también la dirección del administrator con la finalidad de mostrar como llega el correo:

Relay en Exchange 2013

La cuenta que estoy utilizando en las pruebas " apptest" tiene un buzón en la organización de contoso, sin embargo pueden ver que el mail no llega con el nombre para mostrar sino que simplemente con la dirección de correo.

Si este comportamiento no es el deseable podemos utilizar la alternativa de la Opción 2.

OPCIÓN 2

New-ReceiveConnector -Name "AppRelay" -TransportRole Frontend -Bindings 0.0.0.0:25 -RemoteIPRanges 192.168.1.170 -Server EX2013 -Banner "220 Conector para relay de aplicaciones" -AuthMechanism Tls,ExternalAuthoritative -PermissionGroups ExchangeServers

Relay en Exchange 2013

Este comando crea un nuevo conector de recepción con las siguientes características:

  • Asociado al servicio de Frontend en el servidor con el rol de (esto también aplica en el caso que tengamos ambos roles instalados en el mismo servidor).

  • Escucha en todas las direcciones IP en el puerto 25 ( al igual que el conector que probamos en el escenario 1). Esto es posible mientras la combinación de IP / Puerto / Rango de IP remotas sea único.

  • Se configura el parámetro " Banner" para distinguir con mayor facilidad a que conector nos estamos conectando ( ya que estamos usando el mismo puerto del default). Esto nos permite simplificar un eventual proceso de troubleshooting.

En este caso estamos utilizando un mecanismo de autenticación distinto (ExternalAuthoritative) y en lugar de dar permisos a Anonymous, lo hacemos a ExchangeServers. Esto implica que confiamos 100% en el equipo que vamos a agregar ya que esto entre otras cosas pasaría por alto los filtros antispam.

Si repetimos la prueba de telnet desde el equipo que habilitamos, el procedimiento sería exactamente el mismo que en el caso anterior:

Relay en Exchange 2013

La diferencia la encontramos cuando recibimos el correo:

Relay en Exchange 2013

Como pueden ver se resolvió la dirección al nombre para mostrar ( display name) en lugar de simplemente mostrar la dirección de correo.

Conclusión

Tenemos varias formas de habilitar que un dispositivo o aplicación envíe correo a través de Exchange 2013, si el objetivo es enviar a destinatarios internos, en principio no sería necesario realizar nada más allá de que exista conectividad al puerto 25 del conector predeterminado del rol de Client Access.

Si la idea es enviar correo externo y la aplicación o dispositivo puede autenticarse alcanzaría con configurar para que se conecte al puerto 587 del conector de clientes del CAS (y que no este bloqueado a nivel de firewall o antivirus).

Por último, si necesitamos que la aplicación pueda enviar correo externo y no tiene la posibilidad de autenticarse con un usuario y contraseña, tenemos la opción de crear un nuevo conector de recepción para relay como se describe en el Escenario 3 y dependiendo del requerimiento específico como configurarlo.


Volver a la Portada de Logo Paperblog