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:
-
Aplicaciones o dispositivos que envían correo a destinatarios internos
-
Aplicaciones o dispositivos que envían correo externo y tienen la posibilidad de autenticarse con Exchange
-
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):
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
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.
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
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”
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
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:
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
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:
La diferencia la encontramos cuando recibimos el correo:
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 más información sobre configuración de conectores y transporte de correo en Exchange, ver el siguiente recurso para miembros VIP del sitio (videos de entrenamiento):
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
Hola Nelson, podes confirmar con telnet cual de los conectores es el que esta habilitando el relay?
Buen dia, mi duda es esto se puede realizar en Exchange 2007 Ver. 08.03
Saludos
Hola Emilio, a qué parte te referís exactamente?
saludos
tengo este error cuando intento enviar correo a grupo dentro de la organizacion :
Your message can’t be delivered because delivery to this address is restricted.
For more information about this issue see DSN code 5.7.1 in Exchange Online.
sabes de que se trata
Hola Kayser, probablemente el grupo este configurado para requerir autenticación. Si envías correo desde un origen no autenticado podría dar ese error (por ejemplo desde un usuario externo o un aplicación que no se autentique). En definitiva una opción es desmarcar la opción de que requiera autenticación en las propiedades del grupo de distribución.
Hola consulta, que puede ser este problema.
Al enviar correos desde mi aplicación web me da un error cuando envía afuera de mi empresa
Mailbox unavailable. The server response was: 5.7.1 Unable to relay
Esta misma aplicación envía el mismo mail a usuarios internos, y si llega.
Cual puede ser el problema?
Hola Nicolás, de forma predeterminada podes conectarte al servidor y enviar correo a usuarios internos, lo que no podes hacer es relay (enviando correos externos) hasta no correr alguno de los procedimientos detallados en el artículo. Revisalo y contame.
Gracias Daniel.
Realice los procedimientos del escenario opción 1 y 2 y nada.
Tengo los receptores por defecto no se si esto influye en algo.
Cuando en el conector por defecto deshabilito la opción anonimo me da el siguiente error:
The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.1 Client was not authenticated
Hola Nicolás, validaste usando telnet que el relay quede efectivamente habilitado? Esto no tendrías que hacerlo en el conector predeterminado. Tendrías que configurar un conector dedicado.
Tengo un problema cuando quiero ejecutar la sentencia de Add-AdPermisision
Get-ReceiveConnector AppRelay | Add-ADPermission -User «NT AUTHORITY\ANONYMOUS LOGON» -ExtendedRights «MS-Exch-SMTP-Accept-Any-Recipient»
No se ha encontrado D250EX01\AppRelay. Compruebe que lo ha escrito correctamente.
+ CategoryInfo : NotSpecified: (:) [Add-ADPermission], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : [Server=D250EX01,RequestId=43555e5d-ab63-4bfe-a205-c3ebee1d867c,TimeStamp=21/07/2017 05:15:48 p.m.] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 6247976D,Microsoft.Exchange.Management.RecipientTasks.AddADPermission
+ PSComputerName : (mi url de correo)
Cualquier pista que me pudieras dar sobre el problema me sería de utilidad.
Desde ya muchas gracias
Hola Orlando, el tema es que no encuentra un conector con ese nombre. Verifica la propiedad «identity» del conector y sustitui «apprelay» por el valor que corresponda. Para ver rapidamente la propiedad identity podes ejecutar en el shell lo siguiente:
Get-ReceiveConnector | ft identity
Hola, me ha servido de mucho tu articulo, en mi caso estoy tratando de implementar el escenario 2, tengo un par de aplicaciones las cuales tiene la capacidad de recibir los parámetros de nombre de servidor(la ip de mi servidor), puerto(587), usuario(domain\user) y contraseña, pero aun definiendo estos parámetros recibo el error «530 5.7.1 client was not authenticated» al intentar enviar correos desde dichas aplicaciones, mi servidor es un Exchange 2013, según entiendo debería ser posible el envió de estos correos por el conector Client Fronted en este conector tengo desabilitado «Usuarios anonimos» y por seguridad no me gustaría habiilitarlo. Que estoy haciendo mal?
Hola German, sería conveniente habilitar el log de protocolo del conector de cliente, reproducir el problema y ver que información se registra. Estos logs en una instalación predeterminada quedan en:
C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive
hola amigo buenos dias, no se si puedas ayudarme, tengo el siguiente problema, yo envio mensajes desde mi exchange a correros externos de la empresa, en este caso gmail.com, lo que esta sucediendo es que se me encolan los correos, cuando veo las colas hay algunos mensajes que dicen lo siguiente «this message dont have authentication information or fails to pass».
Los corres salen y llegan pero se tardan mucho, tienes idea de que pudiera esta causando eso? en este caso yo tengo el enlace de salida con un proovedor de internet y para recibir uso otro proovedor, no se si tengra que ver con el registo mx.
Buenas tardes, en mi organizacion hay un Exchange 2016 en el que le llegan habitualmente correos desde direcciones internas que no son nuestros. Es decir estan usando nuestro servidor para el envio de spam entre otros. Para ello usan el puerto 25 del conector de recepcion y no usan autenticacion es decir son usuarios anonimos. Si deshabilito en el conector usuarios anomimos dejo de recibir mails desde fuera. Como se soluciona esto? Gracias.
Hola Daniel, en principio habría que validar si tienen un registro SPF correctamente configurado en la zona externa.
De no tenerlo sería el primero paso.
Respecto al conector de recepción publicado hacia Internet, si se desmarca el anónimo vas a dejar de recibir correos externos.
buen dia daniel, espero que este muy bien, aun en el 2024 sigo tu blog porque es un manual ANTIDESASTRE para mi, se que la pregunta es tonta, como configuro el rango de ip de una o varias o rango en EJEMPLO RemoteIPRanges 192.168.1.170 muchas gracias