如何解决 SMTP 错误:第 1 部分

什么是 SMTP?

简单邮件传输协议 (SMTP) 是一种用于在相应电子邮件服务器之间传输电子邮件的通信协议。 使用像 Mac Mail 这样的电子邮件客户端, Outlook、Thunderbird 或 Gmail 或 Windows Live 等 Web 客户端,SMTP 可以将消息发送到电子邮件服务器。 尽管 SMTP 最初被设计为电子邮件传输和传递系统,但后来它包含了邮政现在都在使用的电子邮件提交协议 Office 协议 (POP) 和 Internet 消息访问协议 (IMAP)。 上述电子邮件客户端使用这些协议从电子邮件服务器检索电子邮件。 当该系统出现故障时,它提供了识别和解决 SMTP 错误的方法。

SMTP 如何工作?

发送电子邮件时,电子邮件客户端将通过提供与电子邮件帐户关联的用户名和密码向电子邮件服务器验证自己的身份。 如果凭据有效,则确认、分析用户的电子邮件并将其转发到收件人的目的地。 如果身份验证失败,则会在服务器上创建并记录 SMTP 错误消息,通常在客户端的电子邮件软件中。

如果服务发生故障会发生什么?

我们都遇到过电子邮件问题。 发生这种情况时,不仅电子邮件不会通过,而且会发送失败消息,并且会在发送和接收电子邮件服务器上创建日志条目。 日志条目包含大量信息。 这些日志条目的一部分称为状态代码。

SMTP 状态码

状态代码是 SMTP 提供的数字名称,附加到发送或接收的每封电子邮件消息中,表示对消息进行了哪些操作。 我们可以参考此编号来收集有关发生故障的原因以及修复问题所需的必要信息。 当我们查看该代码时,我们可以使用状态代码的信息来确定电子邮件发送失败的原因。

SMTP 响应代码

一般响应代码中列出的第一个数字表示服务器的响应是好、坏还是不完整。 一般响应代码编号从 1 到 7 不等,涵盖了发生电子邮件故障时产生的所有问题。 这些代码总是出现在服务器日志中。 这些错误消息包含广泛的含义,很容易 在网上找到 并在下面引用。

一般响应代码

查看表

代码状态类型意义
1.XX寻址状态地址状态报告始发者或目的地地址。 它可能包括地址语法或有效性。 这些错误通常可以由发件人纠正并重试。
2.XX邮箱状态邮箱状态表明与邮箱有关的某些事情导致了此 DSN。 假定邮箱问题在收件人的一般控制之下。
3.XX邮件系统状态邮件系统状态表明与目标系统有关的某些事情导致了此 DSN。 假定系统问题在目标系统管理员的总体控制之下。
4.XX网络和路由状态网络或路由代码报告有关交付系统本身的状态。 这些系统组件包括任何必要的基础设施,例如目录和路由服务。 假设网络问题在目标或中间系统管理员的控制之下。
5.XX邮件传递协议状态邮件传递协议状态代码报告涉及消息传递协议的故障。 这些故障包括由实施错误或不可靠连接导致的所有问题。
6.XX消息内容或媒体状态消息内容或媒体状态代码报告涉及消息内容的故障。 这些代码报告由于翻译、转码或其他不受支持的消息媒体而导致的失败。 消息内容或媒体问题由发送者和接收者控制,两者都必须支持一组通用的受支持内容类型。
7.XX安全或策略状态安全或策略状态代码报告涉及策略的故障,例如按收件人或按主机过滤和加密操作。 假定安全和策略状态问题由发送者和接收者中的一个或两个控制。 发送者和接收者都必须允许交换消息并安排交换必要的密钥和证书以进行加密操作。

有超过 八十个子码 进一步将响应定义为更具体的错误类别。 我们可以查看这些代码以确定如何解决我们的 SMTP 错误。

SMTP 状态码含义

以下是一些最常见的状态码及其含义

查看表

代码意义
200(非标准成功响应,见 rfc876)
211系统状态,或系统帮助回复
214帮助信息
220 服务就绪
221 服务关闭传输通道
250请求的邮件操作正常,已完成
251用户不是本地的; 将转发到
252无法 VRFY 用户,但会接受消息并尝试传递
354开始邮件输入; 以 . 结尾
421 服务不可用,正在关闭传输通道
450未采取请求的邮件操作:邮箱不可用
451请求的操作中止:处理中的本地错误
452未采取请求的操作:系统存储空间不足
500语法错误,命令无法识别
501参数或参数中的语法错误
502命令未执行
503错误的命令序列
504命令参数未实现
521 不接受邮件(参见 rfc1846)
530访问被拒绝(???a Sendmailism)
550未采取请求的操作:邮箱不可用
551用户不是本地的; 请尝试
552请求的邮件操作中止:超出存储分配
553未采取请求的操作:不允许使用邮箱名称
554交易失败

SMTP 故障排除

以下是发生电子邮件错误时采取的步骤。 这些步骤在所有情况下几乎相同。 唯一的例外是当问题对系统管理员可见时。

收集信息

我们的第一步是收集信息。 我们首先回答这些基本问题。

  • 我连接到互联网了吗?
  • 我的电子邮件客户端帐户设置是否正确?
  • 我的防病毒软件是否启用? 这可以阻止发送电子邮件。
  • 我的防火墙在运行吗? 这可以阻止发送电子邮件。
  • 我是否在邮箱中看到任何可疑电子邮件?
  • 发送或接收电子邮件是否有问题? 或两者?
  • 是只有一个帐户受到影响还是多个帐户受到影响?
  • 遇到问题的电子邮件地址是什么? 或域(如果有多个)。
  • 是否出现任何退回邮件或错误消息?
  • 最近是否更改了域的 DNS?
  • 我可以从我的网络邮件帐户连接和发送/接收电子邮件吗?
  • 您使用的是哪个电子邮件客户端?

这些问题的答案将使我们的管理员能够快速推断出错误的来源。

定位权威域名服务器

如果偶然地,任何 DNS 记录在前 24 小时内发生了更改,这可能是导致错误的原因。 有时,如果名称服务器的所有者配置了更长的 TTL(或生存时间)时间,则新记录的传播可能会延迟。 要定位权威名称服务器,我们需要运行 whois 命令来查找该信息。

whois domain.com

此命令将返回大量信息。 我们感兴趣的部分如下。

Domain servers in listed order:

NS1.DOMAIN.COM            210.60.130.21
NS2.DOMAIN.COM            65.81.241.154

使用此信息,我们可以检查以确保域名服务器在注册商处列出。 这也表明他们正在正确地解析到正确的地址。 同样,我们使用 whois 命令来验证这一点。

root@host:~# whois ns1.domain.com
   Server Name: NS1.DOMAIN.COM
   IP Address: 66.96.142.147
   Registrar: Domain.com, LLC
   Registrar WHOIS Server: whois.domain.com
   Registrar URL: https://www.domain.com
>>> Last update of whois database: 2021-02-16T17:42:44Z <<<

如果没有与此名称服务器关联的 IP 地址,我们知道该域未正确解析,并且电子邮件将无法通过。

查询 MX 记录的名称服务器

域的 MX 记录告诉 Internet 上的其他服务器哪些主机接受域的电子邮件。 如果您的电子邮件托管在 Liquid Web 的服务器上,则该服务器的主机名应该在 MX 记录中。 当我们找到这些信息时,我们使用 dig 命令。 此命令查找各种类型的 DNS 记录。

root@host:~# dig mx domain.com

; <<>> DiG 9.16.1-Ubuntu <<>> mx domain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19270
;; flags: qr rd ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;domain.com.                    IN      MX

;; ANSWER SECTION:
domain.com.             0       IN      MX      10 mx.domain.com.
mx.domain.com.          0       IN      A       66.96.140.72
mx.domain.com.          0       IN      A       66.96.140.73
ns-166.awsdns-20.com.   0       IN      A       205.251.192.166
ns-2022.awsdns-60.co.uk. 0      IN      A       205.251.199.230
ns-683.awsdns-21.net.   0       IN      A       205.251.194.171
ns-2022.awsdns-60.co.uk. 0      IN      AAAA    2600:9000:5307:e600::1

;; Query time: 80 msec
;; SERVER: 172.29.80.1#53(172.29.80.1)
;; WHEN: Tue Feb 16 12:49:51 EST 2021
;; MSG SIZE  rcvd: 274

root@host:~#

正如我们在答案部分中看到的,MX 记录是响应该命令而记录的。

mx.domain.com.          0       IN      A       66.96.140.72
mx.domain.com.          0       IN      A       66.96.140.73

除了 dig 之外的其他命令,如 host 和 ping,也可以提供此信息。 其他 在线的工具 可以解析域名的通常会为我们提供我们需要的数据。

验证电子邮件传递

使用 Telnet

如果上述所有域信息都正确解析,我们就可以测试服务器了。 对于此任务,我们使用 telnet 命令。 使用 telnet 命令,我们可以使用端口 25(默认 SMTP 端口)登录服务器。

注意:服务器可能需要一两分钟才能返回如下所示的 220 响应。 这很正常。

root@host:~# telnet 66.96.140.72 25
Trying 66.96.140.72...
Connected to 66.96.140.72.
Escape character is '^]'.
220-host.domain.com ESMTP Exim 4.94 #2 Tue, 16 Feb 2021 13:04:21 -0500
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.

连接后,我们将看到与上述类似的横幅消息。 为了与服务器交互,我们发出“EHLO”命令和我们的主机名。 通常,主机名无关紧要,因为我们要连接的 SMTP 服务器会查找我们要连接的 IP 的 RDNS(反向 DNS)信息。

EHLO server.BYNSS.com
250-host.server.com Hello host.server.com [65.21.72.171]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-X_PIPE_CONNECT
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP

定义消息

接下来,我们使用以下命令告诉服务器是谁在发送消息。

MAIL FROM: [email protected]

服务器应以“250 OK”响应。

250 OK

现在,我们可以使用“RCPT TO:”命令输入收件人的电子邮件地址。 发件人和收件人可以拥有相同的电子邮件地址。

RCPT TO: [email protected]

如果服务器可以验证发件人、收件人和其他信息,它会告诉我们消息已被接受。

250 Accepted

发信息

接下来,我们使用“DATA”命令输入消息本身。

DATA

服务器通过告诉我们输入电子邮件消息进行响应。

354 Enter message, ending with "." on a line by itself

现在,我们输入电子邮件的主题行(这不是服务器命令)。 添加此信息后,我们点击 Enter 两次表示标题的结束,然后输入消息的正文。

Subject: test message

Hello, this is a test message.

.

输入消息后,添加“.” 单独一行。这让服务器知道我们的消息是完整的。然后服务器为消息分配一个 ID 并说,“250 OK id=messagenumbersandletters。”

250 OK id=1JR2se-0201DI-Cq

一旦我们看到“250 OK”输出,这表明电子邮件已发送。 我们可以 close 通过键入“QUIT”命令连接。

QUIT
The server announces that it is going to close the connection and then does so:

221 server.BYNSS.com closing connection
Connection closed by foreign host.

我们知道我们的电子邮件使用了 250 状态码,因此我们知道问题不在于服务器上的 SMTP。

使用网络邮件

我们还可以使用附加到我们域的 webmail 客户端来验证工作连接。 如果我们访问 https://host.server.com:2096/,cPanel 将向我们显示 webmail 登录屏幕。

一旦我们登录到 webmail,将测试电子邮件发送到正在工作的辅助电子邮件地址。 如果电子邮件发送和接收成功,我们就知道出站邮件服务器按预期运行。

现在,从辅助电子邮件地址回复电子邮件。 如果我们在 webmail 界面中收到电子邮件,则入站电子邮件服务器也在正常工作。 这告诉我们问题不在我们的服务器上。

如果由于某种原因,我们无法发送,下一步是检查电子邮件日志条目中的错误代码。 我们将在本文中进一步查看解决此问题的步骤。

结论

我们以成为 Hosting™ 中最乐于助人的人而自豪! 我们的支持团队由经验丰富的 Linux 技术人员和才华横溢的系统管理员组成,他们对多种网络托管技术有着深入的了解,尤其是本文中讨论的技术。 如果您对此信息有任何疑问,我们将随时为您解答与本文相关问题的任何询问,每天 24 小时、每周 7 天、每年 365 天。

如果您是完全托管的 VPS 服务器, Cloud 专用,VMWare 私有 Cloud私有父服务器, 托管 Cloud 服务器或专用服务器所有者并且您对执行概述的任何步骤感到不舒服,可以通过电话 800.580.4985 联系我们, 聊天 或支持票以帮助您完成此过程。