Sender、From 和 Return-Path 有啥区别?
Posted
技术标签:
【中文标题】Sender、From 和 Return-Path 有啥区别?【英文标题】:What's the difference between Sender, From and Return-Path?Sender、From 和 Return-Path 有什么区别? 【发布时间】:2011-05-21 00:32:14 【问题描述】:电子邮件发件人、发件人和返回路径值有什么区别?
示例:我有一个联系表单,用户可以在其中输入他们的电子邮件,这会分配给发件人,发件人还是返回路径?
我在 *** 上快速搜索了一下,找不到任何有用的东西。
【问题讨论】:
【参考方案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
?以上是关于Sender、From 和 Return-Path 有啥区别?的主要内容,如果未能解决你的问题,请参考以下文章
在通过 .NET 发送的电子邮件中设置 Return-Path 的方法是啥?