优先顺序:电子邮件中的标题

时间:2020-03-06 14:56:39  来源:igfitidea点击:

我的Web应用程序经常发送电子邮件,它发送3种电子邮件:用户发起的,响应系统中的事件以及对应用程序收到的电子邮件的自动响应。

我想确保第三种电子邮件不会卡在自动回复彼此交谈的无尽循环中。当前,我使用标题:

Precedence: junk

但是雅虎!邮件会将这些邮件视为垃圾邮件。这显然是不理想的,因为我们希望SOMEBODY阅读我们的自动回复并做出决定,而不是非办公室回复。

在不触发垃圾邮件过滤器或者自动响应器的情况下发送电子邮件的最佳方法是什么?

Precedence: junk?

Precedence: bulk?

Precedence: list?

X-Priority: 2?

解决方案

如何在电子邮件帐户上配置白名单?

我假设所有电子邮件关键字都可能被垃圾过滤器标记。

解决此问题的传统方式是使用空信封发送者(传统上写为<>)发送电子邮件。这样可以防止另一端的自动响应器响应,因为没有发送方可以响应。

RFC 2076不鼓励使用优先级标头。正如我们已经指出的那样,许多客户只会将其过滤掉(尤其是优先级:垃圾杂种)。最好使用空路径来避免自动响应程序大战:

Return-Path: <>

最终,我们可以使用优先级来尝试解决此问题,但这似乎与标题的精神背道而驰。我建议为此只使用return-path标头,并避免优先级。在某些情况下,我们可能必须编写某种方式在应用程序中删除自动响应器(以避免陷入响应器大战),但是我不记得使用适当的返回路径发生这种情况。 (我记得必须处理的大多数自动响应程序大战都是格式非常错误的电子邮件的结果)

注意:简而言之," Return-Path"标头是通知的目的地(退信,延迟发送等),并在RFC 2821中进行了描述-因为SMTP必需。这也是丢弃坏邮件的一种方法(理论上,所有好邮件都会设置适当的返回路径)。

有一个专用于自动电子邮件响应的RFC 3834.

简而言之,它建议:

  • 如果是有效的电子邮件地址,则仅将自动回复发送到传入消息的" Return-Path"标头中包含的地址。消息的"返回路径"中的" <>"(空地址)尤其意味着不得为此消息发送自动响应。
  • 发送自动响应时,MAIL FROM smtp命令必须包含" <>"(空地址)。当邮件将被传递时,这将导致返回路径:<>。
  • 使用具有" no"以外的值的"自动提交的标头"来明确指示自动响应。

请注意:在传出消息中显式设置Return-Path标头是不值得的,因为在发送过程中必须用信封地址(从MAIL FROM smtp命令)重写此标头。