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]
격리를 방해하는 대신 RBL 및 SPFFAIL 전자 메일을 거부하도록 postfix 설치를 구성했습니다. 불행하게도, 한동안 그런 식으로 유지되어 온 잘못된 SPF 기록을 가지고 있는 회사로부터 이메일을 받아야 하는 회사가 있습니다. 따라서 이메일 대신 다음과 같은 멋진 로그를 받게 됩니다.
Apr 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=< 수정됨> to=< 수정됨> proto=ESMTP helo=< us-smtp-delivery-134.mimecast.com>
해당 회사에는 웹사이트나 WHOIS 정보에 이 문제를 해결할 수 있는 연락처가 없습니다(등록자 @dnstinations.com[일부 제3자 공급업체]가 제3자가 다음과 같이 말하는 이메일을 무시할 것이라고 가정합니다). 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_recipient_restrictions" 부분.
또한 이 항목을 사용하여 /etc/postfix/spf_client_regex를 만들었습니다(mimecast가 스팸 방지 공급업체이므로 충분히 안전해 보입니다).
/.*\.mimecast\.com$/ OK
나는 postmap -q를 사용하여 이를 테스트했고 예상된 "OK" 결과를 얻었으며 "postmap /etc/postfix/spf_client_regex"를 실행하여 업데이트된 내용을 업데이트하고 postfix를 다시 로드했습니다. 안타깝게도 이 발신자가 보낸 메일은 SPF 오류로 인해 계속 차단됩니다.
따라서 저는 거부_rbl_client 규칙을 무시하게 만드는 smtpd_client_restrictions 섹션의 화이트리스트 규칙에 대해 취한 단계와 기본적으로 동일하다는 점을 고려하면 위의 단계가 정확할 것이라고 예상했지만 작동하지 않습니다. 따라서 이 게시물의 제목에 명시된 대로: 화이트리스트를 사용하여 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
그걸 토대로 보면 그런 것 같다.domain_whitelist"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 결과가 나오면 이 답변에 메모를 추가하겠습니다.