Dovecot으로 IMAP/POP3 메일 서버 구축하기

Linux 환경에서 Dovecot을 활용하여 IMAP과 POP3 메일 서버를 구성하는 방법을 다룹니다. 메일 저장소 설정부터 사용자 인증, 쿼터 관리까지 실무에서 필요한 핵심 설정을 단계별로 학습합니다.

---

목차

1. Dovecot_아키텍처_이해
2. IMAP_vs_POP3_프로토콜_설정
3. Maildir_형식_메일_저장소
4. 사용자_인증_방식_설정
5. 메일함_자동_구독_설정
6. 쿼터_용량_제한_설정

---

1. Dovecot 아키텍처 이해

신입 시스템 관리자 김개발 씨는 회사에서 자체 메일 서버를 구축하라는 미션을 받았습니다. "Dovecot을 써서 IMAP 서버를 만들어 주세요." 팀장님의 말씀에 김개발 씨는 고개를 끄덕였지만, 사실 Dovecot이 정확히 무엇인지, 어떻게 동작하는지 막막하기만 합니다.

Dovecot은 한마디로 메일을 저장하고 사용자에게 전달해주는 MDA(Mail Delivery Agent) 역할을 하는 서버입니다. 마치 우체국에서 편지를 분류하고 각 가정의 우편함에 넣어주는 집배원과 같습니다.

이것을 제대로 이해하면 메일 시스템 전체의 흐름을 파악할 수 있습니다.

다음 코드를 살펴봅시다.

# Dovecot 설치 (Ubuntu/Debian)
sudo apt update
sudo apt install dovecot-core dovecot-imapd dovecot-pop3d

# 설치 확인
dovecot --version

# 기본 설정 파일 구조 확인
ls -la /etc/dovecot/
# dovecot.conf        - 메인 설정 파일
# conf.d/             - 모듈별 상세 설정 디렉토리

# Dovecot 서비스 시작
sudo systemctl start dovecot
sudo systemctl enable dovecot

# 상태 확인
sudo systemctl status dovecot

김개발 씨는 입사 6개월 차 시스템 관리자입니다. 오늘 팀장님으로부터 특별한 미션을 받았습니다.

회사에서 사용하던 외부 메일 서비스가 비용 문제로 자체 메일 서버로 전환하기로 했다는 것입니다. "Dovecot으로 IMAP 서버를 구축해 주세요.

다음 주까지 테스트 환경이 필요합니다." 팀장님의 말씀에 김개발 씨는 당장 구글링을 시작했습니다. 그렇다면 Dovecot이란 정확히 무엇일까요?

쉽게 비유하자면, Dovecot은 마치 아파트 경비실과 같습니다. 택배 기사가 물건을 가져오면 경비실에서 각 세대별로 분류해서 보관합니다.

그리고 주민이 찾으러 오면 신분을 확인한 후 물건을 전달해줍니다. Dovecot도 마찬가지로 메일을 받아서 저장하고, 사용자가 메일 클라이언트로 접속하면 인증 후 메일을 전달해줍니다.

메일 시스템 전체를 이해하려면 세 가지 구성요소를 알아야 합니다. 첫 번째는 **MTA(Mail Transfer Agent)**입니다.

Postfix나 Sendmail이 여기에 해당합니다. 이것은 메일을 인터넷을 통해 다른 서버로 전송하는 역할을 합니다.

마치 우체국에서 다른 지역으로 우편물을 보내는 것과 같습니다. 두 번째는 **MDA(Mail Delivery Agent)**입니다.

바로 Dovecot이 이 역할을 담당합니다. MTA가 받은 메일을 실제 사용자의 메일함에 저장하고, 사용자가 요청하면 메일을 전달합니다.

세 번째는 **MUA(Mail User Agent)**입니다. Outlook, Thunderbird, 스마트폰 메일 앱 등이 여기에 해당합니다.

사용자가 실제로 메일을 읽고 쓰는 프로그램입니다. Dovecot의 아키텍처를 살펴보면 크게 세 가지 핵심 프로세스로 구성됩니다.

dovecot-auth는 사용자 인증을 담당합니다. 사용자가 메일 클라이언트에서 아이디와 비밀번호를 입력하면 이 프로세스가 검증합니다.

리눅스 시스템 계정, LDAP, SQL 데이터베이스 등 다양한 방식으로 인증을 처리할 수 있습니다. imap-login과 pop3-login은 클라이언트의 접속을 받아들이는 관문입니다.

보안을 위해 최소한의 권한으로 실행되며, 인증이 완료되면 실제 메일 처리 프로세스로 연결해줍니다. imap과 pop3 프로세스는 실제로 메일을 읽고 관리하는 작업을 수행합니다.

사용자별로 별도의 프로세스가 생성되어 격리된 환경에서 동작합니다. 위의 코드를 살펴보겠습니다.

먼저 apt 명령어로 Dovecot의 핵심 패키지들을 설치합니다. dovecot-core는 기본 프레임워크이고, dovecot-imapd와 dovecot-pop3d는 각각 IMAP과 POP3 프로토콜을 지원하는 모듈입니다.

설정 파일은 /etc/dovecot/ 디렉토리에 위치합니다. 메인 설정 파일인 dovecot.conf와 세부 설정을 담은 conf.d 디렉토리로 구성됩니다.

이렇게 모듈화된 구조 덕분에 필요한 부분만 수정하기 편리합니다. 선배 박시니어 씨가 다가와 조언을 해줍니다.

"Dovecot의 장점은 보안성과 성능이야. 프로세스가 분리되어 있어서 하나가 문제가 생겨도 전체 시스템에 영향을 주지 않지.

그리고 메모리 사용량도 적어서 수천 명의 동시 접속도 거뜬히 처리할 수 있어." 김개발 씨는 고개를 끄덕였습니다. 이제 Dovecot이 어떤 역할을 하는지 이해했으니, 본격적인 설정을 시작할 차례입니다.

실전 팁

💡 - Dovecot 설정 변경 후에는 반드시 doveconf -n 명령어로 문법 오류를 확인하세요

• 로그 파일은 기본적으로 /var/log/mail.log에 기록되며, 문제 해결의 핵심입니다

---

2. IMAP vs POP3 프로토콜 설정

Dovecot 설치를 마친 김개발 씨에게 팀장님이 다가왔습니다. "그런데 IMAP으로 할 거야, POP3로 할 거야?" 김개발 씨는 순간 당황했습니다.

둘 다 메일을 받는 프로토콜인 건 알지만, 정확히 무슨 차이가 있는지 설명하기 어려웠기 때문입니다.

**IMAP(Internet Message Access Protocol)**은 메일을 서버에 보관하면서 여러 기기에서 동기화하는 프로토콜입니다. 반면 **POP3(Post Office Protocol 3)**는 메일을 로컬로 다운로드하고 서버에서 삭제하는 방식입니다.

마치 도서관에서 책을 빌려 읽는 것(IMAP)과 책을 사서 집으로 가져가는 것(POP3)의 차이와 같습니다.

다음 코드를 살펴봅시다.

# /etc/dovecot/conf.d/10-master.conf
# IMAP 서비스 설정
service imap-login {
  inet_listener imap {
    port = 143          # 일반 IMAP 포트
  }
  inet_listener imaps {
    port = 993          # SSL/TLS IMAP 포트
    ssl = yes
  }
}

# POP3 서비스 설정
service pop3-login {
  inet_listener pop3 {
    port = 110          # 일반 POP3 포트
  }
  inet_listener pop3s {
    port = 995          # SSL/TLS POP3 포트
    ssl = yes
  }
}

# /etc/dovecot/conf.d/10-mail.conf
# 프로토콜 활성화
protocols = imap pop3 lmtp

김개발 씨는 팀장님의 질문에 제대로 답하지 못한 것이 마음에 걸렸습니다. 점심시간에 선배 박시니어 씨를 찾아가 물었습니다.

"선배님, IMAP이랑 POP3가 정확히 뭐가 다른 거예요?" 박시니어 씨가 커피를 한 모금 마시며 설명을 시작했습니다. "쉽게 생각해봐.

POP3는 우체통에서 편지를 꺼내 집으로 가져가는 거야. 한 번 가져가면 우체통은 비어 있지.

그래서 다른 곳에서는 그 편지를 볼 수 없어." 김개발 씨가 고개를 끄덕였습니다. "반면에 IMAP은 도서관 같아.

책이 도서관에 있고, 너는 가서 읽기만 하는 거지. 집에서도 읽고, 회사에서도 읽고, 스마트폰으로도 읽을 수 있어.

책은 항상 도서관에 있으니까." 이제 명확해졌습니다. POP3는 메일을 클라이언트로 다운로드하고 서버에서 삭제합니다.

반면 IMAP은 메일을 서버에 보관하면서 클라이언트는 이를 열람만 합니다. 현대적인 환경에서는 대부분 IMAP을 사용합니다.

이유가 있습니다. 첫째, 요즘 사람들은 스마트폰, 태블릿, 노트북, 데스크톱 등 여러 기기를 사용합니다.

IMAP을 쓰면 모든 기기에서 동일한 메일함을 볼 수 있습니다. PC에서 읽은 메일은 스마트폰에서도 읽음 표시가 됩니다.

둘째, 서버에 메일이 보관되므로 백업이 중앙에서 이루어집니다. 사용자의 컴퓨터가 고장 나도 메일은 안전합니다.

그렇다면 POP3는 언제 쓸까요? 서버 용량이 제한적일 때 유용합니다.

메일을 다운로드하고 서버에서 삭제하면 서버 공간을 절약할 수 있습니다. 또한 오프라인 환경에서 메일을 자주 읽어야 하는 경우에도 POP3가 적합합니다.

위의 설정 코드를 살펴보겠습니다. 10-master.conf 파일에서 각 프로토콜의 포트를 설정합니다.

IMAP은 143번(일반)과 993번(암호화) 포트를 사용합니다. POP3는 110번(일반)과 995번(암호화) 포트를 사용합니다.

현업에서는 반드시 암호화된 포트를 사용해야 합니다. 일반 포트는 평문으로 통신하기 때문에 비밀번호가 노출될 수 있습니다.

많은 회사에서 143번과 110번 포트를 아예 비활성화하고 암호화 포트만 허용합니다. protocols 설정에서 어떤 프로토콜을 활성화할지 지정합니다.

lmtp는 Local Mail Transfer Protocol로, Postfix 같은 MTA와 Dovecot 사이에서 메일을 전달하는 데 사용됩니다. 김개발 씨가 물었습니다.

"그럼 저희 회사는 뭘 쓰는 게 좋을까요?" 박시니어 씨가 답했습니다. "직원들이 여러 기기를 쓰니까 IMAP이 맞아.

다만 서버 용량 관리를 위해 쿼터 설정은 꼭 해둬야 해. 나중에 알려줄게." 김개발 씨는 노트에 열심히 적으며 다음 단계를 준비했습니다.

실전 팁

💡 - 보안을 위해 143번, 110번 포트는 비활성화하고 993번, 995번 암호화 포트만 사용하세요

• 회사 환경에서는 IMAP 사용을 권장하며, POP3는 특수한 경우에만 고려하세요

---

3. Maildir 형식 메일 저장소

프로토콜 설정을 마친 김개발 씨 앞에 새로운 과제가 나타났습니다. "메일 저장 형식은 Maildir로 해주세요." 팀장님의 한마디에 김개발 씨는 또다시 검색창을 열었습니다.

mbox도 있고 Maildir도 있는데, 대체 뭐가 다른 걸까요?

Maildir은 각 메일을 개별 파일로 저장하는 형식입니다. 반면 mbox는 모든 메일을 하나의 큰 파일에 연속으로 저장합니다.

Maildir은 마치 서류를 한 장씩 다른 봉투에 넣어 보관하는 것이고, mbox는 모든 서류를 하나의 바인더에 차곡차곡 쌓아두는 것과 같습니다.

다음 코드를 살펴봅시다.

# /etc/dovecot/conf.d/10-mail.conf
# Maildir 형식으로 메일 저장 위치 설정
mail_location = maildir:~/Maildir

# 또는 절대 경로 지정
# mail_location = maildir:/var/mail/%u/Maildir

# Maildir 디렉토리 구조 확인
# ~/Maildir/
#   cur/    - 읽은 메일
#   new/    - 새로운 메일
#   tmp/    - 임시 저장 (메일 쓰기 중)

# 사용자별 Maildir 생성 스크립트
sudo mkdir -p /home/testuser/Maildir/{cur,new,tmp}
sudo chown -R testuser:testuser /home/testuser/Maildir
sudo chmod -R 700 /home/testuser/Maildir

# 네임스페이스 설정 (폴더 구조)
namespace inbox {
  inbox = yes
  separator = /
}

김개발 씨는 메일 저장 형식에 대해 찾아보다가 흥미로운 역사를 발견했습니다. 오래전 유닉스 시스템에서는 mbox 형식이 표준이었습니다.

모든 메일이 하나의 파일에 순차적으로 저장되는 단순한 방식이었습니다. 하지만 이 방식에는 심각한 문제가 있었습니다.

mbox 파일이 손상되면 모든 메일을 잃어버릴 수 있었습니다. 또한 여러 프로그램이 동시에 mbox 파일에 접근하면 충돌이 발생했습니다.

메일함이 커지면 특정 메일을 찾는 데도 시간이 오래 걸렸습니다. 이런 문제를 해결하기 위해 1995년 Daniel J.

Bernstein이 Maildir 형식을 고안했습니다. Maildir의 핵심 아이디어는 간단합니다.

각 메일을 별도의 파일로 저장하는 것입니다. 마치 편지를 각각 다른 봉투에 넣어 보관하는 것처럼요.

Maildir 디렉토리는 세 개의 하위 폴더로 구성됩니다. new 폴더에는 아직 읽지 않은 새 메일이 저장됩니다.

메일 서버가 새 메일을 받으면 이 폴더에 파일을 생성합니다. cur 폴더에는 이미 읽은 메일이 저장됩니다.

사용자가 메일을 읽으면 new에서 cur로 파일이 이동합니다. tmp 폴더는 메일 쓰기 작업 중 임시로 사용됩니다.

메일이 완전히 저장되기 전에 이 폴더에 먼저 쓰인 후 new로 이동합니다. 이렇게 하면 불완전한 메일이 저장되는 것을 방지할 수 있습니다.

김개발 씨가 박시니어 씨에게 물었습니다. "그럼 Maildir이 무조건 좋은 건가요?" 박시니어 씨가 웃으며 답했습니다.

"대부분의 경우 그렇지. 장점이 많거든." 첫째, 안정성입니다.

파일 하나가 손상되어도 다른 메일에는 영향이 없습니다. mbox처럼 전체 메일함을 잃어버리는 일은 없습니다.

둘째, 동시 접근이 가능합니다. 각 메일이 별도 파일이므로 여러 프로세스가 동시에 다른 메일에 접근해도 문제없습니다.

파일 잠금 문제가 발생하지 않습니다. 셋째, 성능이 좋습니다.

특정 메일을 삭제하거나 이동할 때 파일 하나만 처리하면 됩니다. mbox처럼 거대한 파일을 다시 써야 하는 오버헤드가 없습니다.

설정 코드의 mail_location 지시자가 핵심입니다. maildir:~/Maildir은 각 사용자의 홈 디렉토리 아래 Maildir 폴더를 메일 저장소로 사용한다는 의미입니다.

%u 변수는 사용자 이름으로 대체됩니다. 예를 들어 /var/mail/%u/Maildir로 설정하면 testuser 사용자의 메일은 /var/mail/testuser/Maildir에 저장됩니다.

namespace 설정은 메일함의 폴더 구조를 정의합니다. **separator = /**는 폴더 구분자를 슬래시로 지정합니다.

이렇게 하면 INBOX/Sent, INBOX/Trash 같은 계층 구조를 사용할 수 있습니다. 김개발 씨는 테스트 사용자를 만들어 Maildir 구조를 직접 확인해보았습니다.

정말로 세 개의 폴더가 생성되어 있었습니다. 이제 메일이 어떻게 저장되는지 이해했습니다.

실전 팁

💡 - 새 사용자 생성 시 Maildir 디렉토리를 자동으로 만들려면 /etc/skel/에 Maildir 구조를 미리 생성해두세요

• 권한 설정(700)을 꼭 확인하세요. 다른 사용자가 메일을 읽을 수 없어야 합니다

---

4. 사용자 인증 방식 설정

메일 저장소 설정을 마친 김개발 씨에게 보안팀에서 연락이 왔습니다. "인증은 어떻게 처리할 건가요?

PAM으로 할 건가요, 아니면 별도 DB를 쓸 건가요?" 김개발 씨는 메일 서버의 인증이 이렇게 다양한 방식으로 가능하다는 것을 처음 알았습니다.

Dovecot의 **인증(Authentication)**은 사용자가 메일에 접근할 권한이 있는지 확인하는 과정입니다. 마치 은행에서 신분증을 확인하고 본인 계좌만 접근하게 하는 것과 같습니다.

PAM, SQL 데이터베이스, LDAP 등 다양한 백엔드를 지원하여 환경에 맞는 인증 방식을 선택할 수 있습니다.

다음 코드를 살펴봅시다.

# /etc/dovecot/conf.d/10-auth.conf
# 인증 메커니즘 설정
auth_mechanisms = plain login

# 평문 인증은 SSL/TLS 연결에서만 허용
disable_plaintext_auth = yes

# PAM 인증 사용 (시스템 계정 연동)
!include auth-system.conf.ext

# /etc/dovecot/conf.d/auth-system.conf.ext
passdb {
  driver = pam
  # PAM 서비스 이름 (기본값: dovecot)
}

userdb {
  driver = passwd
  # /etc/passwd 파일에서 사용자 정보 조회
}

# SQL 인증 사용시 (auth-sql.conf.ext)
passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}

userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}

김개발 씨는 보안팀의 질문에 답하기 위해 Dovecot의 인증 시스템을 파헤쳐보기로 했습니다. Dovecot의 인증은 두 가지 구성요소로 나뉩니다.

**passdb(Password Database)**는 사용자의 비밀번호를 검증합니다. "이 사용자가 입력한 비밀번호가 맞나요?"라는 질문에 답합니다.

**userdb(User Database)**는 사용자의 시스템 정보를 제공합니다. 홈 디렉토리가 어디인지, UID와 GID가 무엇인지 등을 알려줍니다.

메일을 어디에 저장하고 어떤 권한으로 접근할지 결정하는 데 사용됩니다. 가장 간단한 방식은 PAM(Pluggable Authentication Modules) 인증입니다.

PAM은 리눅스 시스템의 표준 인증 프레임워크입니다. /etc/passwd와 /etc/shadow 파일에 저장된 시스템 계정을 그대로 사용합니다.

서버에 SSH로 로그인하는 계정과 메일 계정이 동일해지는 것입니다. 소규모 환경에서는 PAM이 적합합니다.

별도의 데이터베이스를 관리할 필요 없이 기존 시스템 계정을 활용할 수 있기 때문입니다. 하지만 대규모 환경에서는 다른 방식이 필요합니다.

SQL 인증은 MySQL, PostgreSQL 같은 데이터베이스에서 사용자 정보를 조회합니다. 웹 기반 관리 도구와 연동하기 쉽고, 수천 명의 사용자를 효율적으로 관리할 수 있습니다.

LDAP 인증은 Active Directory나 OpenLDAP과 연동할 때 사용합니다. 회사에서 이미 LDAP으로 직원 계정을 관리하고 있다면, 메일 서버도 같은 계정을 사용하게 할 수 있습니다.

설정 파일을 자세히 살펴보겠습니다. auth_mechanisms는 클라이언트와 서버 사이의 인증 방식을 지정합니다.

plain은 평문으로 비밀번호를 전송하고, login은 Base64 인코딩을 사용합니다. 둘 다 암호화되지 않은 방식이므로 반드시 SSL/TLS와 함께 사용해야 합니다.

disable_plaintext_auth = yes 설정이 중요합니다. 이 옵션을 활성화하면 SSL/TLS로 암호화되지 않은 연결에서는 인증을 거부합니다.

누군가 네트워크를 도청해도 비밀번호를 알아낼 수 없습니다. 박시니어 씨가 조언했습니다.

"우리 회사는 아직 사용자가 많지 않으니까 PAM으로 시작해도 돼. 나중에 사용자가 늘어나면 SQL로 마이그레이션하면 되고." 김개발 씨가 물었습니다.

"마이그레이션이 어렵지 않나요?" "Dovecot의 장점이 그거야. passdb와 userdb를 여러 개 설정할 수 있거든.

둘 다 사용하다가 점진적으로 옮길 수 있어." 김개발 씨는 일단 PAM 인증으로 설정하고, 테스트 계정으로 접속을 시도해보았습니다. 성공입니다.

이제 실제 사용자들이 메일에 접속할 수 있게 되었습니다.

실전 팁

💡 - 프로덕션 환경에서는 반드시 disable_plaintext_auth = yes를 설정하세요

• 인증 문제 디버깅 시 doveadm auth test username password 명령어가 유용합니다

---

5. 메일함 자동 구독 설정

메일 서버가 어느 정도 모양을 갖추자 테스트 사용자들의 피드백이 들어오기 시작했습니다. "Sent 폴더가 안 보여요." "Trash 폴더를 수동으로 만들어야 하나요?" 김개발 씨는 기본 메일함이 자동으로 생성되고 구독되어야 한다는 것을 깨달았습니다.

**메일함 자동 구독(Auto-subscription)**은 사용자가 처음 접속할 때 표준 메일함(Sent, Drafts, Trash 등)을 자동으로 생성하고 구독 처리하는 기능입니다. 마치 새 집에 입주하면 기본적인 가구가 배치되어 있는 것처럼, 사용자가 별도의 설정 없이 바로 메일을 사용할 수 있게 해줍니다.

다음 코드를 살펴봅시다.

# /etc/dovecot/conf.d/15-mailboxes.conf
namespace inbox {
  inbox = yes

  # 보낸 메일함
  mailbox Sent {
    auto = subscribe      # 자동 구독
    special_use = \Sent   # IMAP 특수 용도 플래그
  }

  # 임시 보관함
  mailbox Drafts {
    auto = subscribe
    special_use = \Drafts
  }

  # 휴지통
  mailbox Trash {
    auto = subscribe
    special_use = \Trash
  }

  # 스팸 메일함
  mailbox Junk {
    auto = subscribe
    special_use = \Junk
  }

  # 보관함 (선택적 생성)
  mailbox Archive {
    auto = create         # 생성만 하고 구독은 안 함
    special_use = \Archive
  }
}

김개발 씨는 테스트 사용자로 Thunderbird에 접속해보았습니다. 받은편지함은 보이는데, 보낸편지함이나 휴지통이 없었습니다.

메일을 보내려고 하니 "보낸편지함을 선택하세요"라는 메시지가 나왔습니다. 문제가 뭘까요?

IMAP 프로토콜에서 메일함은 기본적으로 구독(subscribe) 상태여야 클라이언트에 표시됩니다. 서버에 폴더가 있어도 구독하지 않으면 보이지 않는 것입니다.

더 근본적인 문제는 폴더 자체가 없었습니다. 새 사용자가 처음 접속하면 INBOX만 존재하고, Sent, Drafts, Trash 같은 폴더는 생성되어 있지 않습니다.

박시니어 씨가 해결책을 알려주었습니다. "15-mailboxes.conf 파일에서 자동 생성과 구독을 설정할 수 있어." auto 지시자에는 세 가지 값을 사용할 수 있습니다.

no는 아무것도 하지 않습니다. 기본값입니다.

create는 메일함을 자동으로 생성하지만 구독하지는 않습니다. 클라이언트에서 수동으로 구독해야 표시됩니다.

subscribe는 메일함을 자동으로 생성하고 구독까지 합니다. 사용자가 처음 접속하면 바로 해당 폴더가 보입니다.

special_use 플래그도 중요합니다. 이것은 RFC 6154에서 정의한 표준 메일함 용도 플래그입니다.

\Sent는 보낸 메일을 저장하는 폴더임을 나타냅니다. 메일 클라이언트는 이 플래그를 보고 자동으로 보낸 메일을 이 폴더에 저장합니다.

\Drafts는 임시 저장 폴더입니다. 작성 중인 메일이 여기에 저장됩니다.

\Trash는 휴지통입니다. 삭제한 메일이 이 폴더로 이동합니다.

\Junk는 스팸 메일함입니다. 스팸 필터가 걸러낸 메일이 저장됩니다.

이 플래그가 없으면 어떻게 될까요? 예를 들어 한국어 환경의 클라이언트는 "보낸편지함"이라는 이름을 찾을 수 있습니다.

영어 환경에서는 "Sent"를 찾겠죠. 서버에 "Sent"라는 폴더만 있으면 한국어 클라이언트에서는 보낸편지함을 인식하지 못할 수 있습니다.

하지만 special_use = \Sent 플래그가 있으면 폴더 이름과 관계없이 클라이언트가 용도를 인식합니다. 어떤 언어 설정이든 올바른 폴더를 사용하게 됩니다.

김개발 씨가 설정을 적용하고 새 테스트 계정으로 접속해보았습니다. 이번에는 Sent, Drafts, Trash, Junk 폴더가 모두 자동으로 나타났습니다.

"완벽해요!" 테스트 사용자의 긍정적인 피드백이 돌아왔습니다.

실전 팁

💡 - Archive 폴더는 auto = create로 설정하면 필요한 사용자만 구독해서 사용할 수 있습니다

• 폴더 이름은 영문으로 유지하고 special_use 플래그를 활용하면 다국어 환경에서도 문제없습니다

---

6. 쿼터 용량 제한 설정

메일 서버가 안정적으로 운영되던 어느 날, 시스템 모니터링 알람이 울렸습니다. "디스크 사용량 90% 초과!" 김개발 씨가 확인해보니 한 사용자가 수 기가바이트의 첨부파일 메일을 보관하고 있었습니다.

사용자별 용량 제한이 필요한 순간이었습니다.

**쿼터(Quota)**는 사용자별로 메일 저장 용량을 제한하는 기능입니다. 마치 아파트 창고에 물건을 넣을 수 있는 양이 정해져 있는 것처럼, 각 사용자가 사용할 수 있는 메일함 크기를 제한합니다.

이를 통해 서버 디스크 공간을 효율적으로 관리하고, 특정 사용자가 전체 시스템에 영향을 주는 것을 방지합니다.

다음 코드를 살펴봅시다.

# /etc/dovecot/conf.d/10-mail.conf
# 쿼터 플러그인 활성화
mail_plugins = $mail_plugins quota

# /etc/dovecot/conf.d/20-imap.conf
protocol imap {
  mail_plugins = $mail_plugins imap_quota
}

# /etc/dovecot/conf.d/90-quota.conf
plugin {
  # 기본 쿼터 설정: 1GB 용량, 10000개 메시지 제한
  quota = maildir:User quota
  quota_rule = *:storage=1G
  quota_rule2 = *:messages=10000

  # 휴지통은 쿼터에서 제외 (선택 사항)
  quota_rule3 = Trash:ignore

  # 쿼터 초과시 경고 메시지
  quota_warning = storage=95%% quota-warning 95 %u
  quota_warning2 = storage=80%% quota-warning 80 %u

  # 쿼터 상태 표시 형식
  quota_status_success = DUNNO
  quota_status_nouser = DUNNO
  quota_status_overquota = "552 5.2.2 Mailbox is full"
}

# 경고 스크립트 서비스
service quota-warning {
  executable = script /usr/local/bin/quota-warning.sh
  user = dovecot
}

디스크 용량 알람을 받은 김개발 씨는 즉시 문제의 사용자에게 연락해 불필요한 메일을 삭제해달라고 요청했습니다. 하지만 이것은 임시 방편일 뿐이었습니다.

박시니어 씨가 다가왔습니다. "쿼터 설정 안 해뒀어?" 김개발 씨가 고개를 저었습니다.

"쿼터요? 그게 뭔가요?" "메일 용량 제한이야.

사용자마다 쓸 수 있는 용량을 정해두는 거지. 안 그러면 지금처럼 한 사람이 전체 디스크를 다 써버릴 수 있어." 쿼터의 개념은 간단합니다.

은행 금고를 생각해보세요. 각 고객에게 일정 크기의 금고 칸이 할당됩니다.

아무리 물건이 많아도 자기 칸에 들어가는 양만 보관할 수 있습니다. 메일 쿼터도 마찬가지로 사용자별로 저장 공간을 할당합니다.

Dovecot의 쿼터 설정을 살펴보겠습니다. 먼저 quota 플러그인을 활성화해야 합니다.

10-mail.conf에서 mail_plugins에 quota를 추가합니다. IMAP에서 쿼터 정보를 조회하려면 imap_quota 플러그인도 필요합니다.

quota_rule 지시자로 실제 제한을 설정합니다. quota_rule = *:storage=1G는 모든 메일함(*)의 총 용량을 1기가바이트로 제한합니다.

quota_rule2 = *:messages=10000은 메시지 개수를 10,000개로 제한합니다. 용량과 개수 중 하나라도 초과하면 새 메일을 받을 수 없습니다.

quota_rule3 = Trash:ignore는 휴지통을 쿼터 계산에서 제외합니다. 사용자가 메일을 삭제해서 용량을 확보하려 할 때, 휴지통에 있는 메일 때문에 여전히 쿼터 초과 상태가 되면 곤란하기 때문입니다.

quota_warning 설정이 실용적으로 중요합니다. 쿼터가 80%에 도달하면 사용자에게 경고 메일을 보낼 수 있습니다.

95%에 도달하면 긴급 경고를 보냅니다. 사용자가 미리 정리할 기회를 주는 것입니다.

쿼터를 초과하면 어떻게 될까요? 새 메일이 도착해도 저장되지 않습니다.

quota_status_overquota 설정에 따라 "Mailbox is full" 오류가 발송자에게 반환됩니다. 발송자는 메일이 전달되지 않았다는 것을 알게 됩니다.

김개발 씨가 물었습니다. "회사에서는 보통 얼마나 할당하나요?" 박시니어 씨가 답했습니다.

"회사마다 다르지만, 일반 직원은 12GB, 임원은 510GB 정도가 일반적이야. 요즘은 첨부파일 대신 클라우드 공유를 많이 쓰니까 예전보다 적어도 괜찮아." 김개발 씨는 일반 사용자 1GB, 관리자 5GB로 차등 쿼터를 설정했습니다.

그리고 80% 경고 메일이 자동으로 발송되도록 스크립트도 작성했습니다. 다음 주, 같은 사용자가 80% 경고 메일을 받고 스스로 정리했습니다.

더 이상 디스크 용량 알람은 울리지 않았습니다. 김개발 씨가 팀장님께 보고했습니다.

"메일 서버 구축이 완료되었습니다. IMAP 지원, Maildir 저장, 인증 시스템, 자동 폴더 생성, 그리고 쿼터 관리까지 모두 설정했습니다." 팀장님이 만족한 표정으로 고개를 끄덕였습니다.

"수고했어요. 이제 실서버에 적용해봅시다."

실전 팁

💡 - 쿼터 초과 사용자 확인은 doveadm quota get -u username 명령어로 가능합니다

• 전체 사용자 쿼터 현황은 doveadm quota get -A로 한 번에 확인할 수 있습니다

---

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