【问题标题】:What is the behavior difference between return-path, reply-to and from?return-path、reply-to 和 from 之间的行为区别是什么?
【发布时间】:2010-11-17 03:47:11
【问题描述】:

在我们的邮件应用程序中,我们发送带有以下标题的电子邮件:

FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com

我们面临的问题是某些电子邮件服务器会立即退回邮件并使用来自或反向路径 (marketing@customer.com) 而不是我们的退回管理服务器。我们想知道我们是否在标题中修改回复到与返回路径相同,如果我们能够捕获所有反弹。

欢迎提出其他想法?

我们使用以下文件作为参考: VERP RFC Bounce Messages

SMTP Log Parsing to get Bounces

编辑 1:再提供一些信息,看看我们是否能解决这个问题。

我们想知道中继消息的电子邮件服务器在什么时候会选择使用回复路径而不是返回路径。我们注意到,当第一个中继消息的 smtp 服务器被拒绝时,它会将其发送到回复对象,但是当它发生在一个跃点之后,它会将其发送到返回路径。

【问题讨论】:

标签: email smtp email-client rfc email-bounces


【解决方案1】:

让我们从一个简单的例子开始。假设您有一个电子邮件列表,它将发送以下RFC2822 内容。

From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

现在,假设您要从一个实现VERP(或其他使用不同返回路径的退回跟踪机制)的邮件列表发送它。假设它的返回路径为coolstuff-you=yourcompany.com@mymailinglist.com。 SMTP 会话可能如下所示:

{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<coolstuff-you=yourcompany.com@mymailinglist.com>
{S}250 2.1.0 me@mycompany.com....Sender OK
{C}RCPT TO:<you@yourcompany.com>
{S}250 2.1.5 you@yourcompany.com 
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.
.

{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel

其中 {C} 和 {S} 分别代表客户端和服务器命令。

收件人的邮件如下所示:

Return-Path: coolstuff-you=yourcompany.com@mymailinglist.com
From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

现在,让我们来描述不同的“FROM”。

  1. 返回路径(有时称为反向路径、信封发件人或信封发件人——所有这些术语都可以互换使用)是MAIL FROM 命令中的 SMTP 会话中使用的值。如您所见,这不需要与在消息头中找到的值相同。只有收件人的邮件服务器才应该在电子邮件顶部添加 Return-Path 标头。这将记录 SMTP 会话期间的实际返回路径发件人。如果邮件中已存在 Return-Path 标头,则该标头将被删除并由收件人的邮件服务器替换。

在 SMTP 会话期间发生的所有退回邮件都应返回到返回路径地址。一些服务器可能会接受所有电子邮件,然后在本地排队,直到它有一个空闲线程将其传递到收件人的邮箱。如果收件人不存在,它应该将其退回到记录的 Return-Path 值。

注意,并不是所有的邮件服务器都遵守这条规则;一些邮件服务器会将其退回到 FROM 地址。

  1. FROM 地址是在 FROM 标头中找到的值。这应该是消息的发件人。这就是您在大多数邮件客户端中看到的“FROM”。如果电子邮件没有回复标头,则所有人工(邮件客户端)回复都应返回到 FROM 地址。

  2. Reply-To 标头由发件人(或发件人的软件)添加。这也是所有人类回复都应该处理的地方。基本上,当用户单击“回复”时,回复值应该是用作新撰写电子邮件的收件人的值。任何服务器都不应使用回复值。它仅供客户端 (MUA) 使用。

但是,如您所知,并非所有邮件服务器都遵守 RFC 标准或建议。

希望这应该有助于解决问题。但是,如果我遗漏了什么,请告诉我,我会尽力解答。

【讨论】:

  • 这很有帮助。谢谢你的时间。一个问题。是否会发生一些退回到回复而不是返回路径的情况?
  • 好吧,从技术上讲,您可以(但不应该)添加返回路径标头,但是,如果返回路径标头存在,它将被接收 smtp 服务器覆盖。如果不存在,则将其添加到标题的顶部。
  • 我有点不清楚return-path 的使用方式。如果return-path 是回信地址,为什么收件人的邮件服务器会填写此字段而不是发件人? recipent 的服务器怎么会知道要放什么?这看起来不是倒退吗?
  • 收件人的邮件服务器通过复制发件人邮件服务器在 SMTP“MAIL FROM”命令中提供的值,将 Return-Path 标头插入到邮件中。想象一下收发室的职员打开邮件——他们查看信封上的回信地址,然后将其写在信封的顶部(然后将信封扔掉)。
  • 那么Sender: 标头如何适应这一切?
【解决方案2】:

另一种思考 Return-PathReply-To 的方式是将其与蜗牛邮件进行比较。

当您在邮件中发送一个信封时,您指定一个返回地址。如果收件人不存在或拒绝您的邮件,邮递员会将信封退回到回信地址。对于电子邮件,返回地址Return-Path

信封内可能是一封信,信内可能会引导收件人“将信件发送到示例地址”。对于电子邮件,示例地址Reply-To

本质上,回邮地址类似于 SMTP 的 Return-Path 标头,而 SMTP 的 Reply-To 标头类似于一封信中包含的回复说明。

【讨论】:

  • @Jesse Hobart +1 很好的解释,我更困惑谢谢你让我更容易理解。
  • 我要指出,在这个类比中没有捕捉到的主要概念是Return-Path 标头是由 receiving 邮件服务器添加的,而 不是发件人。所以它更像是这样:您可以在信封内写上您想要的任何地址,但要交付它,您必须将它带到邮局并向他们出示您的驾驶执照(或其他身份证件)和他们 在寄出之前把地址放在信封上。换句话说,Return-Path 标头与接收 SMTP 服务器执行的检查一样值得信赖,其他的很容易被欺骗。
【解决方案3】:

我必须在 Redmine 实例发送的电子邮件中添加 Return-Path 标头。 我同意greatwolf,只有发件人可以确定正确的(非默认)返回路径。 案例如下: 电子邮件使用默认电子邮件地址发送:admin@yourcompany.com 但是我们希望启动操作的真实用户收到退回电子邮件,因为他将是知道如何修复错误收件人电子邮件的人(而不是有其他猫要鞭打的应用程序管理员:-))。 我们使用它,它与应用程序服务器上的 exim 和作为最终公司邮件服务器的 zimbra 完美配合。

【讨论】:

    【解决方案4】:

    对于那些因为问题的标题而来到这里的人:

    我在网络表单中使用Reply-To: 地址。当有人填写表格时,该网页会自动向该页面的所有者发送一封电子邮件。 From: 是自动邮件发件人的地址,因此所有者知道它来自网络表单。但是Reply-To:地址是用户填写的,所以楼主可以直接点击回复联系他们。

    【讨论】:

      猜你喜欢
      • 2011-05-21
      • 2016-09-08
      • 2018-01-19
      • 1970-01-01
      • 2022-11-14
      • 2017-03-13
      • 1970-01-01
      • 2013-06-09
      • 2014-05-24
      相关资源
      最近更新 更多