使用会员的“来自”的潜在问题地址和“发送者”头 [英] 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:
回复：Mary Smith
< marysmith@memberisp.example> ;
这有助于将邮件错误分类为垃圾邮件。随着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:
发件人：
< messages@company.example>
事情工作可以，但事实证明，在实践，一些电子邮件客户端和大多数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>
其中消息之后的字符串是表示我们系统中的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和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.
所以问题是，使用这个会员的地址与发件人标题？这将消除不良客户端发送到系统地址的回复。我不认为它解决了反弹/假期/白名单问题，因为即使指定了返回路径，它们也经常发送到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.
我们最后做的是这样的：
What we're finally doing is this:
设置从头到用户的实际电子邮件地址。
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上运行的程序拦截这些自动回复并将其转发到他们最初打算到达的人。大多数真实的电子邮件客户端将回复发件人：头。我没有看到黑莓用户的问题，还有其他人对系统帐户的回复。
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客户端中添加了一个关于On Behalf Of的小笔记，但这适用于我们的使用。在这种设置（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月，雅虎和美国在线更改了DMARC设置，恕不另行通知。 （他们切换到p =拒绝;请参阅 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屋！
