如果电子邮件消息未通过 MTA-STS 检查，则不得投递；寄件人会收到送货失败的通知吗？什么时候？
When an e-mail message fails MTA-STS checks, it must not be delivered; will the sender be informed about the delivery failure? When?
短：
如果要发送的电子邮件未通过 MTA-STS 检查，则不得按设计进行投递； 发件人 会被告知投递失败吗？什么时候？
长&背景信息：
在自定义域上实施 mta-sts 以强制使用 TLS 连接时，mta-sts.txt 策略文件（或不支持 TLS 连接的 smtp 服务器）的错误配置将导致电子邮件未作为强制策略传送将需要 TLS 连接来传送电子邮件。
通过 TLS 报告，域持有者（而不是发件人）可以被告知任何问题，前提是 TLS 报告设置为不同的域或工具，该工具在与相关域不同的地址上进行通知。
我的问题是关于电子邮件的任何发件人。 在一个包含策略文件的测试用例中提到不正确的 mx 记录，没有电子邮件被发送（如预期的那样），但是测试发件人尚未收到任何有关递送问题的消息。
这是预期的行为吗？还是会在几个小时后通知发件人？如果是这样，几个小时？ - 我问是因为交付失败和 NDR（未交付报告）通常会立即返回。
如果用户拼错了电子邮件地址或接收服务器已关闭，发件人会收到有关问题的通知并可以采取措施。有时甚至会宣布“交货延迟”；还没有失败，但也没有交付。
我的印象是发件人没有被告知邮件未送达，而是“默默地黑洞/丢弃”。需要明确的是：未传递消息是此测试用例中的预期行为。
在运行一些测试用例之后，我经历了以下情况：
（这是由 Outlook.com smtp 服务器完成的。）
测试用例 C
- MTA-STS：故意不正确，但 mta-sts 文件中存在第三方 mx 服务器。
- DNS：正确的 mx 服务器。
24 小时后通知发件人投递失败。
有人用我的当地语言解释了发生的事情；此处信息亮点：
- 邮件未能送达。
- 已尝试多次交付。
- 但原因是无法连接到远程服务器。
- 建议 phone 联系收件人，要求收件人将错误通知邮政局长。
- 甚至有人建议这个问题很可能只能由邮政局长解决。
- （提供了 link，但这并没有多大帮助。此外，技术退回消息中还可以看到技术用语“MTA-STS 验证失败”）。
测试用例 B
- MTA-STS：mta-sts 文件中的正确和所需的 mx。
- DNS：故意设置为不正确的 mx 服务器，但现有服务器。
24 小时后，我收到错误回复。令人困惑的是，该地址在目标域中不存在。虽然这是事实，但不应该走到这一步。但是，在查看技术部分时，outlook 发送服务器提到 'failed mta-sts errors validation'。因此技术部分包含正确的 mta-sts 验证错误，但 human/user 可读部分仅提到目标地址在目标服务器中不存在。
我想如果地址不存在，任何 mta-sts 错误都“不太重要”，无法报告给最终用户。建议用户重新键入并重新发送电子邮件，并验证是否提到了收件人的地址（phone）。
但是，即使用户按照说明进行操作，下一封电子邮件也不会送达，但这超出了这个测试用例的范围。
测试用例 A
- MTA-STS：更正 mta-sts 文件中的 mx。
- DNS：假 MX 更正。
24 小时后，我收到错误回复。无法传递邮件的原因是无法解析收件人的域位置。 （不希望的结果，但合乎逻辑，mx 没有指代任何东西。）
消息的技术部分提到 'DNS query failed'。没有提到任何 mta-sts。
测试用例 Z（奇怪的一个）
- MTA-STS：更正 mta-sts 文件中的 mx。
- DNS：不正确但存在的 mx 记录；引用正确 mx 服务器的相同 IP 的 cname（这无关紧要，因为 mta-sts 应该将 cert 与 cname 进行比较。）
结果，出乎意料：
- 一封电子邮件在 24 时间之间的某处发送 -window。
- 由于 mta-sts 验证错误，一封电子邮件失败。
网络服务器的临时停机可能是一个因素，但这应该无关紧要。 - 无法解释。
结论
如您所见，我花了一些时间才找到正确的测试用例。但是测试用例 C 描述了所需的行为。 是的，24 小时后发件人会收到通知，outlook.com 作为 smtp 服务器。 用户会收到清晰的通知。话虽如此，我对这里的时间安排还有其他意见，如下所述。
限制
坚持事实：我没有使用尝试未加密连接的服务器执行测试用例。测试用例 C 将球放入接收者的邮政局长的法庭，我很想知道在未加密尝试的情况下，球（'todo'）将被放置在哪里，因为接收者无法解决但必须由发件人或发件人的邮局解决。
我也没有测试多个smtp服务器。
进一步思考
也就是说，发件人 SMTP 需要支持 MTA-STS 验证（如果我错了，请在评论中纠正我*），因此如果服务器太旧，它会尝试通过以下方式发送电子邮件非加密连接，它很可能不支持 MTA-STS，因此它不会验证 MTA-STS 策略并简单地发送未受保护的电子邮件。 * 在此处找到确认，来自段落 "There is a standard...")
如果有人试图通过 dns 中毒重定向一些传入的电子邮件，现代的 smtp 服务器将不会将电子邮件传送到错误的目的地。
所以它防止作恶，而不是防止遗留。
意见
我觉得24小时的反馈延迟太长了。测试用例 C 在 24 小时内报告了 11 次重试 window。虽然我很欣赏系统没有放弃，但我认为，至少通知他非正常投递可能符合发件人的利益。
短：
如果要发送的电子邮件未通过 MTA-STS 检查，则不得按设计进行投递； 发件人 会被告知投递失败吗？什么时候？
长&背景信息：
在自定义域上实施 mta-sts 以强制使用 TLS 连接时，mta-sts.txt 策略文件（或不支持 TLS 连接的 smtp 服务器）的错误配置将导致电子邮件未作为强制策略传送将需要 TLS 连接来传送电子邮件。
通过 TLS 报告，域持有者（而不是发件人）可以被告知任何问题，前提是 TLS 报告设置为不同的域或工具，该工具在与相关域不同的地址上进行通知。
我的问题是关于电子邮件的任何发件人。 在一个包含策略文件的测试用例中提到不正确的 mx 记录，没有电子邮件被发送（如预期的那样），但是测试发件人尚未收到任何有关递送问题的消息。
这是预期的行为吗？还是会在几个小时后通知发件人？如果是这样，几个小时？ - 我问是因为交付失败和 NDR（未交付报告）通常会立即返回。
如果用户拼错了电子邮件地址或接收服务器已关闭，发件人会收到有关问题的通知并可以采取措施。有时甚至会宣布“交货延迟”；还没有失败，但也没有交付。
我的印象是发件人没有被告知邮件未送达，而是“默默地黑洞/丢弃”。需要明确的是：未传递消息是此测试用例中的预期行为。
在运行一些测试用例之后，我经历了以下情况：
（这是由 Outlook.com smtp 服务器完成的。）
测试用例 C
- MTA-STS：故意不正确，但 mta-sts 文件中存在第三方 mx 服务器。
- DNS：正确的 mx 服务器。
24 小时后通知发件人投递失败。
有人用我的当地语言解释了发生的事情；此处信息亮点：
- 邮件未能送达。
- 已尝试多次交付。
- 但原因是无法连接到远程服务器。
- 建议 phone 联系收件人，要求收件人将错误通知邮政局长。
- 甚至有人建议这个问题很可能只能由邮政局长解决。
- （提供了 link，但这并没有多大帮助。此外，技术退回消息中还可以看到技术用语“MTA-STS 验证失败”）。
测试用例 B
- MTA-STS：mta-sts 文件中的正确和所需的 mx。
- DNS：故意设置为不正确的 mx 服务器，但现有服务器。
24 小时后，我收到错误回复。令人困惑的是，该地址在目标域中不存在。虽然这是事实，但不应该走到这一步。但是，在查看技术部分时，outlook 发送服务器提到 'failed mta-sts errors validation'。因此技术部分包含正确的 mta-sts 验证错误，但 human/user 可读部分仅提到目标地址在目标服务器中不存在。
我想如果地址不存在，任何 mta-sts 错误都“不太重要”，无法报告给最终用户。建议用户重新键入并重新发送电子邮件，并验证是否提到了收件人的地址（phone）。 但是，即使用户按照说明进行操作，下一封电子邮件也不会送达，但这超出了这个测试用例的范围。
测试用例 A
- MTA-STS：更正 mta-sts 文件中的 mx。
- DNS：假 MX 更正。
24 小时后，我收到错误回复。无法传递邮件的原因是无法解析收件人的域位置。 （不希望的结果，但合乎逻辑，mx 没有指代任何东西。）
消息的技术部分提到 'DNS query failed'。没有提到任何 mta-sts。
测试用例 Z（奇怪的一个）
- MTA-STS：更正 mta-sts 文件中的 mx。
- DNS：不正确但存在的 mx 记录；引用正确 mx 服务器的相同 IP 的 cname（这无关紧要，因为 mta-sts 应该将 cert 与 cname 进行比较。）
结果，出乎意料：
- 一封电子邮件在 24 时间之间的某处发送 -window。
- 由于 mta-sts 验证错误，一封电子邮件失败。
网络服务器的临时停机可能是一个因素，但这应该无关紧要。 - 无法解释。
结论
如您所见，我花了一些时间才找到正确的测试用例。但是测试用例 C 描述了所需的行为。 是的，24 小时后发件人会收到通知，outlook.com 作为 smtp 服务器。 用户会收到清晰的通知。话虽如此，我对这里的时间安排还有其他意见，如下所述。
限制
坚持事实：我没有使用尝试未加密连接的服务器执行测试用例。测试用例 C 将球放入接收者的邮政局长的法庭，我很想知道在未加密尝试的情况下，球（'todo'）将被放置在哪里，因为接收者无法解决但必须由发件人或发件人的邮局解决。
我也没有测试多个smtp服务器。
进一步思考
也就是说，发件人 SMTP 需要支持 MTA-STS 验证（如果我错了，请在评论中纠正我*），因此如果服务器太旧，它会尝试通过以下方式发送电子邮件非加密连接，它很可能不支持 MTA-STS，因此它不会验证 MTA-STS 策略并简单地发送未受保护的电子邮件。 * 在此处找到确认，来自段落 "There is a standard...")
如果有人试图通过 dns 中毒重定向一些传入的电子邮件，现代的 smtp 服务器将不会将电子邮件传送到错误的目的地。 所以它防止作恶，而不是防止遗留。
意见
我觉得24小时的反馈延迟太长了。测试用例 C 在 24 小时内报告了 11 次重试 window。虽然我很欣赏系统没有放弃，但我认为，至少通知他非正常投递可能符合发件人的利益。