19 个版本
0.7.0-alpha.1 | 2024年6月13日 |
---|---|
0.6.0 | 2023年9月20日 |
0.5.0 | 2023年2月7日 |
0.4.3 | 2022年11月16日 |
0.1.0 | 2020年11月28日 |
94 在 电子邮件 中
86 每月下载
220KB
5K SLoC
SPF Milter
SPF Milter 是一个使用 发送者策略框架 协议验证电子邮件发送者的 milter 应用程序。它可以与具有 milter 功能的 MTA 集成,以检查和强制执行在 DNS 中发布的 SPF 策略的授权。
SPF Milter 严格遵循 SPF 规范的规则和建议,RFC 7208。SPF 验证严格按照推荐的方式执行:首先,可选步骤是验证客户端的 HELO 身份(使用 SMTP HELO
命令提供的域名)。如果此步骤未执行或结果不确定,则验证客户端的 MAIL FROM 身份(使用 SMTP MAIL FROM
命令提供的反向路径或信封发送者)。在两种情况下,验证都会产生最终 SPF 结果。然后 milter 可以采取行动,通过发送 SMTP 错误回复来拒绝消息,或者将结果记录在消息头中。
在规范约束下,SPF Milter 提供了灵活的配置选项。验证过程、结果处理、SMTP 回复、头部字段等的配置参数支持广泛的应用场景。SPF Milter 能够在运行时重新加载配置,因此不需要重新启动即可进行配置更改。
在实现方面,SPF Milter 实质上是 milter 协议中集成 SPF 验证器的配置界面。SPF 实现由 viaspf 库提供,DNS 实现由 domain 库提供。
安装
SPF Milter 是一个 Rust 项目。可以使用 Cargo 如常进行构建和/或安装。例如,使用以下命令安装在 crates.io 上发布的最新版本:
cargo install --locked spf-milter
如以下章节所述,默认的编译内配置文件路径为 /etc/spf-milter.conf
。当构建 SPF Milter 时,可以通过设置环境变量 SPF_MILTER_CONFIG_FILE
为所需路径来覆盖此默认路径。
构建完成后,可以通过将 spf-milter
复制到 /usr/sbin
;将 spf-milter.service
复制到 /etc/systemd/system
;以及将 spf-milter.conf
复制到 /etc
来安装。检查配置后,通过执行 systemctl enable --now spf-milter
来启动服务。
可以通过简单的复制方式以相同的方式安装手册页。
cp spf-milter.8 /usr/local/share/man/man8/
cp spf-milter.conf.5 /usr/local/share/man/man5/
mandb
最低支持的Rust版本是1.74.0。
用法
安装后,可以通过命令行作为 spf-milter
调用SPF Milter。SPF Milter从默认配置文件 /etc/spf-milter.conf
读取配置参数。至少,必须在文件中设置强制性的 socket
参数。有关示例配置,请参阅包含的 spf-milter.conf
。
通过调用 spf-milter
在前台启动milter。向进程发送终止信号或按Ctrl-C关闭milter。
要设置SPF Milter作为系统服务,请尝试使用提供的 spf-milter.service
systemd服务。修改此文件以满足您的需求(例如,设置 User
、Group
和 UMask
),然后将其安装到 /etc/systemd/system
,然后启动并启用服务。
SPF Milter将状态消息记录到syslog。默认情况下,除了错误和警告外,每个已验证实体的验证结果也写入日志。
配置
SPF Milter主要通过在配置文件 /etc/spf-milter.conf
中设置配置参数进行配置。参数带有合理的默认设置,只需指定强制性的 socket
参数,就可以立即使用SPF Milter。
包含的手册页 spf-milter.conf(5) 作为参考文档。(您可以通过将文件的路径传递给 man
来查看手册页,而不需要安装:man ./spf-milter.conf.5
)
可以通过向milter进程发送信号 SIGHUP
在操作期间从磁盘重新加载配置。有关详细信息,请参阅手册页。
对于那些刚开始使用SPF Milter的人来说,以下部分提供了一个简介,简洁地介绍了核心配置参数。
入门
让我们花两分钟来运行SPF Milter的初始设置。
第一步是选择并配置milter的监听套接字,以便接收来自MTA的连接。这由 socket
参数提供。此参数的值应是一个套接字规范,可以是以下两种形式之一
inet:host:port
用于TCP套接字unix:path
用于UNIX域套接字
以下是您如何在配置文件中设置它的示例
# A TCP socket listening on port 3000:
socket = inet:localhost:3000
请记住,配置参数位于文件 /etc/spf-milter.conf
中,使用此处显示的语法,并在手册页中进行了说明。当然,别忘了将 milter 与 MTA 集成。例如,使用 Postfix 将套接字位置添加到 /etc/postfix/main.cf
中的 milters。
smtpd_milters = inet:localhost:3000
在此设置下,milter 启动并重新加载了 Postfix 配置,SPF Milter 将开始处理到达的消息。
可以调整 SPF Milter 运行的各个方面。验证过程的主要可配置方面是是否也要验证 HELO 身份:这由布尔参数 verify_helo
控制。
# Also verify HELO before MAIL FROM:
verify_helo = yes
启用 HELO 验证并不意味着禁用 MAIL FROM 验证。相反,在验证 MAIL FROM 身份之前,还会验证 HELO 身份。只要 HELO 身份对您来说很重要,启用此功能可能是有益的,因为,如 RFC 7208 第 2.3 节所述,处理 HELO 身份通常比更复杂的 MAIL FROM 身份简单,通常使用更简单的 SPF 策略,因此需要更少的 DNS 资源。
评估结果为负面授权或错误结果的发件人身份可能被拒绝在 SMTP 层级,通过让 milter 以临时或永久 SMTP 错误回复响应。要拒绝的 SPF 结果集通过 reject_results
参数声明。
# Reject senders that evaluate to one of the following results:
reject_results = fail, temperror, permerror
值列表以逗号分隔 SPF 结果。上面的示例中,来自 SPF 结果为 fail 的发件人的消息将被拒绝,而那些结果为 softfail 的将被接受。
来自已接受发件人的消息,而不是被拒绝,其结果将记录在消息头部的新的条目中。可以通过 header
参数配置头部字段的类型。值 Received-SPF
和 Authentication-Results
分别选择同名的头部字段。例如
# Add a ‘Received-SPF’ header to accepted messages:
header = Received-SPF
有了这些,我们就留给你自己去实验。
在实验配置时,您不需要重新启动 SPF Milter,只需发送它重新加载信号即可。有关此以及许多其他设置的说明,请参阅手册页,spf-milter.conf(5)。
用例
为了使上述信息更加实用,本节将更详细地讨论两个常见的示例用例:“标准” SPF,以及 SPF 作为 DMARC 的一部分。
标准 SPF
符合 RFC 的标准 SPF 验证用例已很好地由 SPF Milter 的默认配置设置覆盖。因此,只需设置必需的 socket
参数,并将所有其他参数保留在默认值,就足以配置标准 SPF 验证用例。
/etc/spf-milter.conf
:
socket = inet:localhost:3000
让我们简要地了解一下默认行为。
SPF Milter 首先会验证 HELO 身份(verify_helo = yes
)。如果 HELO 身份评估的结果既不在要拒绝的结果集中,也不在“最终”HELO 结果集中,则接下来验证 MAIL FROM 身份。上述两个设置,reject_helo_results
和 definitive_helo_results
,允许精确调整哪些 HELO 结果可以绕过或跳过对 MAIL FROM 身份的验证。默认情况下,对于 HELO 和 MAIL FROM 身份,拒绝相同的结果集,并且没有 HELO 结果是“最终”的。
对于HELO或MAIL FROM标识符,最终结果会确定。然后根据RFC 7208的建议进行强制执行。结果失败、临时错误和永久错误会使用适当的永久或临时SMTP错误回复被拒绝,而对于所有其他结果,则会在消息头部添加一个记录结果的头部字段。可以自由地通过参数reject_results
和reject_helo_results
调整要拒绝的结果集合。还可以为每个SPF结果单独配置SMTP回复代码和文本。
对于头部条目,默认情况下会生成一个类型为Received-SPF的头部字段。配置头部字段类型的参数名为header
(header = Received-SPF
)。RFC 7208中定义的两种头部类型都是“标准”的,但它们有不同的用途:Received-SPF提供了关于输入参数的完整信息以及关于结果的附加信息,而Authentication-Results仅传达结果本身。在这里,就像在其他地方一样,SPF Milter旨在完全符合规范,特别是RFC 7208和8601,以及其中引用的其他规范。如有疑问,请参考RFCs。
变体
将softfail
视为失败结果。非常严格的设置可能希望将softfail
的结果与fail
结果具有相同的严重性,并将其拒绝。要实现这一点,只需将softfail
添加到要拒绝的结果中。
/etc/spf-milter.conf
:
reject_results = fail, softfail, temperror, permerror
在头部中添加更多信息。SPF Milter支持指定的两种头部字段,并且可能希望将它们都添加到消息中。使用header
参数进行配置非常简单。此外,启用include_all_results
会导致记录所有已验证标识符的结果(包括HELO和MAIL FROM)。
/etc/spf-milter.conf
:
header = Received-SPF, Authentication-Results
include_all_results = yes
DMARC中的SPF
SPF也可以作为DMARC验证设置的一部分使用。《基于域的消息身份验证、报告和一致性》(DMARC)在RFC 7489中定义。由于DMARC将使用SPF结果作为其自身验证过程的一个输入,因此需要对默认配置进行一些调整。
/etc/spf-milter.conf
:
socket = inet:localhost:3000
verify_helo = no
reject_results =
header = Authentication-Results
首先,在DMARC中,只有MAIL FROM标识符是有意义的;HELO标识符不予考虑。因此,应该禁用verify_helo
来跳过此步骤。
其次,由于SPF结果将作为DMARC的输入,因此可能不想在SPF验证后拒绝发件人,而是将此类操作委托给后续的DMARC组件(尽管根据要求,其他方法可能更有意义)。在上面的配置中,通过设置reject_results =
(空集)禁用了拒绝。这指示milter将结果记录在头部,而不是返回SMTP错误回复。
最后,参数header
将头部字段从默认的Received-SPF
更改为Authentication-Results
,因为DMARC依赖于这种类型的头部字段。《Authentication-Results》头部是一种通用设备,用于传达身份验证状态以便后续机器处理。它最近在RFC 8601中定义。
变体
尽早拒绝失败的HELO身份。 带有一点想象力,即使在为DMARC设置了SPF的情况下,人们仍然可能会利用HELO身份:拥有失败HELO身份的发送者可能不是什么好东西,可能被尽早拒绝。可以通过将fail
包含在要拒绝的结果中来实现此要求,但仅限于HELO身份。在所有其他方面,此配置的行为与上面的配置相同。
/etc/spf-milter.conf
:
verify_helo = yes
reject_helo_results = fail
reject_results =
贡献
欢迎各种形式的贡献。在问题跟踪器上打开一个工单以提问、建议、错误报告、功能请求、文档、翻译等。为了这个项目的长期可行性,我还可以授予你提交权限。
在实现新功能之前,请首先在问题跟踪器上讨论。实现通常比较简单,设计并推动一个功能是我们花费最多时间的地方。遵守并稳健实现RFC是SPF Milter相对于类似软件的主要成就之一;请务必查阅RFC。
本项目是在GPL许可证下作为免费软件开发的。请尊重这一许可证选择。
许可证
版权所有 © 2020–2024 David Bürgin
本程序是免费软件:您可以按照自由软件基金会发布的GNU通用公共许可证的条款重新分发和/或修改它,许可证版本为3,或(根据您的选择)任何后续版本。
本程序的分发是希望它将是有用的,但没有任何保证;甚至没有关于适销性或适用于特定目的的暗示性保证。有关详细信息,请参阅GNU通用公共许可证。
您应该已经随本程序收到一份GNU通用公共许可证的副本。如果没有,请参阅https://www.gnu.org/licenses/。
依赖关系
~9–18MB
~264K SLoC