[ 地区要求 ]

衡量MTA-STS采用率和策略主机可用性

使用可重现的数据集和错误统计分别测量MTA-STS发现、策略有效性和 HTTPS 可用性。

由EmailAuth研究团队提供 · 8 分钟阅读

[ 要点 ]

  • 在计算域之前定义采用类别。
  • 保留DNS发现、HTTPS 检索和MX兼容性作为单独的证据。
  • 探测中断不会建立每个发送方的缓存策略行为。
在此页面上

将采用率和可用性定义为单独的衡量标准

MTA-STS 采用可以指DNS发现、语法上有效的策略检索、强制模式的发布或观察到的与域接收MX路由的兼容性。策略主机可用性是另一个属性:它涉及 HTTPS 端点在观察时是否可访问且有效。研究应该单独定义这些措施,而不是将一次成功的获取视为完整的传输安全采用。

RFC 8461 定义MTA-STS发现、策略检索、验证和缓存。它支持可重复的测量设计,而不是数据集存在的断言。本文不包含域扫描、可用性百分比、连接测试或纵向调查结果。所有示例均明确为假设。

建立接收域人口

MTA-STS涉及接收域的邮件路由。网站、出站发件人品牌或客户组织的列表不会自动成为适当的接收域列表。收集前明确单位、选择方法和排除情况。记录示例是否包含没有可用邮件路由的域以及这些情况如何影响每个指标,而不是默默地删除它们。

冻结输入列表并保留其来源、日期、规范化规则和哈希值。如果列表在运行之间发生变化,请保留成员资格历史记录。进入或离开样本的域可以改变明显的采用情况,而无需对其策略进行任何更改。除非抽样设计支持该推论,否则不要将便利样本称为全局估计。本手稿没有提供这样的估计。

将DNS发现与 HTTPS 检索分开

RFC 8461定义了_mta-sts所有者处的发现记录以及 mta-sts 主机下众所周知路径的策略检索位置。发现标识符表明策略发生变化;它不是证书指纹或端点当前工作的证明。记录DNS答案、所有者、解析器和时间,与后续 HTTPS 观察无关。

该标准要求 HTTP 200 OK 进行策略检索,并规定发件人不得在该检索过程中遵循 HTTP 重定向。它还表示发送者不得使用 HTTP 缓存进行策略检索,这与MTA-STS策略缓存不同。该方法应该保留响应状态和重定向行为,而不是接受任何看起来成功的浏览器目标。在此工作期间未获取端点或遵循重定向。

根据规定的规则验证策略和连接

该策略包含RFC 8461语法下的版本、模式、 MX模式和最大期限。保留实际字节和解析器版本。使用测试模式的策略与强制模式不是同一测量类别。无策略是另一种应该被命名而不是归入通用采用计数的状态。使用标准的要求强度报告内容类型处理:发送者应该验证文本/纯文本,而不是发明一个通用的更强的要求。

HTTPS 证书验证是一个单独的观察。记录请求的主机名、端点、时间和实际验证结果。网络故障、证书故障、意外状态和格式错误的策略具有不同的含义,应在错误日志中单独保留。不要仅仅因为一个观察位置无法到达某项策略而推断该策略不存在,也不要忽略连接错误以产生更大的采用分子。

将策略模式与预期MX路由进行比较

语法上有效的策略仍然可以描述错误的接收主机。 RFC 8461定义了MX主机名和通配符模式的精确匹配。通配符并不是名称中任意位置的不受限制的通配符。该方法必须实现标准定义的语法和匹配。保留测量范围内每个主机的MX观测值和匹配决策。

单独的 HTTPS 获取并不能确定每个MX端点都提供与策略匹配的有效TLS服务。如果研究未执行授权的SMTP观察,请说明未测量路由兼容性。如果稍后的测试获得批准,请将其连接证据和人口与策略主机可用性分开。不要仅通过DNS和 HTTP 来实现端到端执行。

考虑缓存的策略行为

发件人可以在协议规定的最长期限内保留MTA-STS策略。因此,临时策略主机中断对具有可用缓存策略的发件人的影响可能与首次发现域的发件人的影响不同。外部测量探针通常不知道每个发送器的缓存状态。该研究不得将端点停机时间直接转化为普遍的未受保护邮件时期。

类似地,发现标识符和观察到的策略版本需要临时记录。如果策略在收集过程中发生变化,请保留序列,而不是在没有解释的情况下将旧的DNS观察结果加入到新的主体中。重复测量应记录探针状态和任何有意的缓存处理。该方法必须将其测量行为与完整发送区分开来 MTA 执行。

收集前设计可用性时间表

提前定义探测位置、节奏、超时、重试策略和分类规则。失败一次并重试成功的端点不应从错误记录中消失。使用明确的分母报告尝试的观察、成功的观察和失败类别。如果排除维护时段或无法到达的有利点,请保留原因并说明排除如何改变结果。

本文并未普遍强加节奏或服务水平目标。选择适合研究问题和授权的时间表,避免负担过重。记录工具版本和依赖项,以便其他分析师可以重现该方法。实际可用性结论需要收集数据;拟议的时间表并不能证明服务达到或未达到任何目标。

版本化数据集工作表

创建示例版本、接收域、观察时间、 DNS发现结果、策略标识符、HTTPS 端点、状态、证书结果、内容类型的字段, 正文哈希、解析模式、 MX模式和最大年龄。添加MX观察参考、匹配结果、错误类别、重试历史记录和排除原因。将原始证据与标准化分类分开保存。

RFC 8460 定义了SMTP TLS报告,当合法可用时可以提供另一个视角。此类报告并不等同于外部可用性探测,并且不会自动覆盖每个发送者。如果包含,请分别记录其来源和范围。该草案既没有收集调查,也没有收集报告,并不意味着它们之间存在确切的相关性。

虚构诊断:端点中断成为强制执行声明

一项虚构的研究观察到一次失败的 HTTPS 检索,并将接收域标记为一整天没有MTA-STS保护。拟议的审查确定了缺失的证据:观察覆盖了一个时间和有利位置,并且发件人可能缓存了策略。正确的结论范围较窄,描述了失败的检索及其在测量计划内的错误类别。

该团队将保留后续观察结果并报告分母,而不是消除故障或将其推断为通用邮件行为。这是一个虚构的方法示例,而不是观察到的中断或有关命名域的声明。未执行网络探测或电子邮件传送测试。

仅发布可重复的结果

该目录需要其他分析师可以重现的版本化数据集、查询方法和错误/排除日志。这些原始文物仍然开放。人类专家审查、来源适用性、生产路线、可访问性和所有者发布也保持开放。该草案提供了研究设计和虚构的诊断,而不是采用计数、可用性结果或端到端传输安全评估。

[ 外卖 ]

在其时间表和范围内报告政策东道国的观察结果,而不将其转化为普遍的运输保护主张。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

测量工程师

实现定义的检索

浏览器的成功可以隐藏重定向或缓存差异。

后续步骤

  1. 需要记录的 HTTP 结果。
  2. 保留失败和主体哈希值。

邮件安全分析师

单独的路线准备

策略语法并不能证明每个MX端点都有效。

后续步骤

  1. 保留MX匹配范围。
  2. 区分外部探测器和发送者缓存。

研究评审员

审核分母

排除和重试可能会改变明显的可用性结果。

后续步骤

  1. 版本人口和方法。
  2. 保留错误和排除日志。

[ 常见问题解答 ]

常见问题

什么算作MTA-STS采用?

研究必须定义它是否意味着发现、有效策略、执行模式或路由兼容性;这些是不同的属性。

RFC 8461 : SMTP MTA 严格传输安全

任何 HTTP 成功状态都足够吗?

不可以。RFC RFC 8461需要 HTTP 200 OK 才能进行策略检索。

RFC 8461 : SMTP MTA 严格传输安全

定义的检索可以遵循重定向吗?

不可以。该标准规定发件人不得遵循 HTTP 重定向进行策略检索。

RFC 8461 : SMTP MTA 严格传输安全

HTTP 缓存与MTA-STS策略缓存相同吗?

不可以。该标准禁止使用 HTTP 缓存进行检索,同时单独定义保留的策略行为。

RFC 8461 : SMTP MTA 严格传输安全

text/plain 是否具有通用的 MUST 验证强度?

RFC 规定发送者应该验证媒体类型。在方法中保留该要求强度。

RFC 8461 : SMTP MTA 严格传输安全

一次失败的提取是否证明所有邮件都不受保护?

不会。观察是有范围的,发送者可以使用自己的状态缓存策略。

RFC 8461 : SMTP MTA 严格传输安全

TLS报告会取代外部探测器吗?

不会。RFC RFC 8460报告是一个不同的观察源,具有自己的覆盖范围和语义。

RFC 8460 : SMTP TLS报告

是否衡量了采用率或可用性结果?

不会。版本化数据集、查询方法和错误/排除日志保持打开状态。

[ 来源 ]

来源

  1. RFC 8461 : SMTP MTA 严格传输安全

    部分 §3.1 MTA-STS TXT记录 · §3.2 MTA-STS策略 · §3.3 HTTPS 策略获取 · §4.1 MX主机验证 · §5 策略应用 · §8.1 策略更新

  2. RFC 8460 : SMTP TLS报告

    部分 §3 报告政策 · §4 报告架构 · §5 报告交付

[ 词汇表 ]

词汇表

策略主机可用性
在声明的时间表下观察到的 HTTPS 策略端点的可达性和有效性。
发现标识符
用于表示策略更改的MTA-STS DNS标识符,而不是证书指纹。

RFC 8461 : SMTP MTA 严格传输安全

策略缓存
发送方保留的MTA-STS策略状态由协议管理。

RFC 8461 : SMTP MTA 严格传输安全

错误/排除日志
保留对失败观察和遗漏案例的核算并注明原因。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库