在我们的邮件应用中,我们用下面的头发送电子邮件:
FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com
我们所面临的问题是,一些电子邮件服务器会立即反弹回来的消息,并使用来自或反向路径(marketing@customer.com),而不是我们的反弹MGMT服务器。 我们想知道,如果我们在标题修改回复到是一样的返回路径,如果我们将能够捕获所有反弹。
任何其他的想法,欢迎?
我们正在使用下列文件作为参考: 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” S。
- 返回路径(有时称为反向路径,包络发送方,或从包络-所有这些术语可以互换使用的)是在SMTP会话中使用的值
MAIL FROM
命令。 正如你所看到的,这并不需要是在邮件标题中发现相同的值。 只有收件人的邮件服务器应该是一个返回路径头添加到邮件的顶部。 这个记录在SMTP会话期间的实际返回路径发件人。 如果返回路径头的消息中已经存在,则该头被删除,由收件人的邮件服务器所取代。
在SMTP会话期间发生的所有的反弹应该回到返回路径地址。 有些服务器可能会接受所有的电子邮件,然后排队在本地,直到它有一个空闲线程来它传递到收件人的邮箱。 如果收件人不存在,它应该反弹回记录的返回路径值。
注意,不是所有的邮件服务器遵守这个规则; 有些邮件服务器会反弹回发件人地址。
该FROM地址是在发现FROM首部的值。 这应该是消息来自谁。 这就是你看到的,因为在大多数的邮件客户端的“FROM”。 如果电子邮件没有回复到标题,然后所有的人(邮件客户端)回复应该回到发件人地址。
答复-To报头由发送者(或发送者的软件)加入。 这是所有人类的答复也应该被解决。 基本上,当用户点击“回复”,回复到价值应作为新组成的电子邮件的收件人值。 答复向价值不应该由任何服务器使用。 这是为客户端(MUA)只使用。
然而,正如你所知道的,不是所有的邮件服务器遵守RFC标准或建议。
这应该可以帮助明确的事情了。 但是,如果我错过了什么,让我知道,我会尽力回答。
考虑另一种方式Return-Path
VS Reply-To
是把它比作蜗牛邮件。
当你在发送邮件的信封,你指定一个返回地址 。 如果收件人不存在,或拒绝您的邮件,邮政返回信封放回到返回地址。 对于电子邮件, 返回地址的Return-Path
。
信封里的可能是字母和字母的内部可指示接收者“发送信件到例如地址 ”。 对于电子邮件, 范例地址是Reply-To
。
从本质上说,一个邮资返回地址相当于SMTP的Return-Path
头和SMTP的Reply-To
头类似于包含在信进行回复的说明。
对于那些谁到这儿,因为问题的标题:
我用Reply-To:
地址与网络表单。 当有人填写表格,网页将自动电子邮件页面的所有者。 在From:
是自动邮件发送者的地址,所以店主知道它是从网络表单。 但Reply-To:
地址是一个由用户表单填写,所以车主可以只需点击回复与他们联系。
我不得不添加一个返回路径头在电子邮件中由管理平台的实例发送。 我greatwolf同意只有发送者能够确定一个正确的(非默认)返回路径。 案例如下:电子邮件与默认的电子邮件地址发送:admin@yourcompany.com但是,我们希望,真正的用户发起的动作收到电子邮件反弹,因为他将是一个知道如何解决错误的收件人的邮件(而不是有其他猫的应用adminstrators到:-)鞭)。 我们用这个和它完美的作品很好地与应用程序服务器和Zimbra作为最终的公司邮件服务器上的进出口。