【发布时间】：2011-04-19 14:27:19
【问题描述】：
请帮我订一些带有电子邮件标题的订单。
以下各项的含义：return-path、sender、from。
这个问题是在电子邮件接收应用程序的上下文中提出的（假设是posterous 克隆）。
- 什么东西容易伪造？
- 可以验证什么？
- 三者或二者在什么情况下可以不同？
【问题讨论】：
标签： smtp email posterous incoming-mail
【发布时间】：2011-04-19 14:27:19
【问题描述】：
根据我的经验-
发件人是写电子邮件的人。这可以由用户的邮件软件设置。
Return-Path 是退回邮件（无法送达的通知等）应送达的地址。它可以由发送或接收邮件服务器设置，有时也可以由用户的邮件软件设置。对于普通消息，它通常与 From 地址相同。某些消息（通常是系统生成的消息）可能使用不同的 Return-Path，并且退回消息通常会将其留空。
发件人是发送电子邮件的人，如果与发件人不同（“由发件人代表发件人发送”）。有时这是由用户的邮件软件设置的，有时是由他们的邮件服务器设置的。这（如果存在）应该与发件人地址不同。
这些标头都可以很容易地被伪造，因此验证非常困难。
但是，如果发送域有 SPF 记录，您可以根据该域的已批准邮件服务器列表验证 Received 标头。这至少会告诉您消息是否真的来自该域，但这并不能保证特定用户发送它（它可能被同一域上的另一个用户欺骗）。此外，并非所有域都发布 SPF 记录，因此并不总是一种选择。
【讨论】：
-
请注意，Outlook 似乎喜欢使用
Sender，即使它与From相同。例如，如果Sender标头不是邮件的一部分，即使From存在，预览窗格也会显示一个空白发件人。 -
那么
from和sender可以为空吗？您将如何发送包含这些字段的空值的电子邮件？ （如果有人感兴趣，Mailgun also has descriptions for those fields。） -
@Dennis 我对 RFC2822 的阅读使我相信 From 标头是必需的，并且 Sender 应该或不应该根据情况出现。查看您的 Mailgun 参考，他们的“发件人”由“发件人”邮件标题填充，但他们的“发件人”由 SMTP 信封中的“发件人”填充，不是“发件人”邮件header（我假设你需要从他们的“message-headers”参数中获取）
“发件人”标头旨在成为消息来自的人。收件人的电子邮件客户端应该显示邮件的发件人。
Return-Path 标头指定应将回复（或退回/NDR）传送到何处。这可能不同于邮件列表中的“发件人”地址，以及许多自动邮件，其中退回邮件被发送到删除不可投递地址的系统。
可以将发件人视为 From 标头的更具体版本。如果消息是由某人发出的，或者是由实际“发件人”地址的其他系统发出的。示例可能是为非 Gmail 托管的域配置的 gmail。在这种情况下，From 标头将包含“you@yourdomain.com”，但发件人将是“someuser@gmail.com”。许多邮件客户端现在将其呈现为“someuser@gmail.com 代表 you@yourdomain.com”。 “发件人”标头应用于邮件身份验证 (SPF/DKIM)，因为那是实际发送邮件的系统。
【讨论】：
我想补充一点，根据我们的经验，您无法从标头验证谁在发送消息。
出于这个原因，很多人会实施一次性地址 (example+uniquecode@example.com) 并为每条传出消息提供一个发送地址，以此来验证谁在发送消息。其他一些用户在主题行中包含一些内容。
Posterous FAQ's 建议他们正在做一些事情，以确保您是您所说的那个人。例如，您可以跟踪第一次将电子邮件发送到您的电子邮件服务器的服务器的 IP/DNS，然后要求用户确认您是否怀疑存在问题。虽然欺骗标头很容易，但接收他们的传入邮件并不容易。
【讨论】：
-
不是只有Gmail支持点加号吗？
-
+ 并不是这个响应的关键部分。事实是，如果没有唯一标识符作为返回消息的收件人，就很难验证发件人。 Zendesk 使用这种格式 (support+xxxxxx-xxxx@dynamicedge.zendesk.com)，对讲机 (notifications+admin_xxxx_xxxxxxxxxxxxx@intercom-mail.com) 也是如此。如果您运行自己的邮件服务器或与专门处理传入电子邮件的第三方合作，那么他们通常会支持 +，但他们也会接受域中的任何唯一地址。