合法原因 SMTP“MAIL FROM:”将与 DATA 中的“From:”标头不匹配

dko*_*vic 24 email smtp rfc

除了邮件列表之外,SMTP“MAIL FROM:”字段与邮件数据部分中的“From:”字段不匹配是否有正当理由?

来自/sf/ask/122513611/

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

这条逻辑线的问题在于:“对收件人的礼貌”。通过 SMTP 在电子邮件中包含“发件人:”地址不是一种礼貌;如果收件人要能够发送回复,则需要它。

From:如何限制 From 标头以匹配 postfix 中的 MAIL FROM?

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

这样做有什么影响?邮件列表显然是一个问题。是否还有其他合法用途不同的“MAIL FROM:”和“From:”标头信息?

mc0*_*c0e 24

Header 和 Envelope From 地址可能不匹配的原因有很多。大多数涉及发送邮件的自动化流程,其中需要将投递问题报告给一个地址,该地址不代表发送邮件的人、代表发送的人或应回复的人。正如您所指出的,邮件列表就是一个很好的例子。

从用户的邮件客户端发送的邮件可能与地址不同的主要原因是转发邮件。邮件内容应合理忠实于原始内容,但如果出现投递错误,则应将这些内容报告给转发电子邮件的用户,而不是原始发件人。

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

一种处理邮件的方式是否可取与您问的是否“合法”不同。如果您正在考虑处理潜在垃圾邮件的政策等方面的合法性,那么不,我认为您无法以这种方式进行简单的区分。

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

——

应要求扩展:

MIME 'Reply-To' 标头指示 MUA(邮件用户代理,通常是一个人的邮件客户端)将回复发送到不同的地址,而不是 MIME 的“发件人”地址。MTA(邮件传输代理)不会将其用于诸如错误之类的事情。

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

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

某些 MUA 软件在转发邮件时使用“Originally-From”,“From”标头使用转发器的地址。其他 MUA 将单独保留发件人地址,并使用“Resent-From”标头。收到这些不同标题电子邮件的 MUA 是否有用地解释标题,甚至显示它们是非常可变的。回复已转发给您的邮件时,默认情况下应该回复给谁?也许最好设置“回复”标题?

MUA 的行为是可变的,并且定义不明确,尽管它似乎随着时间的推移而有所改善。相比之下,Envelope 的语义更加明确。MTA 永远不应该关注 MIME 标头,这通常是一种强硬立场,但随着 MTA 越来越多地对邮件内容负责(例如,参见 SPF 和新兴的 DMARC 标准),该立场的清晰度面临着降低的压力。像 Errors-To 这样的长期存在的机制也与 MTA 不查看头内容的概念相冲突,这就是为什么这些机制总是被不一致地应用的部分原因。软件作者的哲学各不相同。

您可能会发现查看http://tools.ietf.org/html/rfc4021#section-2很有用,但请记住,大量邮件软件的实际做法各不相同,这些方式不一定是标准所祝福的。

尝试提出您认为应该如何使用邮件的清晰理念是很好的,但不要期望其他人会按照您认为的方式做事。


小智 12

自动化处理是一个重要原因。您希望能够发送任何退回/自动回复/错误以单独处理,否则这些消息会消失,或被忽略,或者一些可怜的 sap 不得不挖掘它们。是的,添加 X- 标头进行处理是可能的,但很多时间会反弹/等等。不会包含原始电子邮件或仅包含其中的一部分,您将无法获得源。

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

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>
Run Code Online (Sandbox Code Playgroud)

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

user-signup-123123123@bounces.example.com

并且自动化过程可以轻松地从标题中提取用户 ID(123123123 部分)和创建反弹的系统部分(-signup- 部分),并轻松删除/标记该用户为禁用。


Ric*_*lts 8

smtp 对话中的邮件 from: 被设计为退回邮件的地方 邮件正文中的 From: 标头用于向收件人显示,如果 Reply-to: 标头未设置,则用作回复地址。

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

另一种情况是邮件服务器使用 BATV 来拒绝伪造的退回邮件。来自:的邮件格式为 prvs=tag-value=mailbox@example.com。