使用成员“来自”的潜在问题地址和“发件人”标头
我们应用程序的一个主要组成部分代表其他会员向会员发送电子邮件。目前，我们将“发件人”地址设置为我们的系统地址，并使用带有会员地址的“回复”标头。问题在于，某些电子邮件客户端的回复（以及自动回复/退回邮件）不尊重“回复”标头，因此会被发送到我们的系统地址，从而有效地将它们发送到黑洞。我们正在考虑将“发件人”地址设置为我们的会员地址，将“发件人”地址设置为我们的系统地址。看来这种方式可以通过 SPF 和发件人 ID 检查。
有什么理由不改用这种方法？还有其他潜在问题吗？
这里有比您可能需要的更多详细信息：
首次开发应用程序时，我们只是将“发件人”地址更改为发送成员的地址，因为这是当时的常见做法（这是很多年前的事）。后来我们将其更改为“发件人”地址为会员姓名和我们的地址，即
发件人：“Mary Smith”
[电子邮件受保护]>
将“回复”标头设置为会员地址：
回复：“Mary Smith”
<[电子邮件受保护] >
这有助于将邮件错误地分类为垃圾邮件。随着 SPF 变得越来越流行，我们添加了一个额外的标头，可以与 SPF 记录结合使用：
发件人：
[电子邮件受保护]>
一切正常，但事实证明，在实践中，一些电子邮件客户端和大多数 MTA 不尊重“回复”标头。因此，许多成员将邮件发送到 [email protected]，而不是所需的成员。
因此，我开始设想各种方案，将有关发件人的数据添加到电子邮件标头或将其编码到“发件人”电子邮件地址中，以便我们可以处理响应并适当地重定向。例如，
来自：“玛丽·史密斯”
<[电子邮件受保护]>
其中“messages”后面的字符串是代表 Mary Smith 在我们系统中的成员的哈希值。当然，这条路径可能会带来很多麻烦，因为我们需要为我们的系统地址开发 MTA 功能。我再次查看 SPF 文档，发现此页面很有趣：
http://www.openspf.org/Best_Practices /Web generated
他们展示了两个示例，evite.com 的示例和 egreetings.com 的示例。基本上，evite.com 正在按照我们的方式做事。 egreetings.com 示例使用成员的发件人地址并添加了“Sender”标头。
所以问题是，使用带有发件人标头的成员发件人地址的 egreetings 方法是否存在任何潜在问题？这将消除不良客户端发送到系统地址的回复。我不认为它解决了退回/休假/白名单问题，因为即使指定了返回路径，这些问题也经常发送到邮件。
A major component of our application sends email to members on behalf of other members. Currently we set the "From" address to our system address and use a "Reply-to" header with the member's address. The issue is that replies from some email clients (and auto-replies/bounces) don't respect the "Reply-to" header so get sent to our system address, effectively sending them to a black hole. We're considering setting the "From" address to our member's address, and the "Sender" address to our system address. It appears this way would pass SPF and Sender-ID checks.
Are there any reasons not to switch to this method? Are there any other potential issues?
Here are way more details than you probably need:
When the application was first developed, we just changed the "from" address to be that of the sending member as that was the common practice at the time (this was many years ago). We later changed that to have the "from" address be the member's name and our address, i.e.,
From: "Mary Smith"
<[email protected]>
With a "reply-to" header set to the member's address:
Reply-To: "Mary Smith"
<[email protected]>
This helped with messages being mis-categorized as spam. As SPF became more popular, we added an additional header that would work in conjunction with our SPF records:
Sender:
<[email protected]>
Things work OK, but it turns out that, in practice, some email clients and most MTA's don't respect the "Reply-To" header. Because of this, many members send messages to [email protected] instead of the desired member.
So, I started envisioning various schemes to add data about the sender to the email headers or encode it in the "from" email address so that we could process the response and redirect appropriately. For example,
From: "Mary Smith"
<[email protected]>
where the string after "messages" is a hash representing Mary Smith's member in our system. Of course, that path could lead to a lot of pain as we need to develop MTA functionality for our system address. I was looking again at the SPF documentation and found this page interesting:
http://www.openspf.org/Best_Practices/Webgenerated
They show two examples, that of evite.com and that of egreetings.com. Basically, evite.com is doing it the way we're doing it. The egreetings.com example uses the member's from address with an added "Sender" header.
So the question is, are there any potential issues with using the egreetings method of the member's from address with a sender header? That would eliminate the replies that bad clients send to the system address. I don't believe that it solves the bounce/vacation/whitelist issue since those often send to the MAIL FROM even if Return Path is specified.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
所以我决定回答我自己的问题，因为没有其他人回答。也许其他人在搜索时会找到这个条目。
我们最终要做的是：
将 From 标头设置为用户的实际电子邮件地址。
使用带有系统范围电子邮件地址的发件人标头。
最后，显示在服务器提供的 MAIL FROM/Return Path 标头中的实际发件人设置有唯一标识符，即，
允许程序在 [电子邮件受保护] 拦截这些自动回复并将其转发给最初打算联系的人。大多数真正的电子邮件客户端都会回复“发件人：”标头。我还没有看到黑莓用户或其他人响应系统帐户的问题。
经过一个月左右的生产后，我们遇到的问题比之前使用的方法要少。
发件人标头在 Microsoft Outlook 客户端中添加了一个关于“代表”的小注释，但这适合我们的使用。使用此设置（Gmail、Yahoo、SpamAssassin 等），普通客户端/mta 中的 SPF 没有出现任何问题。
更新：2014 年 4 月，Yahoo 和 AOL 更改了其 DMARC 设置以删除这些各种消息，恕不另行通知。 （他们切换到 p=reject；请参阅 https://wordtothewise.com/2014/04 /brief-dmarc-primer/ 了解更多信息。）我们的解决方案是对这些域进行特殊处理，因为所需的功能仍然适用于绝大多数域。
So I decided to answer my own question since no one else responded. Perhaps others will find this entry when searching.
What we're finally doing is this:
Set the From header to the user's actual email address.
Use a Sender header with the system wide email address.
Finally, the actual sender that shows up in the server supplied MAIL FROM/Return Path header is set with a unique identifier, i.e.,
That allows a program running at [email protected] to intercept those auto replies and forward them onto the person they were originally intended to reach. Most real email clients will reply to the From: header. I haven't seen problems from blackberry users nor others responding to the system account.
After a month or so in production, we've had fewer issues with this than the previous method we were using.
The Sender header adds a small note in Microsoft Outlook clients about "On Behalf Of" but that's appropriate for our usage. There haven't been any issues with SPF in common clients/mta with this setup (Gmail, Yahoo, SpamAssassin, etc.)
Update: In April 2014, Yahoo and AOL changed their DMARC settings to drop these kinds of messages without notice. (They switched to p=reject; see https://wordtothewise.com/2014/04/brief-dmarc-primer/ for more information.) Our solution was to special case those domains, since the needed functionality still works with the vast majority of domains.