Mejora del flujo de correo con MTA-STS

Artículo
08/10/2024

Se agregó compatibilidad con el estándar SMTP MTA Strict Transport Security (MTA-STS) a Exchange Online. El estándar se desarrolló para garantizar que siempre se use TLS para las conexiones entre los servidores de correo electrónico. También proporciona una manera de enviar servidores para validar que el servidor receptor tenga un certificado de confianza. Si no se ofrece TLS o el certificado no es válido, el remitente se negará a enviar los mensajes. Estas nuevas comprobaciones mejoran la seguridad general de SMTP y protegen frente a los ataques de tipo "Man in the middle”.

MTA-STS se puede dividir en dos escenarios: protección entrante y saliente. La protección de entrada cubre la protección de los dominios hospedados en Exchange Online con MTA-STS. La protección saliente cubre las validaciones de MTA-STS realizadas por Exchange Online al enviar correos electrónicos a dominios protegidos por MTA-STS.

Sugerencia

Si no es cliente de E5, use la prueba de 90 días de soluciones de Microsoft Purview para explorar cómo las funcionalidades adicionales de Purview pueden ayudar a su organización a administrar las necesidades de cumplimiento y seguridad de los datos. Comience ahora en el centro de pruebas del portal de cumplimiento de Microsoft Purview. Obtenga más información sobre términos de suscripción y prueba.

Protección saliente

Todos los mensajes enviados salientes desde Exchange Online a destinatarios protegidos por MTA-STS se validan con estas comprobaciones de seguridad adicionales establecidas por el estándar MTA-STS. No hay nada que los administradores tengan que hacer para aplicarlo. Nuestra implementación saliente respeta los deseos de los propietarios del dominio del destinatario a través de su directiva MTA-STS. MTA-STS forma parte de la infraestructura de seguridad de Exchange Online y, por tanto, siempre está activada (como otras características principales de SMTP).

MTA-STS saliente puede impedir que se entreguen correos electrónicos en función de los resultados de la validación de MTA-STS en el dominio de destino. Si el dominio no es seguro y la directiva MTA-STS está establecida en Aplicar, se puede devolver un NDR al remitente con uno de los siguientes códigos de error:

Código de error	Descripción	Posible causa	Información adicional
5.4.8	Error de validación de MTA-STS en los hosts MX de '{domain}'	El host MX de destino no era el host esperado según la directiva STS del dominio.	Este error suele indicar un problema con la directiva MTA-STS del dominio de destino que no contiene el host MX. Para obtener más información sobre MTA-STS, vea https://datatracker.ietf.org/doc/html/rfc8461.
5.7.5	Error en la validación de MTA-STS del certificado remoto. Motivo: {validityStatus}	El certificado del servidor de correo de destino debe encadenarse a una entidad de certificación raíz de confianza y el nombre común o el nombre alternativo del firmante deben contener una entrada para el nombre de host en la directiva STS.	Este error suele indicar un problema con el certificado del servidor de correo de destino. Para obtener más información sobre MTA-STS, vea https://datatracker.ietf.org/doc/html/rfc8461.

Protección de entrada

Los propietarios de dominios pueden tomar medidas para proteger los correos electrónicos enviados a sus dominios con MTA-STS si su registro MX apunta a Exchange Online. Si el registro MX apunta a un servicio intermedio de terceros, deberá saber si cumplen los requisitos de MTA-STS y, a continuación, seguir sus instrucciones.

Una vez configurado MTA-STS para su dominio, todos los mensajes enviados desde remitentes que admitan MTA-STS realizarán las validaciones establecidas por el estándar para garantizar una conexión segura. Si recibe un correo electrónico de un remitente que no es compatible con MTA-STS, el correo electrónico se enviará de todas maneras, pero sin la protección adicional. Del mismo modo, no habrá ninguna interrupción en los mensajes si usted aún no está usando MTA-STS pero el remitente sí lo admite. El único escenario en el que los mensajes no se entregan es cuando ambos lados usan MTA-STS y la validación MTA-STS produce un error.

Adopción de MTA-STS

MTA-STS permite a un dominio declarar la compatibilidad con TLS y comunicar el registro MX y el certificado de destino esperados. También indica lo que debe hacer un servidor de envío si hay un problema. Esta comunicación se realiza a través de una combinación de un registro TXT de DNS y un archivo de directiva que se publica como una página web HTTPS. La directiva protegida con HTTPS introduce otra protección de seguridad que los atacantes deben superar.

El registro TXT MTA-STS de un dominio indica la compatibilidad con MTA-STS para un remitente, tras lo cual el remitente recupera la directiva MTA-STS basada en HTTPS del dominio. El registro TXT debe contener v=STSv1; hasta que se admita STSv2 y el identificador de la directiva. El identificador DEBE ser único para el propietario del dominio y la directiva, ya que un cambio en el identificador indica a los remitentes que necesitan volver a capturar la directiva. El identificador no tiene que ser único globalmente, no se preocupe por los identificadores de directiva de otros propietarios de dominio. Después de actualizar cualquier directiva MTA-STS, debe actualizar el identificador o los remitentes seguirán usando directivas almacenadas en caché para el dominio hasta que expire el max_age de la directiva almacenada en caché.

Un patrón repetible para establecer un identificador único es usar la hora UTC como tal:
id=<yyyymmddhh0000>Z;

El siguiente registro TXT es un ejemplo que declara compatibilidad con MTA-STS; el identificador se estableció a las 8 a. m. 1 de enero de 2022 hora UTC:

_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20220101080000Z;

La directiva MTA-STS de un dominio debe encontrarse en una dirección URL predefinida hospedada por la infraestructura web del dominio. La sintaxis de la dirección URL es https://mta-sts.<domain name>/.well-known/mta-sts.txt. Por ejemplo, la directiva de Microsoft.com se encuentra en: https://mta-sts.microsoft.com/.well-known/mta-sts.txt.

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Cualquier cliente cuyos registros MX apunten directamente a Exchange Online puede especificar en su propia directiva los mismos valores que se muestran en https://mta-sts.microsoft.com/.well-known/mta-sts.txt. La información única necesaria en la directiva es el registro MX que apunta a Exchange Online (*.mail.protection.outlook.com) y todos los clientes de Exchange Online comparten el mismo certificado. Exchange Online solo permite que una organización reciba correos electrónicos para un dominio determinado para que el uso de un carácter comodín no debilite la seguridad; sin embargo, puede que no sea el caso de otros servicios de correo electrónico. Es posible publicar la directiva en modo de prueba para asegurarse de que es válida antes de cambiarla a modo de aplicación . Hay herramientas de validación de terceros que pueden comprobar la configuración.

Estas directivas no son algo que Exchange Online pueda hospedar en nombre de los clientes; Por lo tanto, los clientes deben configurar la directiva STS de su dominio mediante los servicios que prefieran. Los servicios de Azure se pueden usar fácilmente para el hospedaje de directivas y hay un tutorial de configuración más adelante en este artículo. La directiva debe protegerse mediante HTTPS con un certificado para el subdominio mta-sts.<domain name>.

Una vez que se crea el registro TXT de DNS y el archivo de directiva está disponible en la dirección URL HTTPS necesaria, el dominio estará protegido por MTA-STS. Los detalles sobre MTA-STS están disponibles en RFC 8461.

Configuración de MTA-STS de entrada con Azure Services

Nota:

Estos flujos de configuración se desarrollaron para ayudar a los clientes de Microsoft Exchange Online a hospedar su directiva MTA-STS mediante recursos de Azure. Este flujo de configuración supone que es un cliente de Exchange Online que es consciente de cómo funciona MTA-STS y de sus requisitos. Para obtener más información sobre el protocolo más allá de este tema, consulte RFC8461.

Hay dos recursos de Azure que se pueden usar para hospedar la directiva MTA-STS: Azure Static Web App y Azure Functions. Aunque en este artículo se describe cómo implementar la directiva con ambos recursos, el método recomendado es Azure Static Web App , ya que está diseñado para hospedar páginas estáticas, como la directiva STS, y Azure simplifica la configuración proporcionando un certificado TLS para la página web MTA-STS de forma inmediata, sin necesidad de más configuración. Si no puede usar Azure Static Web App, también puede hospedar la directiva como código sin servidor mediante Azure Functions. Este enfoque no es el método preferido porque Azure Functions es una característica diseñada para otros escenarios y no emite un certificado TLS automáticamente, a diferencia de Azure Static Web Apps. Por lo tanto, el uso de Azure Functions para MTA-STS requiere que emita su propio "mta-sts. [su dominio]" y enlazarlo a la función.

Independientemente del enfoque que haya adoptado, le recomendamos que valide si la directiva se ha configurado correctamente y si el tiempo de respuesta es aceptable: el tiempo de espera por instrucciones RFC es de 60 segundos.

Estos flujos de configuración están diseñados para proporcionar solo información técnica sobre las características de Azure que se pueden usar para hospedar la directiva MTA-STS y no proporcionan información sobre los costos o los cargos de las características de Azure. Si quiere conocer los costos de las características de Azure, use la calculadora de precios de Azure.

Opción 1 (RECOMENDADO): Aplicación web estática de Azure

Cree una organización de Azure DevOps o use una organización que ya exista. En este ejemplo, se usará una organización denominada "ContosoCorporation" para hospedar la directiva MTA-STS.
En Archivos de repositorios>, clone el repositorio en cualquier IDE que prefiera. En este ejemplo, el repositorio se clonará en Visual Studio.
Una vez clonado el repositorio, cree la ruta de acceso de home\.well-known\la carpeta . A continuación, cree los siguientes archivos:
- Archivo 1: home.well-known\mta-sts.txt
  
  Nota:
  
  Esta configuración solo permite que Exchange Online reciba mensajes en nombre de su dominio. Si usa varios proveedores de correo electrónico, también debe hacer referencia a hosts MX para los dominios de esos otros proveedores. Los caracteres comodín o '*' no se deben usar como prefijo MX en todos los escenarios de MTA-STS; La configuración siguiente es específica solo para Exchange Online y NO debe usarse como guía general para configurar MTA-STS.
  1. Escriba el texto siguiente en el mta-sts.txt archivo:
```
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800
```
    Nota:
    
    Se recomienda establecer inicialmente el modo de directiva como prueba. A continuación, al final de la configuración y después de validar que la directiva funciona según lo esperado, actualice el mta-sts.txt archivo para que el modo se aplique.
    
    El archivo solo debe contener el contenido como se muestra en la captura de pantalla siguiente:
- Archivo 2: home\index.html
  1. Cree un index.html archivo e introduzca el código siguiente en él:
```
<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="UTF-8">
<title>MTA-STS</title>
</head>

<body>
<h1>MTA-STS Static Website index</h1>
</body>

</html>
```
    El archivo solo debe contener el contenido como se muestra en la captura de pantalla siguiente:
    
    Una vez creada la ruta de acceso de la carpeta y los archivos, no olvide confirmar los cambios e insertarlos en la rama principal.
Cree una nueva aplicación web estática de Azure con la siguiente configuración:
- Nombre: MTA-STS-StaticWebApp
- Tipo de plan: Estándar
- Detalles de la implementación: Azure DevOps
- Organización: ContosoCorporation
- Proyecto: MTA-STS_Project
- Repositorio: MTA-STS_Project
- Rama: master
- Valores preestablecidos de compilación: Angular
- Ubicación de la aplicación: /home
Una vez finalizada la creación de la aplicación web estática y aprovisionado el recurso, vaya a Información general > Administrar token de implementación y copie el token como se usará en el paso siguiente.
Vaya a Pipelines > Create Pipeline > Azure Repos Git > MTA-STS_Project y realice las siguientes subtareas:
1. Vaya a Variables > Nueva variable y escriba lo siguiente:
  1. Nombre: token
  2. Valor: (pegue el token que copió anteriormente, en el paso 5)
2. Una vez guardada la variable, vuelva a Revisar yaML de la canalización y pegue el siguiente yml, guárdelo y ejecútelo:
```
trigger:
- main

pool:
vmImage: ubuntu-latest

steps:
- checkout: self
submodules: true
- task: AzureStaticWebApp@0
inputs:
 app_location: '/home'
 azure_static_web_apps_api_token: $(token)
```
  En Azure DevOps, durante la implementación, si experimenta el error No se ha comprado o concedido ningún paralelismo hospedado, solicite a través de este formulario o implemente una configuración a través de la configuración de la > organización Trabajos paralelos Trabajos > paralelos hospedados > por Microsoft Change > Paid Parallel, de modo que se permitan "trabajos paralelos de pago".
Una vez que el trabajo finaliza correctamente, puede validar la implementación a través de Azure Portal. Para ello, vaya al Explorador de Azure Static Web App > Environment>. Debe ver el index.html contenido del archivo.
Agregue el dominio de vanidad en dominios > personalizados de Azure Static Web App > Agregar. Se le pedirá que cree un registro CNAME a través de su proveedor dns (por ejemplo, GoDaddy) para validar si la zona le pertenece. Una vez finalizada la validación, Azure emitirá un certificado y lo enlazará a la aplicación web estática automáticamente.
Valide si la directiva MTA-STS se publica a través de: https://mta-sts.[su dominio]/.bien conocido/mta-sts.txt.
Cree el registro DNS TXT de MTA-STS a través del proveedor dns. El formato es:
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Nota:

Puede encontrar un registro TXT MTA-STS de ejemplo en Cómo adoptar MTA-STS.
Una vez que el registro TXT esté disponible en DNS, valide la configuración de MTA-STS. Una vez validada correctamente la configuración, actualice el mta-sts.txt archivo para que se aplique el modo de directiva y, a continuación, actualice el identificador de directiva en el registro TXT.

Opción 2: Función de Azure

Cree una nueva aplicación de funciones de Azure con la siguiente configuración:
- Nombre de la aplicación de función: [Como prefiera]
- Publicar: Código
- Pila en tiempo de ejecución: .NET
- Versión: 6
- Sistema operativo: Windows
- Tipo de plan: [Como prefiera]
Agregue el dominio personalizado a function app. Tendrá que crear un registro CNAME para validar si el dominio le pertenece.
Enlace el "mta-sts. [su dominio]" a la aplicación de funciones.
En Archivo de aplicación, agregue la siguiente extensión a la host.json de function app para eliminar routePrefix. Esta adición es necesaria para quitar /api de la dirección URL de la función.
```
"extensions": {
  "http": {
    "routePrefix": ""
  }
}
```
En function app, vaya a Creación de funciones > y configure los parámetros siguientes:

Nota:

Aunque en este ejemplo se describe el desarrollo de funciones a través del portal, puede usar VS Code o cualquier otra herramienta que prefiera.
- Entorno de desarrollo: [Como prefiera; en este ejemplo se usará "Desarrollar en el portal"]
- Seleccionar una plantilla: desencadenador HTTP
- Nueva función: [Como elija]
- Nivel de autorización: Anónimo
Una vez creada la función, abra Código y prueba y desarrolle en C# una respuesta HTTP asincrónica sencilla que será la directiva MTA-STS. En el ejemplo siguiente se indica que se espera que Exchange Online reciba correos electrónicos:

Nota:

Se recomienda establecer inicialmente el modo de directiva como prueba. A continuación, al final de la configuración y después de validar que la directiva funciona según lo esperado, actualice el mta-sts.txt archivo para que el modo se aplique.
En Http de integración > (req), edite el desencadenador con los valores siguientes:
- Plantilla de ruta: .well-known/mta-sts.txt
- Métodos HTTP seleccionados: GET
Valide que la directiva MTA-STS se publica a través de: https://mta-sts.[su dominio]/.bien conocido/mta-sts.txt.
Cree el registro DNS TXT de MTA-STS a través del proveedor DNS en el formato siguiente:
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Nota:

Puede encontrar un registro TXT MTA-STS de ejemplo en Cómo adoptar MTA-STS.
Una vez que el registro TXT esté disponible en DNS, valide la configuración de MTA-STS. Una vez que la configuración se haya validado correctamente, actualice el mta-sts.txt archivo para que se aplique el modo de directiva y, a continuación, actualice el identificador de directiva en el registro TXT.