| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
D.M.Z
CONTENT
PRE
NEXT
15.1 Introduction to Sendmail+IDA 15.1 Introduction to sendmail+IDA sendmail.cf 파일을 편집하기전엔 진정한 Unix 시스템 관리자가 아니란 말이 있다. 또한 그것을 두 번 시도한다면 미친 사람이란 말도 있다. :-) Sendmail은 믿을 수 없을 만큼 강력한 프로그램이다. 또한 그것은 대부분의 사람들에게 있어 믿을 수 없을 만큼 배우기 어려운 것이기도 하다. 가장 권위있는 레퍼런스(Sendmail, O'Reilly and Associates 발행)는 792 페이지나 되어 다부분의 사람을 겁먹게 한다. Sendmail+IDA는 다르다. 그것은 항상 암호화된 것 같은 sendmail.cf 파일을 수정해야하는 필요성을 배제하고, 상대적으로 이해하기 쉬운 tables이라는 지원파일을 통하여 관리자가 사이트 특정 라우팅과 어드레싱을 설정할 수 있게 한다. sendmail+IDA로 바꾸는 편이 작업의 시간과 스트레스를 줄여줄 것이다. 다른 메이저 메일 전송 에이전트들과 sendmail+IDA를 비교해볼 때, 이보다 더 빠르고 단순한 것은 없을 것이다. 보통의 UUCP나 인터넷 사이트를 운영하면서 필요한 보편적인 것들은 간단히 이루어진다. 극도로 어려운 설정도 만들기 쉽고 유지하기도 쉽다. 이 글을 쓰는 당시의 현재버전은 sendmail5.67b+IDA1.5는 vixen.cso.uiuc.edu에서 anonymous FTP로 구할 수 있다. 리눅스에선 패치할 필요없이 컴파일된다. 리눅스에서 Sendmail+IDA 소스를 얻어 컴파일, 인스톨하고 실행하는데 필요한 모든 설정파일은 newspak-2.2.tar.gz에 포함되어 있다. 이는 sunsite.unc.edu의 /pub/Linux/system/Mail 디렉토리에서 anonymous FTP로 구할 수 있다.
15.2 Configuration Files - Overview 전통적인 sendmail은 시스템 설정파일(보통 /etc/sendmail.cf 또는 /usr/lib/sendmail.cf를 통해 셋업되는데, 당신이 이전에 본 어떠한 언어와도 비슷한 구석이 없을 것이다. sendmail.cf를 수정하여 원하는대로 동작하게 만드는 것은 고통스런 경험이 될 것이다. Sendmail+IDA는 모든 설정옵션들을 다소 쉬운 문법의 테이블로 조절할 수 있게 함으로써 그러한 고통을 과거의 것으로 만들어 버린다. 이 옵션들은 m4(매크로 프로세서) 또는 dbm(데이터베이스 프로세서)를, 소스와 헴께 제공되는 Makefile로 몇가지 데이터 파일에 실행함으로써 설정된다. sendmail.cf 파일은 단지 시스템의 디폴트 동작만을 정의한다. 모든 커스터마이징은 직접 sendmail.cf를 수정하는 대신 몇가지 옵션 테이블을 통해 이루어진다. 그림 15.1에선 모든 sendmail 테이블의 목록을 보여준다.
그림 15.1: sendmail 지원 파일
Sendmil+IDA의 sendmail.cf 파일은 직접적 편집되진 않고, 로컬 시스템 관리자에의해 제공되는 m4 설정파일에서 생성된다. 이제부터 그것을 가리켜 sendmail.m4라고 칭하기로 한다. 이 파일은 약간의 정의를 포함하거나, 단순히 실제 동작이 수행되는 테이블의 위치를 가리킨다. 보통의 경우, 다음의 사항들만을 지정해 주면된다.
로컬 사이트의 동작을 확정하거나 compile-in된 설정아이템을 오버라이드하기위해 정의할 수 있는 많은 종류의 파라미터가 존재한다. 이 설정옵션들은 소스 디렉토리내의 ida/cf/OPTIONS에서 정의할 수 있다. 최소 설정(로컬이 아닌 메일이 스마트 호스트로 릴레이되는 UUCP나 SMTP)을 위한 sendmail.m4 파일은 주석문을 빼고 나면 10에서 15라인정도밖에 안된다. 15.3.1 An Example sendmail.m4 File Virtual Brewery내 vstout의 sendmail.m4 예제파일은 아래에서 볼 수 있다. vstout은 Brewery LAN상의 모든 호스트와 SMTP를 사용하여 통신하고, 그 외의 모든 메일은 UUCP로 릴레이 호스트인 moria에게 보낸다. 15.3.2 Typically Used sendmail.m4 Parameters sendmail.m4의 아이템 중 언제나 필요한 것은 약간 뿐이고, 그 외의 것들은 디폴트로 없애버리면 무시되는 것들이다. 예제 sendmail.m4 파일에 있는 각각의 아이템에 대해선, 다음 절에서 보다 자세히 다룬다. Items that Define Paths
dnl #define(LIBDIR,/usr/local/lib/mail)dnl # where all support files go
LIBDIR은 sendmail+IDA가 설정파일, 즉 여러 dbm 테이블과 특수한 로컬 정의사항을 찾을 디렉토리를 정의한다. 전통적인 바이너리 배포판에서, 이는 sendmail바이너리에 compile-in되어 있으므로 sendmail.m4 파일에서 따로 지정할 필요는 없다. 위의 예제 앞엔 dul이 붙는데, 이는 이 라인이 근본적으로 오직 정보를 위한 주석문임을 의미한다. 지원파일의 위치를 다른 곳으로 변경하기위해선, 위의 라인앞에 붙은 dnl을 제거하고 원하는 위치로 패스를 지정한 뒤, sendmail.cf 파일을 다시 build하고 재설치하면 된다.
dnl #------------------ SAMPLE SENDMAIL.M4 FILE ------------------
dnl # (the string 'dnl' is the m4 squivalent of commenting out a line)
dnl # you generally don't want to override LIBDIR from the compiled in paths
dnl #define(LIBDIR,/usr/local/lib/mail)dnl # where all support files go
define(LOCAL_MAILER_DEF, mailers.linux)dnl # mailer for local delivery
define(POSTMASTERBOUNCE)dnl # postmaster gets bounces
define(PSEUDODOMAINS, BITNET UUCP)dnl # don't try DNS on these
dnl #-------------------------------------------------------------
dnl #
define(PSEUDONYMS, vstout.vbrew.com vstout.UUCP vbrew.com)
dnl # names we're known by
define(DEFAULT_HOST, vstout.vbrew.com)dnl # our primary 'name' for mail
define(UUCPNAME, vstout)dnl # our uucp name
dnl #
dnl #-------------------------------------------------------------
dnl #
define(UUCPNODES, |uuname|sort|uniq)dnl # our uucp neighbors
define(BANGIMPLIESUUCP)dnl # make certain that uucp
define(BANGONLYUUCP)dnl # mail is treated correctly
define(RELAY_HOST, moria)dnl # our smart relay host
define(RELAY_MAILER, UUCP-A)dnl # we reach moria via uucp
dnl #
dnl #--------------------------------------------------------------------
dnl #
dnl # the various dbm lookup tables
dnl #
define(ALIASES, LIBDIR/aliases)dnl # system aliases
define(DOMAINTABLE, LIBDIR/domaintable)dnl # domainize hosts
define(PATHTABLE, LIBDIR/pathtable)dnl # paths database
define(GENERICFROM, LIBDIR/generics)dnl # generic from addresses
define(MAILERTABLE, LIBDIR/mailertable)dnl # mailers per host or domain
define(UUCPXTABLE, LIBDIR/uucpxtable)dnl # paths to hosts we feed
define(UUCPRELAYS, LIBDIR/uucprelays)dnl # short-circuit paths
dnl #
dnl #--------------------------------------------------------------------
dnl #
dnl # include the 'real' code that makes it all work
dnl # (provided with the source code)
dnl #
include(Sendmail.mc)dnl # REQUIRED ENTRY !!!
dnl #
dnl #------------ END OF SAMPLE SENDMAIL.M4 FILE -----
Defining the Local Mailer
#define(LOCAL_MAILER_DEF, mailers.linux)dnl # mailer for local delivery
대부분의 운영체계는 메일의 local delivery를 핸들하기 위한 프로그램을 제공하는데, 여러 Unix에서의 전통적인 프로그램은 이미 sendmail 바이너리에 내포되어 있다. 리눅스에선, 당신이 인스톨한 배포판엔 local delivery 프로그램이 꼭 들어있는것이 아니기 때문에 따로 적절한 로컬 mailer를 정의해 줄 필요가 있다. 이는 sendmail.m4 파일내에 LOCAL_MAILER_DEF를 사용하여 지정할 수 있다. 예를 들어, 일반적으로 쓰이는 deliver 프로그램이 이 서비스를 제공하게 하려면, LOCAL_MAILER_DER를 mailers.linux로 지정해 주면 된다. 다음의 파일은 LIBDIR이 가리키는 디렉토리에 mailers.linux라는 이름으로 설치되어야 한다. 그것은 따로 sendmail이 로컬 시스템을 타겟으로한 메일을 올바르게 배달할 수 있게 하는 적절한 paramater와 함께, internal Mlocal mailer에 deliver 프로그램을 정의한다. 당신이 sendmail에 숙련되지 않았다면, 굳이 다음예제를 대체할 필요를 못 느낄 것이다.
# -- /usr/local/lib/mail/mailers.linux --
# (local mailers for use on Linux )
Mlocal, P=/usr/bin/deliver, F=SlsmFDMP, S=10, R=25/10, A=deliver $u
Mprog, P=/bin/sh, F=lsDFMeuP, S=10, R=10, A=sh -c $u
sendmail.cf 파일에 include되는 Sendmail.mc 파일 내에 deliver에 대한 bulit-in 디폴트도 존재한다. 그것을 지정하기 위해, mailers.linux 파일을 사용하지 않고, 그 대신 다음을 sendmail.m4 파일에 정의할 수 있다.
dnl --- (in sendmail.m4) ---
define(LOCAL_MAILER_DEF, DELIVER)dnl # mailer for local delivery
불행하게도, Sendmail.mc는 deliver가 /bin에 설치되어 있다고 가정하는데, Slackware1.1.1에선 그러하지 않다(/usr/bin에 설치되어 있다). 그러한 경우 링크를 사용하여 속이거나, deliver를 소스에서 rebuild하여 /bin에 넣든가 해야 된다. Dealing with Bounced Mail
define(POSTMASTERBOUNCE)dnl # postmaster gets bounces
많은 사이트에 있어서, 메일이 100%에 가까운 성공률로 송수신 된다고 확신하는 것은 중요한 일이다.
로컬 메일 관리자는 메일이 배달되지 않은 이유가 유저의 실수인지, 또는 연루된 시스템 중 하나의 설정 에러인지를 결정하기 위해 bounce된 메일의 헤더를 보길 원하는데, syslog(8)의 로그를 검토하는 것도 도움이 된다.
POSTMASTERBOUNCE를 정의하게 되면, bounce된 메시지 각각의 복사본이 그 시스템에 Postmaster로 정의된 사람에게 보내진다. 불행하게도, 이 파라미터를 지정하게 되면 bounce된 메시지의 텍스트도 Postmaster에게 보내지게 되어 잠정적으로 그 시스템에서 메일을 사용하는 사람들의 프라이버시를 침해하게되는 결과를 초래한다. postmaster는 자신에게 온 메일이 아니면 읽지 않도록 자기 스스로를 훈련시켜야한다. (또는 bounce 메시지의 텍스트 부분을 지우는 쉘 스크립트를 만들어 기술적으로 그렇게 할 수도 있다.) Domain Name Service Related Items
define(PSEUDODOMAINS, BITNET UUCP)dnl # don't try DNS on these
DNS의 목적엔 부합되지 않으나, 역사적인 이유에서 메일 주소내에 통상적으로 언급되는 몇가지 잘 알려진 네트웍이 있다. PSEUDODOMAINS를 정의하면, 언제나 실패하기만 하는 쓸데없는 DNS 검색시도를 하지 않도록 한다. Defining Names the Local SYstem is Known by
define(PSEUDONYMS, vstout.vbrew.com vstout.UUCP vbrew.com)
dnl # names we're known by
define(DEFAULT_HOST, vstout.vbrew.com)dnl # our primary 'name' for mail
때때로, 시스템이 자신의 진짜 identity를 숨기거나, 메일 게이트웨이로 서비스하거나, 또는 그들이 알려졌던 '옛날' 이름으로 메일을 수신하고 처리했으면 할 경우가 있다.
PSEUDONYMS는 로컬 시스템이 메일을 받아들일 모든 호스트네임의 리스트를 지정한다. DEFAULT_HOST는 로컬 호스트에서 발생한 메시지에 써 넣을 호스트네임을 지정한다. 이 파라미터를 지정하지 않으면, 리턴되는 모든 메일이 배달되지 않기 때문에 중요한 것이다. UUCP-Related Items
define(UUCPNAME, vstout)dnl # our uucp name
define(UUCPNODES, |uuname|sort|uniq)dnl # our uucp neighbors
define(BANGIMPLIESUUCP)dnl # make certain that uucp
define(BANGONLYUUCP)dnl # mail is treated correctly
종종, 시스템은 DNS를 목적으로한 하나의 네임과 UUCP 목적을 위한 또다른 네임으로 알려지는데, UUCPNAME은 outgoing UUCP 메일의 헤더에 서로 다른 호스트네임을 정의할 수 있게 한다.
UUCPNODES는 UUCP 커넥션으로 직접 연결된 시스템들의 호스트네임 리스트를 리턴하는 커맨드를 정의한다. BANGIMPLIESUUCP와 BANGONLYUUCP는 UUCP 'bang' systax로 표현된 메일 주소가 오늘날의 인터넷 상에서 사용되는, 보다 새로운 Domain Name Service 동작방식 대신, UUCP 동작방식에 따른다고 취급함을 보장하는 역할을 한다. Relay Systems and Mailers
define(RELAY_HOST, moria)dnl # our smart relay host
define(RELAY_MAILER, UUCP-A)dnl # we reach moria via UUCP
많은 시스템 관리자들은 그들의 시스템이 모든 world-wide 규모 네트웍상의 모든 네트웍(그리고 시스템)에 reachable함을 보장하는데 필요한 일로 시간을 허비하고 싶지 않을 것이다. 그리하여, 그들은 모든 outgoing 메일을, 정말로 "smart"하다고 알려진 다른 시스템으로 relay 한다. RELAY_HOST는 그러한 이웃의 스마트 시스템의 UUCP 호스트네임을 정의한다. RELAY_MAILER는 그 곳으로 메시지를 relay하는데 사용되는 메일러를 정의한다. 이 파라미터들을 세팅하는 것이 당신의 outgoing 메일이 포워드되는 시스템의 로드에 영형을 주는 결과를 초래한다는 것에 주의해야한다는 일은 중요하다. 당신의 시스템이 다른 시스템을 일반적인 목적의 릴레이 호스트로 설정하기에 앞서, 리모트 Postmaster로 부터 따로 승인받기를 바란다. The Various Configuration Tables
define(ALIASES, LIBDIR/aliases)dnl # system aliases
define(DOMAINTABLE, LIBDIR/domaintable)dnl # domainize hosts
define(PATHTABLE, LIBDIR/pathtable)dnl # paths database
define(GENERICFROM, LIBDIR/generics)dnl # generic from addresses
define(MAILERTABLE, LIBDIR/mailertable)dnl # mailers per host or domain
define(UUCPTABLE, LIBDIR/uucpxtable)dnl # paths to hosts we feed
define(UUCPRELAYS, LIBDIR/uucprelays)dnl # short-circuit paths
이 매크로들은, 시스템의 sendmail+IDA가 "실제" 동작을 정의하는 여러 dbm파일을 찾을 위치를 변경할 수 있다.
일반적으로 볼때는, 그것을 LIBDIR에 그래로 남겨두는 편이 현명하다.
The Master Sendmail.mc File
include(Sendmail.mc)dnl # REQUIRD ENTRY !!!
Sendmail+IDA의 저자들은 sendmail.cf 파일이 되는 진짜 "알맹이"를 정의하는 Sendmail.mc 파일이라는 것을 제공한다.
주기적으로, full 릴리즈와 소스에서의 sendmail 재컴파일을 요하지 않고 bug fix 또는 기능이 추가된 새 버전이 릴리즈된다.
이 파일을 편집하지 않는다는 것은 중요하다 So Which Entries are Really Required? 옵션격인 dbm 테일블의 어떤 것도 사용하지 않을 때, sendmail+IDA는 sendmail.cf를 생성하는데 사용하는 sendmail.m4 파일에 정의된 DEFAULT_MAILER(RELAY_HOST, RELAY_MAILER도 가능하다)로 메일을 배달한다. domaintable이나 uucpxtable 내의 엔트리로 이러한 동작을 쉽게 override할 수 있다. 인터넷 상에서 Domain Name Service를 사용하는 일반 사이트, 또는 오직 UUCP만을 사용하여 스마트 RELAY_HOST를 통해 UUCP로 모든 메일을 포워드하는 사이트들은, 아마도 특정 테이블 엔트리를 전혀 필요로 하지 않을 것이다. 이론적으로 모든 시스템은 canonical 사이트 네임과 앨리어스를 정의하는 DEFAULT_HOST와 PSEUDONYMS 매크로를 지정해줘야 한다. 그러나 만약 당신이 쓸 수 있는 것이 오직 릴레이 호스트와 릴레이 메일러 뿐이라면, 그것들이 알아서 잘 동작하므로 이러한 디폴트들을 지정해 주지 않아도 된다. 아마도 UUCP 호스트들은 UUCPNAME을 그들의 공식 UUCP 네임으로 지정해 줘야 할 것이다. 또한 메일 릴레이를 통한 스마트 호스트 라우팅을 가능하게하는 RELAY_MAILER와 RELAY_HOST 역시나 지정해줘야 한다. 사용되는 메일 transport는 RELAY_MAILER에 정의되며 UUCP 사이트의 경우 보통 UUCP-A가 들어간다. 당신의 사이트가 SMTP만을 사용하여 'Domain Name Service'를 이용한다고 할 땐, DEFAULT_MAILER를 TCP-A로 고치고, RELAY_MAILER와 RELAY_HOST라인을 삭제하면 된다.
15.4 A Tour of Sendmail+IDA Tables sendmail+IDA는 sendmail의 디폴트 동작(sendmail.m4파일에 정의된)을 override하고 독특한 상황, 리모트 시스템, 그리고 네트웍에대한 특수한 동작을 정의하도록 허용하는 몇가지 테이블을 제공한다. 이들 테이블은 배포판과 함께 제공되는 Makefile을 이용하여 후처리(post-process)된다. 대부분의 사이트에선 이들 테이블이 거의 필요치 않다. 만일 당신의 사이트가 이 테이블들을 요하지 않는다면, Makefile 자체를 에디트하는 것보단, LIBDIR 내의 디폴트 Makefile을 그대로 사용하고, 테이블을 zero length 파일(touch 커맨드를 사용하여)로 만들어 두는 것이 가장 쉬운 방법일 것이다. mailertable은, 리모트 호스트나 네트웍 네임에 기반하여 특정호스트나 도메인에 대한 특수한 취급방식을 정의한다. 그것은 인터넷 사이트에서, 리모트 네트웍에 다다를 수 있게 중개 역할을 해주는 메일 릴레이 호스트나 게이트웨이를 고르고, 사용할 특정 프로토콜(UUCP나 SMTP)를 지정하는데 사용된다. 일반적으로 UUCP 사이트에선 이 파일을 사용할 필요가 없다. 순서는 중요한 요소이다. sendmail은 파일을 위에서 아래로 읽고 메시지가 일치하는 첫번째 룰에 따라 그것을 처리한다. 그러므로 명시적인 룰을 파일의 최상단에 위치시키고, 보다 일반적인 룰들을 아래에 놓는 것이 현명하다. Groucho Marx University의 Computer Science과에 대한 모든 메일을 릴레이 호스트인 ada에 UUCP로 포워드하길 원한다고 가정해보자. 그렇게 하려면 mailertable 엔트리를 다음과 같이 만들어 주자.
# (in mailertable)
#
# forward all mail for the domain .cs.groucho.edu via UUCP to ada
UUCP-A,ada .cs.groucho.edu
보다 큰 groucho.edu 도메인으로의 모든 메일이 릴레이 호스트인 bighub로 가서, 거기서 대신 address resolution과 delivery를 하길 원한다고 가정하자. 좀 더 확장된 mailertable 엔트리도 꽤 비슷하다.
# (in mailertable)
#
# forward all mail for the domain .cs.groucho.edu via UUCP to ada
UUCP-A,ada .cs.groucho.edu
#
# forward all mail for the domain groucho.edu via UUCP to bighub
UUCP-A,bighub .groucho.edu
위에 언급한대로, 순서는 중요하다. 위의 두 줄의 순서를 뒤바꾸면, .cs.groucho.edu로의 모든 메일이 실제로 원하는 명시적인 ada 경로 대신, 보다 일반적인 bighub 경로를 경유하게 되어버린다.
# (in mailertable)
#
# forward all mail for the domain .groucho.edu via UUCP to bighub
UUCP-A,bighub .groucho.edu
#
# (it is impossible to reach the next line because
UUCP-A,ada .cs.groucho.edu
#
위의 mailertable 예제에서, UUCP-A는 sendmail이 도메인화된 헤더와 함께 UUCP delivery를 사용하게 만든다. 메일러와 리모트 시스템간의 쉼표는 address resolution과 delivery를 위해 메시지를 ada로 포워드하고 알리는 역할을 한다. mailertable 엔트리는 다음의 포맷으로 이루어진다.
사용할 수 있는 몇가지 메일러가 존재하는데, 차잇점은 그것들이 주소를 어떻게 다루는지에 관한 것이다. 전통적으로 사용되는 메일러들로는, TCP-A(인터넷 스타일의 주소로의 TCP/IP), TCP-U(UUCP 스타일 주소로의 TCP/IP), 그리고 UUCP-A(인터넷 스타일 주소로의 UUCP)가 있다. mailertable 라인 왼쪽에서 메일러와 호스트를 구분하는 캐릭터(delimiter)는 그 주소가 mailertable에 의해 어떻게 수정되는지를 정의하는 역할을 한다. 중요한 것은, 이것이 단지 (리모트 시스템으로 메일을 보내기위해) envelope을 rewrite하기만 한다는 것을 인지하는 것이다. envelope 외의 것들을 rewrite하는 것은 메일 설정을 깨뜨릴 높은 가능성 때문에 곤란하다.
보통, FQDN으로 적힌 호스트로의 메일은 Domain Name Service (DNS)를 사용한 인터넷 스타일(SMTP) delivery로, 또는 릴레이 호스트를 통해 배달된다. uucpxtable은 도메인화된 네임을 UUCP 스타일의 도메인화 되지 않은 리모트 호스트네임으로 변환하여 UUCP 라우팅을 사용하여 배달하도록 강제한다. 그것은 당신이 한 사이트나 도메인에 대한 메일 포워더(forwarder)이거나, 잠재적으로 많은 hop을 갖고 있는 디폴트 메일러와 중개 시스템과 네트웍을 통하는 것보다 직접적이고 신뢰성있는 UUCP 링크로 메일을 보내고자 할 때 종종 사용된다. 도메인화된(domainized) 메일 헤더를 사용하는 이웃 UUCP와 통신하는 UUCP 사이트는, RELAY_MAILER와 RELAY_HOST를 통한, 또는 DEFAULT_MAILER를 통하는 덜 직접적인 루트를 사용하는 대신, 두 시스템간의 direct UUCP point-to-point 링크를 통하여 메일을 배달하도록 강제하는데, 이 파일을 사용한다. UUCP로 통신하지 않는 인터넷 사이트에선 uucpxtable을 사용할 필요가 없다. DNS에선 sesame.com, UUCP 맵에선 sesame인 시스템에 메일 포워딩 서비스를 제공한다고 가정해보자. 이 경우, 그 호스트에 대한 메일이 다이렉트 UUCP 커넥션을 통해 가게끔 강제하기 위해서 다음과 같은 uucpxtable 엔트리를 필요로 하게 될 것이다.
#============== /usr/local/lib/mail/uucpxtable =============
# Mail sent to joe@sesame.com is rewritten to sesame!joe and
# therefore delivered via UUCP
#
sesame sesame.com
#
#-----------------------------------------------------------
pathtable은 리모트 호스트들이나 네트웍들로의 별도의 라우팅을 정의하는데 사용된다. pathtable 파일은 패스앨리어스 스타일의 신택스로 적히고, 알파 �맻坪막� 정렬되어 있어야 한다. 각 라인의 두 필드는 TAB으로 나누어져야 하며, 그렇지 않은 경우 dbm이 불평하는 소릴 듣게 될 것이다. 대부분의 시스템에선 어떠한 pathtable 엔트리도 필요로 하지 않는다.
#=============== /usr/local/lib/mail/pathtable ================
#
# this is a pathalias-style paths file to let you kick mail to
# UUCP neighbors to hte direct UUCP path so you don't have to
# go the long way through your smart host that takes other traffic
#
# you want real tabs on each line or m4 might complain
#
# route mail through one or more intermediate sites to a remote
# system using UUCP-style addressing.
#
sesame!ernie!%s ernie
#
# forwarding to a system that is a UUCP neighbor of a reachable
# internet site.
#
swim!%s@gcc.groucho.edu swim
#
# The following sends all mail for two networks through different
# gateways ( see the leading '.' ?).
# In this example, "uugate" and "byte" are specific systems that serve
# as mail gateways to the .UUCP and .BITNET pseudo-domains repectively
#
%s@uugate.groucho.edu .UUCP
byte!%s@mail.shift.com .BITNET
#
#=================== end of pathtable =======================
domaintable은 일반적으로 DNS 검색이 일어난 후, 특정 동작을 강제하는데 사용된다. 그것은 자동으로 shorthand 네임을 적절할 것으로 교체함으로써, 흔히 언급되는 시스템이나 도메인에 대한 shorthand 네임을 관리자가 사용할 수 있게 만들도록 허용한다. 그것은 올바르지 않은 호스트나 도메인의 네임을 "올바른" 정보로 대체하는데에도 사용될 수 있다. 대부분의 사이트에선 domaintable 엔트리가 필요치 않을 것이다. 다음 예제는 사람들이 메일을 보내는 올바르지 않은 주소를, 어떻게 올바른 주소로 대체하는지를 보여준다.
#============= /usr/local/lib/mail/domaintable =================
#
#
brokenhost.correct.domain brokenhost.wrong.domain
#
#
#=================== end of domaintable ========================
앨리어스를 사용해서 할 수 있는 일이 몇가지 있다.
모든 시스템은 RFC에 따르기 위해 Postmaster와 MAILER-DAEMON에 대한 앨리어스를 요한다. 프로그램을 호출하거나 프로그램에 쓰는 앨리어스를 정의할 땐, sendmail이 root로 setuid되어 돌기 때문에 보안에 극도로 주의해야 한다. aliases 파일의 변화는 다음의 커맨드를 실행하기 전엔 영향을 미치지 않는다.
# /usr/lib/sendmail -bi
이는 필요한 dbm 테이블을 build한다. 보통 cron에서 실행되는 newaliases 커맨드를 쓸 수도 있다. 메일 앨리어스에 관한 세부 사항은 aliases(5) 매뉴얼 페이지에 있다.
#--------------------- /usr/local/lib/mail/aliases ------------------
#
# demonstrate commonly seen types of aliases
#
usenet: janet # alias for a person
admin joe,janet # alias for several people
newspak-users :include:/usr/lib/lists/newspak
# read recipients from a file
changefeed: | /usr/local/lib/gup # alias that invokes a program
complaints: /val/log/complaints # alias that writes mail to a file
#
# The following two aliases must be present to be RFC-compliant.
# It is important to have them resolve to 'a person' who reads mail routinely.
#
postmaster: root # required entry
MAILER-DAEMON: postmaster # required entry
#
#--------------------------------------------------------------------
다음의 테이블들은 사용가능하나, 자주 사용되진 않는 것들이다. 세부사항을 위해선 sendmail+IDA 소스에 들어있는 문서를 참고하라.
이 절에선 어떻게 보편적인 sendmail+IDA 바이너리 배포판을 설치하는지를 살펴보고, 그것을 로컬에 적합하고 올바른 기능을 수행하게 만드는데 필요한 것을을 검토한다. 리눅스용 sendmail+IDA의 바이너리 배포판의 현재버전은 sunsite.unc.edu의 /pub/Linux/system/Mail 내에서 얻을 수 있다. 이미 당신이 sendmail의 이전버전을 갖고 있다 하더라도, sendmail5.76b+IDA1.5 버전으로 바꾸기를 강력하게 권고한다. 왜냐하면 필요한 모든 리눅스 특정 패치들이 이제 vanilla 소스에 있으며, 1993년 12월 1일 이전에 있었던 보안 구멍을 막아두었기 때문이다. 당신이 소스에서 sendmail을 build하고자 한다면, 소스 배포판에 포함된 README의 지시에 따라야 한다. 현재 버전의 sendmail+IDA 소스는 vixen.cso.uiuc.edu에서 구할 수 있다. sendmail+IDA를 리눅스에서 build하고자 한다면, newspak-2.2.tar.gz의 리눅스 특정 설정파일들이 필요한데, 그것은 sunsite.unc.edu의 /pub/Linux/system/Mail 디렉토리에서 구할 수 있다. 이전에 smail이나 그 외의 mail delivery agent를 설치해 놓았다면, 안전을 위해 smail의 모든 파일을 제거(또는 rename) 해주면 된다. 15.5.1 Extracting the binary distribution 먼저 안전한 장소에 압축 파일을 푼다.
$ gunzip -c sendmail5.65b+IDA1.5+mailx5.3b.tgz | tar xvf -
당신이 최근의 슬랙웨어 배포판에 있는 것 같은 "modern" tar를 갖고 있다면, tar -zxvf filename.tgz라 해주어도 같은 결과를 얻을 수 있다. 압축 파일을 풀면 sendmail5.65b+IDA1.5+mailx5.3b라는 디렉토리가 생성된다. 이 디렉토리엔 sendmail+IDA의 완전 설치판과 mailx 유저 에이전트가 들어 있다. 이 디렉토리 하의 모든 파일 패스는 파일이 설치되는 위치에 반영되므로, 그것들을 옮기는데 tar 커맨드를 쓰는 것이 안전하다.
# cd sendmail5.65b+IDA1.5+mailx5.3b
# tar cf - . | (cd /; tar xvvpoof -)
당신의 사이트에 알맞게끔 sendmail.cf 파일을 build하려면, sendmail.m4 파일을 작성하여 그것을 m4로 처리해야한다. /usr/local/lib/mail/CF에서 sendmail.m4란 샘플 파일을 얻을 수 있다. 그것을 yourhostname.m4로 복사하고, 당신의 사이트에 알맞게끔 편집하라. 이 섹션에서는 당신이 변경해야할 매크로에대한 개략적인 설명만을 한다. 그것이 어떤 일을 하는지를 완전하게 알고 싶다면, sendmail.m4에대해 이전에 논했던 부분을 참고하라.
sendmail.cf 파일을 만들기 위해선 다음의 커맨드를 실행하라.
# make yourhostname.cf
이는 yourhostname.m4 파일을 처리하여 yourhostname.cf 파일을 생성한다. 다음으로, 당신이 만든 설정파일이 기대하는대로 동작하는지를 테스트해야하는데, 이는 다음의 두 섹션에서 설명할 것이다. 만든 설정파일의 동작에 만족한다면, 그것을 제 위치에 복사하라.
# cp yourhostname.cf /etc/sendmail.cf
이제 당신의 sendmail 세스템을 작동시킬 준비가 다 되었다. 다음의 라인을 적절한 startup 파일(보통 /etc/rc.inet2)에 집어넣자. 물론 지금 프로세스가 구동되게 손수 실행시킬 수도 있다.
# /usr/lib/sendmail -bd -q1h
15.5.3 Testing the sendmail.cf file sendmail을 테스트 모드로 돌리기 위해선 -bt 플래그를 주고 실행하면 된다. 디폴트로 지정된 설정파일은 시스템에 설치된 sendmail.cf 파일이나, -Cfilename 옵션으로 다른 파일을 테스트 할 수도 있다. 다음의 예제에선, 그림 15.2의 vstout.m4에서 생성된 설정파일인 vstout.cf를 테스트한다.
# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
>
다음의 테스트는 sendmail이 모든 메일을 당신 시스템의 유저들에게 배달할 수 있음을 보장한다. 모든 경우에, 테스트의 결과는 동일하고, LOCAL 메일러를 사용하는 로컬 시스템 네임을 가리킬 것이다.
첫번째로, 로컬 유저에게 메일이 잘 배달 되는지를 테스트한다.
# /usr/lib/sendmail -bd -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
>3,0 me
rewrite: ruleset 3 input: me
rewrite: ruleset 7 input: me
rewrite: ruleset 9 input: me
rewrite: ruleset 9 returns: < me >
rewrite: ruleset 7 returns: < > , me
rewrite: ruleset 3 returns: < > , me
rewrite: ruleset 0 input: < > , me
rewrite: ruleset 8 input: < > , me
rewrite: ruleset 20 input: < > , me
rewrite: ruleset 20 returns: < > , @ vstout . vbrew . com , me
rewrite: ruleset 8 returns: < > , @ vstout . vbrew . com , me
rewrite: ruleset 26 input: < > , @ vstout . vbrew . com , me
rewrite: ruleset 26 returns: $# LOCAL $@ vstout . vbrew . com $: me
rewrite: ruleset 0 returns: $# LOCAL $@ vstout . vbrew . com $: me
위의 출력은 sendmail이 어떻게 내부적으로 주소를 처리하는지를 보여준다. ruleset에 주소를 넘겨주면 그것은 다른 ruleset을 차례로 호출하여 분석하고, 컴포넌트 단위로 잘게 나눈다. 예제에서 우리는 me라는 주소를 ruleset 3와 0에 넘겨 주었다. (이는 주소 이전에 적은 3,0의 의미이다). 마지막 라인은 메시지를 배달하는 메일러와, 메일러에 준 호스트와 유저네임이 포함된 주소를 ruleset 0에서 리턴한 값으로 보여준다. 다음으로, UUCP syntax로 적힌, 시스템의 유제에대한 메일을 테스트 해보자.
# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
>3,0 vstout!me
rewrite: ruleset 3 input: vstout ! me
[...]
rewrite: ruleset 0 returns: $# LOCAL $@ vstout . vbrew . com $: me
>
다음으로, FQDN 형식의 호스트네임을 사용하여 인터넷 형식의 주소로 적힌, 당신 시스템으로의 메일을 테스트해보자.
# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
>3,0 me@vstout.vbrew.com
rewrite: ruleset 3 input: me @ vstout . vbrew . com
[...]
rewrite: ruleset 0 returns: $# LOCAL $@ vstout . vbrew . com $: me
>
sendmail.m4 파일의 PSEUDONYMS와 DEFAULT_NAME 파라미터에 지정한 각 네임에 대하여서도 위의 두 테스트를 반복해야 한다. 마지막으로, 릴레이 호스트로 메일을 보낼 수 있는지를 테스트 해보자.
# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
>3,0 fred@moria.com
rewrite: ruleset 3 input: fred @ moria . com
rewrite: ruleset 7 input: fred @ moria . com
rewrite: ruleset 9 input: fred @ moria . com
rewrite: ruleset 9 returns: < fred > @ moria . com
rewrite: ruleset 7 returns: < @ moria . com > , fred
rewrite: ruleset 3 returns: < @ moria . com > , fred
rewrite: ruleset 0 input: < @ moria . com > , fred
rewrite: ruleset 8 input: < @ moria . com > , fred
rewrite: ruleset 8 returns: < @ moria . com > , fred
rewrite: ruleset 29 input: < @ moria . com > , fred
rewrite: ruleset 29 returns: < @ moria . com > , fred
rewrite: ruleset 26 input: < @ moria . com > , fred
rewrite: ruleset 25 input: < @ moria . com > , fred
rewrite: ruleset 25 returns: < @ moria . com > , fred
rewrite: ruleset 4 input: < @ moria . com > , fred
rewrite: ruleset 4 returns: fred @ moria . com
rewrite: ruleset 26 returns: < @ moria . com > , fred
rewrite: ruleset 0 returns: $# UUCP-A $@ moria $: < @ moria . com > , fred
>
15.5.4 Putting it all together - Integration Testing sendmail.cf and the tables 이제, 메일이 원하는 디폴트 동작을 수행하고, 주소화가 적절히 된 메일을 송수신 할 수 있다는 것을 확인하였다. 설치를 완료하기위해선, 원하는 최종 결과를 얻기위해 적절한 dbm 테이블을 생성해야할 필요가 있다. 당신 사이트에 필요한 테이블을 생성한 후, 테이블이 들어있는 디렉로리에서 make를 입력하여 dbm이 그것을 처리하게 해주어야한다. UUCP만을 사용한다면, README.linux에서 언급하는 어떠한 테이블도 만들 필요가 없고, 그저 Makefile이 동작하게끔 그 파일들을 touch해주기만 하면된다. UUCP만을 사용하면서 스마트 호스트외의 호스트들과도 교신한다면, 그 각각에 대한 uucpxtable 엔트리를 추가해 주어야 하고(그렇지 않을 경우 그들로의 메일은 스마트 호스트로 가버리게 된다), 교정된 uucpxtable에대해 dbm을 돌려야 한다. 먼저, 당신은 RELAY_HOST를 통과하는 메일이 RELAY_MAILER를 써서 보내는지를 확인해야한다.
# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
>3,0 fred@sesame.com
rewrite: ruleset 3 input: fred @ sesame . com
rewrite: ruleset 7 input: fred @ sesame . com
rewrite: ruleset 9 input: fred @ sesame . com
rewrite: ruleset 9 returns: < fred > @ sesame . com
rewrite: ruleset 7 returns: < @ sesame . com > , fred
rewrite: ruleset 3 returns: < @ sesame . com > , fred
rewrite: ruleset 0 input: < @ sesame . com > , fred
rewrite: ruleset 8 input: < @ sesame . com > , fred
rewrite: ruleset 8 returns: < @ sesame . com > , fred
rewrite: ruleset 29 input: < @ sesame . com > , fred
rewrite: ruleset 29 returns: < @ sesame . com > , fred
rewrite: ruleset 26 input: < @ sesame . com > , fred
rewrite: ruleset 25 input: < @ sesame . com > , fred
rewrite: ruleset 25 returns: < @ sesame . com > , fred
rewrite: ruleset 4 input: < @ sesame . com > , fred
rewrite: ruleset 4 returns: fred @ sesame . com
rewrite: ruleset 26 returns: < @ sesame . com > , fred
rewrite: ruleset 0 returns: $# UUCP-A $@ moria $: < @ sesame . com > , fred
>
RELAY_HOST가 아닌, UUCP neighbor가 있다면, 그들로의 메일이 적절히 동작하는지 확인할 필요가 있다. UUCP로 교신하는 호스트로의 UUCP-style syntax로 주소가 적힌 메일은 반드시 직접 그들에게로 가야할 것이다 (그렇지않다면 따로 domaintable 엔트리에 지정해 줌으로써 그것을 방지해야 한다). swim이 직접 연결되는 neighbor UUCP라고 가정해보자. 그러면 swim!fred를 sendmail에 주면 다음의 결과가 나올 것이다.
# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
>3,0 swim!fred
rewrite: ruleset 3 input: swim ! fred
[...lines omitted...]
rewrite: ruleset 0 returns: $# UUCP $@ swim $: < > , fred
>
만약 인터넷 스타일로 도메인화한 헤더를 써서 메일을 보내는 특정 neighbor UUCP에, UUCP delivery를 강제하기위한 uucpxtable 엔트리들을 넣어두었다면 그것 또한 테스트 해보아야 한다.
# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
>3,0 dude@swim.2bird.com
rewrite: ruleset 3 input: dude @ swim . 2bird . com
[...lines omitted...]
rewrite: ruleset 0 returns: $# UUCP $@ swim . 2birds $: < > , dude
>
15.6 Administrivia and Stupid Mail Tricks 지금까지 우리는 sendmail+IDA 시스템의 설정과 설치, 그리고 테스트에관한 이론을 얘기하였다. 이제 잠시간 메일관리자의 일상에서 일어나는 일들을 들여다보도록 하자. 리모트 시스템은 때때로 멈춘다. 모뎀 또는 전화라인은 끊어지고, DNS는 인간의 실수로인해 올바르지않은 설정으로 정의되기도 한다. 그 뿐 아니라 네트웍은 갑자기 다운된다. 이러한 경우, 메일관리자는 어떻게하면 리모트 시스템 또는 서비스 제공자가 정상적인 서비스를 할 수 있을 때까지, 빠르고 효과적이면서도 안전하게 메일이 다른 루트를 통해 흘러가도록 조치하는지를 알아야할 필요가 있다. 이 장의 나머지 부분은 가장 자주 부닥칠 수 있는 "electronic mail emergencies"에 대한 해답을 제시하고자 한다. 15.6.1 Forwarding Mail to a Relay Host 특정 호스트 또는 도메인에 대한 메일을 명시된 릴레이 시스템으로 포워드하기 위해선, 주로 mailertable을 사용한다. 예를 들어, backwood.org에 대한 메일을, 그것의 UUCP 게이트웨이 시스템인 backdoor로 포워드하여면 다음의 엔트리를 maildertable에 넣으면 된다.
UUCP-A,backdoor backwood.org
15.6.2 Forcing Mail into Misconfigured Remote Sites 흔히, 인터넷 호스트들은 잘못 설정된 리모트 사이트에 메일을 넣는 문제에 빠진다. 이러한 문제점엔 여러 유형이 있으나, 일반적인 증상은 메일이 리모트 호스트에의해 bounce되거나, 전혀 그 곳에 도착하지 않는 것이다. 이러한 문제는 로컬 시스템 관리자를 좋지않는 입장에 빠뜨리는데, 그 이유는 당신이 world-wide의 모든 시스템을 개인적으로 관리하지 않는다는 점에대해(또는, 그 문제를 바로잡기위해 리모트 관리자와 어떻게 연락을 취할지 아는가에대해) 유저들은 보통 신경을 쓰지 않는다는 점이다. 그들은 그저 메일이 다른쪽편의 원하는 수신인에게 배달이 되지 않는다는 것과, 이에대한 불평을 해야될 사람이 당신이란 것을 알 뿐이다. 리모트 사이트의 설정은 그들의 문제이지, 당신이 상관할 일이 아니다. 모든 경우에 있어서 틀림없는 것은, 잘못 설정된 리모트 사이트랑 통신하기위해서 당신 사이트를 망가뜨리는 일따위는 해선 안된다는 것이다. 만약 리모트 사이트의 Postmaster에게 빠른시일내에 그들의 설정을 바로잡으라고 연락을 취할 수 없다면, 당신은 두가지를 선택할 수 있다.
15.6.3 Forcing Mail to Transferred via UUCP 이상적인 세계에서 (인터넷의 관점으로), 모든 호스트는 Domain Name Service (DNS)에 레코드를 갖고 있고 FQDN을 사용하여 메일을 보낼 것이다. 그러한 사이트에 UUCP로 교신해야할 일이 있다면, 원초적으로 uucpxtable을 통해 호스트네임을 "undomainizing" 함으로써, 메일이 디폴트 메일러가 아닌 point-to-point UUCP 커넥션을 통해 가도록 강제할 수 있다. sesame.com으로 UUCP delivery를 강제하고자 한다면, uucpxtable에 다음을 집어넣으면 된다.
# un-domainize sesame.com to force UUCP delivery
sesame sesame.com
이의 결과로, sendmail은 (sendmail.m4파일의 UUCPNODES를 보고) 당신이 리모트 시스템에 직접 연결되었다고 결정하고, UUCP를 통해 배달될 메일을 queue할 것이다. Preventing Mail from Being Delivered via UUCP 그 반대의 경우도 있을 수 있다. 이따금씩, 자주 사용되지 않거나 신뢰성이 떨어지고 디폴트 메일러나 릴레이 호스트로 사용할 수 없는 것들과 UUCP 커넥션을 갖고 있을 수도 있다. 예를 들어, 시애틀 지역내엔 리눅스 배포판이 릴리즈 될 때 anonymous UUCP로 리눅스 배포판을 교환하는 여러 시스템들이 존재한다고 가정하자. 이들 시스템은 필요할 때만 UUCP 통신을 하므로, 여러개의 신뢰도가 아주 높은 hop(mail을 목적지 까지 릴레이 해주는 호스트들 - 역자주)들과 보통의 (그리고 언제나 사용가능한) 릴레이 호스트를 통해 메일을 보내는 편이 일반적으로 보다 빠르고 신뢰도가 높다. 직접 연결된 호스트로의 메일이 UUCP delivery되지않게 막는 일은 아주 쉽다. 만약 리모트 사이트가 FQDN을 가지고 있다면, domainxtable에 다음과 같은 엔트리를 하나 추가하면 된다.
# prevent mail delivery via UUCP to a neighbor
snorkel.com snorkel
이는 UUCP 네임을 FQDN으로 대체함으로써, sendmail.m4 파일내의 UUCPNODES라인과 매치되는 것을 막는다. 이 결과, 메일은 RELAY_MAILER와 RELAY_HOST (또는 DEFAULT_MAILER)를 사용하여 목적지로 가게 된다.
15.6.5 Running the Sendmail Queue on Demand queue된 메시지를 즉시 처리하기 위해선, 단순히 '/usr/lib/runq'를 치면 된다. 이는 적절한 옵션을 주고 sendmail을 소환함으로써, sendmail이 다음으로 스케줄된 실행을 기다리는 대신, 즉시 대기중인 job의 queue를 훑어보게 한다. 15.6.6 Reporting Mail Statistics 많은 사이트의 관리자들 (그리고 그들을 고용한 사람)은 로컬 사이트로, 로컬 사이트에서, 또는 로컬 사이트를 통하는 메일의 양에대해 관심이 있을 것이다. 메일 트래픽을 측정하는데는 몇가지 방법이 있다.
15.7 Mixing and Matching Binary Distributions 전자메일 transport agent와 delivery agent의 설정에 표준이란 없으며, "진짜 디렉토리 구조"라는 것도 없다. 따라서, 시스템의 모든 여러 단편(USENET 뉴스, 메일, TCP/IP)들이 로컬 delivery 프로그램 (rmail), 그리고 메일 전송 프로그램(sendmail 또는 smail)의 위치에 수긍하는지를 확인할 필요가 있다. strings 커맨드를 사용하여, 어떤 파일과 디렉토리를 예상하고 있는지를 결정할 수 있음에도 불구하고, 그러한 가설은 일반적으로 문서화 되어 있지 않다. 다음은 이전에 우리가 일반적으로 사용할 수 있는 리눅스 바이너리 배포판과 소스들 중에서 본 문제점들이다.
모든 메일 클라이언트 소스를 build하면서 생기는 문제점들을 경험하는 것 보단, 일반적으로 소프트링크를 걸어서 그것을 속이곤 한다.
15.8 Where to Get More Information sendmail에 대한 정보를 찾을 수 있는 곳은 도처에 널려있다. 그 목록을 원한다면, comp.answers에 정기적으로 포스팀되는 Linux MAIL Howto를 보라. 그것은 rtfm.mit.edu에서 anonymous FTP로도 구할 수 있다. 그러나 최종적인 장소는 sendmail+IDA 소스내이다. 소스 디렉토리내의 ida/cf 디렉토리를 보면 DBM-GUIDE, OPTIONS, 그리고 Sendmail.mc가 있을 것이다.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Other Chapters
1. Introduction to Networking | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Appendix
A. A Null Printer Cable for PLIP | |||||||||||||||||||||||||||||||||||||||||||||||||||||||