![Return-Path 到底是什么以及谁设置了它?](https://linux22.com/image/784170/Return-Path%20%E5%88%B0%E5%BA%95%E6%98%AF%E4%BB%80%E4%B9%88%E4%BB%A5%E5%8F%8A%E8%B0%81%E8%AE%BE%E7%BD%AE%E4%BA%86%E5%AE%83%EF%BC%9F.png)
本文 (https://www.sparkpost.com/resources/email-explained/return-path-explained/)对“Return-Path”的解释如下:
当电子邮件未到达预定目的地时,返回路径会指示未送达回执(或退回邮件)的发送位置。
和
许多发件人会将标识符合并到返回路径地址中以方便处理回复和退回流量,这称为可变信封返回路径 (VERP)。
我的理解是:“作为电子邮件发件人,您指定 Return-Path 标头”。
然而,给出以下答案(https://stackoverflow.com/a/28494070/9878135),看起来好像接收服务器总是会覆盖 Return-Path:
在出站电子邮件上设置 Return-Path: 标头是没有意义的,因为它将被收件人的 MTA 替换。如果您想控制写入的内容,请设置信封发件人(传统上,sendmail -f[电子邮件保护])
我目前正在尝试构建一个使用 VERP 的电子邮件服务器。假设“[电子邮件保护]“想向外界发送一封电子邮件。发件人”应该是“[电子邮件保护]“而“Return-Path”应该是完全不同的东西(例如“[电子邮件保护]“)。当外部电子邮件服务无法发送电子邮件时,它应该将电子邮件发送回“[电子邮件保护]“。我的服务器现在可以在数据库中查找这封退回的电子邮件并通知[电子邮件保护]关于配送失败。
我使用 Postfix 发送和接收邮件(并使用 Python 构建邮件)。但是,其他电子邮件服务(例如 Google Mail 或 ProtonMail)似乎从未收到 Return-Path。Google Mail 根本不显示邮件头,而 ProtonMail 会用“发件人”地址覆盖它。
那么谁设置了 Return-Path 标头以及为什么其他电子邮件服务无法接收我的标头?
答案1
Return-Path:
标头包含“信封发件人”地址的副本。 Return-Path:
标头通常由 SMTP/MTA(重新)生成,并直接传送到收件人的邮箱(在最后的 SMTP 跳转之后)。
MAIL FROM:
“信封发件人”是SMTP 会话中命令使用的地址。
因此,您的发送客户端软件应该设置“信封发件人”=>它将(通常)被复制到Return-Path:
。
https://en.wikipedia.org/wiki/Bounce_address#Terminology
返回路径- 当电子邮件放入收件人的邮箱时,会创建一个新的邮件头,名称为“Return-Path:”,其中包含 MAIL FROM 命令上的地址。早期的电子邮件形式(例如 UUCP)需要有关电子邮件到达目的地所经过的路径上每个“跳跃”的信息,因此名称中包含“路径”部分。用于RFC 2821,RFC 3834,RFC 4409。
答案2
电子邮件标Return-Path
头应该包含传递路径中最新 SMTP 握手中已知的最后一个退回地址。与 egReceived
标头不同,邮件中现有的标头可能会被后续服务器丢弃。请注意,如果这些值不一致,将根据 SMTP数据而不是数据Return-Path
发送退回邮件。MAIL FROM
Return-Path
实际上,我们应将标头视为Return-Path
历史事故。它可能包含或不包含可用地址,并且它正式不用于任何用途,应仅将其视为调试信息。SMTP 数据MAIL FROM
是实际使用的反弹地址,可能会或可能不会被复制到该地址Return-Path
进行调试。它Return-Path
应该是更值得信赖的数据,因为它是由接收服务器设置的,但由于它只是它的盲目副本,因此它MAIL FROM
可以包含任何内容。
总结: Return-Path
是设置的调试信息接收用于 SMTP 或 ESMTP 事务的服务器。Return-Path
在添加标头之前,可能会或可能不会删除实际电子邮件中的任何现有标头Return-Path
。