SMTP 서버 구성 Postfix 완벽 가이드

리눅스 환경에서 Postfix를 활용한 메일 서버 구축의 모든 것을 다룹니다. 아키텍처 이해부터 보안 설정까지, 실무에서 바로 적용할 수 있는 핵심 내용을 담았습니다.

---

목차

1. Postfix_아키텍처_이해
2. main.cf_핵심_설정_항목
3. 릴레이_및_접근_제어_설정
4. 메일_큐_관리
5. 발송_제한_및_속도_조절
6. SMTP_인증_설정_SASL

---

1. Postfix 아키텍처 이해

어느 날 김개발 씨가 회사에서 메일 서버 구축 업무를 맡게 되었습니다. "메일이 어떻게 전송되는 거지?" 막막한 마음에 선배 박시니어 씨에게 도움을 요청했습니다.

"Postfix 아키텍처부터 이해해야 해요. 그래야 문제가 생겼을 때 어디를 봐야 하는지 알 수 있거든요."

Postfix는 리눅스에서 가장 널리 사용되는 **MTA(Mail Transfer Agent)**입니다. 마치 우체국 시스템처럼 여러 부서가 협력하여 메일을 처리합니다.

각 데몬의 역할을 이해하면 메일 흐름을 완벽하게 파악할 수 있습니다.

다음 코드를 살펴봅시다.

# Postfix 핵심 데몬 구조 확인
postconf -d | grep mail_version
# mail_version = 3.5.9

# 실행 중인 Postfix 프로세스 확인
ps aux | grep postfix
# master - 모든 데몬을 관리하는 부모 프로세스
# smtpd  - 외부 메일 수신 담당
# smtp   - 외부로 메일 발송 담당
# qmgr   - 메일 큐 관리자
# pickup - 로컬 메일 수집

# 데몬 간 통신 구조 확인
postconf -M

김개발 씨는 입사 2년 차 시스템 엔지니어입니다. 어느 날 팀장님이 다가와 말했습니다.

"우리 회사도 자체 메일 서버가 필요해졌어요. Postfix로 구축해 볼 수 있겠어요?" 메일 서버라니, 처음 해보는 일이었습니다.

김개발 씨는 일단 Postfix를 설치하고 설정 파일을 열어보았지만, 도대체 어디서부터 시작해야 할지 막막했습니다. 그때 옆자리의 박시니어 씨가 조언을 건넸습니다.

"메일 서버를 제대로 운영하려면 먼저 구조를 이해해야 해요. Postfix가 어떻게 메일을 처리하는지 알아야 문제가 생겼을 때 대처할 수 있거든요." 그렇다면 Postfix의 구조는 어떻게 되어 있을까요?

쉽게 비유하자면, Postfix는 대형 우체국과 같습니다. 우체국에는 접수 창구, 분류실, 배송팀 등 여러 부서가 있듯이, Postfix도 각각의 역할을 담당하는 여러 **데몬(daemon)**으로 구성되어 있습니다.

가장 중요한 것은 master 프로세스입니다. 이것은 우체국 국장님과 같습니다.

모든 데몬을 관리하고, 필요에 따라 새로운 데몬을 실행하거나 종료합니다. Postfix를 시작하면 가장 먼저 master가 실행되고, 나머지 데몬들은 master의 지휘 아래 움직입니다.

smtpd 데몬은 접수 창구 직원입니다. 외부에서 들어오는 메일을 받아들이는 역할을 합니다.

누군가 우리 서버로 메일을 보내면 smtpd가 먼저 받아서 처리합니다. 이 과정에서 스팸인지, 허용된 발신자인지 등을 확인합니다.

반대로 smtp 데몬은 배송팀입니다. 우리 서버에서 외부로 메일을 보낼 때 활약합니다.

받는 사람의 메일 서버를 찾아서 메일을 전달하는 것이 이 데몬의 임무입니다. qmgr은 분류실 담당자입니다.

들어온 메일을 큐에 넣고, 언제 어디로 보낼지 결정합니다. 메일 서버가 바쁘거나 상대방 서버에 문제가 있을 때, qmgr이 메일을 보관하고 있다가 적절한 시점에 재시도합니다.

pickup 데몬은 내부 수거 담당입니다. 로컬에서 생성된 메일, 예를 들어 시스템 알림 메일 같은 것을 수집하여 큐에 넣습니다.

이 외에도 cleanup(메일 정리), trivial-rewrite(주소 변환), bounce(반송 처리) 등 다양한 데몬이 있습니다. 각자 맡은 일만 하고, 필요할 때만 실행되기 때문에 시스템 자원을 효율적으로 사용합니다.

다시 김개발 씨 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 이제 메일이 어떤 경로로 처리되는지 그림이 그려지기 시작했습니다.

"아, 그래서 로그를 볼 때 어떤 데몬에서 문제가 생겼는지 확인해야 하는 거군요!" Postfix 아키텍처를 이해하면 설정 파일의 의미도, 로그 분석도, 문제 해결도 훨씬 수월해집니다.

실전 팁

💡 - postfix status 명령으로 현재 실행 상태를 확인하세요

• /var/log/maillog에서 각 데몬별 로그를 추적할 수 있습니다
• master.cf 파일에서 각 데몬의 설정을 조정할 수 있습니다

---

2. main.cf 핵심 설정 항목

김개발 씨가 Postfix 설정 파일을 처음 열었을 때, 수백 줄의 설정 항목에 압도당했습니다. "이걸 다 알아야 하나요?" 박시니어 씨가 웃으며 말했습니다.

"전부 다 알 필요는 없어요. 핵심만 제대로 알면 됩니다."

main.cf는 Postfix의 핵심 설정 파일입니다. 마치 자동차의 계기판처럼 서버의 기본 동작을 결정합니다.

호스트명, 도메인, 네트워크 설정 등 필수 항목만 제대로 잡아도 메일 서버가 동작합니다.

다음 코드를 살펴봅시다.

# /etc/postfix/main.cf 핵심 설정

# 서버 호스트명 설정
myhostname = mail.example.com

# 메일 도메인 설정
mydomain = example.com
myorigin = $mydomain

# 수신 허용 목적지
mydestination = $myhostname, localhost.$mydomain, $mydomain

# 신뢰할 네트워크 범위
mynetworks = 127.0.0.0/8, 192.168.1.0/24

# 메일 저장 경로
home_mailbox = Maildir/

# 수신 인터페이스 설정
inet_interfaces = all
inet_protocols = ipv4

김개발 씨는 드디어 Postfix 설정에 도전하기로 했습니다. /etc/postfix/main.cf 파일을 열어보니 주석을 포함해서 수백 줄이 넘었습니다.

어디서부터 손을 대야 할지 막막했습니다. 박시니어 씨가 다가와 화면을 보더니 말했습니다.

"너무 겁먹지 마세요. Postfix 설정의 90%는 기본값으로도 잘 동작해요.

우리가 건드려야 할 건 핵심 설정 몇 개뿐이에요." main.cf를 쉽게 비유하자면, 이것은 집 주소와 신분증과 같습니다. 우체부가 편지를 배달하려면 정확한 주소가 필요하듯, 메일 서버도 자신이 누구인지, 어떤 메일을 받을지 명확히 알아야 합니다.

가장 먼저 설정해야 할 것은 myhostname입니다. 이것은 메일 서버의 공식 이름입니다.

다른 메일 서버와 통신할 때 자신을 소개하는 명함과 같습니다. 반드시 DNS의 MX 레코드와 일치해야 합니다.

그렇지 않으면 다른 서버가 우리 메일을 스팸으로 의심할 수 있습니다. mydomain은 우리 회사의 도메인입니다.

example.com처럼 설정하면 됩니다. myorigin은 메일을 보낼 때 발신자 주소에 붙는 도메인입니다.

보통 mydomain과 같게 설정합니다. mydestination이 특히 중요합니다.

이것은 "어떤 메일을 내가 받을 것인가"를 결정합니다. 여기에 적힌 도메인으로 오는 메일만 수신합니다.

잘못 설정하면 받아야 할 메일을 거부하거나, 받지 말아야 할 메일을 받게 됩니다. mynetworks는 신뢰할 수 있는 네트워크 범위입니다.

여기에 포함된 IP에서 오는 메일은 별도의 인증 없이 릴레이를 허용합니다. 보안상 매우 중요한 설정이므로 반드시 내부 네트워크만 포함해야 합니다.

잘못하면 스패머들의 중계 서버가 될 수 있습니다. inet_interfaces는 어떤 네트워크 인터페이스에서 메일을 받을지 결정합니다.

all로 설정하면 모든 인터페이스에서 수신합니다. 보안이 중요한 환경에서는 특정 IP만 지정하기도 합니다.

home_mailbox는 수신한 메일을 어디에 저장할지 결정합니다. Maildir/ 형식을 권장합니다.

이 방식은 각 메일을 별도 파일로 저장하기 때문에 손상 위험이 적고, 여러 프로그램이 동시에 접근해도 안전합니다. 설정을 변경한 후에는 반드시 문법을 검사해야 합니다.

postfix check 명령을 실행하면 설정 파일의 오류를 찾아줍니다. 문제가 없다면 postfix reload로 설정을 적용합니다.

김개발 씨는 핵심 설정 항목을 하나씩 채워나갔습니다. 처음에는 막막했던 수백 줄의 설정 파일이 이제는 어떤 구조인지 보이기 시작했습니다.

"생각보다 어렵지 않네요!"

실전 팁

💡 - postconf -n 명령으로 기본값과 다른 설정만 확인할 수 있습니다

• 설정 변경 전 반드시 백업하세요: cp main.cf main.cf.backup
• postfix check로 문법 오류를 먼저 확인하고 reload 하세요

---

3. 릴레이 및 접근 제어 설정

메일 서버를 인터넷에 공개한 지 하루 만에 김개발 씨의 서버는 스팸 릴레이 공격을 받았습니다. 로그를 보니 수천 통의 스팸이 서버를 통해 발송되고 있었습니다.

"큰일 났어요!" 박시니어 씨가 급히 달려왔습니다. "접근 제어 설정을 안 했군요.

지금 바로 막아야 해요."

릴레이 제어는 메일 서버 보안의 핵심입니다. 마치 건물 출입 관리처럼, 누가 우리 서버를 통해 메일을 보낼 수 있는지 엄격하게 통제해야 합니다.

잘못된 설정은 서버를 스팸 중계지로 만들어 블랙리스트에 등재되는 결과를 초래합니다.

다음 코드를 살펴봅시다.

# /etc/postfix/main.cf 접근 제어 설정

# SMTP 수신 제한 (외부에서 들어오는 메일)
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_invalid_hostname,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain

# 발신자 제한
smtpd_sender_restrictions =
    reject_non_fqdn_sender,
    reject_unknown_sender_domain

# 클라이언트 제한
smtpd_client_restrictions =
    permit_mynetworks,
    reject_rbl_client zen.spamhaus.org

# 릴레이 도메인 설정 (특정 도메인만 릴레이)
relay_domains = partner.com

김개발 씨는 식은땀을 흘리며 로그를 확인했습니다. 서버가 인터넷에 공개된 지 불과 몇 시간 만에 스패머들의 표적이 되었습니다.

알 수 없는 IP에서 접속하여 수천 통의 스팸을 전 세계로 발송하고 있었습니다. 박시니어 씨가 급히 설정 파일을 수정했습니다.

"메일 서버를 운영할 때 가장 중요한 건 릴레이 제어예요. 이걸 제대로 안 하면 우리 서버가 스팸 발송 기지가 되어버려요." 릴레이란 무엇일까요?

쉽게 말해 중계입니다. A가 우리 서버를 거쳐 B에게 메일을 보내는 것입니다.

문제는 이 기능을 아무나 사용할 수 있게 열어두면, 스패머들이 자신의 정체를 숨기고 우리 서버를 통해 스팸을 보낸다는 것입니다. 이것은 마치 건물 출입 관리와 같습니다.

건물에 아무나 들어올 수 있게 하면 도둑도 들어옵니다. 직원에게는 출입증을 발급하고, 방문객은 신원 확인 후 허용하며, 수상한 사람은 막아야 합니다.

Postfix에서는 smtpd_recipient_restrictions가 이 역할을 합니다. 여기에 나열된 규칙이 순서대로 적용됩니다.

permit_mynetworks는 내부 네트워크를 허용합니다. mynetworks에 설정된 IP 범위에서 오는 요청은 무조건 통과시킵니다.

회사 직원들이 출입증 없이 들어갈 수 있는 것과 같습니다. permit_sasl_authenticated는 인증된 사용자를 허용합니다.

아이디와 비밀번호로 로그인한 사용자는 릴레이를 사용할 수 있습니다. 외부에서 접속하는 직원이 신원 확인 후 들어오는 것과 같습니다.

reject_unauth_destination이 핵심 방어선입니다. 위의 두 조건에 해당하지 않으면서 우리 도메인이 아닌 곳으로 가는 메일은 거부합니다.

이 설정 하나만으로도 대부분의 릴레이 공격을 막을 수 있습니다. 추가적인 보안을 위해 reject_invalid_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain 등을 설정합니다.

이것들은 형식이 잘못된 메일, 존재하지 않는 도메인에서 오는 메일 등을 걸러냅니다. reject_rbl_client는 블랙리스트 서비스를 활용합니다.

Spamhaus 같은 곳에서 스팸 발송지로 알려진 IP 목록을 관리하는데, 이 목록에 있는 IP의 접속을 차단합니다. 설정을 적용한 후 김개발 씨는 안도의 한숨을 쉬었습니다.

로그를 보니 스팸 시도가 모두 거부되고 있었습니다. "휴, 다행이다.

앞으로는 보안 설정을 먼저 하고 서버를 공개해야겠어요."

실전 팁

💡 - postconf -n | grep restriction으로 현재 제한 설정을 확인하세요

• 테스트 환경에서 충분히 검증한 후 운영 서버에 적용하세요
• 블랙리스트 서비스는 무료와 유료가 있으니 상황에 맞게 선택하세요

---

4. 메일 큐 관리

월요일 아침, 김개발 씨가 출근하니 모니터링 알림이 쌓여 있었습니다. 주말 동안 파트너사 메일 서버가 다운되어 발송 대기 메일이 만 통이 넘게 쌓여 있었습니다.

"이 메일들을 어떻게 처리해야 하죠?" 박시니어 씨가 답했습니다. "메일 큐 관리법을 알아야 할 때가 왔군요."

메일 큐는 발송 대기 중인 메일이 임시로 저장되는 공간입니다. 마치 우체국의 물류 창고처럼, 즉시 배달할 수 없는 우편물을 보관했다가 다시 시도합니다.

큐 관리를 알면 메일 서버 장애 상황에서 침착하게 대응할 수 있습니다.

다음 코드를 살펴봅시다.

# 큐에 쌓인 메일 목록 확인
mailq
# 또는
postqueue -p

# 큐 통계 요약
qshape deferred

# 특정 메일 상세 정보 확인
postcat -q [큐ID]

# 큐에 쌓인 모든 메일 즉시 재발송 시도
postqueue -f

# 특정 메일 삭제
postsuper -d [큐ID]

# 모든 deferred 메일 삭제 (주의!)
postsuper -d ALL deferred

# 큐 디렉토리 위치 확인
postconf queue_directory
# /var/spool/postfix

김개발 씨는 당황한 표정으로 터미널을 바라보았습니다. mailq 명령을 실행하니 끝없이 메일 목록이 스크롤되었습니다.

주말 사이에 파트너사 메일 서버가 다운되면서 발송하지 못한 메일이 산더미처럼 쌓여 있었습니다. 박시니어 씨가 차분하게 설명을 시작했습니다.

"메일 큐는 우체국 물류 창고와 같아요. 배달 못 한 우편물을 버리지 않고 보관했다가 다시 배달 시도하잖아요?

Postfix도 마찬가지예요." 메일 큐는 여러 상태로 나뉩니다. active 큐는 지금 막 발송 중인 메일입니다.

deferred 큐는 발송에 실패해서 나중에 다시 시도할 메일입니다. hold 큐는 관리자가 의도적으로 보류시킨 메일입니다.

메일이 발송에 실패하면 먼저 deferred 큐로 이동합니다. Postfix는 설정된 간격으로 재시도합니다.

기본적으로 처음에는 5분 후, 그 다음은 10분 후, 점점 간격을 늘려가며 최대 5일까지 시도합니다. 5일이 지나도 발송하지 못하면 발신자에게 반송됩니다.

mailq 명령은 현재 큐 상태를 보여줍니다. 각 줄에는 큐 ID, 메일 크기, 대기 시간, 발신자, 수신자 정보가 나옵니다.

큐 ID 옆에 별표(*)가 있으면 active 상태, 느낌표(!)가 있으면 hold 상태입니다. qshape 명령은 큐 상태를 시각적으로 보여줍니다.

어떤 도메인으로 가는 메일이 많이 쌓여 있는지, 얼마나 오래 대기 중인지 한눈에 파악할 수 있습니다. 특정 도메인에 메일이 집중되어 있다면 그 서버에 문제가 있다는 신호입니다.

메일 내용을 확인하려면 postcat -q 명령을 사용합니다. 헤더와 본문을 모두 볼 수 있어 문제 원인 파악에 도움이 됩니다.

하지만 개인정보가 포함되어 있을 수 있으니 주의해야 합니다. postqueue -f는 모든 deferred 메일의 재발송을 즉시 시도합니다.

상대방 서버가 복구되었다면 이 명령으로 한꺼번에 처리할 수 있습니다. 하지만 서버 부하를 고려해야 합니다.

특정 메일만 삭제하려면 **postsuper -d [큐ID]**를 사용합니다. 스팸이나 잘못 발송된 메일을 제거할 때 유용합니다.

모든 deferred 메일을 삭제하는 postsuper -d ALL deferred는 강력한 명령이므로 신중하게 사용해야 합니다. 김개발 씨는 먼저 qshape으로 상황을 파악했습니다.

예상대로 파트너사 도메인으로 가는 메일이 대부분이었습니다. 파트너사에 연락하니 서버가 복구되었다고 합니다.

postqueue -f를 실행하자 쌓여 있던 메일이 순식간에 처리되기 시작했습니다.

실전 팁

💡 - 정기적으로 mailq를 확인하는 모니터링을 구축하세요

• deferred 메일이 계속 쌓인다면 근본 원인을 찾아야 합니다
• postsuper -d ALL은 복구 불가능하니 실행 전 반드시 확인하세요

---

5. 발송 제한 및 속도 조절

마케팅팀에서 10만 명에게 뉴스레터를 발송했습니다. 그런데 얼마 지나지 않아 큰 문제가 생겼습니다.

Gmail이 우리 서버를 스팸 발송지로 의심하여 차단해버린 것입니다. 박시니어 씨가 한숨을 쉬며 말했습니다.

"속도 조절을 안 해서 그래요. 한꺼번에 너무 많이 보내면 이렇게 됩니다."

속도 조절은 대량 메일 발송 시 필수입니다. 마치 고속도로에 차량이 한꺼번에 몰리면 정체가 생기듯, 메일도 적절한 속도로 보내야 합니다.

받는 서버의 정책을 존중하지 않으면 차단당하거나 블랙리스트에 등재될 수 있습니다.

다음 코드를 살펴봅시다.

# /etc/postfix/main.cf 속도 제한 설정

# 동시 발송 제한
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = 20

# 수신자당 발송 속도 제한
default_destination_rate_delay = 1s

# 특정 도메인별 제한 (transport_maps 활용)
# /etc/postfix/transport
# gmail.com    smtp-gmail:
# yahoo.com    smtp-yahoo:

# /etc/postfix/master.cf 에 추가
# smtp-gmail unix - - n - 5 smtp
#   -o smtp_destination_rate_delay=2s
#   -o smtp_destination_concurrency_limit=10

# 메일 크기 제한
message_size_limit = 25600000

# 메일박스 크기 제한
mailbox_size_limit = 51200000

김개발 씨는 머리를 감싸 쥐었습니다. Gmail로 가는 모든 메일이 차단되고 있었습니다.

마케팅팀의 대량 발송 이후 Google이 우리 서버 IP를 의심스러운 발신지로 분류해버린 것입니다. 박시니어 씨가 상황을 살펴보더니 말했습니다.

"이건 throttling을 안 해서 생긴 문제예요. 대형 메일 서비스들은 갑자기 많은 메일이 들어오면 스팸으로 의심해요." 생각해보면 당연한 일입니다.

정상적인 회사에서 1초에 수백 통의 메일을 보낼 일이 있을까요? 대부분 스팸이거나 해킹당한 서버입니다.

그래서 Gmail, Yahoo, Outlook 같은 대형 서비스는 발송 속도 제한을 두고 있습니다. Postfix에서 속도를 조절하는 방법은 여러 가지가 있습니다.

default_destination_concurrency_limit은 하나의 목적지에 동시에 연결할 수 있는 최대 수입니다. 기본값은 20인데, 대량 발송 시에는 이것도 많을 수 있습니다.

5~10 정도로 낮추면 더 안전합니다. default_destination_rate_delay는 같은 목적지로 메일을 보낼 때 간격을 둡니다.

1s로 설정하면 1초에 하나씩만 보냅니다. 급하지 않은 뉴스레터라면 이 정도 속도면 충분합니다.

더 정교한 제어가 필요하다면 도메인별 설정을 할 수 있습니다. transport_maps와 master.cf를 조합하면 Gmail에는 더 느리게, 자체 메일 서버에는 빠르게 보내는 식으로 설정할 수 있습니다.

예를 들어 Gmail에는 동시 연결 5개, 발송 간격 2초로 설정하고, 회사 내부 메일에는 제한 없이 보내도록 할 수 있습니다. 이렇게 하면 외부 서비스의 정책을 존중하면서도 효율성을 유지할 수 있습니다.

message_size_limit은 하나의 메일 최대 크기입니다. 기본값은 10MB인데, 대용량 첨부파일을 보내야 한다면 늘려야 합니다.

하지만 너무 크게 설정하면 서버 자원을 낭비하고 스팸 공격에 취약해질 수 있습니다. mailbox_size_limit은 사용자 메일함의 최대 크기입니다.

이것을 초과하면 새 메일을 받을 수 없습니다. 0으로 설정하면 무제한이지만, 디스크 용량 관리를 위해 적절한 제한을 두는 것이 좋습니다.

김개발 씨는 먼저 속도 제한 설정을 적용하고, Google에 해제 요청을 보냈습니다. 며칠 후 차단이 풀렸습니다.

그리고 앞으로 대량 발송 시에는 반드시 속도 조절을 하기로 마케팅팀과 약속했습니다.

실전 팁

💡 - 대량 발송 전 받는 서버의 정책을 확인하세요

• 갑자기 발송량을 늘리지 말고 점진적으로 늘리세요 (warming up)
• 발송 실패율이 높아지면 즉시 속도를 낮추세요

---

6. SMTP 인증 설정 SASL

재택근무를 시작한 직원들이 불만을 토로했습니다. "회사 밖에서는 메일을 보낼 수가 없어요!" 김개발 씨가 확인해보니 당연한 결과였습니다.

외부 IP는 mynetworks에 포함되지 않아 릴레이가 차단되고 있었습니다. "인증 기능을 추가해야겠군요." 박시니어 씨가 말했습니다.

SASL 인증은 외부에서 접속하는 사용자를 확인하는 방법입니다. 마치 회사 VPN에 로그인하듯, 아이디와 비밀번호로 본인임을 증명해야 메일을 보낼 수 있습니다.

이를 통해 mynetworks 외부에서도 안전하게 메일 서버를 사용할 수 있습니다.

다음 코드를 살펴봅시다.

# SASL 패키지 설치
# yum install cyrus-sasl cyrus-sasl-plain

# /etc/postfix/main.cf SASL 설정
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes

# TLS 필수 설정 (보안을 위해 권장)
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail.key
smtpd_use_tls = yes
smtpd_tls_auth_only = yes

# /etc/sasl2/smtpd.conf
# pwcheck_method: saslauthd
# mech_list: plain login

# saslauthd 서비스 시작
# systemctl enable saslauthd
# systemctl start saslauthd

코로나 이후 재택근무가 일상이 되면서 새로운 문제가 생겼습니다. 직원들이 집에서 회사 메일 계정으로 메일을 보내려 하면 거부당했습니다.

"relay access denied"라는 오류 메시지가 계속 나왔습니다. 김개발 씨는 원인을 금방 파악했습니다.

회사 네트워크 IP만 mynetworks에 등록되어 있었기 때문입니다. 재택근무자들의 집 IP를 전부 등록할 수는 없는 노릇이었습니다.

IP는 유동적으로 바뀌기도 하니까요. 박시니어 씨가 해결책을 제시했습니다.

"SASL 인증을 설정해야 해요. 로그인한 사용자만 메일을 보낼 수 있게 하면 IP와 상관없이 사용할 수 있어요." SASL은 Simple Authentication and Security Layer의 약자입니다.

쉽게 말해 아이디와 비밀번호로 로그인하는 기능입니다. 마치 집 밖에서 회사 시스템에 접속할 때 VPN에 로그인하는 것처럼, 메일 서버에도 로그인해야 사용할 수 있게 만드는 것입니다.

smtpd_sasl_auth_enable = yes가 핵심 설정입니다. 이것만 켜도 인증 기능이 활성화됩니다.

클라이언트가 AUTH 명령으로 로그인할 수 있게 됩니다. smtpd_sasl_security_options = noanonymous는 익명 로그인을 금지합니다.

반드시 아이디와 비밀번호를 입력해야 합니다. broken_sasl_auth_clients = yes는 오래된 메일 클라이언트와의 호환성을 위한 설정입니다.

일부 구형 클라이언트는 표준이 아닌 방식으로 인증을 시도하는데, 이 옵션이 그것을 허용합니다. 여기서 매우 중요한 것이 TLS 암호화입니다.

SASL만 켜면 아이디와 비밀번호가 네트워크에 평문으로 전송됩니다. 이것은 극도로 위험합니다.

반드시 TLS를 함께 설정하고, smtpd_tls_auth_only = yes로 암호화된 연결에서만 인증을 허용해야 합니다. 인증 정보는 어디서 확인할까요?

Postfix는 직접 사용자 정보를 관리하지 않습니다. saslauthd 데몬이 이 역할을 합니다.

saslauthd는 시스템 계정, LDAP, 데이터베이스 등 다양한 소스에서 사용자 정보를 확인할 수 있습니다. 가장 간단한 방법은 시스템 계정을 사용하는 것입니다.

리눅스 서버에 계정이 있는 사용자라면 그 아이디와 비밀번호로 메일 서버에도 로그인할 수 있습니다. 설정을 완료한 후 김개발 씨는 직원들에게 안내 메일을 보냈습니다.

"메일 클라이언트에서 SMTP 인증을 활성화하고, 회사 계정으로 로그인하세요." 이제 재택근무자들도 문제없이 메일을 보낼 수 있게 되었습니다.

실전 팁

💡 - TLS 없이 SASL을 사용하면 비밀번호가 노출될 수 있으니 반드시 함께 설정하세요

• Let's Encrypt로 무료 SSL 인증서를 발급받을 수 있습니다
• saslauthd 대신 dovecot의 인증 기능을 활용할 수도 있습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!