38、邮件格式与路由配置全解析

邮件格式与路由配置全解析

在当今多样化的网络环境中，不同的邮件系统和格式相互交织，理解邮件的格式混合、路由机制以及相关配置显得尤为重要。本文将深入探讨邮件格式的混合问题、邮件路由的工作原理以及 elm 邮件客户端的配置方法。

1. 混合不同邮件格式

当不同的邮件系统和聪明的开发者们汇聚在一起时，他们必然会寻求将这些系统相互连接的方法，以实现网络互联。于是，出现了许多不同的邮件网关，能够将两个不同的电子邮件系统连接起来，使邮件可以在它们之间转发。

在连接两个系统时，地址处理是关键问题。例如，将 UUCP 风格的 bang - path 表示法和 RFC - 822 混合使用时，就会出现地址优先级不明确的问题。像 domainA!user@domainB 这样的混合地址，不清楚是应该先将消息发送到 domainB，再由其转发到 domainA!user，还是先发送到 domainA，再由其转发到 user@domainB。

这种混合不同地址运算符的地址被称为混合地址。通常，解决此类问题的方法是让 @ 符号优先于路径，即在 domainA!user@domainB 中，先将消息发送到 domainB。

此外，还有一种在 RFC - 822 中指定路由的方式，如 @domainA,@domainB:user@domainC 表示用户在 domainC 上的地址，domainC 是通过 domainA 和 domainB 按顺序到达的。但不建议依赖这种源路由地址，因为相关 RFC 的修订建议忽略邮件地址中的源路由，而是尝试直接将邮件发送到远程目的地。

另外，还有 % 地址运算符，如 user%domainB@domainA，邮件先发送到 domainA，domainA 会将最右边的 % 符号扩展为 @ 符号，地址变为 user@domainB，然后邮件被转发到 domainB 并送达用户。不过，这种地址类型被称为 “Ye Olde ARPAnet Kludge”，不建议使用。

在 RFC - 822 环境中，应尽量使用绝对地址，如 user@host.domain，避免使用其他类型的地址。

2. 邮件路由工作原理

将消息定向到收件人主机的过程称为路由。它不仅要找到从发送站点到目的地的路径，还涉及错误检查，可能还包括速度和成本优化。

UUCP 站点和 Internet 站点处理路由的方式有很大不同。在 Internet 上，一旦知道收件人主机的 IP 地址，将数据定向到该主机的主要工作由 IP 网络层完成；而在 UUCP 区域，路由需要由用户提供或由邮件传输代理生成。

3. 互联网上的邮件路由

在 Internet 上，目标主机的配置决定是否执行特定的邮件路由。默认情况下，先确定消息应发送到的主机，然后直接将消息发送到该主机。

大多数 Internet 站点希望将所有入站邮件定向到一个高可用性的邮件服务器，由其处理所有流量并在本地分发邮件。为了宣布这项服务，站点会在其 DNS 数据库中为本地域发布所谓的 MX 记录。MX 代表邮件交换器，表明服务器主机愿意为该域中的所有邮件地址充当邮件转发器。MX 记录也可用于处理未直接连接到 Internet 的主机（如 UUCP 网络或 FidoNet 主机）的流量，这些主机的邮件必须通过网关传递。

MX 记录总是被分配一个优先级（正整数）。如果一个主机有多个邮件交换器，邮件传输代理会尝试将消息传输到优先级最低的交换器，只有在该尝试失败时才会尝试优先级更高的主机。如果本地主机本身是目标地址的邮件交换器，它只允许将消息转发到优先级低于自己的 MX 主机，这是避免邮件循环的安全方法。如果一个域没有 MX 记录，或者没有合适的 MX 记录，邮件传输代理可以检查该域是否有相关的 IP 地址，并尝试直接将邮件发送到该主机。

例如，假设 Foobar 公司希望其所有邮件由 mailhub 机器处理，其 DNS 数据库中会有如下 MX 记录：

green.foobar.com.
IN
MX
5
mailhub.foobar.com.

这表明 mailhub.foobar.com 是 green.foobar.com 的邮件交换器，优先级为 5。当主机要向 joe@green.foobar.com 发送消息时，会检查 DNS 并找到指向 mailhub 的 MX 记录。如果没有优先级小于 5 的 MX 记录，消息将被发送到 mailhub，然后由 mailhub 转发到 green。

4. UUCP 世界中的邮件路由

UUCP 网络中的邮件路由比 Internet 上的要复杂得多，因为传输软件本身不执行任何路由操作。早期，所有邮件都必须使用 bang 路径进行寻址。bang 路径指定了一系列用于转发消息的主机，主机之间用感叹号分隔，最后是用户名。例如，要给名为 moria 的机器上的用户 Janet 发送邮件，路径为 eek!swim!moria!janet，邮件将从你的主机发送到 eek，再到 swim，最后到 moria。

这种技术的明显缺点是需要记住比 Internet 路由更多的网络拓扑和快速链接等信息。而且，网络拓扑的变化（如链接删除或主机移除）可能会导致消息发送失败，因为你可能没有意识到这些变化。此外，如果你更换了位置，很可能需要更新所有这些路由。

为了解决主机名歧义的问题，成立了 UUCP 映射项目。该项目位于罗格斯大学，负责注册所有官方 UUCP 主机名，并记录其 UUCP 邻居和地理位置信息，确保主机名不重复。该项目收集的信息以 Usenet 地图的形式发布，并通过 Usenet 定期分发。一个典型的地图系统条目如下：

moria
bert(DAILY/2),
swim(WEEKLY)

这表明 moria 与 bert 有连接，每天连接两次；与 swim 有连接，每周连接一次。

利用地图中提供的连接信息，可以自动生成从你的主机到任何目标站点的完整路径。这些信息通常存储在路径文件（也称为 pathalias 数据库）中。例如，如果地图显示可以通过 ernie 到达 bert，那么根据上述地图片段生成的 moria 的 pathalias 条目可能如下：

moria
ernie!bert!moria!%s

当你指定目标地址为 janet@moria.uucp 时，邮件传输代理（MTA）会选择上述路由，并将消息发送到 ernie，信封地址为 bert!moria!janet。

然而，从完整的 Usenet 地图构建路径文件并不是一个好主意，因为其中提供的信息通常会有偏差，而且偶尔会过时。因此，只有少数主要主机使用完整的 UUCP 世界地图来构建其路径文件。大多数站点只维护其附近站点的路由信息，将数据库中找不到的任何邮件发送到一个具有更完整路由信息的更智能的主机，这种方案称为智能主机路由。只有一个 UUCP 邮件链接的主机（所谓的叶节点）自己不进行任何路由，完全依赖其智能主机。

5. 混合 UUCP 和 RFC - 822

到目前为止，解决 UUCP 网络中邮件路由问题的最佳方法是在 UUCP 网络中采用域名系统。当然，不能通过 UUCP 查询名称服务器，但许多 UUCP 站点已经形成了小的域，在内部协调其路由。在地图中，这些域宣布一两个主机作为其邮件网关，这样就不需要为域中的每个主机都设置一个地图条目。网关处理流入和流出该域的所有邮件，域内的路由方案对外部世界完全不可见。

这种方法与智能主机路由方案配合得很好。全局路由信息仅由网关维护；域内的次要主机只需要一个小的手写路径文件，列出其域内的路由和到邮件中心的路由。甚至邮件网关也不再需要世界上每个 UUCP 主机的路由信息。除了为其所服务的域提供完整的路由信息外，它们现在只需要在其数据库中包含到整个域的路由。例如，以下 pathalias 条目将把 sub.org 域中所有站点的邮件路由到 smurf：

.sub.org
swim!smurf!%s

发往 claire@jones.sub.org 的邮件将被发送到 swim，信封地址为 smurf!jones!claire。

域名空间的分层组织允许邮件服务器将更具体的路由与不太具体的路由混合使用。例如，法国的一个系统可能对 fr 的子域有特定的路由，但将美国域中主机的任何邮件路由到美国的某个系统。这种基于域的路由技术大大减少了路由数据库的大小，以及所需的管理开销。

在 UUCP 环境中使用域名的主要好处是，符合 RFC - 822 标准允许在 UUCP 网络和 Internet 之间轻松建立网关。如今，许多 UUCP 域都与一个充当其智能主机的 Internet 网关建立了连接。通过 Internet 发送消息更快，而且路由信息更可靠，因为 Internet 主机可以使用 DNS 而不是 Usenet 地图。

为了能从 Internet 访问，基于 UUCP 的域通常让其 Internet 网关为它们宣布一个 MX 记录。例如，假设 moria 属于 orcnet.org 域，gcc2.groucho.edu 充当其 Internet 网关。那么 moria 将使用 gcc2 作为其智能主机，以便将所有发往外部域的邮件通过 Internet 发送。另一方面，gcc2 将为 .orcnet.org 宣布一个 MX 记录，并将所有发往 orcnet 站点的入站邮件发送到 moria。 .orcnet.org 中的星号是一个通配符，匹配该域中没有其他相关记录的所有主机，这对于仅支持 UUCP 的域来说通常是这样的。

剩下的唯一问题是 UUCP 传输程序无法处理完全限定的域名。大多数 UUCP 套件被设计为处理最多 8 个字符的站点名称，有些甚至更少，而且对于大多数套件来说，使用点号等非字母数字字符是完全不可能的。

因此，需要在 RFC - 822 名称和 UUCP 主机名之间进行映射。这种映射完全依赖于实现。一种常见的将完全限定域名（FQDN）映射到 UUCP 名称的方法是使用 pathalias 文件：

moria.orcnet.org
ernie!bert!moria!%s

这将从指定完全限定域名的地址生成一个纯 UUCP 风格的 bang 路径。一些邮件程序为此提供了一个特殊的文件，例如 sendmail 使用 uucpxtable。

当从 UUCP 网络向 Internet 发送邮件时，有时需要进行反向转换（俗称域名化）。只要邮件发送者在目标地址中使用完全限定域名，在将消息转发到智能主机时不删除信封地址中的域名，就可以避免这个问题。然而，仍然有一些 UUCP 站点不属于任何域，它们通常通过附加伪域 uucp 进行域名化。

pathalias 数据库为基于 UUCP 的网络提供了主要的路由信息。一个典型的条目如下（站点名称和路径用制表符分隔）：

moria.orcnet.org
ernie!bert!moria!%s
moria
ernie!bert!moria!%s

这使得所有发往 moria 的消息都通过 ernie 和 bert 传递。如果邮件程序没有单独的方法在这些名称空间之间进行映射，则必须同时提供 moria 的完全限定名称和其 UUCP 名称。

如果你想将所有发往域内主机的消息定向到其邮件中继，也可以在 pathalias 数据库中指定路径，以点号开头的域名作为目标。例如，如果 sub.org 中的所有主机都可以通过 swim!smurf 到达，pathalias 条目可能如下：

.sub.org
swim!smurf!%s

只有在运行不需要进行大量路由的站点时，手动编写 pathalias 文件才是可以接受的。如果你需要为大量主机进行路由，更好的方法是使用 pathalias 命令从地图文件创建该文件。地图文件更容易维护，因为你可以通过编辑系统的地图条目并重新创建地图文件来简单地添加或删除系统。虽然 Usenet 映射项目发布的地图不再广泛用于路由，但较小的 UUCP 网络可能会在其自己的地图集中提供路由信息。

地图文件主要由每个系统轮询或被轮询的站点列表组成。系统名称从第一列开始，后面是用逗号分隔的链接列表。如果下一行以制表符开头，列表可以跨多行继续。每个链接由站点名称和括号内的成本组成。成本是一个由数字和符号表达式（如 DAILY 或 WEEKLY）组成的算术表达式。以井号开头的行将被忽略。

例如，假设 moria 每天两次轮询 swim.twobirds.com，每周一次轮询 bert.sesame.com，并且与 bert 的连接使用 2400 bps 的慢速调制解调器。moria 将发布以下地图条目：

moria.orcnet.org
bert.sesame.com(DAILY/2),
swim.twobirds.com(WEEKLY+LOW)
moria.orcnet.org = moria

最后一行也使 moria 以其 UUCP 名称为人所知。请注意，其成本必须指定为 DAILY/2，因为每天连接两次实际上使该链接的成本减半。

利用这些地图文件中的信息，pathalias 能够计算出路径文件中列出的任何目标站点的最佳路由，并从中生成一个 pathalias 数据库，然后可用于向这些站点进行路由。

pathalias 还提供了一些其他功能，如站点隐藏（即仅通过网关使站点可访问）。有关详细信息和完整的链接成本列表，请参阅 pathalias 手册页。

地图文件中的注释通常包含有关其中描述的站点的附加信息。有一个严格的格式来指定此信息，以便可以从地图中检索它。例如，一个名为 uuwho 的程序使用从地图文件创建的数据库以良好的格式显示此信息。当你向分发地图文件给其成员的组织注册你的站点时，通常需要填写这样的地图条目。以下是一个示例地图条目（实际上是 Olaf 站点的条目）：

#N
monad, monad.swb.de, monad.swb.sub.org
#S
AT 486DX50; Linux 0.99
#O
private
#C
Olaf Kirch
#E
okir@monad.swb.de
#P
Kattreinstr. 38, D-64295 Darmstadt, FRG
#L
49 52 03 N / 08 38 40 E
#U
brewhq
#W
okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993
#
monad
brewhq(DAILY/2)
# Domains
monad = monad.swb.de
monad = monad.swb.sub.org

前两个字符后的空白是制表符。大多数字段的含义非常明显，你将从注册的任何域获得详细描述。L 字段最有趣，它给出了你的地理位置（纬度/经度），用于绘制显示每个国家以及全球所有站点的 PostScript 地图。

6. 配置 elm

elm 是 “electronic mail” 的缩写，是一个命名合理的 Unix 工具，它提供了一个全屏界面和良好的帮助功能。这里不讨论如何使用 elm，只关注其配置选项。

理论上，你可以在未配置的情况下运行 elm，如果运气好的话，一切也能正常工作。但有一些选项必须设置，尽管这些选项只是偶尔需要。

elm 启动时，会从 /etc/elm 中的 elm.rc 文件读取一组配置变量，然后尝试读取你主目录中的 .elm/elmrc 文件。这个文件通常不是你自己编写的，而是在你从 elm 的选项菜单中选择 “Save new options” 时创建的。

私有 elmrc 文件中的选项集也可以在全局 elm.rc 文件中找到。大多数私有 elmrc 文件中的设置会覆盖全局文件中的设置。

7. 全局 elm 选项

在全局 elm.rc 文件中，必须设置与你主机名相关的选项。例如，在 Virtual Brewery，vlager 的文件包含以下内容：

#
# The local hostname
hostname = vlager
#
# Domain name
hostdomain = .vbrew.com
#
# Fully qualified domain name
hostfullname = vlager.vbrew.com

这些选项设置了 elm 对本地主机名的认知。虽然这些信息很少使用，但你应该设置这些选项。请注意，这些特定选项只有在全局配置文件中设置时才会生效，在私有 elmrc 文件中找到时将被忽略。

8. 国家字符集

已经开发了一组标准和 RFC 来修改 RFC - 822 标准，以支持各种类型的消息，如纯文本、二进制数据、PostScript 文件等。这些标准通常被称为 MIME（Multipurpose Internet Mail Extensions，多用途 Internet 邮件扩展）。除其他功能外，MIME 还可以让收件人知道在编写消息时是否使用了除标准 ASCII 之外的字符集，例如使用法语重音或德语变音符号。elm 在一定程度上支持这些字符。

Linux 内部用于表示字符的字符集通常称为 ISO - 8859 - 1，它符合相应的标准，也称为 Latin - 1。任何使用该字符集字符的消息，其头部应包含以下行：

Content - Type: text/plain; charset = iso - 8859 - 1

接收系统应识别此字段，并在显示消息时采取适当措施。纯文本消息的默认字符集值为 us - ascii。

为了能够显示使用除 ASCII 之外字符集的消息，elm 必须知道如何打印这些字符。默认情况下，当 elm 收到字符集字段不是 us - ascii（或者内容类型不是纯文本）的消息时，它会尝试使用一个名为 metamail 的命令来显示消息。需要使用 metamail 显示的消息在概览屏幕的第一列会显示一个 M。

由于 Linux 的本地字符集是 ISO - 8859 - 1，因此显示使用该字符集的消息时不需要调用 metamail。如果告诉 elm 显示器支持 ISO - 8859 - 1，它将直接显示消息而不使用 metamail。可以通过在全局 elm.rc 中设置以下选项来启用此功能：

displaycharset = iso - 8859 - 1

请注意，即使你永远不会发送或接收包含除 ASCII 之外字符的消息，也应该设置此选项。这是因为发送此类消息的人通常会将邮件程序配置为默认在邮件头部添加正确的 Content - Type 字段，无论他们是否发送仅包含 ASCII 的消息。

然而，仅在 elm.rc 中设置此选项是不够的。当使用其内置分页器显示消息时，elm 会为每个字符调用一个库函数来确定它是否可打印。默认情况下，此函数只将 ASCII 字符识别为可打印字符，并将所有其他字符显示为 ^?。你可以通过将环境变量 LC_CTYPE 设置为 ISO - 8859 - 1 来克服此问题，这会告诉库接受 Latin - 1 字符为可打印字符。自 Linux 标准库的 4.5.8 版本起，就支持此功能和其他相关功能。

当发送包含 ISO - 8859 - 1 特殊字符的消息时，你应该确保在 elm.rc 文件中设置另外两个变量：

charset = iso - 8859 - 1
textencoding = 8bit

这会使 elm 在邮件头部将字符集报告为 ISO - 8859 - 1，并以 8 位值发送（默认是将所有字符截断为 7 位）。

当然，我们讨论的所有字符集选项也可以在私有 elmrc 文件中设置，而不是在全局文件中设置，这样如果全局设置不适合，个别用户可以有自己的默认设置。

综上所述，了解不同邮件格式的混合、邮件路由的工作原理以及 elm 邮件客户端的配置方法，对于在复杂的网络环境中高效、准确地处理邮件至关重要。通过合理配置和使用这些技术，我们可以更好地应对各种邮件处理需求。

邮件格式与路由配置全解析

9. 邮件路由工作流程总结

为了更清晰地理解邮件路由的工作流程，我们可以将 Internet 和 UUCP 网络的邮件路由过程分别梳理成流程图。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B{目标主机是否在 Internet?}:::decision
    B -->|是| C(查询 DNS 获取 MX 记录):::process
    C --> D{是否有合适的 MX 记录?}:::decision
    D -->|是| E(选择优先级最低的 MX 主机):::process
    E --> F(发送邮件到 MX 主机):::process
    D -->|否| G(查询目标主机的 IP 地址):::process
    G --> H(直接发送邮件到目标主机):::process
    B -->|否| I(判断是否在 UUCP 网络):::process
    I --> J{是否有可用的路由信息?}:::decision
    J -->|是| K(根据 pathalias 数据库生成路由):::process
    K --> L(发送邮件到路由起点):::process
    J -->|否| M(发送邮件到智能主机):::process
    F --> N([结束]):::startend
    H --> N
    L --> N
    M --> N

这个流程图展示了邮件在不同网络环境下的路由选择，当目标主机在 Internet 时，优先根据 MX 记录进行路由；当目标主机在 UUCP 网络时，根据本地的路由信息或智能主机进行路由。

10. 不同邮件地址格式对比

为了更直观地对比不同邮件地址格式的特点和使用场景，我们可以列出一个表格。
| 地址格式 | 示例 | 特点 | 使用场景 |
| — | — | — | — |
| UUCP 风格 bang - path | eek!swim!moria!janet | 需要明确指定路由路径，依赖网络拓扑信息 | 早期 UUCP 网络，网络拓扑相对稳定且简单 |
| RFC - 822 | user@host.domain | 简单直观，符合标准规范，依赖 DNS 解析 | Internet 网络，广泛应用于现代邮件系统 |
| 混合地址（如 domainA!user@domainB） | domainA!user@domainB | 地址优先级不明确，容易产生歧义 | 不同邮件系统混合使用的过渡场景 |
| 源路由地址（如 @domainA,@domainB:user@domainC ） | @domainA,@domainB:user@domainC | 明确指定路由路径，但不被推荐使用 | 特殊需求下需要手动指定路由的情况 |
| % 地址运算符（如 user%domainB@domainA） | user%domainB@domainA | 通过扩展 % 符号实现地址转换 | 特定的旧系统或过渡阶段使用 |

通过这个表格，我们可以清晰地看到不同邮件地址格式的优缺点和适用场景，在实际使用中可以根据具体情况选择合适的地址格式。

11. elm 配置的注意事项和常见问题解决

在配置 elm 时，有一些注意事项和常见问题需要我们关注。
- 主机名配置 ：
- 注意事项：全局 elm.rc 文件中的主机名相关选项（hostname、hostdomain、hostfullname）只有在全局配置文件中设置才生效，私有 elmrc 文件中的设置会被忽略。
- 常见问题及解决方法：如果邮件发送或接收时显示主机名错误，检查全局 elm.rc 文件中的主机名配置是否正确。
- 字符集配置 ：
- 注意事项：显示非 ASCII 字符集的消息时，不仅要在 elm.rc 中设置 displaycharset = iso - 8859 - 1，还要设置环境变量 LC_CTYPE = ISO - 8859 - 1。
- 常见问题及解决方法：如果收到的非 ASCII 字符集消息显示乱码，检查上述两个配置是否正确设置。如果仍然有问题，检查系统的字符集支持是否完整。
- 配置文件管理 ：
- 注意事项：私有 elmrc 文件中的设置会覆盖全局 elm.rc 文件中的设置，因此在进行个性化配置时要注意这一点。
- 常见问题及解决方法：如果发现某些配置没有生效，检查私有 elmrc 文件中是否有冲突的设置。

12. 邮件路由和配置的未来发展趋势

随着网络技术的不断发展，邮件路由和配置也在不断演进。以下是一些可能的发展趋势：
- 智能化路由 ：未来的邮件路由系统可能会更加智能化，能够根据网络状况、邮件优先级等因素自动选择最优的路由路径，提高邮件传输的效率和可靠性。
- 标准化和兼容性提升 ：随着邮件系统的不断融合和发展，对邮件格式和协议的标准化要求会越来越高，以确保不同系统之间的兼容性和互操作性。
- 安全性能增强 ：邮件安全一直是一个重要的问题，未来的邮件路由和配置可能会更加注重安全性能的提升，例如采用更先进的加密技术、身份验证机制等。
- 与云计算和大数据的结合 ：云计算和大数据技术的发展为邮件系统带来了新的机遇，未来的邮件路由和配置可能会与这些技术相结合，实现更高效的邮件处理和管理。

13. 总结与建议

通过本文的介绍，我们深入了解了邮件格式的混合、邮件路由的工作原理以及 elm 邮件客户端的配置方法。在实际应用中，我们可以根据以下建议来优化邮件处理：
- 选择合适的邮件地址格式 ：在 RFC - 822 环境中，优先使用绝对地址（如 user@host.domain），避免使用容易产生歧义的混合地址。
- 合理配置邮件路由 ：在 Internet 上，利用 MX 记录来优化邮件路由；在 UUCP 网络中，采用智能主机路由和基于域的路由技术，减少路由数据库的大小和管理开销。
- 正确配置 elm ：根据实际需求，正确配置 elm 的全局和私有配置文件，确保主机名和字符集等设置正确，以提高邮件处理的效率和准确性。
- 关注技术发展趋势 ：及时了解邮件路由和配置的未来发展趋势，以便在合适的时候采用新的技术和方法，提升邮件系统的性能和安全性。

邮件处理是一个复杂而重要的领域，通过不断学习和实践，我们可以更好地掌握邮件格式、路由和配置的相关知识，为我们的工作和生活提供更高效、便捷的邮件服务。