RFC822在Return-Path:
:
此字段由将邮件递送给收件人的最终传输系统添加。该字段旨在包含有关返回邮件发件人的地址和路线的明确信息。
那么为什么有些电子邮件有两个呢?(在我的示例中,通常一个在末尾,一个在开头,我假设客户在那里添加了它。)不是吗?只有一个鼻祖?
这是一些客户的坏习惯吗?
答案1
你已经落后了 30 年。RFC 822 已被取代两次。
…而替代文件虽然仍然存在一些缺陷,但确实试图解释 RFC 822 允许什么,而世界决定不做什么,或者完全做错了什么。
发起者不是只有一个吗?
和Return-Path:
标题Delivered-To:
不表示鼻祖和接受者. 它们包含消息信封邮件离开 SMTP 环境后,不再被分解为信封和内容— 就像本地传送代理在本地传送点将邮件信封和邮件内容写入邮箱文件时一样。
这是一些客户的坏习惯吗?
这是发送邮件的 MUA 或 MTA 的坏习惯,或者是 SMTP 环境之外的某些中间网关的坏习惯。最上面的跟踪字段几乎可以肯定是由您的本地交付代理添加的。更靠后的那些是由其他东西添加的。您的 LDA 可以在添加自己的信封头时自由地删除现有的信封头。但它没有被要求这样做,而且显然它没有这样做。
进一步阅读
- 丹尼尔·J·伯恩斯坦。 信封信息:Return-Path,已收到. 互联网邮件消息头格式。
- 互联网信息格式. Peter W. Resnick (编辑). 2008-10. RFC 5322. 征求意见。
- 丹尼尔·J·伯恩斯坦(1997-02-01)。邮件循环战中的工具。
- J. Klensin(2008-10)。 “跟踪信息”。 简单邮件传输协议. RFC 5321. 征求意见。
答案2
Return-Path 通常会在收到电子邮件时添加到顶部。具体来说,它会在 SMTP 传输“MAIL FROM”命令期间发生。它可能与 From:、Reply-To: 或 Sender: 标头中的电子邮件地址不同。如果底部有第二个 Return-Path,则很可能是可疑的,可能是在交付完成后添加的。
答案3
这要么是客户不良习惯,要么是垃圾邮件。
您可以通过检查内容和其余标题来确定是否是后者。
Return-Path 是 MTA 将检查的少数标头之一,并且传送 MTA 应该将其删除并替换为其自己的标头。
答案4
一些电子邮件帐户可以选择“代表...”发送电子邮件,这将使用不同的服务器来路由电子邮件。这将涉及多封电子邮件的回复。否则,另一个例子可能是,如果 php 应用程序通过服务器发送电子邮件 - 您可以指定一个或多个回复地址(有时您甚至可以伪造回复地址)。
显然,最好的习惯是让您的客户只发布一个回复地址,用于定位电子邮件交易和其他调试任务(如果需要)。
" Once the transmission channel is established and initial handshaking
completed, the SMTP client normally initiates a mail transaction.
Such a transaction consists of a series of commands to specify the
originator and destination of the mail and transmission of the
message content (including any headers or other structure) itself.
When the same message is sent to multiple recipients, this protocol
encourages the transmission of only one copy of the data for all
recipients at the same destination (or intermediate relay) host."
来源:http://www.ietf.org/rfc/rfc2821.txt
另外:ARPA 互联网短信标准
C.3.2. FROM
The "From" field must contain machine-usable addresses (addr-
spec). Multiple addresses may be specified, but named-lists
(groups) may not.