使用会员的“来自"的潜在问题地址和“发件人"标题 [英] Potential issues using member's "from" address and the "sender" header
问题描述
我们应用程序的一个主要组件代表其他成员向成员发送电子邮件.目前，我们将发件人"地址设置为我们的系统地址，并使用带有成员地址的回复"标头.问题是来自某些电子邮件客户端的回复(和自动回复/退回)不尊重回复"标头，因此将其发送到我们的系统地址，从而有效地将它们发送到黑洞.我们正在考虑将发件人"地址设置为我们会员的地址，将发件人"地址设置为我们的系统地址.这种方式似乎可以通过 SPF 和 Sender-ID 检查.
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"
<messages@company.example>
将回复"标头设置为成员地址:
With a "reply-to" header set to the member's address:
回复:玛丽·史密斯"
这有助于将邮件错误归类为垃圾邮件.随着 SPF 变得越来越流行，我们添加了一个额外的标头，可与我们的 SPF 记录结合使用:
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:
发件人:
一切正常，但事实证明，在实践中，一些电子邮件客户端和大多数 MTA 不尊重回复"标题.因此，许多成员将消息发送到 messages@company.example 而不是所需的成员.
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 messages@company.example 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"
<messages+ca54bb7482ace09f@company.example>
messages"后面的字符串是一个哈希值，代表我们系统中 Mary Smith 的成员.当然，这条路径可能会导致很多痛苦，因为我们需要为我们的系统地址开发 MTA 功能.我再次查看 SPF 文档，发现这个页面很有趣:
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
他们展示了两个例子，evite.com 和 egreetings.com.基本上，evite.com 正在按照我们的方式进行操作.egreetings.com 示例使用成员的发件人地址和添加的发件人"标头.
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.
那么问题是，使用带有发件人标头的成员发件人地址的 egreetings 方法是否存在任何潜在问题?这将消除坏客户端发送到系统地址的回复.我不相信它解决了退回/假期/白名单问题，因为即使指定了返回路径，这些问题也经常发送到 MAIL FROM.
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.
推荐答案
所以我决定回答我自己的问题，因为没有其他人回应.也许其他人会在搜索时找到这个条目.
So I decided to answer my own question since no one else responded. Perhaps others will find this entry when searching.
我们最终要做的是:
将发件人标头设置为用户的实际电子邮件地址.
Set the From header to the user's actual email address.
From: "Mary Smith" <marysmith@memberisp.example>
使用带有系统范围电子邮件地址的发件人标头.
Use a Sender header with the system wide email address.
Sender: <messages@company.example>
最后，显示在服务器提供的 MAIL FROM/Return Path 标头中的实际发件人设置有唯一标识符，即，
Finally, the actual sender that shows up in the server supplied MAIL FROM/Return Path header is set with a unique identifier, i.e.,
Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example>
这允许在 messages@company.example 上运行的程序拦截这些自动回复并将它们转发给他们最初打算联系的人.大多数真实的电子邮件客户端都会回复 From: 标头.我没有看到黑莓用户或其他人响应系统帐户的问题.
That allows a program running at messages@company.example 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.
发件人标题在 Microsoft Outlook 客户端中添加了一个关于代表"的小注释，但这适合我们的使用.使用此设置(Gmail、Yahoo、SpamAssassin 等)的常见客户端/mta 中的 SPF 没有任何问题
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.)
更新: 2014 年 4 月，雅虎和 AOL 更改了他们的 DMARC 设置，在没有通知的情况下删除此类邮件.(他们切换到 p=reject；参见 https://wordtothewise.com/2014/04/brief-dmarc-primer/ 了解更多信息.)我们的解决方案是对这些域进行特殊处理，因为所需的功能仍然适用于绝大多数域.
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.
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
这篇关于使用会员的“来自"的潜在问题地址和“发件人"标题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
