☰

SMTP“MAIL FROM:”与数据中的“From:”标头不匹配的合理原因

tag-icon • tag-icon email smtp rfc
SMTP“MAIL FROM:”与数据中的“From:”标头不匹配的合理原因

除了邮件列表之外，是否还有其他正当理由导致 SMTP“MAIL FROM：”字段与邮件数据部分的“发件人：”字段不匹配？

从https://stackoverflow.com/questions/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean：

“但是，继续用蜗牛邮件来比喻，大多数专业信件都会在信件本身上印有发件人和收件人的地址。这些地址对邮递员来说不是必需的，而是对收件人的一种礼貌。因此，电子邮件以同样的方式工作是合理的。”

这种逻辑的问题在于：“对收件人的礼貌”。在通过 SMTP 发送的电子邮件中包含“发件人：”地址并不是一种礼貌；如果收件人想要发送回复，那么这是必须的。

从：如何限制发件人标头以匹配 Postfix 中的 MAIL FROM？：

“但如果你真的想确保 From: 和 MAIL FROM，那么你必须应用 header_checks 以便 Return-Path: 匹配 From:”

这样做意味着什么？邮件列表显然会成为一个问题。不同的“MAIL FROM:”和“From:”标头信息还有其他合法用途吗？

答案1

标题和信封发件人地址不匹配的原因有很多。大多数与发送邮件的自动化流程有关，其中需要将投递问题报告给一个地址，该地址不代表邮件的发送者、代表谁发送邮件或应该回复谁。正如您所指出的，邮件列表就是一个很好的例子。

用户邮件客户端发送的邮件可能与地址不同的主要原因是转发邮件。因此，邮件内容应该合理地忠实于原始内容，但如果出现传递错误，则应向转发电子邮件的用户而不是原始发件人报告。

除了 SMTP 标头之外，各种程序还使用各种 MIME 标头来尝试区分原始发件人和中间发件人，以及/或者报告错误的首选地址。例如 Reply-To、Sender、Originally-From、Errors-To 等，每个标头都有不同的语义。其中一些有标准支持，而更多则没有，但可能仍在使用。各种邮件程序在实践中的行为方式差异很大。

处理邮件的方式是否可取与您所问的是否“合法”是两码事。如果您在这里考虑的合法性是指处理潜在垃圾邮件的政策之类的东西，那么不，我认为您无法以这种方式做出简单的区分。

请考虑一下电子邮件的 DKIM 签名以及电子邮件域的邮件服务器的 SPF 身份验证。如果您要发送大量邮件，那么能够以这些方式验证您的邮件可能很重要，这可能会对邮件发件人标头的寻址产生影响，因为您只能验证与您有权限的域相关的邮件。

--

根据要求扩展：

MIME“回复至”标头指示 MUA（邮件用户代理，通常是个人的邮件客户端）将回复发送到不同的地址，而不是 MIME“发件人”地址。MTA（邮件传输代理）不会将此用于诸如错误之类的事情。

通常，MTA 会使用 SMTP 信封“MAIL From”地址来发送错误。可以使用 MIME“Errors-To”标头（这是一条 MTA 指令）覆盖它。并非所有 MTA 都会遵守它，因此它是设置 SMTP 信封地址的次等机制，但在许多情况下，可以在消息中设置 MIME 标头，但不能设置 SMTP 信封发件人地址。例如，在共享托管环境中运行的软件可能会遇到这种情况。

作为对软件代理的指令，“发件人”的含义更加模糊，但它表明了谁或什么发送了电子邮件，这与发件人地址不同，后者更像是代表谁发送了邮件。例如，当您填写在线邮寄政客表格时，生成的电子邮件在发件人标题中使用您的邮件是非常合适的，但发件人地址与设置表格的组织相关。

一些 MUA 软件在转发邮件时使用“Originally-From”，并将转发者的地址用作“From”标头。其他 MUA 将保留“From”地址，并使用“Resent-From”标头。接收这些不同标头电子邮件的 MUA 是否能够有效解释标头，甚至显示这些标头，这存在很大差异。回复已转发给您的邮件时，默认情况下应该回复给谁？也许最好设置“Reply-To”标头？

MUA 的行为是可变的，并且定义不明确，尽管随着时间的推移它似乎确实在不断改进。相比之下，信封的语义则更加明确。通常，MTA 不应该关心 MIME 标头，但随着 MTA 越来越多地被要求对邮件内容负责（例如，参见 SPF 和新兴的 DMARC 标准），人们面临着降低这一立场清晰度的压力。像 Errors-To 这样的长期机制也与 MTA 不查看标头内容的概念相冲突，这也是这些机制始终不一致应用的原因之一。软件作者的理念各不相同。

你可能会发现查看以下内容很有用https://www.rfc-editor.org/rfc/rfc4021#section-2但请记住，众多邮件软件的实际做法各不相同，不一定符合标准。

尝试提出一个关于如何使用邮件的清晰理念是可以的，但不要期望其他人都会按照你认为应该的方式去做事。

答案2

自动处理是一个重要原因。您希望能够发送任何退回/自动回复/错误以进行单独处理，否则这些消息会消失或​​被忽略，或者某些可怜的家伙必须仔细研究它们。是的，可以添加 X- 标头进行处理，但很多时候退回/等不会包含原始电子邮件或仅包含其中的一小部分，您将无法获取源。

例如，假设有人在您的网站上注册，您向他们发送一封电子邮件，感谢他们的注册。您的 MAILFROM 和 From 可能如下所示：

MAIL FROM: <[email protected]>
From: Website X <[email protected]>

这样，用户就可以在邮件客户端中看到“友好发件人”。但如果用户不存在，他们的 MTA 会将退回邮件发送到：

[电子邮件保护]

自动化流程可以轻松地从标题中提取用户 ID（123123123 部分）和创建退回的系统部分（-signup- 部分），并轻松删除/将该用户标记为已禁用。

答案3

smtp 对话中的邮件发件人：被设计为退回邮件的目的地。邮件正文中的发件人：标题用于显示给收件人，如果未设置回复：标题，则用作回复地址。

不应产生退回的电子邮件应在信封中设置空的发件人，例如回执通常会有：mail from:<>发件人：标题中的用户姓名。

另一种情况是邮件服务器使用 BATV 拒绝虚假退回。邮件发件人：将采用以下格式[电子邮件保护]。

答案4

除非我没有正确阅读标题或问题，否则我的黑莓手机发送的电子邮件都是从黑莓手机服务器发送的，而且基本上没有一个字段匹配。我知道只有一小部分用户。我最近在评估我的邮件服务器时一直在关注这个问题。以下是从我的黑莓手机发送到我的 Gmail 帐户的匿名电子邮件：

Delivered-To: [email protected]
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <[email protected]>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <[email protected]>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <[email protected]>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: [email protected]
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <[email protected]>
From: [email protected]
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T

相关内容