![我可以使用白名单覆盖 SPF 策略吗?如何?](https://linux22.com/image/170276/%E6%88%91%E5%8F%AF%E4%BB%A5%E4%BD%BF%E7%94%A8%E7%99%BD%E5%90%8D%E5%8D%95%E8%A6%86%E7%9B%96%20SPF%20%E7%AD%96%E7%95%A5%E5%90%97%EF%BC%9F%E5%A6%82%E4%BD%95%EF%BC%9F.png)
我在 Linode 上运行 postfix。
Linux redacted 5.3.11-x86_64-linode131 #1 SMP PREEMPT Wed Nov 13 18:51:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
amavisd-new-postfix/xenial,xenial,now 1:2.10.1-2ubuntu1 all [installed]
postfix/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-mysql/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-pcre/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-policyd-spf-python/xenial,xenial,now 1.3.2-1 all [installed,automatic]
我将 postfix 安装配置为拒绝 RBL 和 SPFFAIL 电子邮件,而不是搞乱隔离区。不幸的是,我需要从一家公司接收电子邮件,该公司的 SPF 记录不正确,这种情况已经存在了一段时间。因此,我得到的不是电子邮件,而是这样的日志:
4 月 1 日 10:41:42 编辑 postfix/smtpd[18833]:NOQUEUE:拒绝:来自 us-smtp-delivery-134.mimecast.com[216.205.24.134] 的 RCPT:550 5.7.1 :收件人地址被拒绝:消息被拒绝至:SPF 失败 - 未授权。请参见http://www.openspf.net/Why?s=mfrom;id=redacted;ip=216.205.24.134;r=redacted; from=< 已编辑> 到=< 已编辑> proto=ESMTP helo=< us-smtp-delivery-134.mimecast.com>
该公司没有可能在其网站或 WHOIS 信息中解决此问题的联系人(我假设注册者 @dnstinations.com [某些第三方供应商] 会忽略来自第三方的电子邮件,其中表示: DNS配置错误)。
当我第一次收到此日志而不是电子邮件时,我尝试将 *.mimecast.com 列入白名单,但这没有什么区别,所以今天,我看了一下我的 main.cf。我看到 SPF 配置与我的白名单位于不同的行,所以我想也许我可以制作一个单独的特定于 SPF 的白名单。这是我的 main.cf 之前的样子:
smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access regexp:/etc/postfix/rbl_client_regex, check_client_access hash:/etc/postfix/rbl_client_override, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service unix:private/policy-spf
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access, reject_unknown_sender_domain
这是现在的样子:
smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access regexp:/etc/postfix/rbl_client_regex, check_client_access hash:/etc/postfix/rbl_client_override, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, regexp:/etc/postfix/spf_client_regex, check_policy_service unix:private/policy-spf
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access, reject_unknown_sender_domain
基本上,我对 main.cf 所做的就是添加“正则表达式:/etc/postfix/spf_client_regex,“ 前 ”check_policy_service unix:private/policy-spf“ 在里面 ”smtpd_收件人限制“ 部分。
我还使用此条目创建了 /etc/postfix/spf_client_regex (这似乎足够安全,因为 mimecast 是反垃圾邮件供应商):
/.*\.mimecast\.com$/ OK
我使用 postmap -q 进行了测试,得到了预期的“OK”结果,运行“postmap /etc/postfix/spf_client_regex”来更新所有更新,并重新加载 postfix。不幸的是,来自该发件人的邮件仍因 SPF 失败而被阻止。
因此,我预计上述步骤是正确的,因为它们与 smtpd_client_restrictions 部分中的白名单规则所采取的步骤基本相同,导致拒绝_rbl_client 规则被忽略,但它不起作用。正如本文标题所述:我可以使用白名单覆盖 SPF 策略吗?如何?
答案1
好的,所以我在评论后阅读了手册克里夫·阿姆斯特朗,我想我已经找到了解决方案。首先,我发现虽然 smtpd_client_restrictions 和 smtpd_sender_restrictions 都允许解析表,但都不允许处理策略。接下来,我发现定制政策可以创建,但这似乎不需要我学习编程语言来解决,所以我做了一个搜索,导致我这个帖子对某个特定的 spf 政策代表有一些合理的抱怨,并解释了如何将当前可用的两个 spf 政策代表列入白名单。
幸运的是,我已经安装了“更好”的策略委托,所以我不必更改它:
~$ apt list | grep policyd-spf
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
postfix-policyd-spf-perl/xenial,xenial 2.010-2 all
postfix-policyd-spf-python/xenial,xenial,now 1.3.2-1 all [installed,automatic]
接下来,我查看了注释文件(嗯,在我的情况下它是 gzip 的,所以我复制到了gunzip,然后在完成后删除了该副本)并找到了这些相关注释:
# Whitelist: CIDR Notation list of IP addresses not to check SPF for.
# Example (default is no whitelist):
# Whitelist = 192.168.0.0/31,192.168.1.12
# Domain_Whitelist: List of domains whose sending IPs (defined by passing
# their SPF check should be whitelisted from SPF.
# Example (default is no domain whitelist):
# Domain_Whitelist = pobox.com,trustedforwarder.org
基于此,听起来像是域名白名单对我不起作用,因为评论说“通过通过 SPF 检查定义的应该被列入 SPF 白名单”。这看起来很奇怪(如果发件人通过了域的 spf 检查,我就不需要加入白名单),但我仍然有白名单选项,所以我发现mimecast spf 文档然后使用 nslookup 收集 IP:
~$ nslookup
> set type=txt
> us._extnetblocks.mimecast.com
;; Truncated, retrying in TCP mode.
Server: 50.116.58.5
Address: 50.116.58.5#53
Non-authoritative answer:
us._extnetblocks.mimecast.com text = "v=spf1 ip4:207.211.30.40 ip4:207.211.30.41 ip4:207.211.30.42 ip4:207.211.30.43 ip4:207.211.30.44 ip4:207.211.30.45 ip4:207.211.30.46 ip4:207.211.30.47 ip4:207.211.30.48 ip4:207.211.30.49 ip4:205.139.111.40 ip4:205.139.111.41 ip4:205.139.111.42 " "ip4:205.139.111.43 ip4:205.139.111.44 ip4:205.139.111.45 ip4:205.139.111.46 ip4:205.139.111.47 ip4:205.139.111.48 ip4:205.139.111.49 ~all"
Authoritative answers can be found from:
mimecast.com nameserver = dns02.mimecast.net.
mimecast.com nameserver = dns03.mimecast.net.
mimecast.com nameserver = dns04.mimecast.net.
mimecast.com nameserver = dns01.mimecast.net.
然后我将这些结果放入配置文件中:
Whitelist = 207.211.30.40, 207.211.30.41, 207.211.30.42, 207.211.30.43, 207.211.30.44, 207.211.30.45, 207.211.30.46, 207.211.30.47, 207.211.30.48, 207.211.30.49, 205.139.111.40, 205.139.111.41, 205.139.111.42, 205.139.111.43, 205.139.111.44, 205.139.111.45, 205.139.111.46, 205.139.111.47, 205.139.111.48, 205.139.111.49
这并不理想,因为它会自动允许这些 IP 从其他域发送,并且 IP 可能易手,但对于我的私人实现来说已经足够了。因此,我不会尝试学习创建自己的代表或雇用某人为我创建一个代表。尽管进行了这些更改,如果我得到另一个类似的 NOQUEUE 结果,我会为此答案添加注释。