SMTP电子邮件头部:返回路径 vs 发件人 vs 发件地址

28
请帮我整理一下电子邮件头。
以下每个意思是什么:return-path,sender,from。
这个问题是在一个电子邮件接收应用程序的背景下提出的(比如说posterous克隆)。
哪些内容容易伪造?
哪些内容可以验证?
在什么情况下它们中的三个或两个会有所不同?

1
可能是What's the difference between Sender, From and Return-Path?的重复问题。 - MaxiWheat
3个回答

34

基于我的经验 -

  • 发送人是撰写电子邮件的人。这可以由用户的邮件软件设置。

  • 回复路径是应该投递退信通知等的地址。它可以由发送或接收邮件服务器设置,有时也可以由用户的邮件软件设置。对于普通消息,它通常与发送人地址相同。某些消息(通常是系统生成的消息)可能使用不同的回复路径,而退信通知通常将其留空。

  • 发件人是发送电子邮件的人,如果与发送人不同,则为 From 字段后面的名称("Sent by Sender on behalf of From")。有时这由用户的邮件软件设置,有时由他们的邮件服务器设置。如果存在,应与发送人地址不同。

这些标头都很容易伪造,因此验证几乎没有意义。

但是,如果发送域具有 SPF 记录,则您可以将 Received 标头与该域的批准邮件服务器列表进行验证。这至少会告诉您该消息是否真的来自该域,但这并不保证特定用户发送了它(它可能被同一域上的另一个用户欺骗)。此外,并非所有域都发布 SPF 记录,因此这不总是可行的选择。


关于这个问题,需要注意的是,Outlook似乎喜欢即使SenderFrom相同也要有Sender。例如,预览窗格会显示一个空白的发件人,如果Sender头部不在邮件中,即使From存在。 - Jeff Evans
那么 fromsender 可以为空吗?如果这些字段的值为空,你该如何发送电子邮件呢?(如果有人感兴趣,Mailgun 还为这些字段提供了说明。) - Dennis
1
@Dennis 我阅读RFC2822的理解是From头是必需的,而Sender应该或不应该出现取决于情况。看着你提供的Mailgun参考,他们的“from”由“From”消息头填充,但是他们的“sender”由SMTP信封中的“From”填充,而不是“Sender”消息头(我假设您需要从他们的“message-headers”参数中获取)。 - Bill B

8

"From"头部应该显示发送邮件的人。这是收件人邮件客户端应该显示发件人的信息。

Return-Path头部指定回复(或退信/NDR)应该被送到哪里。在邮件列表和许多自动邮件的情况下,它可能与“From”地址不同,因为退信会发送到一个删除无法投递的地址的系统。

发送者可以被视为“From”头部的更具体版本。如果消息是由某个人或其他系统发起的,而非实际的'From'地址,则如gmail配置为非Gmail托管的域名的情况。此时,From头部将包含'you@yourdomain.com',但发送者将是'someuser@gmail.com'。许多邮件客户端现在会呈现为'someuser@gmail.com代表you@yourdomain.com'。“Sender”头部应该用于邮件验证(SPF/DKIM)目的,因为它才是实际发起消息的系统。


0

根据我们的经验,您无法从邮件头中验证发送方身份。

因此,许多人会实现一次性地址(例如:example+uniquecode@example.com),并为每个发件人分配一个地址,以验证谁发送了该消息。其他一些用户在主题行中包含一些内容。

Posterous FAQ's 建议他们正在采取其他措施来确保您所说的是您自己。例如,您可以追踪第一次向您的电子邮件服务器传递电子邮件的服务器的IP / DNS,然后在怀疑存在问题时要求用户确认。虽然很容易伪造标题,但很难接收其传入邮件。


点和加号字符不是只被Gmail支持吗? - Pacerier
“+”并不是这个响应的关键部分。事实上,如果没有一个唯一的标识符作为返回消息的接收者,很难验证发送者。Zendesk使用这种格式(support+xxxxxx-xxxx@dynamicedge.zendesk.com),intercom也是如此(notifications+admin_xxxx_xxxxxxxxxxxxx@intercom-mail.com)。如果您运行自己的邮件服务器或与专门从事传入电子邮件的第三方合作,那么它们通常会支持“+”,但它们也会接受域上的任何唯一地址。 - Steve Smith

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接