return-path,reply-to和from之间的行为差​​异是什么?

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

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

我们面临的问题是,一些电子邮件服务器会立即反弹消息,并使用反向path(marketing@customer.com)而不是我们的反弹pipe理服务器。 我们想要知道,如果我们能够捕获所有的反弹,我们是否在标题中修改了答复 – 与返回path相同。

任何其他的想法,欢迎?

我们使用以下文档作为参考: VERP RFC Bounce消息

SMTP日志parsing来获取反弹

编辑1:多一点的信息,看看我们是否可以得到这个决心。

我们想知道中继邮件的电子邮件服务器将select使用回复还是回复path。 我们已经注意到,当中继消息的第一个smtp服务器被拒绝时,它将它发送给回复,但是当它发生在一跳后,它将它发送到返回path。

我们从一个简单的例子开始。 假设您有一个电子邮件列表,即将发送以下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(或其他使用不同返回path的其他反弹跟踪机制)。 让我们说它将有一个coolstuff-you=yourcompany.com@mymailinglist.com返回path。 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. 返回path(有时称为反向path或信封 – 从这些术语中可以互换使用)是SMTP会话期间使用的值。 正如你所看到的,这不需要和邮件头中实际发现的值相同。 只有收件人的邮件服务器应该在电子邮件的顶部添加一个Return-Path头。 这会在SMTP会话期间logging实际的Return-Path发件人。 如果电子邮件中已经存在返回path标题,那么该标题将被删除,并由收件人的邮件服务器取代。

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

    请注意,并非所有的邮件服务器都遵守这个规则。 有些邮件服务器会将其退回到FROM地址。

  2. FROM地址是在FROM标题中实际find的值。 这应该是谁的消息是从。 这就是你在大多数邮件客户端看到的“FROM”。 如果电子邮件没有回复标题,则所有人类(邮件客户端)回复应该回到FROM地址。

  3. 回复标题由发件人(或发件人的软件)添加。 这也是所有人类的答复都应该解决的地方。 基本上,当用户点击“回复”时,回复值应该是用作新组合电子邮件的值。 Reply-To值不应该被任何服务器使用。 这是为了客户端使用。

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

希望这应该有助于清理事情。 但是,如果我错过了什么,请告诉我,我会尽力回答。

另一种思考Return-Path与Reply-To的方法是将其与Snail Mail进行比较。

当您在邮件中发送信封时,您将指定一个返回地址。 如果收件人不存在或拒绝您的邮件,邮局pipe理员可以使用此function将邮件退回给您。

信封里面可能是一封信,里面可能会写明“回复实例地址 ”。

所以,本质上,邮资退货地址与SMTP返回path标题和SMTP答复标题相似,类似于回复信中包含的指令。

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

我使用Reply-To:地址与webforms。 当有人填写表单时,网页会自动发送电子邮件给页面​​的所有者。 From:是自动邮件发件人的地址,所以所有者知道它来自于webform。 但Reply-To:地址是用户填写的表单,所以业主可以打回复联系。

我必须在由Redmine实例发送的电子邮件中添加一个Return-Path头。 我同意伟大的狼人只有发件人可以确定一个正确的(非默认)返回path。 情况如下:电子邮件是用默认的电子邮件地址发送的:admin@yourcompany.com但是我们希望发起行动的真实用户收到弹回电子邮件,因为他会知道如何修复错误的收件人电子邮件(而不是有其他猫鞭打的应用程序pipe理员:-))。 我们使用这个工具,并且在应用程序服务器和zimbra上作为最终的公司邮件服务器进行工作。