[ Seguridad en el transporte ]
Destinos de informes TLS-RPT y entrega de informes
Defina rutas de recopilación de correo electrónico o HTTPS aprobadas, integridad de informes, tiempos y responsabilidades de procesamiento sin asumir una entrega duplicada garantizada.
Por el equipo de investigación EmailAuth · 8 minutos de lectura
[Puntos clave]
- La recopilación y el transporte TLS-RPT son dependencias independientes.
- Múltiples destinos rua no garantizan una copia en cada punto final.
- Verificar recepción, integridad, análisis y atribución como etapas distintas.
[ Llevar ]
Trate el destino de los informes como un contrato de servicio propio con intercambio de datos aprobado y etapas observables desde la entrega hasta el procesamiento.
[ Por rol ]
¿Qué significa esto para ti?
Elija su función para conocer los próximos pasos prácticos.
Administrador de TI/correo
Rastree el informe a través de la recopilación
La aceptación del punto final no es lo mismo que un análisis exitoso.
Próximos pasos
- Verifique el registro de informes exacto y los URI admitidos.
- Conserve los identificadores de informes mediante la ingesta.
- Verifique la compresión, la integridad y la atribución por separado.
CISO / Operaciones de seguridad
Aprobar y proteger el canal de denuncias
Los informes contienen metadatos operativos y contenido que no es de confianza.
Próximos pasos
- Aprobar destinatarios y retención de terceros.
- Conservar las comprobaciones de firma de informes SMTP requeridas.
- Evite asumir que el transporte de informes siempre está cifrado.
Fundador / No técnico
Asignar responsabilidad de cobranza
Publicar un destino no responsabiliza a nadie de actuar ante los fallos.
Próximos pasos
- Nombre el cobrador y el propietario del incidente.
- Defina la relación entre archivo y panel.
- Establezca expectativas realistas de participación y tiempo.
[ Preguntas frecuentes ]
Preguntas frecuentes
¿Dónde se publica el registro TLS-RPT ?
En _smtp._tls bajo el dominio de políticas, usando TXT con versión TLSRPTv1 y destinos rua. Esto es independiente del archivo de política MTA-STS .
¿Qué esquemas de destino admite RFC 8460 ?
Los esquemas admitidos son mailto y https. Los informes HTTPS utilizan POST; Los informes mailto utilizan la ruta de entrega del buzón especificada.
¿Un destino externo requiere un registro de autorización estilo DMARC?
RFC 8460 no define ese protocolo de enlace DNS estilo DMARC. Confirmar la aprobación de la organización y cualquier incorporación específica del recopilador por separado; No inventes un registro de protocolo.
¿Recibirán cada informe dos rua URI cada uno?
No necesariamente. Un periodista puede intentar varios destinos admitidos o elegir uno. La aceptación exitosa en un punto final puede satisfacer la entrega.
¿Qué verificación de integridad se aplica a los informes SMTP ?
Requieren una firma DKIM de dominio de informes válida sin l=. La clave debe declarar s=tlsrpt; un receptor puede ignorar los informes que carecen de esa declaración de servicio.
¿La confirmación HTTPS demuestra que el procesamiento se realizó correctamente?
No. Una respuesta exitosa acusa recibo de la entrega y el cobrador puede procesarla más tarde. Realice un seguimiento de los resultados de la cola, el analizador y la atribución por separado.
¿Están garantizados los informes diarios?
No. Se recomienda un intervalo de días UTC completo y una entrega retrasada, pero los informes son opcionales y no se sigue una promesa de recepción diaria universal.
¿Qué sucede si se publican dos registros de políticas TLS-RPT válidos?
Después de descartar registros de recursos TXT que no comienzan con el prefijo literal " v=TLSRPTv1; ", el remitente debe encontrar exactamente un registro restante. Si encuentra cero o más de uno, RFC 8460 requiere que asuma que TLS-RPT no está implementado. Los límites de los registros son importantes: varias cadenas dentro de un registro TXT no significan por sí solas múltiples registros de políticas.
[ Fuentes ]
Fuentes
- RFC 8460
Secciones §3. Política de informes · §4.1 Plazo del informe · §4.3 Tipos de resultados · §5.2 Compresión · §5.3 Transporte de correo electrónico · §5.4 Transporte HTTPS · §5.5 Reintento de entrega · §5.6 Variaciones de metadatos · §7. Consideraciones de seguridad
[ Glosario ]
Glosario
- Aceptación del informe
- Acuse de recibo exitoso del destino, distinto del procesamiento posterior.
- Identificador de informe
- Metadatos utilizados para identificar un informe y ayudar a detectar envíos duplicados.
- Contrato de coleccionista
- El acuerdo propuesto cubre la propiedad del destino, el manejo de datos y el procesamiento de pruebas.
Procedencia de la empresa
Por qué las principales instituciones financieras y gobiernos retiraron sus paneles de seguridad de correo electrónico.
Las plataformas tradicionales de autenticación de correo electrónico le venden un panel y piden a sus ingenieros que hagan el trabajo. En entornos de alto riesgo, la supervisión manual significa retrasos en la aplicación, cambios en la configuración y dominios en la sombra no monitoreados.
EmailAuth es la plataforma de procedencia de correo electrónico agente. Nuestros agentes hacen cumplir p=reject, mantenga alineados a los remitentes externos y mueva sus dominios al máximo RFC 9989 cumplimiento, el nuevo estándar DMARC , con auditabilidad humana.
SaaS · Arrendamiento dedicado · Air-gapped on-premise · Cifrado BYOK