将电子邮件作为服务发送给他人时,我应该使用Reply-To标头吗？

Question

将电子邮件作为服务发送给他人时,我应该使用Reply-To标头吗？

Gav*_*vin 106 email spam email-headers phishing

假设我们有一个充当中间人的应用程序,允许A公司向其客户发送报告.

公司A - >公司B(我) - >公司A的客户

收到报告后,我们会向收件人发送电子邮件通知,但这些通知必须来自我们公司的通知电子邮件地址,例如

joe.bloggs@a.com - > notifications@b.com - > peter@c.com

现在,客户倾向于回复这些电子邮件通知,希望他们回到在A公司发送报告的人.相反,他们最终回到我们的地址notifications@b.com.

一个简单的解决方案可能是更改我们发送到相关公司A地址的通知的回复标题,例如

joe.bloggs@a.com - > notifications@b.com [回复:joe.bloggs@a.com] - > peter@c.com

但我主要担心的是:

"发件人"和"回复"字段之间的电子邮件地址和域中的完全差异可能会使垃圾邮件或网络钓鱼过滤器更加渴望标记电子邮件
当人们实际点击"回复"时,并非所有电子邮件客户端都会尊重"回复"字段,而只是使用"来自".一个较小的问题,除非普遍存在.

这些问题是否始终存在？或者,我应该有其他问题吗？

Answer 1

Ale*_*man 148

我用gmail测试了dkarp的解决方案,并将其过滤为垃圾邮件. 改为使用Reply-To标头(或者另外,虽然gmail显然不需要它).以下是linkedin如何做到这一点:

Sender: messages-noreply@bounce.linkedin.com
From: John Doe via LinkedIn <member@linkedin.com>
Reply-To: John Doe <John.Doe@gmail.com>
To: My Name <My.Name@gmail.com>

Run Code Online (Sandbox Code Playgroud)

切换到此格式后,gmail不再将我的邮件过滤为垃圾邮件.

这是我们使用的方法.但是,我们现在遇到一些服务器(......嗯...... AOL)弹跳消息的问题,说明他们不遵守他们的政策.我们收到的唯一解释是回复标题和标题有不同的域,即使这似乎是拥有两个不同标题的确切意图.在多租户应用程序上依赖电子邮件进行B2B通信已经开始变得非常令人沮丧. (5认同)
@BrianH:AOL和雅虎现在显然已经进行了激进的DMARC验证.这导致我从'发件人:'地址到AOL的问题.http://www.emailonacid.com/blog/details/C4/could_yahoo_and_aols_dmarc_policies_destroy_your_deliverability. (4认同)
这种方法的缺点是收件人的地址簿(在许多电子邮件客户端中)现在包含"John Doe via LinkedIn <member@linkedin.com>".当一个不知情的接收者想要再次联系John Doe时,在新消息的To字段中写下他的名字时会弹出这个地址(因此:"通过LinkedIn"在UX方面非常重要). (2认同)

Answer 2

dka*_*arp 87

您可能需要考虑将From标题中的客户名称和标题中的地址放在一起Sender:

From: Company A <joe.bloggs@a.com>
Sender: notifications@b.com

Run Code Online (Sandbox Code Playgroud)

大多数邮寄者都将其称为"来自notifications@b.com代表公司A",这是准确的.然后Reply-To公司A的地址似乎不会出现问题.

来自RFC 5322:

"发件人:"字段指定消息的作者,即负责编写消息的人员或系统的邮箱."发件人:"字段指定负责实际传输消息的代理的邮箱.例如,如果秘书要为另一个人发送消息,则秘书的邮箱将出现在"发件人:"字段中,而实际作者的邮箱将出现在"发件人:"字段中.

我真的不希望我的主人回答过积极的问题,但值得一提的是这个有用的问题和答案,它基本上也证实了dkarp的答案:http://stackoverflow.com/questions/2231897/potential-issues-using-members-from-地址和 - 所述发送者的头 (3认同)
当以这种方式使用From字段时，2018年是否有可交付性方面的更新？ (2认同)

归档时间：	14 年，9 月前
查看次数：	99934 次
最近记录：	11 年，9 月前