포스트픽스 설정 · 9 min read · Nov 14, 2025
우분투 대퍼, 메일스캐너, 스팸어쌔신, 레이저, 피조르, DCC 및 클램AV를 이용한 포스트픽스 스팸 필터 - 페이지 3
2.3 포스트픽스 안티 스팸 설정
예비 노트:
클라이언트(메일을 보내려는 컴퓨터)가 포스트픽스에 연결하고 통신 세션을 시작하면 포스트픽스는 해당 세션에 대한 정보를 기록합니다. 포스트픽스가 해당 세션에서 메일을 수신하여 배달하기 전에, 우리는 세션을 평가하고 main.cf에서 몇 가지 제한을 설정하여 메일을 거부할 수 있는 옵션이 있습니다. 이 링크는 일반적인 SMTP 세션 동안 발생하는 일을 설명합니다: http://helpdesk.islandnet.com/pep/smtp.php. 아래의 제한은 일부 스팸을 차단하고 우리의 시스템이 오픈 릴레이가 되는 것을 방지하는 데 도움이 됩니다. 이러한 제한은 일부 메일이 포스트픽스의 “정문”에서 바로 거부되도록 합니다. 이는 메일이 우리 시스템에 들어오지 않게 하여 메일스캐너(그리고 이후 스팸어쌔신)에 의해 스캔되지 않도록 하여 시스템 자원을 절약합니다. 이는 좋기도 하고 나쁘기도 합니다. 시스템 자원을 절약하지만, 거부된 메일을 볼 수 없게 됩니다. 당신이 볼 수 있는 것은 포스트픽스에서 “안녕하세요, IP 주소 X.X.X.X의 “xxxxxxxx”라는 메일 서버가 메일을 보내려고 했지만 규칙 XYZ를 위반했으므로 거부했습니다”라는 로그 항목 몇 개뿐입니다. 이것이 스팸일 수도 있지만(스팸 발송자는 종종 목표를 달성하기 위해 RFC를 의도적으로 따르지 않습니다) 만약 고객의 IT 부서가 단순히 메일 서버를 잘못 구성한 경우와 같은 “합법적인” 메일이었다면, 당신은 다루어야 할 불편한 상황이 생길 수 있습니다.
모든 메일이 우리에게 들어오도록 허용하고, 따라서 메일스캐너/스팸어쌔신이 시스템 내에서 모든 스팸 제어를 처리하도록 하려면 아래의 몇 가지 설정을 수정해야 합니다. 개인적으로 포스트픽스와 스팸어쌔신의 안티 스팸 제어 조합이 가장 좋다고 생각합니다. 최소한 포스트픽스의 기본 안티 릴레이 제어를 비활성화하지 않도록 해야 합니다 (smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination).
아래의 구성은 실제로 매우 보수적이며, 대부분의 이메일이 정문으로 들어오도록 허용하여 메일스캐너와 스팸어쌔신이 이를 처리할 수 있도록 합니다. 제 경우에는 (안전하게) 사용자에게 전달될 이메일의 약 35%를 거부하므로 이러한 설정이 매우 가치 있다고 생각합니다. 이 접근 방식을 시작으로 추천합니다. 추가 제한을 추가하면 잘못 구성된 컴퓨터에서 유효한 이메일이 거부될 가능성이 높아집니다. 향후 권한/제한을 추가하거나 제거하기로 결정하면 한 번에 하나씩 수행하고 변경의 영향을 평가할 충분한 시간을 주십시오. 아래 항목을 변경하기 전에 이러한 제한이 어떻게 작동하는지 잘 이해하는 것이 좋습니다. 다른 것들 중에서, 이 내용을 잘못 이해하면 합법적인 메일을 거부하거나 오픈 릴레이가 될 수 있습니다. 제한이 항상 제한하는 것은 아니며, 일부는 허용하기도 합니다.
이러한 설정을 더 잘 이해하고 싶다면 좋은 자료는 http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt, http://www.postfix.org/SMTPD_ACCESS_README.html, http://www.securitysage.com/antispam/, 다소 오래된 (2001) http://www.mengwong.com/misc/postfix-uce-guide.txt, 그리고 이 훌륭한 책입니다. 나는 이와 같은 설정 중 몇 개만 사용하므로 이 구성은 제한적이지 않습니다. 스팸어쌔신과 메일스캐너가 곧 등장하여 스팸을 인식하고 조작할 수 있는 훨씬 더 유연하고 구성 가능한 옵션을 제공할 것임을 기억하십시오.
2.3.1 smtpd_helo_required
연결된 모든 메일 서버가 적절한 smtp “핸드셰이크”를 수행하고 자신의 이름을 발표하도록 합니다. 인터넷 RFC는 이를 요구하므로 우리도 그렇게 합니다.
postconf -e "smtpd_helo_required = yes"서문: 포스트픽스의 제한 단계는 다음과 같으며, 다음 순서로 처리됩니다:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictionssmtpd_recipient_restrictions
smtpd_data_restrictions우리는 마지막 세 가지 제한 단계에만 항목을 배치할 것입니다. 제한 단계는 main.cf에 나열된 순서와 관계없이 이 순서로 처리됩니다.
2.3.2 smtpd_sender_restrictions
이 제한 단계는 이 시스템이 MAIL FROM: 명령(봉투 발신자)에서 어떤 발신자 주소를 수락하는지를 제한합니다. 우리는 이 제한 단계에 세 가지 테스트(제한)를 배치할 것입니다.
제한 단계는 제한(테스트)의 목록을 보유합니다. 일반적으로 테스트는 DUNNO, REJECT 또는 OK로 평가됩니다. DUNNO는 “무엇을 해야 할지 모르겠으니 다음 테스트가 결정하게 하세요“를 의미합니다. REJECT는 단순히 메일을 거부합니다. OK는 이 제한 단계에서 더 이상 테스트가 수행되지 않으며, 테스트는 다음 단계(있는 경우)로 계속 진행됩니다. Reject* 유형 테스트는 일반적으로 REJECT 또는 DUNNO로 평가됩니다. Permit 유형 테스트는 일반적으로 OK 또는 DUNNO로 평가되며, check__access 유형 테스트는 다양한 작업을 수행할 수 있습니다. 그림은 기본 논리를 보여줍니다.
SMTP 세션
|
V
제한 단계-------------
테스트 ---------------REJECT->
| \
| DUNNO
| \
| V
| 다음 테스트------REJECT->
| | \
OK OK DUNNO
| | \
| | V
V V
다음 제한 단계------->2.3.2.1 check_sender_access
http://www.postfix.org/access.5.html을 참조하십시오. 여기서 우리는 포스트픽스에게 봉투 발신자를 /etc/postfix/sender_access 데이터베이스의 항목과 비교하고 일치하는 항목이 발견되면 해당 항목에 따라 행동하도록 요청합니다. 우리는 또한 발신자별로 어떤 조치가 취해지는지(OK, DUNNO, REJECT 등)를 정의합니다. 발신자가 파일에 나열되지 않은 경우, 테스트는 DUNNO로 평가되며 다음 테스트가 수행됩니다. 이 파일의 한 용도는 메일을 수신하고 싶지 않은 발신자(이메일 주소, 도메인, 네트워크 주소 등)의 목록을 배치하는 것입니다(블랙리스트). 우리는 메일스캐너와 스팸어쌔신에서도 발신자를 블랙리스트에 추가할 수 있지만, 여기서 블랙리스트에 추가하면 자원을 절약할 수 있습니다. 우리는 또한 이 파일을 사용하여 특정 발신자가 이 제한 단계의 다음 두 테스트를 우회하도록 허용할 수 있습니다. 여기서 OK를 주면 이 제한 단계에서 더 이상 테스트가 수행되지 않으며, 테스트는 다음 제한 단계(smtpd_recipient_restrictions)로 계속 진행됩니다. 이 설정을 reject_unauth_destination 테스트 전에 smtpd_recipient_restrictions 제한 단계에 배치하고, 누군가에게 OK를 주면, 그곳에 위치한 reject_unauth_destination 테스트가 우회됩니다. 이는 나쁜 일이 될 수 있습니다. 왜냐하면 우리가 OK를 준 사람은 우리 서버를 오픈 릴레이로 사용할 수 있게 되기 때문입니다. 접근 제한은 우리가 나열한 순서대로 평가되며, 일치하는 항목이 발견되면 이후 제한이 어떻게(여부) 평가되는지에 영향을 미칩니다.
2.3.2.2 reject_non_fqdn_sender
봉투 발신자 메일 주소가 올바른 형식이 아닐 때 거부합니다. “봉투 발신자”는 발신 메일 서버가 SMTP 세션 중 “MAIL FROM:” 줄에서 제공하는 것이며, 헤더 “From:” 줄이 아닙니다. “Joe”는 우리에게 메일을 보낼 수 없습니다(왜냐하면 “Joe”에게 회신할 수 없기 때문입니다) 하지만 “[email protected]”는 최소한 이메일 주소입니다. 발신자가 이 시점에서 거부되지 않으면 이 테스트는 “DUNNO”로 평가됩니다.
2.3.2.3 reject_unknown_sender_domain
봉투 발신자의 도메인 부분이 DNS “A” 또는 “MX” 레코드가 전혀 없을 때 거부합니다. 이 설정은 제 메일 서버로 들어오는 메일의 약 35%를 차단합니다. 스팸 발송자가 거부된 메일의 반발을 피하기 위해 가짜 도메인 이름을 사용하는 것은 일반적입니다. 또한 발신자의 도메인이 존재하지 않기 때문에 반송 통지로 큐가 가득 차는 것을 방지하는 것이 중요합니다. 발신자의 도메인에 “A” 또는 “MX” 레코드가 있는 경우, 이 테스트는 또한 “DUNNO”로 평가됩니다. 때때로, 당신이 메일을 받고 싶어하는 누군가가 이 설정에 의해 거부되었다는 보고서를 볼 수 있습니다. 이 경우의 한 가지 가능한 원인은 합법적인 발신자가 의도적으로 가짜 도메인 이름을 사용하여 당신이 그들에게 회신하지 않도록 하는 것입니다. 이럴 때 발신자 접근 목록이 유용합니다. 그곳에서 OK를 주면 이 테스트가 우회됩니다.
이제 이 세 가지 제한을 구현합니다:
postconf -e "smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access, reject_non_fqdn_sender, reject_unknown_sender_domain"2.3.3 smtpd_recipient_restrictions
포스트픽스 SMTP 서버가 RCPT TO: 명령의 맥락에서 적용하는 접근 제한입니다. 이는 SMTP 세션 중 클라이언트가 “RCPT TO:” 줄에서 제공한 “봉투 수신자”를 의미하며, 헤더 “To:” 줄이 아닙니다. smtpdrecipient_restrictions는 특정 제한 목록을 보유하는 또 다른 제한 단계입니다. smtpd_recipient_restrictions 이전에 평가되는 다른 제한 단계는 smtpd_client_restrictions, smtpd_helo_restrictions 및 smtpd_sender_restrictions(이 순서로)입니다. 일반적으로 이러한 이전 제한 단계에 들어가야 할 제한은 대안으로 smtpd_recipient_restrictions에 배치될 수 있습니다. 따라서 일부 사람들은 일반적으로 이전 제한 단계에 들어가야 할 모든 smtpd*_restrictions를 smtpd_recipient_restrictions에 배치하고 이전 단계는 비워두는 것을 선호합니다. 우리의 경우 smtpd_sender_restrictions와 smtpd_recipient_restrictions를 사용하는 것이 더 안전합니다. smtpd_recipient_restrictions에 배치하는 특정 제한(테스트)을 살펴보겠습니다:
2.3.3.1 permit_mynetworks
“mynetworks”에 나열된 머신이 이 제한 단계의 나머지 테스트를 건너뛰도록 허용합니다(permit = OK). 즉, 이 단계에서 종료되고 다음 단계(smtpd_data_restrictions)에서 테스트됩니다. permit_mynetworks가 reject_unauth_destination 앞에 배치되었기 때문에, $mynetworks에 있는 머신은 모든 도메인으로 메일을 릴레이할 수 있습니다. 그렇지 않으면 우리는 자신의 도메인에만 메일을 보낼 수 있습니다. 발신자의 IP 주소가 $mynetworks에 나열되지 않은 경우, 테스트는 “DUNNO”로 평가되고 다음 테스트(reject_unauth_destination)로 계속 진행됩니다.
2.3.3.2 reject_unauth_destination
이 설정은 permit_mynetworks와 함께 릴레이 제어에 사용됩니다. 본질적으로 이 설정은 우리가 메일을 수신하도록 구성하지 않은 모든 도메인으로 향하는 메일은 거부된다는 것을 의미합니다. 우리의 경우 포스트픽스는 이전에 구성한 relay_domains 설정(또는 테이블)을 사용하여 어떤 도메인인지 결정합니다. 추가 세부정보는 http://www.postfix.org/postconf.5.html#reject_unauth_destination를 참조하십시오. 도메인이 relay_domains에 나열되어 있으면 이 테스트는 “DUNNO”로 평가되고 세션은 다음 테스트(있는 경우)로 진행됩니다. “mynetworks”와 마찬가지로 이 설정은 매우 중요합니다. permit_mynetworks를 reject_unauth_destination 바로 앞에 배치함으로써 우리는 우리의 도메인 외의 도메인으로 메일을 보낼 수 있지만, 외부 네트워크에서 우리에게 주소가 지정된 메일만 수신하도록 보장합니다. 따라서 permit_mynetworks와 reject_unauth_destination은 팀으로 작동합니다.
2.3.3.3 reject_unauth_pipelining
파이프라이닝을 사용하여 배달 속도를 높이려는 대량 메일 발송자를 거부합니다. 먼저 지원되는지 확인하지 않고(비 RFC, 스팸 발송자 사이에서 일반적입니다).
이제 이 세 가지 제한을 구현합니다:
postconf -e "smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining"2.3.4 smtpd_data_restrictions
SMTP DATA: 명령의 맥락에서 포스트픽스 SMTP 서버가 적용하는 선택적 접근 제한입니다. smtpd_recipient_restrictions와 마찬가지로, 이것은 제한 단계입니다.
2.3.4.1 reject_unauth_pipelining
이 설정은 smtpd_recipient_restrictions에 배치할 때 항상 효과적이지 않기 때문에 smtpd_data_restrictions에 반복합니다. 정책 서버보다 앞에 두고 싶기 때문에 smtpd_recipient_restrictions에 포함합니다. smtpd_data_restrictions에서 잘 활용되는 제한은 몇 가지에 불과합니다.
postconf -e "smtpd_data_restrictions = reject_unauth_pipelining"2.3.5 포스트픽스 콘텐츠 필터링 제어 파일:
http://www.postfix.org/header_checks.5.html - /etc/postfix/header_checks 및 /etc/postfix/body_checks
이 파일들은 특정 “문자열”을 나열하고, 이메일 헤더나 메시지 본문에서 이러한 문자열을 발견했을 때 포스트픽스가 무엇을 해야 하는지 알려줍니다. 샘플 파일이 이미 생성되어 있으며, 무엇을 넣어야 하는지 설명하는 주석이 있습니다. 편한 대로 편집할 수 있습니다. 이러한 파일은 “정규 표현식 형식”을 사용해야 합니다. “regexp”는 *nix 세계에서 살기 위해 배우고 싶어하는 것입니다. 책을 구입하거나 인터넷에서 조사해 보십시오. 태도 있는 사람의 정교한 header_checks 파일의 예를 보려면 http://www.geekounet.org/filters/header_checks를 확인하십시오. 하지만 맹목적으로 따르지 마세요, 이것은 단지 예일 뿐입니다! body_checks 파일의 예는 http://www.securitysage.com/files/body_checks입니다. 여유가 있을 때 http://www.securitysage.com/guides/postfix_uce.html를 확인하는 것이 좋습니다. 특히 http://www.securitysage.com/antispam/hedchek.html 및 http://www.securitysage.com/antispam/bodchek.html을 확인하십시오. 포스트픽스의 어떤 부분에 대해서도 많은 변경을 하지 않도록 권장합니다. 충분한 시간을 두고 효과를 평가하십시오. 거북이처럼 천천히 가세요, 오래 사세요.
2.3.5.1 header_checks & body_checks
이 두 가지를 main.cf에 넣어 보겠습니다. header_checks는 메일스캐너가 작업을 수행할 수 있도록 모든 수신 이메일을 보관할 수 있게 해주기 때문에 필수입니다:
postconf -e "header_checks = pcre:/etc/postfix/header_checks"
postconf -e "body_checks = pcre:/etc/postfix/body_checks"header_checks 편집:
vi /etc/postfix/header_checksheader_checks 파일에 이 줄을 추가하십시오. 없으면 메일스캐너가 작동하지 않습니다:
/^Received:/ HOLDpcre 유형 테이블은 postmap할 필요가 없음을 유의하십시오. 이들은 일반 텍스트로 남아 있으며 포스트픽스는 “있는 그대로” 사용합니다.
mime_header_checks 및 nested_header_checks를 header_checks 및 body_checks와 함께 구성할 수도 있습니다. 포스트픽스에서 콘텐츠 필터링을 너무 창의적으로 사용하면(header_checks 및 body_checks 사용) 성능에 상당한 영향을 미칠 수 있습니다.
2.3.5.2 /etc/postfix/sender_access http://www.postfix.org/access.5.html
우리는 smtpd_sender_restrictions에서 이 파일을 참조했습니다. 우리는 이 파일을 사용하여 정문에서 발신자를 확인합니다. 이 파일에서는 특별한 처리를 위해 특정 발신자/도메인/IP 주소 범위를 나열합니다. 아래는 가짜 예시이며, 필요에 따라 자신만의 것을 만드십시오. 자세한 내용은 /etc/postfix/sender_access를 읽어보십시오. 이 파일을 다양한 용도로 사용할 수 있지만, smtpd_sender_restrictions에서 설정한 방식으로 고려할 때, 발신자를 블랙리스트에 추가하거나 특정 발신자가 smtpd_sender_restrictions의 나머지 테스트를 우회하도록 허용하는 데 사용하는 것이 좋습니다.
vi /etc/postfix/sender_access#예시 발신자 접근 맵 파일
[email protected] 550 MLM은 필요 없습니다
allspam.tld 550 스팸은 수용되지 않습니다
badguy.net REJECT
[email protected] REJECT
newsletter-favorite-lug.org OK
my-really-l337-test-domain.com OK해시 테이블이므로, 평소처럼 postmap해야 합니다:
postmap /etc/postfix/sender_access2.3.6 포스트픽스 설치 최종 점검
변경 사항 검토:
less /etc/postfix/main.cf파일의 내용을 확인하여 오류가 있는지 확인하고 필요시 수정합니다. 포스트픽스를 시작합니다:
postfix start포스트픽스가 응답하는지 확인합니다:
telnet 127.0.0.1 25다음과 같은 메시지가 표시되어야 합니다:
220 [yourFQDNhere] ESMTP Postfix (Ubuntu)[enter]를 몇 번 누른 후, quit를 입력하여 종료합니다.
이런 방식으로 응답하지 않으면, 다른 터미널 창을 열고 포스트픽스를 중지합니다: postfix stop. newaliases 및 위의 모든 postmap 명령을 실행했는지 확인하십시오. main.cf 및 master.cf의 모든 설정을 확인하십시오. 포스트픽스 문제 해결에 대한 좋은 논문은 http://www.postfix-book.com/debugging.html에 있지만, 이 시점에서 우리의 시스템은 메일을 릴레이할 준비가 되어 있지 않음을 기억하십시오(큐에 들어가게 됩니다).
master.cf 또는 main.cf 또는 데이터 테이블에 변경을 할 때마다, 대부분(모든 것은 아님) 경우 포스트픽스를 다시 로드해야 합니다:
postfix reload이제 기본 포스트픽스 구성이 완료되었습니다. http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall 및 http://www.postfix.org/BASIC_CONFIGURATION_README.html은 우리가 사용한 설정에 대해 더 잘 이해할 수 있는 좋은 장소입니다. 이 시점에서 이러한 README는 더 의미가 있을 것입니다.
기본적으로 우리의 포스트픽스는 chrooted 상태로 실행됩니다. 이것이 무엇을 의미하는지 모른다면, 이 시점에서는 그리 중요하지 않을 것입니다. 나중에 chroot가 무엇인지 조사해 보시기 바랍니다. 포스트픽스가 제대로 실행되기 위해 필요한 일부 시스템 파일은 설치 중에 포스트픽스의 chroot 감옥(/var/spool/postfix)으로 복사되었습니다. 때때로 원본 파일이 수정되면 포스트픽스는 가지고 있는 복사본이 원본과 다르다고 불평합니다. 이럴 경우, 포스트픽스가 불평한 파일을 chroot 감옥으로 수동으로 복사하거나, 포스트픽스 소스 코드와 함께 제공되는 스크립트(LINUX2)를 실행하여 포스트픽스가 필요한 모든 파일을 다시 복사할 수 있습니다.
cd /usr/local/src/postfix-2.3.3/examples/chroot-setup
postfix start
chmod +x LINUX2
cp LINUX2 /usr/bin
LINUX2
cd
postfix check이렇게 하면 LINUX2 스크립트가 실행 가능해지고, 경로에 있는 디렉토리로 복사한 다음 실행됩니다. LINUX2는 포스트픽스가 구성 파일이나 디렉토스에 접근하는 데 오류가 발생할 경우 일반적으로 문제를 해결합니다.
새 게시물을 받은 편지함에서 받기
스팸은 없습니다. 언제든지 구독 해지 가능합니다.