En esta entrada vamos a ver como configurar un conector para relay anónimo en Exchange 2010.
Por qué habilitar el relay anónimo en Exchange 2010?
Si bien lo ideal sería que toda aplicación o dispositivo que requiera enviar correo externo se autentique con el servidor, la realidad es que esto no es posible en todos los casos, por lo que a falta de una mejor alternativa, habilitar el relay smtp anónimo a una o más direcciones IP específicas puede ser el único camino.
Esto no sería globalmente un “open relay” donde se podría hacer spam utilizando nuestro servidor de correo ya que entre otras cosas estaríamos habilitando esta posibilidad a direcciones IP puntuales, en adición a que este conector no debería de ser accesible desde internet. De cualquier modo, se debe tener en cuenta que cualquier aplicación alojada en los equipos con las IP permitidas podrían enviar correo externo.
Dicho esto, la recomendación es que las aplicaciones o dispositivos que requieran enviar correo a través de Exchange se autentiquen con un usuario y contraseña, si esto no es posible podemos configurar un conector de recepción para que se haga relay a través de este hacia internet.
Cómo crear un conector de recepción para relay?
Lo primero que vamos a hacer es crear un conector SMTP de recepción dedicado a la función de relay. Para esto abrimos el shell de Exchange (EMS) y ejecutamos el siguiente comando:
New-ReceiveConnector –Name “AppRelayAnon” –Bindings 0.0.0.0:25 –RemoteIPRanges 192.168.1.245 –Server servidorExchange –Banner “220 Conector para relay anonimo” –PermissionGroups AnonymousUsers
En este punto tenemos un conector creado con las siguientes características:
-
Escucha en todas las direcciones IP del servidor en el puerto 25 (0.0.0.0 25)
-
Se habilita a que se conecte únicamente la IP 192.168.1.245 (RemoteIPRanges). Se puede especificar más de una dirección separando con comas, adicionalmente pueden editarlo por la EMC)
-
Como escucha en el puerto 25 al igual que el conector predeterminado, opcionalmente especificamos un “Banner” para simplificar un eventual proceso de troubleshooting.
-
Le damos permisos a usuarios anónimos (mientras vengan desde la IP especificada)
Para habilitar el relay hacia fuera de la organización (por ejemplo internet), faltaría dar permisos adicionales sobre el conector:
Get-ReceiveConnector AppRelayAnon | Add-ADPermission –User “NT AUTHORITY\ANONYMOUS LOGON” –ExtendedRights “MS-Exch-SMTP-Accept-Any-Recipient”
Cómo verificar que el relay este funcionando?
Para validar que este funcionando el relay vamos a utilizar el comando telnet especificando un destinatario externo, si el relay no esta habilitado deberíamos recibir un error “550 Unable to relay”, de lo contrario tendríamos que ver un “Recipient Ok”. Esto sería recomendable ejecutarlo 2 veces; 1 desde un equipo con una IP en la lista de direcciones permitidas y otra desde cualquier otro equipo para verificar que solo este aplicando a las IP específicas (si la IP no esta listada no podría conectarse al conector).
Para validar el funcionamiento con telnet seguir los pasos a continuación:
1. Abrir el CMD
2. Ejecutar Telnet hacia el servidor en el puerto del conector recientemente creado:
Telnet servidor 25
3. Ejecutamos el comando “helo”
helo
4. Especificamos el remitente con el comando “Mail From” (puede ser una dirección no existente, en este caso estoy usando la dirección de un usuario con buzón):
Mail From: apptest@nwtraders.msft
5. Especificamos un destinatario externo para validar el relay habilitado (en este caso también voy a especificar un destinatario interno para mostrar de que forma llega el correo):
Rcpt to: externo@test.com
6. Ejecutamos el comando Data e ingresamos un texto de prueba:
Data
7. Para finalizar la conexión y enviar el correo ingresamos “.” (punto sin comillas):.
Estos mismos pasos los podemos ejecutar sobre otros conectores, por ejemplo sobre el predeterminado, si no devuelve “550 Unable to relay” en principio podríamos decir que el relay esta “abierto”.
Luego de realizar la prueba recibimos el correo y como podrán ver en la imagen llega con la dirección de correo en lugar de con el nombre para mostrar (display name):
Si el requerimiento incluye que el correo llegue con el nombre para mostrar debemos crear el conector de otra manera, en este caso hay que tener en cuenta que en adición a eliminar varias restricciones, los equipos que se conecten a este nuevo conector pasarían por alto los filtros antispam.
Antes de proceder con la prueba voy a remover el conector anteriormente creado con el comando Remove-ReceiveConnector:
Remove-ReceiveConnector AppRelayAnon
Para crear el nuevo conector abrimos el EMS y ejecutamos el siguiente comando:
New-ReceiveConnector –Name “AppRelay” –Bindings 0.0.0.0:25 –RemoteIPRanges 192.168.1.245 –server servidorExchange –Banner “220 Conector para relay” – AuthMechanism Tls,ExternalAuthoritative –PermissionGroups ExchangeServers
La diferencia en este caso respecto al anterior es que modificamos el mecanismo de autenticación incluyendo “ExternalAuthoritative” y en permisos especificamos “ExchangeServers” en lugar de “AnonymousUsers”.
Ahora realizamos nuevamente la prueba de telnet:
El correo llega del siguiente modo:
Como se puede ver en la imagen ya no aparece la dirección de correo sino que el display name del usuario.
Por información sobre relay en Exchange 2013 pueden ver el siguiente artículo:
Hola Daniel.
Creo que llegué al lugar indicado para hacer una consutla de Exchage… 8)
Excelente blog!!!
En mi empresa tengo un exchange 2010 y la auditoría me marcó que se puede hacer relay interno.
El relay externo está deshabilitado.
Como hago para evitar el relay interno???
Muchas gracias por tu ayuda.
Saludos
Horacio
*Uruguay
Hola Horacio, cuando hablas de relay interno haces referencia a que usando telnet te podes conectar al conector de recepción y enviar mail a un usuario interno? Porque de ser así esto es de forma predeterminada.
Si este es el caso tendrías que modificar las IP desde las que acepta tráfico el conector (Remote IP ranges). En este caso tendrías que dejar unicamente las IP de servidores que se conectan directamente por SMTP (incluyendo smarthosts, aplicaciones, impresores, etc).
A tener en cuenta que si tenes clientes que utilicen POP/IMAP también requieren utilizar SMTP para enviar pero en ese caso convendría que usen el conector predeterminado que escucha en el puerto 587 y permite solo conexiones autenticadas.
saludos
Hola Daniel, una pregunta:
Como puedo hacer el relay pero que solo permita que se envie correo desde direcciones de mi domino, no que deje enviar direcciones de dominios externos. Ejemplo mi dominio es pepito.com y con esta configuracion le digo por telnet que mail from:pepito@gmail.com y rcpt to:pepito@gmail.com y me la acepta. No se si entiendes lo que te estoy preguntando.
Saludos
Hola Armando, por lo que comentas entiendo que el relay esta «abierto», lo estas restringiendo para alguna IP en particular? Si el relay esta abierto cualquier IP que se pueda conectar al conector básicamente puede enviar pasando cualquier información. En este caso abría que acotarlo a IP específicas.
saludos
Hola,
Tengo problemas con mi relay, no se como configurarlo exactamente, tengo lo siguiente:
correo internos todos envian correos normal a cualquier destino, y los usuarios que estan fuera de la organizacion cuando entran por el correo cliente, necesito que le pida autenticarse, porque , estoy viendo correos spam que me llegan con mi dominio.
Como deberia estar la configuracion de mis conectores para no tener este problema?
Hola Kenji, no me queda claro como se conectan tus usuarios. De cualquier modo que recibas SPAM con tu dominio no necesariamente tiene relación con el relay, lo más probable es que sea un problema de spoofing. Quizás no tengas un registro SPF configurado.
Te paso info introductoria sobre DNS incluyendo el registro SPF:
https://aprendiendoexchange.com/introduccion-a-dns-para-exchange
Y te recomiendo ver la consulta sobre spoofing de correos:
https://aprendiendoexchange.com/pr4-preguntas-respuestas-exchange
Hola. Excelente blog….
Queria realizarte una consulta.
Estamos migrando en mi empresa Exchange 2010 (On premises) a Office365
Una vez que esta migración finalice, eliminaremos todos los servidores de exchange y su organización. Tenemos la necesidad de tener un servidor que nos haga de relay SMTP para determinadas aplicaciones. Mi pregunta es la siguiente: ¿Existe la posibilidad de montar este servicio sin que esté integrado en la organización de exchange? Algo parecido al montar un servicio SMTP en IIS. Cosa a la que se niega mi empresa……. No se si existe la posibilidad de instalar un servidor unicamente con el rol de Edge y que realice esta función.
Ya se que Office 365 permite esto abriendo las conectividades por el puerto 25 desde esas aplicaciones contra las IPS publicad en Tenant. Pero tampoco quieren………… Muchisimas gracias por tu ayuda
Excelente trabajo!!!
Hola que buen blog..!
tengo una consulta. tenemos algunos servidores de aplicaciones que una de sus funciones es enviar notificaciones via mail, pere dichas notificaciones solo las recibo en mi dominio no se envian a dominios externos como gmail o hotmail, yo configuré un relay solo para este grupo de servidores ya que lo habia agregado a un relay existente y no se enviaban ni siquiera a mi propio dominio, atento a tu respueta! Saludos!
Bn Dia buen dato,, una consulta que limites de envio tiene este relay ? un mensaje puede ser enviados a mas de 10.000 destinatarios sin problema ? doden se ven este limite o donde se configura ?
Hola Ale, para específicar límites a nivel de conector podes usar el cmdlet Set-ReceiveConnector como se detalla en el artículo que te dejo más abajo, este cmdlet te permite también cambiar la cantidad de destinatarios, por fuera de esto hay otros límites a nivel de organización que podrían aplicar.
https://docs.microsoft.com/es-es/powershell/module/exchange/set-receiveconnector?view=exchange-ps