최근 Self-hosted mail-receiver update following Let's Encrypt root certificate change mail-receiver 업데이트에서는 더 이상 IP를 호스트네임으로 해석하지 않는 것으로 보입니다. 이로 인해 이전에 정상적으로 작동하던 postfix 클라이언트 접근 제한에 문제가 발생합니다. 해당 제한은 mail-receiver.yml에 다음 줄을 추가하여 활성화됩니다:
POSTCONF_smtpd_client_restrictions: 'regexp:/etc/postfix/shared/client_access_regex'
다음은 수신 연결을 보여주는 mail-receiver 로그 일부입니다:
Oct 01 17:38:11 discourse-mail-receiver postfix/master[1]: reload -- version 3.5.6, configuration /etc/postfix
Oct 01 17:41:58 discourse-mail-receiver postfix/smtpd[151]: connect from unknown[167.71.160.115]
Oct 01 17:41:59 discourse-mail-receiver postfix/smtpd[151]: disconnect from unknown[167.71.160.115] ehlo=2 starttls=1 mail=1 quit=1 commands=5
예전에는 원본 클라이언트의 호스트네임인 www11-do.checktls.com[167.71.160.115]로 해석되던 것이 이제는 해석되지 않고 unknown[167.71.160.115]로 표시됩니다.
이로 인해 client_access_regex 파일의 정규식 항목과 충돌이 발생합니다. 이 파일은 유효한 PTR 레코드가 없는 모든 호스트(기본적으로 스팸 릴레이)와 동적 IP 범위(주로 가상 호스트이며, 역시 대부분 스팸 릴레이)의 모든 호스트를 거부하도록 설계되어 있습니다.
IP가 호스트네임으로 해석되지 않기 때문에 어떤 규칙도 더 이상 작동하지 않으며, 더 심각한 문제는 /unknown/ REJECT 줄이 이제 모든 수신 이메일을 차단한다는 점입니다. 수신 연결이 가능하도록 규칙을 일시적으로 비활성화해야 했으며, 해석 문제로 인해 다른 모든 규칙도 비활성화 상태가 되어 서버가 다시 스팸에 노출되고 있습니다(이 규칙을 구현하기 전에는 포럼에 스팸이 넘쳐났고, 구현 후에는 스팸을 받은 기억이 없습니다).
우회책으로 이전 버전으로 되돌아갈 수 없습니다(letsencrypt 문제 때문에) 그리고 새로운 버전은 다시 스팸의 범람을 허용하므로, 수정이 매우 필요할 것 같습니다(docker 이미지 내에서 DNS 해석을 수동으로 활성화하는 방법을 알아보고자 노력했지만 실패했습니다).
참고용 client_access_regex 파일입니다. 동일한 반복적인 스팸 문제를 겪고 있으며 시도해 보고자 하는 분들을 위해 공유합니다(/etc/postfix/shared와 mail-receiver.yml을 설정하려면 Customize direct-delivery Postfix configuration 을 사용하세요):
# regex dns: ([a-zA-Z0-9]+(-[a-zA-Z0-9]+)*\.)+[a-zA-Z]{2,}
# regex ip: ((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)
#
# dyn-ip-dns:
/((\.|-|x)(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2}((\.|-)[a-zA-Z0-9]+)+\.[a-zA-Z]{2,}/ REJECT
/unknown/ REJECT
/sample-spam\.domain\.com/ REJECT