我们的应用程序的一个主要组成部分是代表其他成员发送电子邮件给会员。目前，我们将“发件人”地址设置为我们的系统地址，并使用“回复地址”标头与成员地址一起使用。问题是，某些电子邮件客户端（以及自动回复/退信）不尊重“回复地址”标头，因此将其发送到我们的系统地址，实际上是将它们发送到黑洞中。我们正在考虑将“发件人”地址设置为我们会员的地址，并将“发送者”地址设置为我们的系统地址。看起来这种方式可以通过SPF和Sender-ID检查。
是否有任何原因不切换到此方法？还存在其他潜在问题吗？
以下是更详细的信息：
当应用程序首次开发时，我们只是将“发件人”地址更改为发送成员的地址，因为那是当时的常见做法（很多年前）。后来，我们将“发件人”地址更改为成员的名称和我们的地址，例如：
From: "Mary Smith" 并设置“回复地址”标头为成员的地址：
Reply-To: "Mary Smith" 这有助于防止消息被误分类为垃圾邮件。随着SPF变得越来越流行，我们添加了一个额外的标头，可与我们的SPF记录一起使用：
Sender: 事情还可以正常运作，但实际上，一些电子邮件客户端和大多数MTA并不尊重“回复地址”标头。因此，许多成员将消息发送到messages@company.example而不是所需的成员。
因此，我开始设想各种方案，以在电子邮件标题中添加有关发件人的数据或将其编码为“发件人”电子邮件地址，以便我们可以处理响应并适当地重定向它们。例如：
是否有任何原因不切换到此方法？还存在其他潜在问题吗？
以下是更详细的信息：
当应用程序首次开发时，我们只是将“发件人”地址更改为发送成员的地址，因为那是当时的常见做法（很多年前）。后来，我们将“发件人”地址更改为成员的名称和我们的地址，例如：
From: "Mary Smith" 并设置“回复地址”标头为成员的地址：
Reply-To: "Mary Smith" 这有助于防止消息被误分类为垃圾邮件。随着SPF变得越来越流行，我们添加了一个额外的标头，可与我们的SPF记录一起使用：
Sender: 事情还可以正常运作，但实际上，一些电子邮件客户端和大多数MTA并不尊重“回复地址”标头。因此，许多成员将消息发送到messages@company.example而不是所需的成员。
因此，我开始设想各种方案，以在电子邮件标题中添加有关发件人的数据或将其编码为“发件人”电子邮件地址，以便我们可以处理响应并适当地重定向它们。例如：
发件人为"Mary Smith" <messages+ca54bb7482ace09f@company.example>，其中"messages"后面的字符串是代表Mary Smith在我们系统中的成员哈希值。当然，这个路径可能会给我们带来很多痛苦，因为我们需要为系统地址开发MTA功能。我再次查看了SPF文档，并发现了这个页面：
http://www.openspf.org/Best_Practices/Webgenerated
他们展示了两个例子，一个是evite.com的，另一个是egreetings.com的。基本上，evite.com采用的方式和我们一样。而egreetings.com的例子则是在成员的发件地址中添加了"Sender"头信息。
所以问题是，使用成员发件地址并添加"Sender"头信息的egreetings方法是否存在任何潜在问题？这将消除不良客户端发送到系统地址的回复。但我认为这并没有解决退信/假期/白名单问题，因为即使指定了Return Path，它们通常也会发送到MAIL FROM。