return-path、reply-to 和 from 之间的行为差异是什么?
-
22-07-2019 - |
题
在我们的邮件应用程序中,我们发送带有以下标题的电子邮件:
FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com
我们面临的问题是,某些电子邮件服务器会立即退回邮件,并使用发件人或反向路径 (marketing@customer.com) 而不是我们的退回管理服务器。我们想知道如果我们能够捕获所有退回邮件,我们是否可以在标头中将回复修改为与返回路径相同。
还有其他想法欢迎吗?
编辑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.
现在,假设您要从邮件列表发送它,该邮件列表实现了 韦尔普 (或其他一些使用不同返回路径的反弹跟踪机制)。假设它的返回路径为 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”。
- 返回路径(有时称为反向路径、信封发件人或信封发件人 — 所有这些术语都可以互换使用)是 SMTP 会话中使用的值。
MAIL FROM
命令。正如您所看到的,该值不需要与消息标头中的值相同。只有收件人的邮件服务器才应该在电子邮件顶部添加 Return-Path 标头。这会记录 SMTP 会话期间的实际返回路径发件人。如果邮件中已存在 Return-Path 标头,则该标头将被删除并由收件人的邮件服务器替换。
SMTP 会话期间发生的所有退回邮件都应返回到返回路径地址。某些服务器可能会接受所有电子邮件,然后在本地对其进行排队,直到有空闲线程将其传递到收件人的邮箱。如果收件人不存在,则应将其退回到记录的 Return-Path 值。
请注意,并非所有邮件服务器都遵守此规则;有些邮件服务器会将其退回到发件人地址。
FROM 地址是在 FROM 标头中找到的值。这应该是消息的发件人。这就是您在大多数邮件客户端中看到的“发件人”。如果电子邮件没有 Reply-To 标头,则所有人工(邮件客户端)回复都应返回到 FROM 地址。
Reply-To 标头由发送者(或发送者的软件)添加。这也是所有人类回复都应该得到解决的地方。基本上,当用户单击“回复”时,回复值应该是用作新撰写的电子邮件的收件人的值。Reply-To 值不应被任何服务器使用。它仅供客户端 (MUA) 使用。
然而,正如您所知,并非所有邮件服务器都遵守 RFC 标准或建议。
希望这有助于澄清问题。但是,如果我错过了什么,请告诉我,我会尽力回答。
其他提示
去想Return-Path
VS Reply-To
另一种方式是把它比作蜗牛邮件。
当你发送的邮件信封,你指定的返回地址的。如果收件人不存在,或拒绝您的邮件,邮政返回信封放回到返回地址。对于电子邮件,所述的返回地址是Return-Path
。
在包络的可能是一个字母和字母的内部可指示接收者“发送对应于例如地址”。对于电子邮件,所述的例如地址是Reply-To
。
在本质上,一个邮资返回地址相当于SMTP的Return-Path
头和SMTP的Reply-To
头类似于包含在信进行回复的指令。
对于那些谁到这儿,因为问题的标题:
我用web表单Reply-To:
地址。当有人填写表格,网页将自动电子邮件页面的所有者。该From:
是自动邮件发送者的地址,所以店主知道它是从网络表单。但Reply-To:
地址是一个在由用户表格填写,所以可以只需点击回复所有者与他们联系。
我不得不添加一个返回路径头在电子邮件中由管理平台的实例发送。 我greatwolf同意只有发送者能够确定一个正确的(非默认)返回路径。 案例如下: 电子邮件是发送带有默认的电子邮件地址:admin@yourcompany.com 但是,我们希望,真正的用户发起的动作收到电子邮件反弹,因为他将是一个知道如何解决错误的收件人电子邮件(而不是有其他猫:-)鞭应用adminstrators)。 我们用这个和它完美的作品很好地与应用程序服务器和Zimbra作为最终的公司邮件服务器上的进出口。