发件人,发件人和返回路径有什么区别?


138

电子邮件发件人,发件人和返回路径值之间有什么区别?

示例:我有一个联系表,用户可以在其中输入他们的电子邮件,这将被分配给发件人,来自还是返回路径?

我对StackOverflow进行了快速搜索,找不到有用的东西。

Answers:


171

因此,通过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使任何传递报告都发送给它,而不是发送者。

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


1
同样,您不必设置所有内容。即,如果您忽略了发件人和返回路径,则它们将转到发件人地址。我认为,如果不考虑返回路径,则NDR会发送给发件人。
肖恩D.

1
...这对邮件轰炸机来说是一个令人讨厌的麻烦。不要那样做!
2013年

我理解这个权利吗?在谈到提交的电子邮件网络的形式,将Sender谁提交的网络形式和From服务器发送出去的电子邮件?还是相反?
伊桑·莱罗伊

7
想象一下,有一位VIP助手正在管理其邮箱。如果助手代表VIP编写电子邮件,则助手为Sender,而消息为FromVIP。这是当您看到描述为“代表VIP的助理发送的电子邮件”时发生的情况
2015年

@ShawnD。,如果没有Return-Path。是否默认为Senderthen?
Pacerier '17

99

定义此规范的官方RFC可在以下位置找到:

http://tools.ietf.org/html/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.

4
感谢您提供正式的RFC链接。如果有人问“基于什么?”,这真的很有用。
bayuah 2015年

这个其他答案(从2011年开始)声称,此处指出的方法导致gmail将电子邮件标记为垃圾邮件。我想知道今天是否仍然如此。
showdev 2013年

在RFC 5322 tools.ietf.org/html/rfc5322#section-3.6中更新。有人可以告诉SMTP RFC人们,如果要使用发件人字段必须与SMTP握手过程中使用的“发件人”地址相匹配的话,这会有所帮助。
BeowulfNode42

22

对此进行较小的更新:发送者永远不要设置Return-Path:标头。Return-Path:传输消息中没有标题。该标头由进行最终传递的MTA设置,并且通常设置为的值,5321.From除非本地系统需要某种古怪的路由。

这是一种常见的误解,因为用户很少会看到邮箱中没有Return-Path:标题的电子邮件。这是因为他们总是看到传递的邮件,但是MTA永远都不会看到Return-Path:正在传输的邮件的标头。参见http://tools.ietf.org/html/rfc5321#section-4.4


使用电子邮件客户端的发件人不会设置它,但是编写发送电子邮件脚本的“发件人”可以按脚本设置它,因此,我认为说发件人不应设置它会引起误解。
chiliNUT 2015年

3
不幸的是,Chilinut实际上是不准确的。正在传送的邮件上的Return-Path:标头将被丢弃,执行最终传递的MDA(邮件传递代理)将设置Return-Path:标头以匹配由以下项携带的5321.From(信封-发件人)的值消息。这是因为在传递邮件时信封丢失了,所以Return-Path:标头记录了MDA收到邮件时信封来自的位置。
cmeid 2015年

我现在正在查看收件箱中邮件的标题,它有一个From:地址和(一个不同的Return-Path:地址,所以我不知道您在说什么
chiliNUT 2015年

2
Return-Path:标题反映了信封从,或RFC5321.From地址。该From:标题反映了头,从,或RFC5322.From地址。
cmeid 2015年

5
它已经成为语义,重要的是(如上所述),您不能Return-Path:在发送消息时设置标头。如果是的话,它将在传输过程中被丢弃,然后由进行最终传递消息的MDA设置为RFC5321发件人或信封发件人的值。Return-Path:标题基本上记录了信封的来源,因为信封在交付时就被丢弃了。
cmeid 2015年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.