몇년 전만 하더라도 전자 메일을 사용하는 사람은 대단한 컴퓨터 광이거나 혹
은 그 계열의 종사자, 전공자로 여겨졌다. 하지만 요즘은 초등학교 학생부터 나
이 지긋하신 분들까지 자신의 직업과는 상관없이 컴퓨터에 조금만 관심이 있으
면 전자 메일을 사용한다. 그만큼 모든 컴퓨터 환경이 발전되었다는 이야기일
것이다. 이렇게 될 수 있었던 이유 중에 커다란 것이 바로 인터넷에서의 웹의
등장이 아닌가 생각한다. 넷스케이프나 익스플로러를 이용하면 정말로 편하게
메일을 보내고 받고 관리할 수 있는 것이다.
이와 같은 전자 메일의 사용은 전세계를 초단위의 연락망으로 연결시키면서 이
전의 통신 수단인 전화를 대체해 나가는 추세이다. 가격 경쟁력으로 보아 전화
는 이미 전자 메일의 상대가 아니다. 반면, 전자 메일을 악용하는 사례도 발생
되었는데 바로 상업적 광고의 메일 살포이다. 앞으로 점점 이와 같은 문제는
크게 대두될 것이고 이의 해결을 위한 메일의 필터링 방법, 보안기법 등도 아
울러 발전할 것이다. 또 하나의 문제는 전자 메일을 통한 직접적인 감정 표현
으로 인해 순간순간의 나쁜 감정도 쉽게 다른 사람에게 전달되어 공유된다. 정
보의 공유와는 반대의 잘못된 정보 공유인 것이다. 여기에 전자 메일을 익명으
로 보낼 수 있는 프로그램을 이용하는 경우 그 심각성은 더욱 커질 것이다.
어찌 되었건 전자 메일이라는 것은 잘만 이용하면 생활의 편리를, 잘못 악용하
면 생활의 불편을 가져다주는 어찌 보면 양면적 특성을 가진다 하겠다.
이러한 전자 메일에 대하여 이제부터 자세히 알아볼 것이다. 개념적으로는 간
단하지만 실제 구현은 매우 복잡한 시스템으로서 주로 전자 메일을 다루는(파
싱, 라우팅) 프로그램인 sendmail의 사용방법보다는 그 세팅(configuration)에
대하여 다루도록 하겠다. 관련된 문서는 RFC822이니 이 글을 읽고 더욱 자세
한 정보를 원하는 독자는 참고하면 될 것이다.

메일 시스템
유닉스에서의 메일 시스템은 전체적으로 3부분으로 구성된다. 첫 번째 부분은
사용자가 메일을 읽고 작성할 수 있도록 해주는 사용자 에이전트(User Agent)
이고 두 번째는 메일을 원하는 시스템으로 전송해 주는 전송 에이전트
(Transport Agent)이며 나머지 하나는 수신측 사용자의 메일 박스에 메일을
넣어주는 배달 에이전트(Deliver Agent)이다.

사용자 에이전트(User Agent-UA)
ATT계열의 시스템에서는 /bin/mail 프로그램이 원래의 사용자 에이전트였다.
그러나 현재는 여러 다른 사용자 에이전트들이 생겨나 같이 공존하고 있다. 어
떤 사용자 에이전트들은 그래픽 환경을 제공하기도 하며 메일 메시지에 멀티미
디어 객체를 포함시키기 위한 MIME(Multi-Purpose Internet Mail Extensions)
을 지원하는 것도 있다. 다음은 주요한 사용자 에이전트들이다.

(1) AT&T의 /bin/mail
(2) BSD의 /usr/ucb/mail
(3) Rand Corporation 사의 mh
(4) Laurence Lundblade, Mike Seibel, Mark Crispin의 pine
(5) GNU의 emacs mail
(6) 버클리의 Dan Heller가 만든 mush
(7) Intuitive System의 David Tayler가 만든 elm

사용자 에이전트의 종류에 따라 구동할 때 세팅파일도 다르고 어떤 것은 전체
시스템에 대한 세팅을 할 수 있도록 한 것도 있다. 다음은 각 사용자 에이전트
의 세팅파일을 보인 것이다.

사용자 에이전트 시스템 세팅 파일 개인 사용자 세팅 파일
/bin/mail - -
/ucb/mail Mail.rc .mailrc
pine pine.conf .pinerc
elm - .elm/*
mh - .mh_profile과 .maildelivery
xmh - .mh_profile과 .maildelivery

참고적으로 시스템 전체에 대한 세팅파일은 각 회사마다 그 위치나 이름이 차
이가 많이 나므로 각각 확인해야 할 것이다.

전송 에이전트(Transport Agent-TA)
전송 에이전트의 역할은 앞서 이야기했지만 사용자 에이전트로부터 메일을 받
아 그 메일을 읽은 후 수신자의 주소를 파악하여 정확한 목적지 호스트로 전달
하는 것이다. 또한 사용자 에이전트뿐만이 아니라 다른 전송 에이전트가 보내
는 메일도 받아 처리하는 일도 수행한다. 이러한 일을 수행하는 많은 전송 에
이전트들이 RFC821에 정의된 SMTP (Simple Mail Transport Protocol)를 준
수한다.
유닉스에서는 여러 전송 에이전트들이 있는데 MMDF, zmailer, smail, upas 등
이 그것이다. 하지만 무엇보다도 가장 많이 쓰이며 융통성 있는 것은 sendmail
이다. 이 연재에서 주로 다룰 전송 에이전트이다.
sendmail은 크게 3가지의 버전이 있는데 version 5(V5)와 IDA 그리고 version
8(V8)이다.
자세한 설명은 조금 후에 하도록 하겠다.

배달 에이전트(Delibery Agent-DA)
배달 에이전트의 역할은 전송 에이전트로부터 메일 메시지를 받아 실제 수신자
에게 전달하는 일을 한다. 여기서 수신자는 일반 사용자일 수도 있고 프로그램
혹은 파일이나 메일링 리스트일 수도 있다.
각 수신자의 종류에 따라 서로 다른 에이전트가 필요한데 일반적으로 보통 사
용자에 대한 배달 에이전트는 /bin/mail이며 메일을 받기 위해 POP(Post
Office Protocol)이나 UUCP를 사용하는 원격 호스트에 대해서는 uux와 spop이
배달 에이전트가 된다.
또한 일반 프로그램이나 파일이 수신자가 되는 경우는 /bin/sh가 그 배달 에이
전트가 된다. 이 글에서는 메일러(Mailer)라는 용어도 같이 사용하도록 하겠다.

메일의 주소 지정
일반적으로 호스트에 사용자는 고유한 사용자명을 가지기 때문에 어떤 호스트
까지 메일이 도착만 하면 그 호스트내의 사용자에게 전달되는 것은 별 문제가
없다. 그러면 목적 호스트까지는 메일이 어떤 경로를 거쳐 전달되는 것일까?
이미 지난 호에서 UUCP를 언급하면서 설명하였지만 다시 한번 설명하자면 주
소를 지정하는 방법은 크게 2가지이다.
하나는 경로 중심(route-based) 설정이다. 예를 들면 ‘2블럭 직진하여 오른쪽
으로 돌아 하얀 색 집’식으로 어떻게 목적지에 도달하는지를 구체적으로 나타
내는 것이다. 이와 같은 경우 예에서도 나타나 있는 것처럼 메일을 보내는 사
람은 목적지 호스트 사이의 중간 경유 호스트를 알아야 한다.
또 한 방법은 목적지 중심(destination-based) 설정인데 예를 들면 ‘서울 서초
구 방배동 1008번지’와 같이 직접 목적지의 주소를 주는 것이다. 물론 어떻게
가야하는지는 지정하지 않는다. 알아서 가란 의미인 것이다. UUCP는 바로 전
자의 경로 중심 방법으로 주소를 지정하는 반면 인터넷의 주소지정 방식은 목
적지 중심이 일반적이다.
이미 다 아는 사실이겠지만 인터넷의 주소지정 예는 다음과 같다.

huclons@inhavision.inha.ac.kr

@는 사용자와 호스트를 구분하는 문자로 메일은 지정한 호스트의 사용자에게
지정된 메일 박스로 전달된다. UUCP 주소 지정의 예는 다음과 같다.

selab!munhak!dragon!eslab!huclons

selab과 munhak, dragon의 호스트를 거쳐 eslab호스트의 사용자 huclons에게
연결하는 것이다.

메일의 헤더
모든 메일 메시지는 헤더라고 불리는 메시지에 대한 정보를 담고 있는 부분으
로 처음 시작된다. 대부분의 사용자 에이전트는 이 부분을 숨기는 것이 보통이
지만 옵션을 주면 보이도록 할 수 있다.

스풀 디렉터리
사용자의 메일박스(우체통)는 보통 /var/spool/mail 디렉터리(BSD) 혹은
/var/mail(ATT)에 사용자명과 같은 파일로 관리된다. 이 디렉터리는 보통 시
스템을 설치할 때 만들어진다.
보통 이 디렉터리는 755의 접근 모드나 혹은 스티키 비트(1777)를 설정해 다른
사람이 삭제할 수 없도록 되어 있다. 그렇지 않은 시스템은 당장 접근 모드를
변경하기 바란다.

메일 시스템 관리의 원칙
메일 시스템을 관리하는데 쉬운 관리를 위해 지켜야 할 원칙이 있다.
첫 번째는 주 메일 서버를 운영하는 것이다. 다시 말해 서버 이외의 다른 시스
템들은 자신이 알 수 없는 메일에 대해서는 모두 서버에게 그 메일을 전송해
버리도록 하는 것이다.
두 번째는 사용자들이 여러 시스템에 계정을 가지고 있다 하더라도 오직 하나
의 시스템에서 모든 메일을 읽을 수 있도록 하는 것이다.

메일 별명(Alias)
별명(Alias)은 시스템 관리자나 혹은 사용자에 의해 메일을 다른 곳으로 방향
전환해 전송될 수 있도록 한다. 또한 이를 이용해 메일링 리스트(다중의 수신
자를 가지는 메일)를 정의하거나 여러 시스템으로 동시에 전송할 수도 있다.
더불어 여러 이름으로서 한 사용자에게 메일이 전송되게 할 수도 있다. 일반적
으로 메일 별명은 3곳에서 정의될 수 있다.

(1) 사용자 에이전트의 세팅 파일
(2) 시스템 전체에 적용되는 별명 지정 파일(/etc/aliases)
(3) 사용자 디렉터리의 파일(~사용자/.forward)

메일 시스템이 별명을 참조하는 순서는 위에서 나열한 순서대로 참조한다.
다음은 SunOS 4.1.3의 /etc/aliases 파일을 예로 보인 것이다.

[eslab:/users/yjy]# cat /etc/aliases
##
# 별명(Aliases)은 왼편에 대, 소문자를 섞어 사용할 수 있다.
# 그러나 오른편은 보통 소문자를 사용하도록 한다.
#
# (참고) newaliases 프로그램은 이 파일을 체크해 갱신된
# 내용을 sendmail에게 알려준다.
#
# @(#)aliases 1.10 89/01/20 SMI
##

# 다음 별명은 메일 프로토콜 RFC 822를 따른다.
# 일반적으로 Postmaster, webmaster를 루트로 별명 부여한다.
Postmaster: root
webmaster: root

# mailer daemon에 대한 별명; MAILER-DAEMON으로부터
# 되돌아온 메일은 postmaster 즉 관리자에게 보내진다.
MAILER-DAEMON: postmaster

# 별명의 예

# 분배 목록에 대한 별명들, 소속원이 여기서 지정된다.
staff:wnj,mosher,sam,ecc,mckusick,sklower,olson,rwh@ernie

###############################
# 그 외 별명은 이 아래 지정 #
##############################

huclons: yjy
yjy: yjy@inhavision.inha.ac.kr
www: yjy,jjjung,hui,stonehead

위에서 첫 번째 라인은 huclons에게 보내는 메일을 현재 시스템의 사용자 yjy
에게 전송하라는 의미이다. 두 번째 라인의 의미는 현재 시스템의 yjy 사용자
로 보내는 모든 메일을 호스트 inhavision.inha.ac.kr의 yjy 사용자에게로 전송
하라는 의미이다. 그리고 세 번째 라인은 호스트의 www사용자, 즉 웹 마스터
에게 오는 모든 메일을 yjy, jjjung, hue, stonehead에게 모두 전달하라는 의미
이다.
참고로 위의 예와 같이 재귀적인 표현도 가능하다. 즉, 현재 호스트의 huclons
에게 보낸 메일은 결국 yjy@inhavision.inha.ac.kr로 전달되는 것이다.

메일 전송하기
aliases 파일은 관리자에 의해 관리되어야 하는 시스템 전반에 미치는 세팅파
일이다. 만약 사용자가 자신의 메일을 다른 곳으로 보내도록 하고자 하면 자신
의 홈디렉터리에 .for ward파일을 생성함으로서 가능하다. 사용용도는 여러 가
지가 있겠지만 대표적인 것으로 사용자가 특정 호스트에서만 메일을 받아보려
는 경우일 것이다.
.forward 파일은 ‘,’로 나누어지는 주소로 된 라인으로 구성된다. 예를 들면
다음과 같다.

huclons@inhavision.inha.ac.kr

해시된 별명 데이터베이스
/etc/aliases 파일에 있는 항목들은 특별한 순서를 가지고 있지 않기 때문에 이
파일을 직접 sendmail이 탐색하는 것은 상당히 비효율적이 된다. 그러므로
aliases파일에 대해 해시된 형식의 파일을 따로 만들어 관리하기도 한다.
SENDMAIL이란

sendmail은 Eric Allman이라는 사람이 버클리 대학에 재학중일 때 만든 것으
로 가장 일반적으로 많이 쓰이는 메일 전송 시스템(프로그램)이다.
이 sendmail 프로그램은 그 세팅파일(configuration file)의 유연성으로 인해 여
러 사람의 요구를 만족시킬 수 있게 되어있다. 이번 연재의 대부분이 바로 이
세팅파일(sendmail.cf)의 설정에 대한 내용이 되는데 솔직히 말해 복잡하고 지
루할 뿐만 아니라 난해하다 못해 이해의 필요성에 대해 의구심을 느낄지도 모
르겠다. 하지만 관리자로서 넘어야 할 또 하나의 큰 산이며 이 산을 넘으면 여
러분은 또 한단계의 수준이 높아진다는 생각을 가지고 끝까지 통독하기 바란
다. 어떤 사람은 “sendmail 세팅파일을 수정할 수 있어야 진정한 유닉스 시스
템 관리자라고 이야기 할 수 있다” 라고 말한다.
sendmail은 상황에 따라 에러 메시지를 출력하기도 하고 메일이 전송되지 않는
경우는 메일을 반송하기도 한다.

sendmail의 과거
sendmail은 3가지의 버전이 존재해왔다. sendmail V5는 1983년 Eric Allman이
라는 사람이 만들었고 가장 최근의 버전은 ftp.uu.net의 anonymous ftp를 통해
구할 수 있다.
IDA sendmail의 확장 키트는 Lennart Lovstrand라는 스웨덴 사람이 1987년
제작하였다. 이름 또한 그 사람이 있던 단체의 이름을 따온 것이다. 현재는 일
리노이즈 대학 등의 몇몇 사람이 관리하고 있다. 현재의 버전은 UIUC IDA
send mail로 불리며 vixen.cso.uiuc.edu에서 구할 수 있다. send mail V8은
1993년에 Eric Allman이 IDA 버전의 많은 장점을 취해 V5를 크게 업그레이드
한 것으로 현재 버전은 ftp.cs.b erkeley.edu의 anonymous ftp를 통해 구할 수
있다.

여러 시스템에서의 sendmail
지금 여러분들이 쓰는 대부분의 유닉스 시스템들은 보안 문제, 혹은 이형
(heterogeneous) 네트워크 시스템에서의 비호환성 등 여러 문제를 가지고 있을
것이다. 이렇게 말할 수 있는 이유는 과거 세 가지 종류의 sendmail이 서로 비
슷한 성능이었을 때 대부분의 시스템 업체들은 V5나 IDA를 선택했고 V8은 대
학이나 몇몇 소수 실험정신이 강한 이들에게 넘겨졌다. 그런데 시간이 지나면
서 V8은 안정성과 보안성이 더해갔고 반면 V5나 IDA는 그렇지 못하였다. 그
러므로 만약 여러분이 시스템을 새로 구입할 때 네트워크 기능이 우선시 되는
경우에는 V8을 채택한 시스템을 선택하는 것이 바람직할 것이다.
혹시 DECnet을 사용해야 하는 경우라면 IDA를 사용하는 시스템을 우선 순위
에 두어야 할 것이다. 왜냐하면 V8은 DECnet을 지원하지 않기 때문이다.
만약 회사에서 요구하는 특정 기능이 강화된 컴퓨터가 V5를 지원하는 경우 대
안으로 V8 sendmail만을 GNU에서 받아 컴파일해서 설치하는 방법도 있을 수
있겠다.
다음 테이블은 대표적인 시스템에서의 sendmail 버전을 나타낸 것인데 최근에
업그레이드된 시스템의 경우는 다를 수 있으니 다음의 표에 나타난 시스템 종
류가 아닌 경우는 각자 확인해 보기 바란다.

시스템 코드 베이스 컨피그 베이스
Solaris 2.4 Circa January '91 Circa February '83
HP-UX 9.0 BSD 5.65 -
IRIX 5.2 IDA 5.65 Circa April '93
IRIX 4.2 BSD 5.21 -
SunOS 4.1.3 BSD 3.67 Circa February '83
OSF/1 2.0 IDA와 비슷 Circa 1991-'92
BSDI 1.1 BSD 8.6.5 Version 8.6.4

여러 동작 모드들
sendmail은 -b옵션(become 혹은 be 의미)과 연관되어 여러 가지 모드로 동작
할 수 있다. -b옵션은 아래 표와 같이 항상 다른 옵션과 같이 사용된다.

플래그 의 미
-bd 데몬 모드로 수행
-bi 해시된 앨리어스(별명)를 초기화 (newaliases와 동일)
-bp 메일 큐를 프린트한다(mailq 명령과 동일).
-bz 컨피그 파일을 고정시킨다(V8에서는 해당 안됨).
-bt 테스트 모드 주소로 들어간다.
-bs SMTP 서버모드로 들어간다(표준 입력에서).

위의 표에서 -bz 옵션의 컨피그 파일을 고정시킨다는 말은 sendmail이 파일을
읽은 후에 그 메모리 이미지를 저장한다는 의미이다. 이것은 과거 여러 이유로
해서 수행시간을 줄이기 위한 방편으로 사용되었지만 근래에는 거의 사용하지
않는 모드이다.

메일 큐
메일 메시지는 시스템이 바쁘지 않으면 바로 전송이 되지만 시스템이 메일 처
리를 하지 못할 정도로 바쁘거나 혹은 목적지 시스템으로의 연결이 되지 않는
경우는 큐 디렉터리에 저장된다. 일반적으로 이 큐 디렉터리는 /var/spool/
mqueue이며 루트를 소유자로, 접근모드는 711 혹은 700으로 지정된다.

접두어 파일 내용
qf 헤더 메시지와 제어 파일
df 메시지의 몸체
lf 메시지에 대한 lock 파일
nf race condition을 피하기 위해 이전 sendmail에 의해 사용된 파일(불필요)
tf 배달이 다시 실패할 경우의 qf의 임시 파일
xf 메일이용자로부터의 에러 메시지의 사본 파일

sendmail의 세팅 설정하기(Configuration)
sendmail의 동작은 기본적으로 하나의 세팅파일인 /etc/ sendmail.cf 혹은
/usr/lib/sendmail.cf를 통해 지정된다. 이 세팅파일을 수정하면 다시 컴파일 할
필요없이 각 호스트에 맡게 sendmail이 동작하게 할 수 있는 것이다. 세팅파일
은 sendmail의 다음 사항을 결정한다.

(1) 배달 에이전트의 선택
(2) 주소를 고쳐 쓰는 규칙
(3) 메일의 헤더 형식

세팅파일의 형식은 해석하기 쉽게 되어 있는데 sendmail이 읽고 이해하기 위한
부하를 가능한 줄이기 위한 것이다. 모든 sendmail은 세팅파일을 사용한다.
IDA와 V8은 이 세팅파일을 생성하는 m4 프리프로세서를 사용하여 세팅 절차
를 간략화 하였다.

오리지널 세팅 파일
sendmail.cf 파일은 일반적으로 세개의 부분으로 구성된다.

(1) 심볼, 클래스, 옵션, 파라미터를 정의하는 부분
(2) 주소를 고쳐 쓰는 규칙 부분
(3) 배달 에이전트의 정의 부분

일반 문법
sendmail 세팅파일에서의 명령들은 항상 첫 세로열(column)에서 시작한다. 라
인의 첫 번째 문자가 바로 명령의 종류와 나머지 지정을 의미하는 것이다. 다
른 세팅 파일과 유사하게 주석은 ‘#’문자로 시작하는 라인이다. 각 라인은
공백이나 탭으로 시작하지 않는 한 완전한 하나의 명령을 의미한다. 공백이나
탭은 앞 라인의 연장임을 나타내는 것이다.
보통 , (, ), ", 문자는 특별한 의미를 가진다.
다음은 세팅 파일의 명령 문자 코드를 나타낸 것이다.

코 드 기 능
D 매크로 변수를 정의한다(단일값).
C 클래스 변수를 정의한다(set과 같은 다중값).
F 파일의 내용을 사용하는 클래스를 정의한다.
O 옵션을 지정한다.
H 헤더를 정의한다.
P 메시지 우선 순위 클래스들을 정의한다.
T 신뢰성 있는 사용자를 정의한다(V8에서는 소용없음).
V 컨피그 파일 버전 번호를 지정한다(V8에서만 유용).
K 데이터베이스 파일을 정의한다(V8에서만 유용, IDA는 K 옵션을 사용).
S 새로운 룰의 집합을 소개한다.
R set에 있는 새로운 룰을 정의한다.
M mailer를 정의한다(배달 에이전트).

D 명령어 문자 - 심볼 정의
변수들은 하나의 문자로된 이름을 가지며 D 명령어를 통해 정의된다. 형식은
다음과 같다.

DX값 (예) DJyjy

위의 예는 J변수에 yjy라는 문자열을 할당한 예이다.
sendmail은 모든 소문자 변수명을 이미 특정한 용도를 사용하고 있기 때문에
사용자가 임의의 변수지정을 하려면 위의 예처럼 대문자를 사용해야 한다.

이름 의미 이름 의미
a 개발 날짜(RFC822) n 데몬 이름(에러일 때)
b 현재 날짜(RFC822) o Operators 집합
c Hop Count p sendmail의 프로세스 ID
d 현재 날짜(ctime) q 송신자 주소 형식
e SMTP 엔트리 메시지 r 사용된 프로토콜
f 송신자 주소 s 송신자의 호스트명
g Envelope 송신자 t 현재 시간(숫자)
h 수신 호스트 u 수신 사용자
i 큐 ID v sendmail 버전
j 완전한 이름의 호스트명 w 자기 사이트의 호스트명
k UUCP 사이트명(V8, IDA) x 송신자의 완전한 이름
l 유닉스의 형식 z 수신자의 홈 디렉터리
m DNS 도메인명 _ 인정된 송신자 주소(V8)

C 명령어 문자 - 클래스 정의
심볼의 클래스(예를 들면 직접 연결 가능한 모든 UUCP 호스트)는 C 명령어
를 이용해 정의 가능한데 형식은 다음과 같다.

CX멤버

F 명령어 문자 - 파일로부터의 클래스 정의
F 명령은 원칙적으로는 C 명령과 동일하나 한 가지, 멤버의 목록을 파일에서
읽는다는 점만 다르다. 파일을 읽는 동안 사용될 형식은 scanf 기호를 사용해
지정한다. 디폴트는 %s 이다. 예를 들면 다음과 같다.

FV/usr/local/lib/sendmail/vms.hosts
FU/usr/lib/uucp/Systems %[A-Za-z0-9_-]
/* 호스트 이름만을 가져옴 */
FW|/usr/local/bin/gethosts /* IDA만 */

O 명령어 문자 - 옵션 세팅
O 명령은 D 명령이 매크로(변수)를 정의하듯이 같은 형식으로 옵션을 세트시
키는 명령이다. 형식은 다음과 같다.

OX값

X는 하나의 옵션을 나타내는 문자로 여기서 지정하는 옵션은 모두 sendmail
의 명령행 라인에서 -o 플래그를 이용해 지정 가능하다.
다음으로 나오는 값은 문자열, 정수, 불리언값, 시간 등 옵션에 따라 여러 가지
가 올 수 있다. 옵션의 종류는 다음과 같다. 이 이외에도 많은 옵션이 있으니
매뉴얼로 확인하기 바란다.

(1) A - 별명 정보를 가져오는 파일이나 호스트
(2) T - 메시지가 큐에 일정시간 그대로 있는 경우 타임아웃을 나타내는 시간
(3) x, X - sendmail에 부하가 걸리는 경우에 대한 제어(Ox8 OX12 하면 부하
가 8이상이면 메일을 큐에 넣고 12이상이면 연결을 거부하도록 한다. 부하의
정도를 나타내는 기준은 시스템마다 상이).
(4) p - 보안 기능 작동
(5) P - 되돌리는 메일에 대한 제어
(6) n - 별명 확인


P 명령어 문자 - 메시지 우선 순위를 정의
모든 메일 메시지는 그것이 sendmail 큐에 들어갈 때 그 우선 순위가 할당된
다. 우선 순위는 메시지를 보내는 시간, 경유한 배달 에이전트 수, 메시지 크기
등을 통해 할당된다.

T 명령어 문자 - 신뢰성 있는(Trusted) 사용자 정의(V8은 아님)
신뢰성 있는 사용자의 지정에는 다음과 같이 T 명령이 사용된다.

T사용자1 사용자2 사용자3 .....

H 명령어 문자 - 헤더 형식 세팅하기
sendmail에 의해 만들어지는 메일 헤더는 매우 잡다해 질 수 있다. 그러다 보
면 실제 메일의 내용보다도 더 많은 공간을 차지할 수도 있다. 물론 잡다한 정
보를 가지는 헤더는 디버깅하기에 좋은 장점이 있지만 항상 그렇게 만들 필요
는 없는 것이다. 이와 같은 헤더의 정의는 H 명령을 통해 정의되는데 형식은
다음과 같다.

H이름: 형식

헤더는 각 외부로 전송되는 메시지에 포함된다. ‘이름’ 필드는 ‘X-’로 시
작하는 문자열이나 아니면 고정된 목록이 된다.

V 명령어 문자 - 세팅파일의 문법 버전 정의하기
sendmail의 세팅파일에서 허용된 형식은 sendmail이 버전이 바뀌면 같이 변경
된다. V8은 이것을 V명령을 써서 사용중인 문법의 버전을 인식함으로써 이를
명시적으로 정의한다.

K 명령어 문자 - Keyed Database 정의(V8에서만)
IDA는 K 옵션을 사용하여 Keyed DB파일을 사용하는 방법을 도입하였다. V8
에서는 이를 정의하기 위해 K 명령을 추가하였다. 두 가지 모두 테이블 검색
속도를 향상시키고 고쳐쓰는 연산에 융통성을 부여한다.

S 명령어 문자 - 새로운 규칙들을 시작하기
고쳐 쓰는 규칙(Rewriting Rules)은 규칙집합(Rulesets)으로 그룹화 되고 각각
은 숫자로서 지정된다. S 명령은 이러한 규칙집합을 나타낸다. 사용 예는 다음
과 같다.

S3

위는 규칙집합 세 번째를 시작한다는 의미이다. 이 세 번째 규칙집합은 또다른
S 명령을 만날 때까지 계속된다.

R 명령어 문자 - 다시 고쳐 쓰는 규칙 정의
이 부분은 실제 고쳐 쓰는 규칙(Rewriting Rule)을 기술하는 부분이다.
이 규칙들이 바로 sendmail의 세팅을 난해하고 난잡하게 만드는 주범인 것이
다. 우선 규칙들을 하나하나 분석해 보고 왼쪽 편에 쓰인 매직토큰과 오른편의
매직토큰을 알아보도록 하자.
다음은 왼쪽의 패턴 매칭 토큰들이다.

토큰 디버그 의 미
$@ 0개 토큰을 매칭(V8만)
$- ^R 정확히 하나의 토큰만을 매칭
$+ ^Q 하나이상의 토큰을 매칭
$* ^P 0개 이상의 토큰을 매칭
$X 매크로 변수 X의 값을 매칭
$&X 수행할 때 변수 X의 값을 매칭
$=X ^SX 클래스 X에서의 어떤 토큰을 매칭
$~X ^TX 클래스 X에 속하지 않는 어떤 토큰을 매칭

yjy@eslab.inha.ac.kr을 위의 규칙에 적용한 왼편의 패턴을 예로 든 것이다.

규칙 결 과
$* $1=yjy@eslab.inha.ac.kr
$+ $1=yjy@eslab.inha.ac.kr
$- 매칭 안됨, 한개 이상의 토큰필요
$+ @ $+ $1=yjy, $2=eslab.inha.ac.kr
$+ % $+ 매칭 안됨, % 없음
$+ ! $+ 매칭 안됨, ! 없음
$- @ $+ $1=yjy, $2=eslab.inha.ac.kr
$+ @ $- 매칭 안됨, @ 다음에 한개 이상의 토큰필요
$+ @ $+. $D $1=yjy, $2=eslab
$+. $+ $1=yjy@eslab, $2=inha.ac.kr
$+. $+. $=T $1=yjy@eslab, $2=inha, $5=ac.kr
그리고 규칙의 오른편에 사용되는 특수한 심볼들이다.

토큰 디버그 의 미
$X - 매크로 변수 X의 값을 사용
$?X yes $| no $. - 조건 매크로
$n ^U n LHS로부터 정의 안된 토큰 n을 사용
$>n ^Y n 규칙집합 n을 호출
${호스트명} ^] 호스트명 호스트명을 지정하기
$(맵이름 키 $) - DB ‘맵이름’에서 ‘키’를 검색
$#메일러 ^V 메일러 규칙집합 0에서
$@호스트 ^W 호스트 규칙집합 0에서 메일러로 ‘호스트’를
지정
$:사용자 ^X 사용자 규칙집합 0에서 메일러로 ‘사용자’를
지정
$@ ^W 접두어로서 규칙집합을 종료
$: ^X 접두어로서 규칙을 종료

M 명령어 문자 - 배달 에이전트 정의하기
Mailer, 즉 메일 메시지를 실제 사용자에게 전달해 주는 프로그램에 대한 정의
를 하는 명령으로서 그 지정 형식은 다음과 같다.

M이름, P=프로그램, F=플래그, ..., A=인자

보면 대충 감을 잡을 수 있겠지만 부가 설명을 하자면 다음의 표는 같이 사용
되는 옵션에 대한 간단한 설명이다.

옵션 값
P 호출할 프로그램
F sendmail과 배달 에이전트 프로그램에 대한 플래그
S 송신자 주소에 대해 사용할 추가적인 규칙집합(ruleset)
R 수신자 주소에 대해 사용할 추가적인 규칙집합(ruleset)
E 줄의 끝을 나타내는 문자
M 허용 가능한 최대 메시지 크기
A 배달 에이전트 프로그램을 호출할 때 같이 넘겨줄 인자
4 사용자 구분을 강제로 시킴(V8.7만)

다음은 F 옵션의 플래그 지정에 대한 문자들의 의미이다.

파일 의 미
D 메일러가 Date 헤더 라인을 필요로 함
E ‘>’문자를 사용하는 라인에 대해 Escape 라인임을 지정
F 메일러가 From 헤더 라인을 필요로 함
M 메일러가 Message-Id 헤더 라인을 필요로 함
P 메일러가 Return-Path 헤더 라인을 필요로 함
S 메일러를 루트로 수행하는 것이 안전
X 도트로 시작하는 라인에 추가의 도트 문자를 넣음
l 로컬 메일 전송자
m 메일러가 한번에 여러 수신자에게 메일 전송
n ‘From’ 라인을 헤더에 넣지 않음(메일러가 넣음)
s quote 문자(`)를 주소에서 떼어냄
u 사용자 이름에 대문자를 남겨둠
x 메일러가 Full-Name 헤더 라인을 필요로 함
7 메시지 몸체를 7비트로 나눔

M4 프리프로세서를 이용한 세팅

이제까지는 순수한 세팅 파일에 대해 공부하였다. 지금부터는 V8과 IDA를 소
개하도록 하겠다. V8이나 IDA는 m4 프리프로세서를 이용하여 세팅 과정을 단
순화 시켰는데 우선은 m4에 대해 간략히 소개하고 나서 세팅에 대한 이야기로
넘어가도록 하겠다. 그리고 맨 나중에 여러 종류의 사이트에 대한 세팅의 예를
들도록 하겠다.
다음은 m4 명령에서 사용되는 매크로에 대한 설명이다. 프로그래밍을 해본 사
람이라면 보고 이해하는데 별 무리가 없을 것이다.

매크로 기 능
define arg2의 값으로 arg1의 이름을 가진 매크로 정의
undefine arg1으로 지정된 이전의 매크로정의를 해제
include arg1을 가진 파일을 포함
dnl 다음 줄을 포함하여 문자를 포기함
divert 출력 스트림을 다룸

V8 세팅하기
대렉터리 내 용
cf 버클리 호스트에 대한 샘플 mc 파일들
domain 버클리 여러 도메인에 대한 샘플 m4 파일들
feature 여러 특징을 구현하기 위한 m4 파일들의 조각들
hack 애매한 특성
m4 기본 세팅 파일과 다른 핵심 파일
ostype 운영체계에 의존하는 파일의 위치
mailer 일반 mailer를 기술하는 m4 파일
sh 사용자명과 호스트명을 결정하는 makeinfo 스크립트
siteconfig UUCP 이웃을 지정하는 샘플 m4 파일들

V8은 m4에 대한 여러 개의 디렉터리를 가지는데 sendmail의 이진 실행 파일
을 만들기 위해 필요한 여러 파일들을 포함하는 src 디렉터리와 세팅을 위해
필요한 파일들을 가지는 cf 디렉터리가 있다. cf 디렉터리의 하위 디렉터리는
위의 표와 같은 디렉터리들이 있다.

define 매크로
define은 m4 언어의 일부로 기본값이 맞지 않은 경우 옵션과 매크로 변수들을
다시 세팅하는데 사용된다.

VERSIONID 매크로
이 매크로는 RCS 혹은 SCCS를 이용해 세팅 파일을 관리하는 경우 자동으로
버전에 대한 정보를 가지는 매크로이다. 이를 이용하여 이전 버전으로 되돌아
가거나 아니면 세팅 파일을 만든 m4 버전 정보를 인식하는 등의 관리를 수행
한다. RCS에 대한 형식은 다음과 같다.

VERSIONID(`$Id$')

SCCS에 대한 형식은 다음과 같다.

VERSIONID(`%W% (고유번호) %G%')

OSTYPE 매크로
변 수 기 본 값
ALIAS_FILE /etc/aliases
HELP_FILE /usr/lib/sendmail.hf
STATUS_FILE /etc/sendmail.st
QUEUE_DIR /var/spool/mqueue
LOCAL_MAILER_PATH /bin/mail
LOCAL_MAILER_FLAG lsDFM
LOCAL_MAILER_ARGS mail -d $u
LOCAL_SHELL_PATH /bin/sh
LOCAL_SHELL_FLAGS lsDFMeu
LOCAL_SHELL_ARGS sh -c $u
USENET_MAILER_PATH /usr/lib/news/inews
USENET_MAILER_FLAGS rlsDFMmn
USENET_MAILER_ARGS inews -m -h -n $u
SMTP_MAILER_FLAGS mDFMuX
UUCP_MAILER_PATH /usr/bin/uux
UUCP_MAILER_FLAGS mDFMhuU
UUCP_MAILER_SIZE 100000
FAX_MAILER_PATH /usr/local/lib/fax/mailfax
FAX_MAILER_MAX 100000

ostype 디렉터리에 있는 파일들은 운영체계의 이름을 따서 짓는데 OSTYPE
매크로를 사용할 때 사용될 수 있다. 모든 기본값을 아는 것은 다소 어려운데
앞의 표는 이를 요약한 것이다. 참고적으로 일반적인 시스템들마다 OSTYPE
파일의 이름이 고유한데 다음 표는 이를 보여준다.

시스템 파 일 사 용
Solaris solaris2.m4 OSTYPE('solaris2')
HP-UX hpux.m4 OSTYPE('hpux')
IRIX irix.m4 OSTYPE('irix')
SunOS sunos4.1.m4 OSTYPE('sunos4.1')
OSF/1 osf1.m4 OSTYPE('osf1')
BSDI bsdi1.0.m4 OSTYPE('bsdi1.0')

MASQUERADE_AS 매크로
MASQUERADE_AS 매크로는 다른 시스템들을 숨겨주는 하나의 시스템을 지
정하는데 사용된다.

FEATURE 매크로
FEATURE 매크로는 feature 디렉터리에 있는 m4 파일을 포함함으로써 여러
일반적인 옵션들을 가능하도록 하는데 사용하는 매크로이다. 형식은 다음과 같
다.

FEATURE(키워드)


MAIL_HUB 과 SMART_HOST 매크로
MAIL_HUB 매크로는 모든 메일들을 하나의 서버로 집중하여 전송시키고자
하는 경우 사용하는 매크로이다. MAIL_HUB 에 ‘메일러:호스트’형태로 값을
지정하면 되는데 여기서 메일러란 지정한 서버 호스트로 메일을 전송할 에이전
트를 말한다. 만약 특별한 지정이 없는 경우는 smtp 가 사용된다. 다음은 지정
예를 보인 것이다.

define(`MAIL_HUB', `smtp:mailhub.inha.ac.kr')

LOCAL_쪱 매크로
만약 특별한 상황을 가정해 새로운 규칙을 집어넣고자 한다면 이 LOCAL_쪱
매크로를 이용하면 된다. 다음은 규칙집합 0에 규칙을 추가한 예이다.

LOCAL_RULE_0
# 새 규칙에 대한 주석
R new rule
R another new rule

MAILER 매크로
MAILER 매크로는 세팅파일에서 필요한 각각의 배달 에이전트를 위해 반드시
포함되어야 한다. 사용 가능한 배달 에이전트(메일러)의 목록은 cf/mailers 디
렉터리에 있다. 현재는 local, smtp, fax, pop, usenet, uucp등이 지원되고 있다.
다음은 그 지정 예이다.

MAILER(local)
MAILER(smtp)

SITE 와 SITECONFIG 매크로
SITE 와 SITECONFIG 매크로는 UUCP 이웃(neighbor)을 지정하는데 사용되
는 매크로이다.

DOMAIN 매크로
DOMAIN 매크로(지시자)는 하나의 파일에 사이트에 대한 정보를 모두 넣어두
고 각각의 호스트에서 이를 참조하도록 하는 경우 사용할 수 있다.

DOMAIN(파일명)


V8 세팅파일 구축하기
이제까지 V8에서 사용되는 여러 매크로에 대해 알아보았다. 실제 sendmail의
세팅 파일 구축은 m4 프리프로세서 파일을 만들고 나서 다음과 같은 명령으로
구축하면 된다.

m4 huclons.mc > huclons.cf

IDA 세팅하기
V8과 유사하게 IDA 또한 IDA 스타일의 m4 세팅 파일들과 sendmail 이진파일
을 필요로 한다. 대부분 uxc.cso.uiuc.edu에서 구할 수 있다.
패키지는 sendmail이 만들어질 src 디렉터리를 가지며 또한 세팅 예제 파일과
m4 파일들을 가지는 cf 디렉터리를 포함한다. Sendmail.mc 파일이 IDA 세팅
파일 중에 핵심으로 V8에서의 cf.m4 파일과 거의 같은 역할을 한다. 자세한 매
크로들은 V8과 마찬가지로 상당히 많은데 내용에서 보면 V8과 큰 차이가 없
으므로 이 글에서는 생략하도록 하겠다.

세팅 설정 파일(Configuration File)의 예
이제부터는 가상회사의 호스트인 huclons.com의 V8과 IDA 세팅파일을 예로
들면서 설명하도록 하겠다. 두개의 세팅파일이 완전히 일대일로 대응되지는 않
지만 거의 같은 역할을 하도록 세팅될 것이다. 특별히 V8에서의 프라이버시
옵션만이 IDA에서 허용되지 않는 점만 차이가 있을 뿐이다. 가상 회사의 호스
트인 huclons.com은 인터넷에 직접 연결되는 게이트웨이 역할을 하며 그 외의
다른 호스트들은 huclons.com 뒤에 숨겨져서 외부로 나가는 모든 메일이
huclons.com이 보내는 것으로 조정되도록 한다. 참고로 UUCP 연결은 없다고
가정한다. huclons.com에 대한 V8 세팅 파일의 이름은 huclons.com.mc라 부르
며 내용은 다음과 같다.

divert(-1)

# huclons.com에 대한 세팅파일
# sendmail 8.6.9

include(`../m4/cf.m4')
VERSIONID(`$Id$')
OSTYPE(`sunos4.1')
define(`confPRIVACY_FLAGS', `noexpn')
define(`confMESSAGE_TIMEOUT', `5d/72h')
FEATURE(use_cw_file)
MASQUERADE_AS(huclons.com)
EXPOSED_USER(`root postmaster hostmaster')
MAILER(smtp)

/etc/sendmail.cw 파일에 들어있는 호스트들은 huclons. com으로 매핑될 것이
다.

메일 통계내기
sendmail은 자신이 다루는 메일 메시지의 크기와 수에 대한 통계를 낼 수 있
다. 주로 mailstats 명령을 통해 확인할 수 있는데 참고로 sendmail의 S 옵션은
이러한 통계가 기록되는 파일의 이름을 지정한다.

inhavision.inha.ac.kr> mailstats
Statistics from Tue Jan 14 19:43:37 1997
M msgsfr bytes_from msgsto bytes_to
1 0 0K 50 50K
3 104476 18837472K 150175 5160720K
4 3 1246K 7 244K
5 49551 2000333K 20664 2967344K

테스팅과 디버깅
V8이나 IDA의 세팅의 경우 어느 정도는 미리 테스트된 것이므로 저수준의 디
버깅이 필요한 경우가 많지는 않을 것이다.
하지만 특별한 상황에서는 사용자 세팅에 대한 디버깅을 해주어야 하는 경우가
생길 것이다. 물론 sendmail을 테스팅 모드로 구동한 후 테스트하는 것이 가장
일반적이다. 메일 시스템을 테스트하는 방법 중에는 직접 SMTP(Simple Mail
Transport Protocol)을 이용하는 방법도 있다.
우선 sendmail이 데몬 모드에서 할당되는 포트인 25번으로 텔넷 접속하여
SMTP 세션을 설정한 후에 SMTP 명령어들을 이용하여 직접 디버깅한다.
SMTP 명령어는 전부해야 14개이며 아래의 표에 나타내었다.

명 령 어 기 능
HELO 호스트명 연결 호스트를 지정
MAIL From: 반대경로 메일 트랜잭션을 초기화
RCPT To: 진행 경로 envelope 수령자를 인지
VRFY 주소 해당 주소가 유효한지를 검증
EXPN 주소 별명을 확장하여 .forward와 매핑
DATA 메시지 몸체를 시작
QUIT 데이터 교환을 끝내고 연결 종료
RSET 연결 상태를 리셋
HELP SMTP 명령 요약을 보여줌

자세한 스펙은 RFC821, RFC1123을 참조하면 되고 SMTP를 확장한 ESMTP
에 대해서는 RFC1425를 참조하기 바란다.

보안과 프라이버시
sendmail은 오래 전부터 보안의 큰 허점으로 이슈가 되어 왔다. 1988년 인터넷
웜이란 커다란 보안관련 사건에서도 초기에는 sendmail의 약점을 이용하려고
하였다고 한다. 물론 나중에 실제 시스템을 침투한 것은 다른 방법을 사용하였
지만 말이다.
사실 최근의 sendmail 버전들은 이러한 버그들을 대부분 고쳤지만 아직도 많은
유닉스 상용 시스템들은 구버전의 sendmail을 쓰고 있으므로 관리자는 자신의
시스템의 sendmail 버전을 확인하여 최신 버전으로 다시 설치하는 것이 필요하
다.

마치며
이번 달에는 전자 메일에 대해서 자세히 알아보았다.
어떻게 보면 명령과 옵션이 나열된 느낌이 드는데 세세하게 설명을 하자니 너
무 길고 지루해질 것 같은 느낌이 들어 간단 간단히 설명하였다. 자세한 것은
독자의 몫으로 남겨두겠다. 독자 여러분들도 정말 복잡하다고 느꼈을 것이다.
필자도 여러 번 자료를 읽고 이해하려고 시도했다가 실패한 경력이 있다. 여러
분도 포기하지 말고 우선은 메일 시스템의 전반적인 이해를 먼저 하고 그리고
나서 그 다음에 읽을 때는 좀더 자세히 세팅에 대해 공부하는 접근 방식이 적
당할 것이라 생각한다. 개인적으로 메일에 대한 세팅은 유닉스 관리자가 넘어
야할 가장 어려운 세팅이 아닌가 하는 생각이 든다. 여러분도 이 산을 무사히
넘기를 바란다. 다음 기사는 네트워크 관리에 대해 공부해 보도록 하겠다.



Posted by BAGE