Office 365 环境中的 SMTP 中继 |故障排除场景 |第 4 部分#4

当前文章的主题是 - 解决使用 SMTP 邮件中继服务器向 Office 365 邮件基础结构发送邮件时可能出现的问题。

向 Exchange Online 发送邮件 - 文章系列

• 向 Exchange Online 发送邮件 |第 1#4 部分
• 使用标准 SMTP 会话将邮件发送到 Exchange Online |第 2 部分#4
• Office 365 环境中的 SMTP 中继 |第 3 部分#4
• Office 365 环境中的 SMTP 中继 |故障排除场景 |第 4 部分#4

在上一篇文章中，我们回顾了如何在基于 Office 365 的环境中将 IIS SMTP 服务器配置为邮件中继的概念。

在 Office 365 环境中使用 SMTP 邮件中继选项时，邮件流可以被视为复杂，因为此过程中涉及多个元素，并且每个元素都有特定的特征或特定的配置设置。

在我们遇到问题的情况下，源邮件客户端（硬件设备、邮件应用程序等）发送的邮件无法到达目的地（Office 365 收件人或其他外部收件人），指出问题的确切原因并不是那么简单。

例如，传真设备需要向 Office 365 收件人发送电子邮件的场景涉及以下步骤：

1. 传真设备连接 IIS SMTP 邮件中继服务器（在我们的场景中为 IIS 服务器）。
   2． SMTP 邮件中继服务器愿意接受来自邮件客户端（我们场景中的传真设备）的请求。
2. SMTP 邮件中继服务器连接“目标邮件服务器”（我们场景中的 EOP 邮件服务器）。
3. “目标邮件服务器”愿意接受来自 SMTP 邮件中继服务器的请求。
4. “目标邮件服务器”（EOP）将电子邮件消息发送到目标收件人。

实际上，邮件流还包括我们没有提到的其他步骤，例如执行 DNS 解析过程等。

由于这种复杂性，我们需要熟悉邮件流中涉及的不同组件，以及在邮件流未成功完成的情况下可以使用哪些故障排除步骤、故障排除工具和方法。

模拟邮件流|内部邮件客户端通过 IIS SMTP 邮件中继服务器发送的邮件

当我们完成所有必需的配置后，最佳实践是实施一些“POC”（概念验证）测试；这将使我们能够验证邮件流是否正确实施，这意味着电子邮件成功到达目标收件人邮箱。

为了能够在使用 SMTP 邮件中继时测试和验证邮件流，我们将模拟组织邮件客户端尝试向 Office 365 邮件收件人发送电子邮件的邮件流。

我们要检查和验证的“参数”是：

• 邮件客户端联系 IIS SMTP 邮件中继服务器的能力以及 IIS SMTP 邮件中继服务器与 Office 365 邮件服务器通信的能力。
• IIS SMTP 邮件中继服务器代表不同邮件客户端发送电子邮件的能力。正如文章中提到的——Office 365环境中的SMTP中继|第 3#4 部分，在 IIS SMTP 邮件中继服务器接受来自不同邮件客户端的要求并需要将电子邮件“转发”到 Office 365 邮件服务器的情况下，IIS SMTP 使用的用户帐户邮件中继服务器需要对每个发送给他的“邮件客户端”具有发送为权限。

为了验证这些参数，我们将使用两种不同的测试。

测试 1 - 一个简单的测试，我们模拟邮件客户端，该客户端使用与 IIS SMTP 邮件中继服务器所使用的用户凭据相同的电子邮件地址。

测试 2 - 模拟邮件客户端，该客户端使用与 IIS SMTP 邮件中继服务器所使用的用户凭据不同的电子邮件地址。在本例中，我们要验证是否为 IIS SMTP 邮件中继服务器用户帐户定义了所需的发送为 权限。

如何模拟邮件流。

在我们的场景中，“真正的”邮件客户端可以是硬件设备，例如传真机、扫描仪或打印机或支持邮件的应用程序。

主要问题是，大多数时候，这个“邮件客户端”无法在失败的情况下提供精确的信息，这意味着邮件没有发送到目标收件人的情况。

SMTP Telnet 客户端实用程序使我们能够模拟邮件流并“查看”邮件客户端和邮件服务器（我们场景中的 IIS SMTP 邮件中继）之间的通信通道的内容。另外，我们可以使用“debug”（启用逐步发送）选项来获取有关问题具体原因的信息。

测试 1 - 使用 SMTP 邮件中继 |目标收件人=SMTP 邮件中继凭据

在第一个测试中，我们要验证邮件流是否可以成功完成，这意味着邮件流中涉及的每个不同“元素”都可以相互通信。

在我们的场景中，邮件客户端将使用与 IIS SMTP 邮件中继所使用的用户凭据相同的电子邮件地址来标识自己。

对于“目标收件人”的主题为目标的电子邮件地址，收件人并不重要，只要我们能够访问目标收件人的邮箱并验证他是否收到我们的测试邮件即可。

当前场景的特点是：

• 来源收件人 - [email protected]
• IIS SMTP 邮件中继凭据 - [email protected]
• 目的地收件人 - [email protected]

使用Telnet 属性选项卡配置与 IIS SMTP 邮件中继服务器内部接口的通信设置。

• 接收连接器 IP：添加 IIS SMTP 服务器的 IP 地址（在我们的特定场景中，IP 地址为 - 10.13.137.2）。
• TCP 端口：这是 IIS SMTP 邮件中继“LAN 接口”的端口号。用于“列出”邮件客户端的默认端口是 - 25
• 邮件发件人：在文本框中，我们需要添加电子邮件地址，“代表”想要通过以下方式发送电子邮件的内部邮件客户端： IIS SMTP 邮件中继。在我们的具体场景中，源收件人是 - [email protected]
  收件人：在本文中框中，我们需要添加应该从内部邮件客户端获取邮件的“目标收件人”的电子邮件地址。在我们的特定场景中，目标 Office 365 收件人是 - [email protected]
• 主题：这是一个可选参数，将创建“主题标题”。在我们的特定场景中，主题是Test 001

要发送电子邮件，我们需要选择Telnet选项卡，然后单击SEND选项

在下面的屏幕截图中，我们可以看到邮件流中的“第一部分”，即内部邮件客户端寻址 IIS SMTP 邮件中继的内部接口的部分已完成。

IIS SMTP 邮件中继“同意”接受电子邮件消息，并“通知”邮件客户端 - 该电子邮件是排队等待传送的邮件

邮件流的第一部分成功完成这一事实并不意味着我们可以假设电子邮件已到达目标 Office 365 收件人邮箱。

能够验证电子邮件是否由 IIS SMTP 邮件中继发送到 Office 365 邮件服务器（由主机名 smtp.office365.com 表示的 EOP） ）我们需要访问目标收件人邮箱（在我们的示例中为约翰）以验证他是否收到电子邮件。

在下面的屏幕截图中，我们可以看到电子邮件到达了 John 邮箱。

测试 2 - 验证 SMTP 邮件中继代表不同邮件客户端发送电子邮件的能力。

如果第一个测试成功完成，并且我们知道邮件流配置正确，下一步就是验证 IIS SMTP 邮件中继代表不同邮件客户端传递电子邮件的能力。

例如，基本假设是每个将寻址 IIS SMTP 邮件中继服务器的邮件客户端都将使用唯一的电子邮件地址来标识自己。

IIS SMTP 邮件中继服务器通过使用特定的用户帐户（在我们的场景中为 [email protected]）向 Office 365 邮件服务器标识自己的身份，并能够在代表其他邮件收件人； IIS SMTP 邮件中继服务器用户帐户，需要为他将要使用的每个邮件客户端配置 发送为 权限将他们的请求“转发”到 Office 365 邮件服务器。

当前场景的特征是：

• 来源收件人 - [email protected]
• IIS SMTP 邮件中继凭据 - [email protected]
• 目的地收件人 - [email protected]

请注意，在这种情况下，IIS SMTP 邮件中继需要具有“Send As”权限才能启用他代表源邮件收件人发送电子邮件（在我们的场景中 [email protected]）。

使用Telnet 属性选项卡配置与 IIS SMTP 邮件中继服务器内部接口的通信设置。

• 接收连接器 IP：添加 IIS SMTP 服务器的 IP 地址（在我们的特定场景中，IP 地址为 - 10.13.137.2）。
• TCP 端口：这是 IIS SMTP 邮件中继“LAN 接口”的端口号。用于“列出”邮件客户端的默认端口是 - 25
• 邮件发件人：在文本框中，我们需要添加电子邮件地址，“代表”想要通过 IIS 发送电子邮件的内部邮件客户端SMTP 邮件中继。在我们的具体场景中，源收件人是 - [email protected]
  收件人：在本文中框中，我们需要添加应该从内部邮件客户端获取邮件的“目标收件人”的电子邮件地址。在我们的特定场景中，目标 Office 365 收件人是 - [email protected]
• 主题：这是一个可选参数，将创建“主题标题”。在我们的特定场景中，主题是“测试 002”。

要发送电子邮件，我们需要选择Telnet选项卡，然后单击SEND选项

在下面的屏幕截图中，我们可以看到邮件流中的“第一部分”，即内部邮件客户端寻址 IIS SMTP 邮件中继的内部接口的部分已成功完成。

IIS SMTP 邮件中继“同意”接受电子邮件消息，并“通知”邮件客户端 - 该电子邮件已排队等待投递

邮件流的第一部分成功完成这一事实并不意味着我们可以假设电子邮件已到达目标 Office 365 收件人邮箱。

在我们的场景中，我们将看到电子邮件未成功发送给 Office 365 收件人。

IIS SMTP 邮件中继“同意”接受电子邮件，但在下一节中，我们将看到目标邮件服务器（Office 365 EOP 服务器）不同意接受电子邮件
。

当我们访问目标收件人邮箱（在我们的示例中为 John）时，我们发现邮件没有到达 John 的邮箱！

出现的问题是：

Q1：邮件流失败的原因是什么？

Q2：如何查找邮件流失败的原因信息？

问题3：我们如何解决这个邮件流问题？

读取 IIS SMTP 服务器日志文件以获取更多信息

A1：邮件流失败的原因是权限问题，或者如果我们想要更准确的话 - “Send As”权限问题。 IIS SMTP 邮件中继用户 ([email protected]) 没有代表邮件收件人发送电子邮件所需的权限 - 传真@o365info.com

A2：为了能够获得有关邮件流和失败原因的更详细信息，我们将使用 IIS SMTP 邮件服务器邮件传递报告，该报告存储在名为：Badmail 的文件夹中。

死信文件夹的完整路径为：C:\inetpub\mailroot\Badmail

在下面的屏幕截图中，我们可以看到保存在死信文件夹中的信息。 IIS SMTP 服务器为每个“邮件传递失败”生成三个不同的文件。

死信文件夹中出现的两个文件或只是一个简单的文本文件。

为了获取有关失败原因的更多信息，我们将尝试读取文件扩展名为 - *.BDR 的文件中的信息

在日志文件中，我们可以看到以下错误消息： 具体错误代码为0xC00402C7

问题是我们从这个错误消息中无法理解太多内容。

有关失败原因的更有用的信息位于扩展名为 - *.BAD 的文件中

当查看“BAD 文件”的内容时，我们可以看到

向以下收件人发送失败。 - [email protected]

另外——

最终收件人：rfc822;[email protected]
操作：失败
状态：5.7.60
诊断代码：smtp;550 5.7.60 SMTP;客户端无权以此发件人身份发送

此错误消息的含义是 IIS SMTP 邮件中继寻址 Office 365 邮件服务器（EOP 服务器）并尝试将电子邮件“传递”到源邮件收件人 - Fax@o365info .com

因为“云”将 IIS SMTP 邮件中继标识为 - [email protected] 并且因为 John 没有所需的“发送为”代表“传真收件人”发送电子邮件的权限，EOP 服务器拒绝接受电子邮件。

将所需的“代理发送”权限分配给 IIS SMTP 服务器用户帐户

为了能够“修复”此问题，我们将分配 IIS SMTP 邮件中继使用的用户帐户 - [email protected] ，发送为“传真收件人”权限。

注意：基本假设是我们已经创建了一个通讯组
代表“启用邮件的传真设备实体”。

为了能够分配发送为权限，我们将登录到Exchange Online人工代理界面。

• 选择收件人菜单，然后选择组菜单
• 双击所需的通讯组（在我们的场景中为传真组）。

• 选择菜单 - 群组授权。 在下面的屏幕截图中，我们可以看到默认情况下，没有收件人具有发送为 此群组的权限。

在发送为部分下，单击加号图标添加具有所需发送为权限。在我们的特定场景中，我们希望将此权限分配给名为 John 的收件人，即 IIS SMTP 邮件中继使用的邮件收件人。

添加所需的权限后，我们必须尝试再次发送电子邮件。

在下面的截图中我们可以看到，此时邮件已成功到达目标收件人邮箱。

如果您是一个好奇的人，并且您想查看有关 IIS SMTP 邮件中继实现的电子邮件传递的信息，我们可以查看 IIS SMTP 邮件中继日志文件。

默认情况下，IIS SMTP 邮件中继日志文件位于以下路径：

C:\Windows\System32\LogFiles\SMTPSVC1

在下面的屏幕截图中，我们可以看到 SMTPSVC1 文件夹包含许多日志文件。
我们需要选择最新的日志文件。

查看日志文件时，我们可以看到 IIS SMTP 邮件中继和 Office 365 邮件服务器之间的邮件流中实施的每个步骤的非常详细的描述。

例如，我们可以看到邮件由以下几个阶段组成：

• 阶段 1 - IIS SMTP 邮件中继寻址 Office 365 邮件服务器且会话基于 TLS 会话的阶段。
• 阶段 2 - 身份验证阶段，IIS SMTP 邮件中继向 Office 365 邮件服务器提供其凭据
• 阶段 3 - IIS SMTP 邮件中继将电子邮件“传递”到 Office 365 邮件服务器并提供有关源 + 目标收件人的信息的阶段。
• 阶段 4 - Office 365 邮件服务器接受来自 IIS SMTP 邮件中继的电子邮件并将该电子邮件存储在队列中。

验证使用 TLS 协议访问 Office 365 邮件服务器的能力

在本节中，我们将回顾如何解决使用 IIS SMTP 中继选项时邮件流问题的常见“原因”。

基于 TLS 的邮件流故障排除 |消除概念

在我们无法将电子邮件发送给目标收件人的情况下，最常见的反应是：“云出现问题”。

如果我们想采取更实用的方法，则应该通过消除邮件流过程中涉及的特定组件来实现故障排除过程，直到我们可以清楚地指出未正确配置的特定元素。

例如，在传真设备等邮件客户端发送的电子邮件未到达目的地的情况下，我们需要验证该过程中涉及的所有组件是否配置正确。

在下图中，我们可以看到使用 SMTP 邮件中继选项将电子邮件发送到 Office 365 邮件基础结构时的标准邮件流。

在下一节中，我们将演示如何绕过以下组件：

1. 邮件客户端（我们示例中的传真设备）
2. IIS SMTP 邮件中继

我们的主要目的是验证

• 我们可以使用 TLS 协议与“云”（主机名代表的 Office 365 邮件服务器 -
  smtp.office365.com ）进行通信
• Office 365 邮件服务器愿意接受我们的请求并将其投递或邮寄给目标收件人。

Office 365 环境中的“安全通信通道”概念。

快速提醒一下，“安全通信通道”是使用端口 25 或 587 实现的。在我们的场景中，基本假设是邮件流将按如下方式应用：

• 客户端将寻址目标邮件服务器（EOP 服务器）
• EOP 服务器将向源客户端发出信号，表明他需要使用 TLS 协议 + 提供用户凭据。
• 客户端将提供所需的用户凭据。
• 将创建“安全通信通道”（TLS）。
• 客户端将请求 EOP 服务器将电子邮件消息发送给目标收件人。

将用于测试目的的邮件客户端

在下一节中，我们将演示如何使用三种不同的邮件客户端测试与 Office 365 邮件服务器的 TLS 通信

1. Windows 操作系统客户端
2. PowerShell 脚本
3. 名为 JBMail 的图形邮件客户端

选项 1 - 使用 Windows Telnet 客户端验证与 EOP 服务器的通信

验证与邮件服务器（我们场景中的 EOP 服务器）的通信通道的最简单方法之一是使用 Telnet 会话。

如果我们成功“Telnet”到目标主机，我们可以知道：

1. 我们成功地将主机名（在我们的场景中为 smtp.office365.com ）解析为 IP 地址。
2. 网络防火墙使我们能够使用所需的端口号（25 或 587）“出去”。
3. 目标服务器（Office 365 邮件服务器）已“启动”，他可以响应我们的通信请求。

唯一的“问题”是与 Office 365 邮件服务器 - smtp.office365.com 的通信应通过使用 TLS 会话和标准 Windows 操作系统 Telnet 客户端来实现，但不能不支持使用 TLS 协议。

尽管存在此限制，我还是使用 Windows 操作系统 Telnet 客户端选项，因为它简单明了，并且允许我验证提到的基本元素（解析主机名等）。

使用 Windows telnet 客户端与 Office 365 邮件服务器通信

例如：打开命令提示符并键入以下命令：

Telnet smtp.office365.com 25
Helo
mail from:[email protected]

在下面的截图中，我们可以看到通信测试失败，EOP服务器发送错误消息：

530 5.7.57 SMTP；客户端未经过身份验证，无法在 MAIL FROM 期间发送匿名邮件

此错误消息的含义是“源客户端”（我们示例中的 Telnet 客户端）无法成功满足加密通信通道（我们场景中的 TLS）的强制要求。

我们失败的原因是我们对特定任务使用了“错误的工具”。 “标准操作系统 Telnet 客户端”不知道如何使用 TLS 实现安全通信通道。

选项 2 - 使用 PowerShell 脚本模拟与 EOP 服务器的安全通信通道

为了能够模拟特定主机和 Office 365 邮件服务器（EOP -Exchange Online 保护服务器）之间的安全通信通道（TLS 通道），我们可以使用 PowerShell 脚本。

为了避免输入复杂而奇怪的 PowerShell 命令，我更喜欢使用简单的 PowerShell 脚本。

SendMail.ps1 PowerShell 脚本中包含的代码

在下面的屏幕截图中，我们可以看到 SendMail.ps1 PowerShell 脚本的内容。

该脚本包含预定义变量，例如我们的 SMTP 服务器名称和端口号 smtp.office365.com 和端口 25设想）。

为了能够成功完成与 EOP 服务器的 TLS 会话，重要的是要了解创建与 EOP 服务器的安全通信通道的强制要求是提供所需的 Office 365 用户凭据（UPN 名称 + 密码）。

我们需要提供的前两个参数是 Office 365 用户名和密码。

最后一个参数是“目标收件人电子邮件地址”。

使用 SendMail.ps1 PowerShell 脚本

然后可以从内置操作系统 PowerShell 控制台发送邮件 PowerShell 脚本。
为了能够运行 PowerShell，我们需要运行一个 PowerShell 策略命令，该命令将使我们能够运行 PowerShell 脚本（默认情况下， PowerShell 策略不允许我们运行脚本）。

在我们的方案中，将尝试使用名为 [email protected] 的 Office 365 用户的凭据在特定主机和 Exchange Online Protection 服务器之间创建安全通信通道。

为了简化测试，我们将使用 John 的电子邮件作为“目标电子邮件地址”。

运行 PowerShell 脚本首次配置

• 找到 PowerShell 控制台
• 右键单击 PowerShell 图标并选择选项：以管理员身份运行

在 PowerShell 控制台上运行以下命令：

Set-ExecutionPolicy Unrestricted -force

运行 SendMail.ps1 PowerShell 脚本

为了能够激发 SendMail.ps1 PowerShell 脚本，我们需要从 PowerShell 控制台“调用”该脚本。

在我们的示例中，SendMail.ps1 PowerShell 脚本保存在以下路径中：

C:\Script

为了能够激发 PowerShell 脚本，我们需要输入以下字符：“.\”，然后输入脚本名称。

在下面的屏幕截图中，我们可以看到运行 SendMail.ps1 PowerShell 脚本的示例：

在下面的截图中，我们可以看到John的邮箱。我们可以从 PowerShell 脚本中看到 John 发送的邮件到达了 John 的邮箱。

选项 3 - 使用 TLS 将电子邮件发送到 Exchange Online | GUI邮件客户端

在以下部分中，我们将演示如何使用加密通信链接 (TLS) 将电子邮件发送到 Exchange Online (EOP)。

我发现的用于模拟 TLS 会话的邮件客户端应用程序名为 JBMail。

您可以从以下链接 JBMail 下载邮件客户端。

下面的演示通过两个步骤实现：

1. 配置邮件客户端配置文件 - 我们定义将用于连接 Exchange Online 服务器的用户凭据、通信协议类型等的步骤。
2. 创建（撰写）新电子邮件。

场景描述

在我们的场景中将实现一个非常简单的测试：名为：[email protected] 的收件人将通过连接 EOP 服务器向自己发送邮件（smtp.office365.com）使用 TLS。

• 选择帐户选项卡
• 在“用户名”框中，添加将向 EOP 服务器验证其身份的收件人凭据。在我们的示例中 - [email protected]

• 选择发送设置选项卡
• 在 SMTP 主机 框中，键入 EOP 服务器的主机名 - smtp.office365.com （数字 1）。
• 在用户名框中，键入将由他发送邮件的收件人姓名。在我们的示例中 - [email protected]（数字2）。
• 在密码框中，输入将由他发送的邮件的收件人姓名密码（数字3）。
• 在协议部分中，选择选项 - 通过 STARTTLS 的 SSL（数字4 ） ）。
• 选择选项 - 使用SMTP AUTH（数字4）。
• 在您的地址框中，输入将由他发送邮件的收件人的电子邮件地址 - 在我们的示例中 - [email protected]（号码 5）。
• 在端口框中，键入端口号。在我们的场景中，端口 25（编号 6）。

通过选择帐户选项卡并单击撰写来创建新邮件

• 在“收件人”字段中，添加目标收件人的电子邮件地址。在我们的示例中 - [email protected]
• 单击发送按钮发送电子邮件

将出现以下消息：
选择接受选项

在下面的屏幕截图中，我们可以看到电子邮件消息已成功发送到 EOP 服务器。

在下面的屏幕截图中，我们可以看到约翰接受了电子邮件。

如果我们想确定电子邮件是使用安全通信通道 (TLS) 发送的，我们可以查看电子邮件标头。

• 双击电子邮件消息
• 选择更多选项图标（三个点）
• 选择菜单 - 查看消息详细信息

在下面的屏幕截图中，我们可以看到发送给 John 的邮件的邮件标头。我们可以看到通信是使用 TLS 实现的。

验证邮件服务器的 TLS 设置

Office 365 EOP 服务器中的 IIS SMTP 邮件中继之间的“安全通信通道”的实现是通过使用 TLS 协议来实现的。

IIS SMTP 邮件中继包括 TLS 协议中的内置支持，并且我们已经创建了文章中描述的所有必需的配置设置 - xxx，IIS SMTP 邮件中继和 Office 365 EOP 服务器之间的通信通道，其中由主机名表示：smtp.office365.com 创建。

在某些情况下，如果我们怀疑问题与 TLS 基础设施有关，则电子邮件问题是 TLS 通信通道是一个“黑匣子”，默认情况下，我们没有简单的选项来查看 TLS参数。

如果您有兴趣获得有关 TLS 会话内容的更多信息，我们可以使用一个名为 checktls 的优秀网站工具，它可以帮助我们测试客户端和邮件服务器之间的 TLS 会话。

在下一个示例中，我们将查看名为 [email protected] 的 Office 365 收件人与 Office 365 EOP 服务器之间的 TLS 会话 - smtp.office365.com

在地址文本中，我们添加收件人电子邮件 - [email protected]，然后单击尝试

在下面的屏幕截图中，我们可以看到结果。

数字 1 - 这是通信过程中涉及的整个 TLS 参数的摘要。在我们的场景中，我们可以看到 TLS 通信通道成功完成，并且所有不同的参数都是正确的。

数字 2 - 显示“目标收件人”的电子邮件地址的部分。

数字 3 - Web 测试应用程序查找 Office 365 邮件服务器的主机名。在我们的场景中 - o365info-com.mail.protection.outlook.com

数字 4 - 我们可以通过使用 SMTP 命令看到 TLS 会话“开始” - STARTTLS

数字 5 - 在本节中我们可以看到“目标邮件服务器”提供的SSL证书的内容。

数字 6 - 在本节中我们可以看到 TLS 通信通道已成功创建。

总结和回顾

我感觉我们在“IIS SMTP世界”中一起走过了一段漫长的旅程。

我希望这些信息将帮助您在 Office 365 环境中实施 SMTP 中继解决方案。