Sender、From 和 Return-Path 有什么区别？答案

【问题标题】：What's the difference between Sender, From and Return-Path?Sender、From 和 Return-Path 有什么区别？
【发布时间】：2011-05-21 00:32:14
【问题描述】：

电子邮件发件人、发件人和返回路径值有什么区别？

示例：我有一个联系表单，用户可以在其中输入他们的电子邮件，这会分配给发件人，发件人还是返回路径？

我在 StackOverflow 上快速搜索了一下，找不到任何有用的东西。

【问题讨论】：

标签： email smtp

【解决方案1】：

对此的小更新：发件人不应设置Return-Path: 标头。对于正在传输的消息，没有 Return-Path: 标头之类的东西。该标头由最终交付的 MTA 设置，并且通常设置为 5321.From 的值，除非本地系统需要某种古怪的路由。

这是一个常见的误解，因为用户很少会在邮箱中看到没有Return-Path: 标头的电子邮件。这是因为他们总是会看到已传递的邮件，但 MTA 永远不会在传输中的邮件上看到 Return-Path: 标头。见https://www.rfc-editor.org/rfc/rfc5321#section-4.4

【讨论】：

使用电子邮件客户端的发件人不会设置它，但编写发送电子邮件的脚本的“发件人”可能会按脚本设置它，因此我认为说发件人永远不应该设置它是一种误导。
很遗憾，Chilinut 实际上是不准确的。正在传输的消息上的 Return-Path: 标头将被丢弃，执行最终传递的 MDA（邮件传递代理）将设置 Return-Path: 标头以匹配 5321.From (envelope-from) 携带的值消息。这是因为在传递消息时信封丢失了，因此 Return-Path: 标头记录了 MDA 收到消息时的信封来源。
Return-Path: 标头反映了信封发件人或 RFC5321.From 地址。 From: 标头反映 header-from 或 RFC5322.From 地址。
这是语义，重要的是（如上）发送消息时不能设置Return-Path: 标头。如果是这样，它将在传输过程中被丢弃，然后由 MDA 设置为 RFC5321.From 或信封的值，最终传递消息。基本上，Return-Path: 标头记录了信封的来源，因为信封在交付时被丢弃。
邮件信封中的返回路径与信封发件人相同。但是，Return-Path: 标头是消息正文的一部分，由 MDA 设置。

【解决方案2】：

定义此规范的官方 RFC 可在此处找到：

https://www.rfc-editor.org/rfc/rfc4021#section-2.1.2（查看第 2.1.2 段及以下内容）

2.1.2.标头字段：来自

Description:  
    Mailbox of message author  
[...]  
Related information:
    Specifies the author(s) of the message; that is, the mailbox(es)
    of the person(s) or system(s) responsible for the writing of the
    message. Defined as standard by RFC 822.

2.1.3。标头字段：发件人

Description:  
    Mailbox of message sender  
[...]  
Related information:
    Specifies the mailbox of the agent responsible for the actual
    transmission of the message.  Defined as standard by RFC 822.

2.1.22。头域：返回路径

Description:
    Message return path
[...]  
Related information:
    Return path for message response diagnostics. See also RFC 2821
    [17]. Defined as standard by RFC 822.

【讨论】：

感谢您提供官方 RFC 链接。如果有人问“基于什么？”，这真的很有用
This other answer（自 2011 年起）声称此处指出的方法会导致 gmail 将电子邮件标记为垃圾邮件。我想知道今天是否仍然如此。
在 RFC 5322 tools.ietf.org/html/rfc5322#section-3.6 中更新。有人可以告诉 SMTP RFC 人员，如果 Sender 字段必须与 SMTP 握手过程中使用的 From 地址匹配（如果要使用），这将有所帮助。

【解决方案3】：

因此，通过 SMTP 提交邮件时，SMTP 信封（发件人、收件人等）与邮件的实际数据不同。

Sender 标头用于在邮件中标识提交它的人。这通常与From 标头相同，即消息来自谁。但是，在邮件代理代表其他人发送邮件的某些情况下，它可能会有所不同。

Return-Path 标头用于向收件人（或接收 MTA）指示未送达收据将发送到何处。

例如，以允许用户从网页发送邮件的服务器为例。因此，sender@yourcompany.com 输入消息并提交。然后服务器将消息发送给其收件人，并将From 设置为sender@yourcompany.com。实际的 SMTP 提交使用不同的凭据，例如 mailagent@mywebmail.com。所以，sender 标头设置为mailagent@mywebmail.com，表明From 标头并不表明谁实际提交了邮件。

在这种情况下，如果无法发送消息，那么代理接收未送达报告可能会更好，因此Return-Path 也将设置为mailagent@mywebmail.com，以便任何送达报告都转到它发件人。

如果您只是这样做，提交表单以发送电子邮件，那么这可能与您设置标题的方式直接相似。

【讨论】：

同样，您不必设置所有内容。即，如果您省略发件人和返回路径，它们会转到发件人地址。如果您省略返回路径，我认为 NDR 会发送给发件人。
... 这对于邮件轰炸机来说是一个有吸引力的麻烦。不要那样做！
我理解对了吗？在谈到用于提交电子邮件的 Web 表单时，Sender 是提交 Web 表单的人，From 是发送出去的服务器电子邮件？还是反过来？
想象一下某个有助理管理邮箱的 VIP。如果助理正在代表 VIP 写电子邮件，则助理是 Sender，但消息是 From VIP。当您看到描述为“来自代表 VIP 的助理”的电子邮件时会发生这种情况
@ShawnD.，如果没有Return-Path 怎么办。那么它是否默认为Sender？