我们应用程序的一个主要组件代表其他成员向成员发送电子邮件。目前我们将“发件人”地址设置为我们的系统地址，并使用带有成员地址的“回复”标题。问题是来自某些电子邮件客户端的回复（以及自动回复/退回）不尊重“回复”标头，因此被发送到我们的系统地址，从而有效地将它们发送到黑洞。我们正在考虑将“发件人”地址设置为我们的会员地址，将“发件人”地址设置为我们的系统地址。看来这种方式可以通过 SPF 和 Sender-ID 检查。
有什么理由不改用这种方法吗？还有其他潜在问题吗？
以下是您可能需要的更多详细信息：
最初开发应用程序时，我们只是将“发件人”地址更改为发送成员的地址，因为这是当时的普遍做法（这是很多年前的事了）。后来我们将其更改为“发件人”地址是会员的姓名和我们的地址，即
出自：《玛丽·史密斯》
<messages@company.example>
将“回复”标头设置为成员的地址：
回复：“玛丽·史密斯”
<marysmith@memberisp.example>
这有助于将邮件错误归类为垃圾邮件。随着 SPF 变得越来越流行，我们添加了一个额外的标头，可以与我们的 SPF 记录一起使用：
发件人：
<messages@company.example>
一切正常，但事实证明，在实践中，一些电子邮件客户端和大多数 MTA 不尊重“回复”标题。因此，许多成员将消息发送到 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。