使用成员的“发件人”地址和“发件人”标头的潜在问题答案

【问题标题】：Potential issues using member's "from" address and the "sender" header使用成员的“发件人”地址和“发件人”标头的潜在问题
【发布时间】：2011-01-14 23:18:03
【问题描述】：

我们应用程序的一个主要组件代表其他成员向成员发送电子邮件。目前我们将“发件人”地址设置为我们的系统地址，并使用带有成员地址的“回复”标题。问题是来自某些电子邮件客户端的回复（以及自动回复/退回）不尊重“回复”标头，因此被发送到我们的系统地址，从而有效地将它们发送到黑洞。我们正在考虑将“发件人”地址设置为我们的会员地址，将“发件人”地址设置为我们的系统地址。看来这种方式可以通过 SPF 和 Sender-ID 检查。

有什么理由不改用这种方法吗？还有其他潜在问题吗？

这里有比你可能需要的更多的细节：

最初开发应用程序时，我们只是将“发件人”地址更改为发送成员的地址，因为这是当时的普遍做法（这是很多年前的事了）。后来我们将其更改为“发件人”地址是会员的姓名和我们的地址，即，

来自：“玛丽·史密斯”<messages@company.example>

将“回复”标头设置为成员的地址：

回复：“玛丽·史密斯”<marysmith@memberisp.example>

这有助于将邮件误归类为垃圾邮件。随着 SPF 变得越来越流行，我们添加了一个额外的标头，可以与我们的 SPF 记录一起使用：

发件人：<messages@company.example>

一切正常，但事实证明，在实践中，一些电子邮件客户端和大多数 MTA 不尊重“Reply-To”标头。因此，许多成员将消息发送到 messages@company.example 而不是所需的成员。

因此，我开始设想各种方案，以将有关发件人的数据添加到电子邮件标头或将其编码到“发件人”电子邮件地址中，以便我们可以处理响应并适当地重定向。例如，

来自：“玛丽·史密斯”<messages+ca54bb7482ace09f@company.example>

“messages”后面的字符串是代表 Mary Smith 在我们系统中的成员的哈希值。当然，由于我们需要为我们的系统地址开发 MTA 功能，这条路径可能会带来很多痛苦。我再次查看 SPF 文档，发现这个页面很有趣：

http://www.openspf.org/Best_Practices/Webgenerated

他们展示了两个例子，evite.com 和 egreetings.com。基本上，evite.com 正在按照我们的方式进行操作。 egreetings.com 示例使用带有“发件人”标头的成员的发件人地址。

所以问题是，使用带有发件人标头的成员发件人地址的 egreetings 方法是否存在任何潜在问题？这将消除不良客户端发送到系统地址的回复。我不相信它可以解决退回/假期/白名单问题，因为即使指定了返回路径，这些问题也经常发送到 MAIL FROM。

【问题讨论】：

标签： email spf

【解决方案1】：

所以我决定回答我自己的问题，因为没有其他人回答。也许其他人会在搜索时找到此条目。

我们最终要做的是：

将 From 标头设置为用户的实际电子邮件地址。

From: "Mary Smith" <marysmith@memberisp.example>

使用带有系统范围电子邮件地址的发件人标头。

Sender: <messages@company.example>

最后，显示在服务器提供的 MAIL FROM/Return Path 标头中的实际发件人设置了唯一标识符，即

Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

这允许在 messages@company.example 上运行的程序拦截这些自动回复并将它们转发给他们最初打算联系的人。大多数真正的电子邮件客户端都会回复 From: 标头。我没有看到黑莓用户或其他人响应系统帐户的问题。

经过一个月左右的生产，我们遇到的问题比我们以前使用的方法少。

发件人标头在 Microsoft Outlook 客户端中添加了一条关于“代表”的小注释，但这适合我们的使用。使用此设置（Gmail、Yahoo、SpamAssassin 等）的普通客户端/mta 中的 SPF 没有任何问题

更新： 2014 年 4 月，Yahoo 和 AOL 更改了其 DMARC 设置，在不另行通知的情况下删除此类邮件。（他们改用 p=reject；有关更多信息，请参阅 https://wordtothewise.com/2014/04/brief-dmarc-primer/。）我们的解决方案是针对这些域的特殊情况，因为所需的功能仍然适用于绝大多数域。

IF ISP MATCHES YAHOO OR AOL

From: "Mary Smith" <messages+ca54bb7482ace09f@company.example>
Reply-To: "Mary Smith" <marysmith@memberisp.example>
Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

ELSE

From: "Mary Smith" <marysmith@memberisp.example>
Sender: <messages@company.example>
Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

END

【讨论】：

感谢您的提问和回答！我发现自己正是你的情况，但在找到你的问题之前就问了一个非常相似的问题。 (stackoverflow.com/questions/4728393/…)
嘿@PaulBurney 你的系统是如何工作的？一切还好吗？
@PaulBurney 在将“发件人”设置为没有 SPF 批准您的电子邮件服务器的域时，我遇到了很多不同域的问题。特别是当 FROM 是 hotmail/gmail 地址并且 TO 是同一个域时。我认为您自己域的发件人地址中的散列编码值是最好的解决方案。你今天对这个话题有什么看法？
从 2018 年开始，有人对此方案有任何更新吗？ @加文