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 기록이 잘못된 회사로부터 이메일을 받아야 하는데, 이런 일이 한동안 계속되었습니다. 따라서 이메일 대신 다음과 같은 로그가 표시됩니다.
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=<편집됨> to=<편집됨> proto=ESMTP helo=< us-smtp-delivery-134.mimecast.com>
회사에는 웹사이트나 WHOIS 정보에서 이 문제를 해결할 수 있는 담당자가 없습니다(registrant@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_recipient 제한" 부분.
또한 이 항목을 사용하여 /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 결과가 나오면 이 답변에 설명을 추가하겠습니다.