[ 运输安全 ]
TLS-RPT报告目的地和报告传送
定义经批准的 mailto 或 HTTPS 收集路径、报告完整性、计时和处理责任，而不假设保证重复交付。
由EmailAuth研究团队提供 · 8 分钟阅读
[ 要点 ]
- TLS-RPT收集和传输强制是独立的依赖关系。
- 多个 rua 目标不保证每个端点都有副本。
- 验证接收、完整性、解析和归属作为不同的阶段。
[ 外卖 ]
将报告目标视为具有批准的数据共享和可观察的交付到处理阶段的自有服务合同。
[ 按角色 ]
这对您意味着什么
选择您的角色以执行后续实际步骤。
IT/邮件管理员
通过采集追踪报告
端点接受与成功解析不同。
后续步骤
- 验证准确的报告记录和支持的 URI。
- 通过摄取保留报告标识符。
- 分别检查压缩、完整性和归属。
CISO / SecOps
批准并保护举报渠道
报告携带操作元数据和不受信任的内容。
后续步骤
- 批准第三方收件人和保留。
- 保留所需的SMTP报告签名检查。
- 避免假设报告传输始终加密。
创始人/非技术人员
分配收集责任
发布目的地并不会让某人对失败的情况负责。
后续步骤
- 列出收集者和事件所有者的名称。
- 定义存档和仪表板关系。
- 设定切合实际的参与和时间预期。
[ 常见问题解答 ]
常见问题
如果发布两个有效的TLS-RPT策略记录会发生什么？
丢弃不以文字前缀“ v=TLSRPTv1; ”开头的TXT资源记录后，发送者必须准确找到一条剩余记录。如果发现零个或多个 1， RFC 8460要求其假定TLS-RPT未实现。记录边界很重要：一个TXT记录中的多个字符串本身并不意味着多个策略记录。
[ 来源 ]
来源
- RFC 8460
部分 §3。报告政策 · §4.1 报告时间范围 · §4.3 结果类型 · §5.2 压缩 · §5.3 电子邮件传输 · §5.4 HTTPS 传输 · §5.5 传送重试 · §5.6 元数据差异 · §7.安全考虑
[ 词汇表 ]
词汇表
- 收藏家合同
- 拟议的协议涵盖目的地所有权、数据处理和处理证据。
企业出处
为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。
传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中，手动监督意味着延迟执行、配置漂移和不受监控的影子域。
EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject，保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准，以及人机交互审核能力。
政府 大型企业 一级金融机构
SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密