后缀重写的 Return-Path 标头
Posted
技术标签:
【中文标题】后缀重写的 Return-Path 标头【英文标题】:Return-Path header rewritten by postfix 【发布时间】:2015-04-13 12:28:41 【问题描述】:我在 ubuntu 使用 postfix 从 php 发送邮件:
mail($to, $subject, $body, "Return-Path: <test@mail.com>");
尝试设置 Return-Path
标头,但似乎 postfix 将其重写为 user@serverdomain
在后缀文档中找到 message_drop_headers
变量,默认值为 bcc, content-length, resent-bcc, return-path
试图更改它在postfix/main.cf
中的值,但它在开始时给出警告:
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: message_drop_headers=bcc content-length resent-bcc
可能是什么原因?如何配置 postfix 不重写 Return-Path 标头?
【问题讨论】:
【参考方案1】:在出站电子邮件上设置 Return-Path:
标头是没有意义的,因为它将被收件人的 MTA 替换。如果您想控制那里写入的内容,请设置信封发件人(传统上,sendmail -f address@example.com
)
更详细地说,当您发送消息时,有两层:信封指定实际收件人,消息本身通常包含具有相同信息的标题......但有时它没有,有时这些标题公然撒谎。
当该邮件传递给收件人时,接收 MTA(Sendmail 或 Postfix 或 Exchange 或其他)会将信封发件人信息复制到 Return-Path:
标头中,如果是,则添加一个如果它已经存在,通常会简单地覆盖它。
因此,如何在传出服务器上配置 Return-Path:
并不重要;为了正确控制这一点,您需要控制将消息传递给收件人的每台服务器上的接收行为。
作为一个简单的例子,订阅一个公共邮件列表,观察标题通常是如何说的:
From: Popular mailing list <popular-list@example.com>
To: Popular mailing list <popular-list@example.com>
但它还是到达了您的收件箱。那是怎么发生的?为什么,通过信封收件人信息。列表软件基本上为每个订阅者添加了一个Bcc:
,但也说服服务器忽略标头中的实际To:
地址。这令人惊讶,直到您意识到标头实际上并没有重要的是,只有信封地址才能真正控制消息的最终传递位置。
简而言之,信封由 SMTP MAIL FROM:
和 RCPT TO:
动词指定,它们在 RFC5321(最初是 822)中定义,而实际消息(包括所有标头)在 SMTP DATA
部分中进行通信在这一点上,就 SMTP 而言,这实际上只是纯数据。他们的规范是RFC5322(née 822),一旦消息被实际传递,接收服务器实际上会添加一些自己的标头,但From:
和To:
标头仍然基本上被忽略。
【讨论】:
这不是没有意义的,因为它可能会泄露您想要保密的信息。 您仍在披露该信息,同时还毫无意义地添加了一个多余的Return-Path:
标头,这并不能阻止此披露。
我如何披露这些信息,考虑到它只在返回路径标题中?我的同事找到了一种阻止后缀添加它的方法,因此它不再出现在消息中的任何位置。
Return-Path:
标头中的内容是信封发件人中的任何内容。您不会通过覆盖或抑制标头来以任何方式掩盖信封,因为它会根据信封中的任何内容添加到 recipient 端。我不知道如何才能更清楚地说明这一点,除非可能要求您确保您了解 SMTP 信封是什么(提示:标头是完全独立的东西,通常不会影响信封)。如果你想保密的东西最终落在了信封里,它就会泄露出去,而你没有保守秘密。以上是关于后缀重写的 Return-Path 标头的主要内容,如果未能解决你的问题,请参考以下文章
Return-Path 标头与实际的电子邮件退回收件人有何不同?
怎么把url的aspx后缀去掉,用URL重写还是啥生成的,具体操作讲下,或具体代码