为什么cron使用MTA发送邮件，而我们使用MUA发送邮件？

Question 1

从根本上来说，Unix 上的邮件是一种本地现象。同一主机上的用户可以在没有任何网络的情况下互相发送邮件。（“地址”只是用户名，没有@。）这当然意味着从 MUA 到 MTA 的消息通信方法必须是本地的。通常，该方法是指向名为的程序的管道sendmail。

通过使 MTA 理解包含该符号的地址，可以将纯本地邮件扩展到参与 Internet 邮件系统@。 MUA仍然不需要知道网络的存在；它只需将地址视为不透明字符串，并让本地 MTA 确定哪些地址需要通过网络。

MTA 显然是网络配置的正确位置，因为系统上只有一个 MTA，但多个 MUA 可以由不同用户甚至同一用户使用。处理所有这些网络内容的单个程序意味着配置不需要多次完成。

将传出消息注入远程服务器的 MUA 旨在允许“类 Unix”系统在没有 MTA 的情况下假装正常工作。这种配置是对传统方案的拒绝。它切断了邮件系统的核心——向任何本地用户发送消息的能力——并且没有提供足够的替代品。

Cron 充当 MUA，这就是为什么它不“使用 MUA”，它正在做 Unix MUA 一直做的事情，在不知道网络存在的情况下发送邮件，依靠本地 MTA 来弄清楚。通过本地用户名寻址收件人是唯一合理的默认设置，因为 cron 作业代表本地用户运行，并且无法知道该用户在某些远程主机上可能拥有什么地址。

Answer

从根本上来说，Unix 上的邮件是一种本地现象。同一主机上的用户可以在没有任何网络的情况下互相发送邮件。（“地址”只是用户名，没有@。）这当然意味着从 MUA 到 MTA 的消息通信方法必须是本地的。通常，该方法是指向名为的程序的管道sendmail。

通过使 MTA 理解包含该符号的地址，可以将纯本地邮件扩展到参与 Internet 邮件系统@。 MUA仍然不需要知道网络的存在；它只需将地址视为不透明字符串，并让本地 MTA 确定哪些地址需要通过网络。

MTA 显然是网络配置的正确位置，因为系统上只有一个 MTA，但多个 MUA 可以由不同用户甚至同一用户使用。处理所有这些网络内容的单个程序意味着配置不需要多次完成。

将传出消息注入远程服务器的 MUA 旨在允许“类 Unix”系统在没有 MTA 的情况下假装正常工作。这种配置是对传统方案的拒绝。它切断了邮件系统的核心——向任何本地用户发送消息的能力——并且没有提供足够的替代品。

Cron 充当 MUA，这就是为什么它不“使用 MUA”，它正在做 Unix MUA 一直做的事情，在不知道网络存在的情况下发送邮件，依靠本地 MTA 来弄清楚。通过本地用户名寻址收件人是唯一合理的默认设置，因为 cron 作业代表本地用户运行，并且无法知道该用户在某些远程主机上可能拥有什么地址。

Question 2

关于 cron 和 MUA-MTA 连接

实用答案

我通常为我的 cron 用户创建一个后缀别名。这样，所有 cron 作业邮件都会发送到我的查找表中的别名地址。

所以，一个实际的答案是：

Cron 消息可以从服务器/域/机器发送到任意互联网范围内的电子邮件地址。

此外，cron它本身可以配置为使用任意~~邮件程序~~MTA。

来自 Debian Buster 中的 cron 源代码树：

cron-3.0pl1/config.h

45 #define MAILCMD _PATH_SENDMAIL                   /*-*/
46 /* #define MAILARGS "%s -i -FCronDaemon -odi -oem  %s"       /*-*/
47 #define MAILARGS "%s -i -FCronDaemon -B8BITMIME -oem  %s"        /*-*/
48          /* -i    = don't terminate on "." by itself
49                         * -Fx     = set full-name of sender
50           * -odi  = Option Deliverymode Interactive
51           * -oem  = Option Errors Mailedtosender
52           * -t    = read recipient from header of message
53           * -or0s = Option Readtimeout -- don't time out
54           * XXX: sendmail doesn't allow -or0s when invoked
55           * by joe user.  --okir
56           */
57
58 /* #define MAILCMD "/bin/mail"           -*/
59 /* #define MAILARGS "%s -d  %s"          -*/
60          /* -d = undocumented but common flag: deliver locally?
61           */
62
63 /* #define MAILCMD "/usr/mmdf/bin/submit"    -*/
64 /* #define MAILARGS "%s -mlrxto %s"      -*/

那么，第二个实际答案：

Cron 可以编译为使用任意 MTA

理论答案

正如评论和其他答案中所述，cron正在充当 MUA。除了位于其自己的逻辑机上的预定 MTA 之外，它没有代码库来处理实际发送消息的情况。值得注意的是，逻辑机实际上可能不是同一台物理机。

关于使用 MTA 发送电子邮件

通过 SMTP 端口直接连接到 MTA

SMTP.URL:port通过连接到 MTA并手动进行任何身份验证，可以直接通过 MTA 发送电子邮件。

telnet example.com 25

如果通过连接 ISP 畅通无阻地访问端口 25，通常会起作用。你会收到类似这样的消息：

Trying xxxx:xxxx::xxxx:xxxx:xxxx:xxxx...
Trying xxx.xxx.xxx.xxx...
Connected to example.com.
Escape character is '^]'.
220 mail.example.com ESMTP Postfix (Debian/GNU)

但是...大多数 ISP 都会阻止端口 25 连接。而且这种发送邮件的方式比较麻烦，所以一般情况下会使用sylpheed或者等设计良好的MUA 。thunderbird

为什么 ISP 会阻止标准 SMTP 端口：25

大多数 Internet 用户通过 Internet 服务提供商 (ISP) 连接到广域网 (WAN)。这些 ISP 通常会阻止用于运行 Internet 服务的常用端口，例如 HTTP (80) SMTP (25) 和其他几种可能的端口。

一般来说，ISP 与其客户签订了条款和条件协议，禁止从其网络运行 Internet 服务。实行这一一般 ISP 政策至少有两个原因：

互联网服务消耗带宽。
ISP 是许多垃圾邮件发送者或恶意 Web 服务的最小障碍。

ISP 通常还将自己的动态 IP 地址池列入黑名单。因此，从 ISP 动态 IP 地址运行的任何邮件服务很可能会被拒绝或直接放入任何大型电子邮件提供商的“垃圾邮件”文件夹中。

黑名单IP拦截

IP黑名单非常简单有效。它在 MTA 配置中用于立即拒绝来自黑名单域的传入邮件。

/etc/postfix/main.cf

...
smtpd_client_restrictions = ...
                            reject_rbl_client cbl.abuseat.org
                            reject_rbl_client pbl.spamhaus.org
                            reject_rbl_client sbl.spamhaus.org
                            reject_rbl_client bl.blocklist.de
...

我的实际服务器日志之一的示例：

Oct 14 04:45:23 xxxx postfix/smtpd[17679]: NOQUEUE: reject: RCPT from xxxxx.xxxx.xxxx.jp[xxx.149.xxx.xxx]: 554 5.7.1 Service unavailable; Client host [xxx.149.xxx.xxx] blocked using sbl.spamhaus.org; https://www.spamhaus.org/sbl/query/SBL319039; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<xxxx.xxx.xxx.jp>

僵尸网络时代端口阻塞和 RBL 的有效性

这些策略在当前的按需 Web 服务器时代之前更为有效。根据我的经验，垃圾邮件发送者和恶意行为者只是从 ISP 连接服务转移到僵尸网络和按需命令与控制 (C&C) 服务器。

大多数针对我自己的服务器的垃圾邮件或暴力攻击都是从通常从 Amazon EC2 IP 地址运行的 C&C 探针开始的。随后是一系列来自遥远国家/地区地址的僵尸网络。

不阻止端口的 ISP

我不确定美国 ISP 是否允许所有端口。然而，我看到一些欧洲互联网服务提供商只是向消费者提供互联网消防水带，没有阻塞端口，也没有过滤器。

所以，除了“与您的 ISP 核实”之外，我没有其他答案。

Answer

关于 cron 和 MUA-MTA 连接

实用答案

我通常为我的 cron 用户创建一个后缀别名。这样，所有 cron 作业邮件都会发送到我的查找表中的别名地址。

所以，一个实际的答案是：

Cron 消息可以从服务器/域/机器发送到任意互联网范围内的电子邮件地址。

此外，cron它本身可以配置为使用任意~~邮件程序~~MTA。

来自 Debian Buster 中的 cron 源代码树：

cron-3.0pl1/config.h

45 #define MAILCMD _PATH_SENDMAIL                   /*-*/
46 /* #define MAILARGS "%s -i -FCronDaemon -odi -oem  %s"       /*-*/
47 #define MAILARGS "%s -i -FCronDaemon -B8BITMIME -oem  %s"        /*-*/
48          /* -i    = don't terminate on "." by itself
49                         * -Fx     = set full-name of sender
50           * -odi  = Option Deliverymode Interactive
51           * -oem  = Option Errors Mailedtosender
52           * -t    = read recipient from header of message
53           * -or0s = Option Readtimeout -- don't time out
54           * XXX: sendmail doesn't allow -or0s when invoked
55           * by joe user.  --okir
56           */
57
58 /* #define MAILCMD "/bin/mail"           -*/
59 /* #define MAILARGS "%s -d  %s"          -*/
60          /* -d = undocumented but common flag: deliver locally?
61           */
62
63 /* #define MAILCMD "/usr/mmdf/bin/submit"    -*/
64 /* #define MAILARGS "%s -mlrxto %s"      -*/

那么，第二个实际答案：

Cron 可以编译为使用任意 MTA

理论答案

正如评论和其他答案中所述，cron正在充当 MUA。除了位于其自己的逻辑机上的预定 MTA 之外，它没有代码库来处理实际发送消息的情况。值得注意的是，逻辑机实际上可能不是同一台物理机。

关于使用 MTA 发送电子邮件

通过 SMTP 端口直接连接到 MTA

SMTP.URL:port通过连接到 MTA并手动进行任何身份验证，可以直接通过 MTA 发送电子邮件。

telnet example.com 25

如果通过连接 ISP 畅通无阻地访问端口 25，通常会起作用。你会收到类似这样的消息：

Trying xxxx:xxxx::xxxx:xxxx:xxxx:xxxx...
Trying xxx.xxx.xxx.xxx...
Connected to example.com.
Escape character is '^]'.
220 mail.example.com ESMTP Postfix (Debian/GNU)

但是...大多数 ISP 都会阻止端口 25 连接。而且这种发送邮件的方式比较麻烦，所以一般情况下会使用sylpheed或者等设计良好的MUA 。thunderbird

为什么 ISP 会阻止标准 SMTP 端口：25

大多数 Internet 用户通过 Internet 服务提供商 (ISP) 连接到广域网 (WAN)。这些 ISP 通常会阻止用于运行 Internet 服务的常用端口，例如 HTTP (80) SMTP (25) 和其他几种可能的端口。

一般来说，ISP 与其客户签订了条款和条件协议，禁止从其网络运行 Internet 服务。实行这一一般 ISP 政策至少有两个原因：

互联网服务消耗带宽。
ISP 是许多垃圾邮件发送者或恶意 Web 服务的最小障碍。

ISP 通常还将自己的动态 IP 地址池列入黑名单。因此，从 ISP 动态 IP 地址运行的任何邮件服务很可能会被拒绝或直接放入任何大型电子邮件提供商的“垃圾邮件”文件夹中。

黑名单IP拦截

IP黑名单非常简单有效。它在 MTA 配置中用于立即拒绝来自黑名单域的传入邮件。

/etc/postfix/main.cf

...
smtpd_client_restrictions = ...
                            reject_rbl_client cbl.abuseat.org
                            reject_rbl_client pbl.spamhaus.org
                            reject_rbl_client sbl.spamhaus.org
                            reject_rbl_client bl.blocklist.de
...

我的实际服务器日志之一的示例：

Oct 14 04:45:23 xxxx postfix/smtpd[17679]: NOQUEUE: reject: RCPT from xxxxx.xxxx.xxxx.jp[xxx.149.xxx.xxx]: 554 5.7.1 Service unavailable; Client host [xxx.149.xxx.xxx] blocked using sbl.spamhaus.org; https://www.spamhaus.org/sbl/query/SBL319039; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<xxxx.xxx.xxx.jp>

僵尸网络时代端口阻塞和 RBL 的有效性

这些策略在当前的按需 Web 服务器时代之前更为有效。根据我的经验，垃圾邮件发送者和恶意行为者只是从 ISP 连接服务转移到僵尸网络和按需命令与控制 (C&C) 服务器。

大多数针对我自己的服务器的垃圾邮件或暴力攻击都是从通常从 Amazon EC2 IP 地址运行的 C&C 探针开始的。随后是一系列来自遥远国家/地区地址的僵尸网络。

不阻止端口的 ISP

我不确定美国 ISP 是否允许所有端口。然而，我看到一些欧洲互联网服务提供商只是向消费者提供互联网消防水带，没有阻塞端口，也没有过滤器。

所以，除了“与您的 ISP 核实”之外，我没有其他答案。

Question 3

简短的回答可能是：这是 unix 哲学”做一件事并把它做好”。

首先了解MTA与MUA的区别：

MUA（邮件用户代理）（如 Thunderbird 等）是一个允许与用户轻松交互的程序。该程序主要关注用户交互。它将各个邮箱中的当前邮件呈现给用户，并允许用户将邮件发送到给定的邮件地址。附加功能是可能的。主要是它处理所有较低级别的事情以使用户满意。
MTA 是一个后台程序。其唯一目的是提供一个稳定的后端将邮件从一个“位置”传输到另一个“位置”。（这里的“位置”可能意味着主机、人或其他东西。只是为了了解其背后的想法。）它的接口主要是一个编程 API（请参阅SMTP协议）。当然，人类可以伪造此类文本，但在进行现实世界的邮件示例时，手动将其保留在规范中并不容易。
MDA（邮件传递代理）是一个提供对用户邮箱的访问的程序。它也使用编程接口。此类接口的示例有 POP3 或 IMAP。

当用户在他的 MUA 中发送邮件时，MUA 连接到他的 ISP 的 MTA。 MTA 检查用户凭据并接受邮件进行投递。现在，邮件被报告为已发送给用户。 ISP 的 MTA 现在检查如何传递邮件，并可能找到下一个站点来放置邮件。在找到作为邮件最终目的地的主机之前，邮件可以通过这种方式进行多次跃点。此 MTA 将知道如何将其放入目标用户的邮箱（通常位于服务器本地）。接收者现在可以打开他的 MUA 并连接到他的 ISP 的 MDA。 MDA 查看本地文件系统并报告有一条新消息及其内容。

所以简单的答案是：Cron 是一个程序，因此将使用 MTA 的编程接口而不是 MUA。（cron 应该如何与这些程序交互？）

要使用 MTA 发送邮件：连接到端口 25、578 或您使用的端口并使用 SMTP(S) 协议。这正是您的 MUA 在幕后为您所做的事情。您可以/必须使用与 MUA 设置中使用的相同的凭据/主机/端口设置。

MUA 能够与 MTA 进行网络通信。因此，每台计算机上都不需要本地 MTA（您不需要在本地运行 postfix 来运行 Thunderbird，对吗？）。

然而，当我们谈论一台机器上的服务应该能够在任何地方发送邮件时，实际上有两种选择：

程序（例如 cron）知道接受邮件的远程 MTA。这需要对每个程序单独完成，这在管理许多服务时是很麻烦的。
所有邮件都存在一个“默认路由”。然后任何本地程序都可以简单地使用该路由，而无需手动配置。

这里上面提到的unix哲学开始发挥作用：它不是为所有程序实现通信（和授权等），而是实现一次（MTA），并且该程序提供一个默认接口来接受来自本地服务的邮件（通过unix套接字，通过管道连接到命令或网络端口）。这就是大多数服务假定本地 MTA 正在运行的原因。该 MTA 可能是一个非常小的 MTA，它只是将邮件转发到更大的 MTA 进行排序等。

这里事实上的标准是最近的程序 sendmail（也是一个 MTA）。由于它存在巨大的问题，它被其他 MTA（例如 postfix）所取代，后者仍然提供旧的 sendmail 接口（这就是 postfix 数据包中存在 sendmail 包装器的原因）。

编辑1： @Tim，为什么你认为发送和接收需要对称？ MTA 负责服务器间通信。从某种意义上来说，这是对称的，但您只能看到它的一侧（在向其他人发送邮件期间）。接收由您的提供商的服务器完成。邮件传输本身非常快（几毫秒）。

因此，您不需要发送端的 MDA 之类的东西。您只需尝试一下即可将邮件送达。将其视为邮政服务。您只需将包裹扔到邮局，他们会处理任何进一步的设置。

MUA 只是将邮件送上路。一旦它被第一个 MTA 接受，MUA 就认为它是发送。再次以邮政为例：一旦您将包裹放入邮局发送，您就认为它会被送达。如果途中出现任何问题，您将退回包裹。当邮件在途中出现问题时，就会发生这种情况。如果邮件无法传送到下一站，MTA 将向您发送返回信息（所谓的退回邮件）。

现在再次是接收方。我首先再次选择邮政类似物。如果您始终可以联系到并且始终处于同一位置，则邮递员可以直接来找您递送邮件。这意味着 MTA 会直接向您发送邮件。

不幸的是，您有一个非静态IP（您并不总是在同一个位置）并且您绝对不总是在那里（并不总是在家）。因此，MTA 可能会尝试投递邮件，但由于您不在，邮件会被退回（见上文）。

为了避免这种情况，您有自己的邮箱。这在电子邮件和普通邮件中都是如此。邮局官员/MTA 按照他的条件（时间）将邮件放入邮箱。每当需要传递消息时，他都可以这样做。对于 MTA，这意味着将文件保存在专用文件夹中。

邮箱代表您和邮递员之间的同步元素。您可以随时前往邮政信箱你找到合适的并寻找您的帖子。由于 MTA 将邮件保存在服务器上，因此您无法直接访问。这里 MDA 就派上用场了。 MDA 允许代表您根据您的时间访问邮箱。

Answer