电子邮件发件人,收件人和退货路径值之间有什么区别？
示例:我有一个联系表单,用户可以在其中输入电子邮件,是将其分配给发件人,来自还是返回路径？
我在StackOverflow上快速搜索,找不到任何有用的东西.
我们的应用程序的一个主要组成部分代表其他成员向成员发送电子邮件.目前我们将"发件人"地址设置为我们的系统地址,并使用成员地址的"回复"标题.问题是来自某些电子邮件客户端的回复(以及自动回复/退回)不尊重"回复"标题,因此会被发送到我们的系统地址,从而有效地将它们发送到黑洞.我们正在考虑将"发件人"地址设置为我们会员的地址,并将"发件人"地址设置为我们的系统地址.这种方式似乎会通过SPF和Sender-ID检查.
有没有理由不改用这种方法？还有其他潜在问题吗？
以下是您可能需要的更多细节:
当应用程序最初开发时,我们只是将"from"地址更改为发送成员的地址,因为这是当时的常见做法(这是多年前).我们后来改为将"起始"地址作为会员的姓名和地址,即
来自:"玛丽史密斯"
<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.