发件人、发件人和返回路径之间有什么区别?
电子邮件发件人、发件人和返回路径值之间有什么区别?
示例:我有一个联系表单,用户可以在其中输入电子邮件,这是否会分配给发件人、发件人或返回路径?
我在 StackOverflow 上快速搜索了一下,但没有找到任何有用的东西。
What's the difference between an email Sender, From and Return-Path value?
Example: I have a contact form where the user can input their email, would this be assigned to sender, from or return-path?
I had a quick search on the StackOverflow and couldn't find anything useful.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
因此,通过 SMTP 提交邮件时,SMTP 信封(发件人、收件人等)与邮件的实际数据不同。
Sender
标头用于在消息中识别提交者。这通常与From
标头相同,即消息的发件人。但是,在邮件代理代表其他人发送邮件的某些情况下,情况可能会有所不同。Return-Path
标头用于向收件人(或接收 MTA)指示未送达回执将发送到何处。例如,以允许用户从网页发送邮件的服务器为例。因此,
[email protected]
在消息并提交。然后,服务器将邮件发送给其收件人,并将From
设置为[电子邮件受保护]
。实际的 SMTP 提交使用不同的凭据,例如[email protected]。因此,
sender
标头设置为[email] protected]
,以指示From
标头并不指示实际提交邮件的人。在这种情况下,如果消息无法发送,代理最好接收未送达报告,因此
Return-Path
也应设置为[email protected]
以便任何送达报告都会发送到它而不是发件人。如果您正在这样做,即提交表单来发送电子邮件,那么这可能与您设置标题的方式直接相似。
So, over SMTP when a message is submitted, the SMTP envelope (sender, recipients, etc.) is different from the actual data of the message.
The
Sender
header is used to identify in the message who submitted it. This is usually the same as theFrom
header, which is who the message is from. However, it can differ in some cases where a mail agent is sending messages on behalf of someone else.The
Return-Path
header is used to indicate to the recipient (or receiving MTA) where non-delivery receipts are to be sent.For example, take a server that allows users to send mail from a web page. So,
[email protected]
types in a message and submits it. The server then sends the message to its recipient withFrom
set to[email protected]
. The actual SMTP submission uses different credentials, something like[email protected]
. So, thesender
header is set to[email protected]
, to indicate theFrom
header doesn't indicate who actually submitted the message.In this case, if the message cannot be sent, it's probably better for the agent to receive the non-delivery report, and so
Return-Path
would also be set to[email protected]
so that any delivery reports go to it instead of the sender.If you are doing just that, a form submission to send e-mail, then this is probably a direct parallel with how you'd set the headers.
定义此规范的官方 RFC 可以在这里找到:
https://www .rfc-editor.org/rfc/rfc4021#section-2.1.2(查看第 2.1.2 段及以下段落)
The official RFC which defines this specification could be found here:
https://www.rfc-editor.org/rfc/rfc4021#section-2.1.2 (look at paragraph 2.1.2. and the following)
对此的一个小更新:发送者永远不应该设置
Return-Path:
标头。传输中的消息不存在Return-Path:
标头。该标头由进行最终传递的 MTA 设置,并且通常设置为5321.From
的值,除非本地系统需要某种奇怪的路由。这是一个常见的误解,因为用户很少会在邮箱中看到没有
Return-Path:
标头的电子邮件。这是因为它们始终会看到已发送的邮件,但 MTA 永远不会在传输中的邮件上看到Return-Path:
标头。请参阅 https://www.rfc-editor.org/rfc/rfc5321#section- 4.4A minor update to this: a sender should never set the
Return-Path:
header. There's no such thing as aReturn-Path:
header for a message in transit. That header is set by the MTA that makes final delivery, and is generally set to the value of the5321.From
unless the local system needs some kind of quirky routing.It's a common misunderstanding because users rarely see an email without a
Return-Path:
header in their mailboxes. This is because they always see delivered messages, but an MTA should never see aReturn-Path:
header on a message in transit. See https://www.rfc-editor.org/rfc/rfc5321#section-4.4