gpt4 book ai didi

email - 使用成员的 "from"地址和 "sender" header 的潜在问题

转载 作者:行者123 更新时间:2023-12-03 01:53:49 26 4
gpt4 key购买 nike

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

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

<小时/>

以下详细信息可能超出您的需要:

当应用程序首次开发时,我们只是将“发件人”地址更改为发送成员的地址,因为这是当时的常见做法(这是很多年前的事了)。后来我们将其更改为“发件人”地址为成员(member)姓名和我们的地址,即

From: "Mary Smith" <messages@company.example>

将“回复” header 设置为成员(member)地址:

Reply-To: "Mary Smith" <marysmith@memberisp.example>

这有助于防止邮件被错误分类为垃圾邮件。随着 SPF 变得越来越流行,我们添加了一个额外的 header ,可以与我们的 SPF 记录结合使用:

Sender: <messages@company.example>

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

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

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

其中“messages”后面的字符串是代表玛丽·史密斯在我们系统中的成员的哈希值。当然,这条路径可能会带来很多麻烦,因为我们需要为我们的系统地址开发 MTA 功能。我再次查看 SPF 文档,发现此页面很有趣:

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

他们展示了两个示例,即 evite.com 和 egreetings.com。基本上,evite.com 正在按照我们的方式做事。 egreetings.com 示例使用成员的发件人地址并添加了“Sender” header 。

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

最佳答案

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

我们最终要做的是:

将“发件人” header 设置为用户的实际电子邮件地址。

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

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

Sender: <messages@company.example>

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

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

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

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

发件人 header 在 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

关于email - 使用成员的 "from"地址和 "sender" header 的潜在问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2231897/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com