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

在我们的邮件应用程序中，我们正在发送带有以下标头的电子邮件：

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

我们面临的问题是某些电子邮件服务器将立即退回邮件，并使用“从”或反向路径（marketing@customer.com）来代替我们的退回mgmt服务器。我们想知道是否可以在标头中将reply-to修改为与return-path相同，以便我们能够捕获所有反弹。

还有其他想法吗？

我们使用以下文档作为参考： VERP RFC 退回邮件

SMTP日志解析以获取退回

编辑1：更多信息，看看是否可以得到解决。

我们想知道中继邮件的电子邮件服务器将在什么时候选择使用回复至返回路径。我们已经注意到，当第一个中继该消息的smtp服务器被拒绝时，它将其发送到答复者，但是当它在一跳之后发生时，它将其发送到返回路径。

让我们从一个简单的例子开始。假设您有一个电子邮件列表，它将发送以下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发件人。如果邮件中已存在Return-Path标头，则该标头将被删除并由收件人的邮件服务器代替。

在SMTP会话期间发生的所有跳回应返回到“返回路径”地址。某些服务器可能会接受所有电子邮件，然后将其在本地排队，直到它有一个自由线程将其发送到收件人的邮箱为止。如果接收者不存在，则应将其反弹回记录的Return-Path值。

请注意，并非所有邮件服务器都遵守此规则；某些邮件服务器会将其退回到发件人地址。

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

3. 发件人（或发件人的软件）添加了Reply-To标头。在这里也应处理所有人类的答复。基本上，当用户单击“答复”时，“答复至”值应为用作新撰写的电子邮件的收件人的值。任何服务器均不应使用Reply-To值。它仅用于客户端（MUA）。

但是，您可以知道，并非所有邮件服务器都遵循RFC标准或建议。

希望这应该有助于清理问题。但是，如果我错过了任何事情，请告诉我，我将尽力回答。

考虑Return-Pathvs的另一种方法Reply-To是将其与蜗牛邮件进行比较。

在邮件中发送信封时，请指定回信地址。如果收件人不存在或拒绝您的邮件，则邮局主管会将信封退回到寄信人地址。对于电子邮件，寄信人地址为Return-Path。

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

从本质上讲，邮寄回邮地址可与SMTP的Return-Path标头媲美，而SMTP的Reply-To标头类似于信件中包含的回复说明。

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

我将Reply-To:地址与网络表单一起使用。当有人填写表格时，网页会自动向该页面的所有者发送电子邮件。这From:是自动邮件发件人的地址，因此所有者可以从网络表单中知道它的地址。但Reply-To:地址是用户填写的表格中的地址，因此所有者只需点击回复即可与他们联系。

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