返回路径、回复和返回之间的行为差异是什么？

在我们的邮件应用程序中，我们发送的电子邮件标题如下:

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

我们面临的问题是，一些电子邮件服务器将立即反弹回一条消息，并使用来自或反向路径(marketing@customer.example) ，而不是我们的反弹 mgmt 服务器。我们想知道，如果我们修改头部的回复-作为相同的返回路径，如果我们将能够捕捉所有的反弹。

还有别的主意吗？

我们使用以下文件作为参考: 副总统 RFC 弹出信息

SMTP 日志解析以获取弹出

编辑1: 多一些信息，看看我们是否能得到这个解决方案。

我们想知道在什么时候邮件服务器转发消息将选择使用回复路径与返回路径。我们已经注意到，当第一个 SMTP 服务器中继消息时被拒绝，它将其发送到回复路径，但是当它在一个跃点之后发生时，它将其发送到返回路径。

244754 次浏览
小开
最佳答案

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

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


This is a very simple body.

现在，假设您要从实现 副总统的邮件列表(或者其他使用不同返回路径的反弹跟踪机制)发送它。假设它的返回路径为 coolstuff-you=yourcompany.com@mymailinglist.example。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.example>
{S}250 2.1.0 me@mycompany.com....Sender OK
{C}RCPT TO:<you@example.com>
{S}250 2.1.5 you@example.com
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff@mymailinglist.example>
To: <you@example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.example>


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.example
From: <coolstuff@mymailinglist.example>
To: <you@example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.example>


This is a very simple body.

现在，让我们描述一下不同的“ FROM”。

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

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

注意，并非所有邮件服务器都遵守此规则; 有些邮件服务器会将其反弹回 FROM 地址。

  1. FROM 地址是 FROM 头中的值。这应该就是消息的发送者。这就是您在大多数邮件客户端中看到的“ FROM”。如果一封电子邮件没有回复标题，那么所有的人工(邮件客户端)回复都应该回到 FROM 地址。

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

但是，正如您所看到的，并非所有的邮件服务器都遵守 RFC 标准或建议。

希望这能帮助我们理清思路。但是，如果我遗漏了什么，请让我知道，我会尽力回答。

小开

考虑 Return-Path和 Reply-To的另一种方式是将其与普通邮件进行比较。

在邮件中发送信封时，需要指定一个 寄件人地址。如果收件人不存在或拒绝您的邮件，邮政局长会将信封返回给回信地址。对于电子邮件，寄件人地址是 Return-Path。

信封的内部可能是一封信，在信的内部，它可能指示收件人“发送信件到 示例地址”。对于电子邮件，示例地址是 Reply-To。

从本质上讲，邮资退回地址与 SMTP 的 Return-Path标头相当，而 SMTP 的 Reply-To标头与信件中包含的回复说明相似。

小开

我不得不在 Redmine 实例发送的电子邮件中添加一个 Return-Path 头。 我同意大灰狼只有发件人可以确定一个正确的(非默认)返回路径。 案情如下: 电子邮件发送的默认电子邮件地址: admin@example.com 但是我们希望真正发起操作的用户收到退回的电子邮件，因为他将知道如何修复错误的收件人电子邮件(而不是应用程序管理员有其他猫鞭打:)。 我们使用它，它与应用程序服务器上的 exim 和 zimbra 作为最终的公司邮件服务器工作得非常好。

小开

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

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


提交答案