发件人、发件人和返回路径之间有什么区别?

发布于 2024-10-06 03:18:16 字数 153 浏览 3 评论 0原文

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

示例:我有一个联系表单,用户可以在其中输入电子邮件,这是否会分配给发件人、发件人或返回路径?

我在 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

谁许谁一生繁华 2024-10-13 03:18:16

因此,通过 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 the From 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 with From set to [email protected]. The actual SMTP submission uses different credentials, something like [email protected]. So, the sender header is set to [email protected], to indicate the From 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.

烟火散人牵绊 2024-10-13 03:18:16

定义此规范的官方 RFC 可以在这里找到:

https://www .rfc-editor.org/rfc/rfc4021#section-2.1.2(查看第 2.1.2 段及以下段落)

2.1.2。标头字段:来自

<前><代码>说明:
留言作者邮箱
[...]
相关信息:
指定消息的作者;即邮箱
负责编写该文件的人员或系统
信息。由 RFC 822 定义为标准。

2.1.3。标头字段:发件人

<前><代码>说明:
消息发送者邮箱
[...]
相关信息:
指定实际负责代理的邮箱
消息的传输。由 RFC 822 定义为标准。

2.1.22。标头字段:返回路径

<前><代码>说明:
消息返回路径
[...]
相关信息:
消息响应诊断的返回路径。另请参阅 RFC 2821
[17]。由 RFC 822 定义为标准。

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)

2.1.2. Header Field: From

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. Header Field: Sender

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. Header Field: Return-Path

Description:
    Message return path
[...]  
Related information:
    Return path for message response diagnostics. See also RFC 2821
    [17]. Defined as standard by RFC 822.
随遇而安 2024-10-13 03:18:16

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

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

A minor update to this: a sender should never set the Return-Path: header. There's no such thing as a Return-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 the 5321.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 a Return-Path: header on a message in transit. See https://www.rfc-editor.org/rfc/rfc5321#section-4.4

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文