Descarga el nuevo ebook de Exchange 2013 / 2016

  • Acceso a material exclusivo del sitio
  • Actualizaciones y novedades
  • Ebooks, tutoriales y mucho más!
 
 

Relay en Exchange 2013 / 2016

En esta entrada vamos a ver en que casos es necesario habilitar el relay de correo y cuales son las opciones en Exchange 2013 / 2016. 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  (esto también aplica a 2016 aunque el CAS ya no sea un rol separado) viene con un conector de recepción ya habilitado para recibir correo anónimo (si no tenemos un servidor de Edge 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):

Conector predeterminado en Exchange 2013 / 2016

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 “open relay”).

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 no habilitado en Exchange

 


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), también tenemos un conector predeterminado, este se encuentra orientado a clientes y permite que usuarios autenticados puedan enviar correo externo. Este conector es el Client Frontend (servidor) y escucha en el puerto 587.

Conector de clientes en Exchange 2013 / 2016

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

Cómo crear un conector para relay en Exchange 2013 / 2016

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

  • Nombre: AppRelayAnon
  • 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”

Habilitar relay anónimo en Exchange 2013 / 2016

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: apptest@contoso.com

Rcpt To: test@externo.com

Relay en Exchange 2013 / 2016

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 adición sería recomendable realizar la misma prueba desde un equipo no incluido en la lista para verificar que realmente esta funcionando solo para las direcciones IP listadas (si la IP no esta listada directamente no podría conectarse al conector).

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 / 2016

La cuenta que estoy utilizando en las pruebas “apptest” tiene un buzón en la organización de contoso, sin embargo podemos ver que el mail no llega con el nombre para mostrar (display name) 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

Conector de relay en Exchange 2013 / 2016

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

  • Nombre: Apprelay
  • Asociado al servicio de Frontend
  • 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 / 2016

La diferencia la encontramos cuando recibimos el correo:

relay en Exchange 2013 / 2016

Como se puede 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 / 2016, 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 “Default Front End”.

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 (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.

Por información sobre relay en Exchange 2010 ver el siguiente artículo:

Consultor IT especializado en Microsoft Exchange y Active Directory.
Principales Certificaciones: Microsoft Certified Trainer | Microsoft Certified Solutions Expert | Microsoft Certified Systems Engineer | Microsoft Certified Systems Administrator | Microsoft Certified IT Professional | Microsoft Certified Technology Specialist

4 Responses to Relay en Exchange 2013 / 2016

  1. buen articulo amigo pero tengo un problema no he podido cerrar el open relay de Exchange 2013 y me están atacando mucho spam como puedo solucionarlos gracias de ante mano te agradezco

    • Daniel Núñez Banega says:

      Hola Nelson, podes confirmar con telnet cual de los conectores es el que esta habilitando el relay?

  2. Emilio says:

    Buen dia, mi duda es esto se puede realizar en Exchange 2007 Ver. 08.03

    Saludos

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Registrarse