| ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
D.M.Z
CONTENT
PRE
NEXT
14.1 UUCP Setup 이 장에서는 smail의 셋업에 관해 간략하게 소개하고, 그것이 제공하는 기능에대해 간략하게 알아본다. smail은 그것의 동작방식에 있어선 sendmail과 흡사하기만, 그들의 설정파일은 완전히 별개의 것이다. 주 설정파일은 /usr/lib/smail/config이다. 당신 사이트에 특정 값을 반영하고자 한다면 반드시 이 파일을 편집해야한다. 당신이 오직 UUCP leaf사이트라면, 해야할 일은 상대적으로 적다. 그 외 라우팅과 전송 옵션을 설정하는 파일도 있는데, 이들에 관해서도 간략하게 다루어 볼 것이다. smail은 디폴트로 모든 인커밍 메일을 즉시 처리하여 배달한다. 만약 당신이 상대적으로 높은 traffic을 갖고 있다면, 그 대신 smail이 모든 메시지를 queue라는 것에 모은 다음, 일정간격으로 그것을 처리하게 만들 수 있다. TCP/IP 네트웍에서 메일을 핸들링할 때, smail은 종종 데몬 모드(daemon mode)로 실행된다: 시스템 부팅시에, 그것은 rc.inet2에서 소환되어, SMTP 포트(보통 25번 포트)에서 인커밍 TCP 커넥션을 기다리는 백그라운다에 자신을 집어 넣는다. 이는 당신이 많은 traffic 량을 가질 때, smail이 인커밍 커넥션 각각마다 개별적으로 구동되지 않으므로 매우 유익하다. 또 다른 방법은 inetd가 SMTP 포트를 관리하게하고, 이 포트로 커넥션이 있을때마다 smail을 띄운다. smail은 그것의 동작을 제어할 수 있는 많은 수의 플래그를 갖고 있다. 여기서 그것들을 세부적으로 다룬다고 해도 별로 도움이 되지 않을 것이다. 운 좋게도, smail은 rmail 또는 smtpd와 같은 그것의 특수 커맨드네임에의해 실행될 때 사용가능한, 몇가지 표준 작업 모드를 지원한다. 보통 이들 앨리어스는 smail 바이너리 자체에대한 심볼릭 링크이다. 그것들 대부분은 smail의 다양한 기능을 논의하면서 다시 만나게 될 것이다. 어떠한 상황에서도 smail에대한 두개의 링크가 존재해야한다. 그것은, 죽 /usr/bin/rmail과 /usr/sbin/sendmail이다. elm과 같은 유저 에이전트로 메일 메시지를 작성하여 보낼때, 메시지는 커맨드라인에 주어진 수취인 목록과 함께, rmail로 보내져 배달된다. UUCP로 메일이 올 때도 비슷한 일이 일어난다. 그러나 elm의 어떤 버전은 rmail> 대신 /usr/sbin/sendmail을 소환하므로, 웰 프롬프트에서 다음을 입력하라.
# ln -s /usr/local/bin/smail /usr/bin/rmail
@ ln -s /usr/local/bin/smail /usr/sbin/sendmail
만약 smail 설정을 보다 깊게 파고들고자 한다면, 매뉴얼 페이지 smail(1)과 smail(5)를 참조하라. 만약 그것이 당신이 선호하는 리눅스 배포판에 들어있지 않다면, smail의 소스에서 그것을 구할 수 있다.
UUCP만을 사용하는 환경에서 smail을 사용하려한다면, 기본 인스톨은 다소 간단한 편이다. 먼저, 위에서 언급한 rmail과 sendmail 심볼릭 링크가 존재하는지 여부를 확인하라. 만육 다른 사이트로부터 SMT{ batch를 받을 수도 있다고 생각한다면, rsmtp라는 링크를 smail에 걸어두어야 한다. Vince Skahan의 smail 배포판엔 샘플 설정파일이 들어있다. 그것의 이름은 config.simple이며 /usr/lib/smail에 들어있다. 이것을 config으로 카피하고, 당신의 사이트에 지정하고자 하는 값으로 편집해야한다. 당신의 사이트가 swim.twobirds.com라는 이름이고, UUCP 맵에 swim으로 등록되어 있으며, 스마트 호스트는 ulysses라고 가정하자. 그러면 당신의 config파일은 다음과 같은 모습을 보일 것이다.
#
# Our domain name
visible_domain=two.birds:uucp
#
# Our name on outgoing mails
visible_name=swim.twobirds.com
#
# Use this as uucp-name as well
uucp_name=swim.twobirds.com
#
# Our smarthost
smart_host=ulysses
젓번째 구문은 당신의 사이트가 속한 도메인에 관해 smail에 말해준다. 그것들의 이름을 콜론으로 구분하여 집어넣는다. 만약 당신의 사이트가 UUCP 맵에 등록되어 있다면, uucp 역시 추가해 주어야 한다. 메일 메시지를 넘겨받을때 추가해 주어야 한다. 메일 메시지를 넘겨받을 때 smail은 hostname(2) 시스템 콜을 사용하여 당신 호스트의 네임을 얻어내고, 이 호스트 네임에 대해 수취인의 주소를 체크하여, 이 리스트에서 차례로 모든 네임을 덧붙인다. 만약 그 주소가 이들 네임중 어느 것 또는 공인되지 않은 호스트네임과 일치한다면, 수취인은 로컬에 있는 것으로 간주되어 smail은 로컬 호스트의 유저나 앨리어스로 메시지를 배달하려 할 것이다. 반면 그렇지 않을 경우, 수취인은 리모트로 간주되며 목적지 호스트로의 배달을 시도할 것이다. visible_name은 외부로 보내는 메일에서 사용하는 당신 사이트의 FQDN만을 포함한다. 이 네임은 외부로 나가는 모든 메일에 송신인의 주소를 생성하는데 사용된다. 당신은 로컬 호스트를 가리키고있다고 smail이 인식할 수 있는 네임(즉, visible_domain 속성에 나열된 도메인들 중의 하나를 쓴 호스트네임)을 사용하였는지 확인해야한다. 그렇지 않다면, 당신의 메일에대한 답장은 당신사이트로 되돌아 올 것이다. 마지막 선언문은 스마트 호스트 라우팅(13.4절에서 논한바 있다)에 대한 패스를 지정한다. 위의 예제의 설정으로, smail은 리모트 호스트에 대한 모든 메일을 스마트 호스트로 포워드한다. smart-path 속성에 지정한 패스는 스마트 호스트로의 루트로써 사용된다. UUCP로 메시지가 배달되기 때문에, 그 속성은 당신의 UUCP 소프트웨어가 알고 있는 시스템으로 지정되어야만 한다. 어떤 사이트를 UUCP에게 알려주는 것은 chapter 12에서 논하고 있으니 참조하기 바란다. 위 파일에서, 우리는 아직 언급하지 않았던 옵션, 즉 uucp-name을 사용했음을 볼 수 있을 것이다. 이 옵션을 사용하는 이유는, smail이 디폴트로 From_ 헤더라인에 주어진 리턴패스와 같은 UUCP 특유의 것을위해 hostname(2)에서 리턴된 값을 사용한다. 만약 당신의 호스트니엠이 UUCP 매핑 프로젝트에 등록되어 있지 않다면, smail이 대신에 FQDN을 사용하게 만들어 주어야 한다. 이는 config 파일에 uucp-name을 추가함으로써 수행된다. /usr/lib/smail엔 또다른 파일이 존재하는데, 그 이름은 paths.sample이다. 그것은 path 파일이 어떠한 모습인지를 보여주는 예제이다. 그러나 당신이 둘 이상의 사이트에 메일링크를 갖고 있지 않다면, 필요치 않을 것이다. 하지만, 만약 그러하다면 직접 하나를 만들든지, 아니면 Usenet 맵에서 생성하든지 해야한다. path 파일에 관해선 이 장의 마지막 무렵에서 설명한다.
만약 LAN으로 둘 이상의 호스트와 연결된 사이트를 운영하고 있다면, 당신은 외부세계로의 UUCP 커넥션을 핸들하는 호스트를 하나 지명해주어야 한다. 당신 LAN 상의 호스트들 간에서도, TCP/IP를 통해 메일을 교환하길 원할 것이다. 다시 Virtual Brewery로 돌아가, vstout의 UUCP 게이트웨이로 셋업되어 있다고 가정해보자. 네트웍환경에선, 모든 유저의 메일박스를 다른 모든 호스트에 NFS로 마운트 된 싱글 파일 시스템에 두는 것이 최선이다. 이는 유저들이 그들의 메일을 이리저리 옮겨야할 필요 없이(좀 더 심한 경우, 매일 아침마다 새 메일을 보기위해 서너대의 머신을 체크해야 한다), 머신에서 머신으로 옮겨 다닐 수 있게 한다. 게다가 송신인 주소를, 메일을 적은 머신에대해 독립적으로 만들고자 할 것이다. 그것엔 호스트네임을 송신인 주소에 적는 대신 도메인 네임을 사용하는 것이 보통이다. 예를 들어, Janet이라는 유저는 janet@vale.vbrew.com대신, janet@vbrew.com가 되는 것이다. 우리는 아래에서, 어떻게 서버가 도메인 네임을 당신 사이트에 대한 적절한 네임으로 인식하도록 만드는지를 설명할 것이다. 모든 메일박스를 중앙 호스트에서 고뀯리하는 또 다른 방법은 POP(Post Office Protocol) 또는 IMAP.POP4뇁 사용하여 유저들이 단순한 TCP/IP 커넥션을 통해 그들의 메일 박스에 억세스하게 만드는 것이다. IMAP(Interactive Mail Access Protocol)은 POP과 비슷하나, 보다 일반적인 것이다. IMAP과 POP에 대한 서버와 클라이언트 양쪽 다 리눅스로 포팅되어 있으며, sunsite.unc.edu의 /pub/Linux/system/Network아래에서 구할 수 있다. 14.2.1 Writing the Configuration Files Brewery의 설정은 다음과 같이 동작한다: 메일서버 vstout 자신을 제외한 모든 호스트는 스마트 호스트 라우팅을 사용하여, outgoing 메일을 서버로 라우트한다. vstout 자신은 실제로 Brewery의 모든 메일을 라우트해 주는 진짜 스마트 호스트(이 호스트는 moria라 한다)로 outgoing 메일을 보낸다. vstout이 아닌 모든 호스트의 표준 config 파일은 이와 같다.
#
# Our domain:
visible_domain=vbrew.com
#
# What we name ourselves
visible_name=vbrew.com
#
# Smart-host routing: via SMTP to vstout
smart_path=vstout
smart_transport=smtp
이는 우리가 UUCP만을 사용하는 사이트에서 보았던 것과 아주 유사하다. 스마트 호스트로 메일을 보내는데 사용되는 전송의 주된 차이점은 물론 그것이 SMTP라는 점이다. visible_domain 속성은 smail이 outgoing 메일에 로컬 호스트네임대신 도메인 네임을 사용하게 만든다. UUCP 메일 게이트웨이인 vstout에서의 config 파일은 약간 다르다.
#
# Our hostnames:
hostnames=vbrew.com:vstout.vbrew.com:vstout
#
# What we name ourselves
visible_name=vbrew.com
#
# in the uucp world, we're known as vbrew.com
uucp_name=vbrew.com
#
# Smart transport: via uucp to moria
smart_path=moria
smart_transport=uux
#
# we're authoritative for our domain
auth_domains=vbrew.com
이 config 파일은 로컬 호스트 네임을 smail에 알려주는, 다른 체계를 사용한다. 그것에 도메인의 리스트를 주고, 시스템 콜로 호스트네임을 찾도록 하는 대신, 개별적으로 리스트를 지정한다. 위의 리스트는 fully qualified와 unqualified 호스트네임, 그리고 도메인 네임을 모두 포함한다. 이는 smail이 janet@vbrew.com을 로컬 추소라 인식하여 메시지를 janet에 배달하게 만든다. auth_domains 변수는 vstout이 관장하는 도메인을 명시한다. 즉, smail이 존재하지 않는 host가 적힌 host.vbrew.com이라는 주소로의 메일을 수신한다면, 그것은 그 메시지를 거부하고 송신인에게 되돌려 보낸다. 만약 이 엔트리가 존재하지 않는다면, 그러한 메시지는 스마트 호스트로 보내지고, 또 그것을 다시 vstout으로 되돌려 보내, 결국 그것은 최대 hop 카운트를 초과하여 대기될 것이다. 먼저 당신은 smail을 별도의 독립적인 데몬으로 돌릴 것인지, 혹은 SMTP 포트를 inetd가 관리하여 클라이언트로부터 SMTP 커넥션 요청이 있을 때마다 smail을 소환할 것인지를 결정해야한다. 보통, 메일 서버에서는 데몬으로 돌리길 제안하는데, 왜냐하면 이 편이 각 싱글 커넥션마다 smail을 다시, 또 다시 띄우는 것보다 로드가 훨씬 적게 걸리기 때문이다. 메일 서버가 대부분의 인커밍 메일을 직접 유저에게로 배달하기도 하기 때문에, 그외의 대부분 호스트에선 inetd를 선택하게 된다. 각 호스트에 어떠한 작업모드를 선택했건 간에, 다음의 엔트리가 /etc/services 파일에 있는지 확인해야 한다.
smtp 25/tcp # Simple Mail Transfer Protocol
이것은 SMTP 통신을 위해 smail이 사용할 TCP 포트번호를 정의한다. 25는 Assigned Numbers RFC에 정의된 표준번호이다. smail이 데몬모드로 돌아갈 때, 그것은 자신을 백그라운드에 집어넣고, SMTP 포트에서 일어날 커넥션을 기다린다. 커넥션이 생길 때 그것은 포크(fork)되어 상대편 프로세스와 SMTP 통신을 다루게 된다. smail 데몬은 보통 rc.inet2 스크립트에서 다음의 커맨드로 소환된다.
/usr/local/bin/smail -bd -q15m
-bd 플래그는 데몬 모드를 켜고, -q15m은 매 15분마다 메시지 큐의 메시지를 처리하게 만드는 역할을 한다. 만약 그 대신 inetd를 사용하고자 한다면, /etc/inetd.conf 파일에 다음의 라인을 넣자.
smtp stream tcp nowait root /usr/sbin/smtpd smtpd
smtpd는 smail 바이너리의 링크여야한다. 이엇을 추가한 다음 inetd에 HUP 시그널을 주어 inetd.conf를 다시 읽도록 해야한다는 것을 잊지말기 바란다. 데몬 모드와 inetd 모드는 상호 배타적이다. smail을 데몬 모드로 돌린다면, inetd.conf에 smtp 서비스에관한 어떠한 라인도 코멕트 아웃되어 있는지 확인해야한다. 마찬가지로 inetd가 smail을 관리하게 할 때로, rc.inet2가 smail 데몬을 구동시키지 않는지 확인해야한다.
14.3 If Your Don't Get Through... 당신이 인스톨한 것에 뭔가 잘못되어 있다 하더라도, 그 문제의 근원이 무엇인지 찾을 수 있게 도와주는 여러 기능이 있다. 그 첫번째 장소는 smail이 로그 파일이다. 그것들은 /usr/spool/smail/log에 있으며 각각 logfile과 paniclog라는 이름을 갖고 있다. 전자는 모든 트랜잭션을 나열하고, 후자는 선정 에러등에 관련된 에러 메시지를 나열한다. 일반적인 logfile 엔트리는 이와 같다.
04/24/94 07:14:04: [m0puwU8-00023UB] received
| from: root
| program: sendmail
| size: 1468 bytes
04/24/94 07:12:04: [m0puwU8-00023UB] delivered
| via: vstout.vbrew.com
| to: root@vstout.vbrew.com
| orig-to: root@vstout.vbrew.com
| router: smart_host
| transport: smtp
이는 root에서 root@vstout.vbrew.com으로의 메시지가 SMTP로 호스트 vstout에 잘 전달되었음을 보여준다. smail이 전달하지 못하는 메시지는 이와 비슷한 엔트리를 로그파일에 남기나, delivered 파트 대신 에러메시지가 들어간다.
04/24/94 07:14:04: [m0puwU8-00023UB] received
| from: root
| program: sendmail
| size: 1468 bytes
04/24/94 07:12:04: [m0puwU8-00023UB] root@vstout.vbrew.com ... deferred
(ERR_148) transport smtp: connect: Connect refused
위의 에러는 보편적으로, smail이 vstout으로 전달할 메시지를 적절히 인식했으나 vstout의 SMTP 서비스에 연결할 수 없는 상황에대한 것이다. 이 경우는 설정상의 문제이거나, smail 바이너리에 TCP 지원기능이 빠져있는데서 초래된다. 이러한 문제는 상식적으로는 생각해 낼 수 없는 것으로, TCP/IP 네트워킹에대한 지원을 하지 않도록 컴파일된 smail 바이너리가, 심지어는 몇몇 리눅스 배포판에도 존재한다. 만약 당신이 이러한 경우에 해당된다면, 당신 머신의 SMTP 포트에 텔넷을 하여 TCP 네트워킹이 지원되는지 체크할 수 있다. SMTP 서버에 성공적으로 연결한 것은 아래와 같다( 당신의 입력은 기울임 꼴로 표시한 것이다):
$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
220 monad.swb.de Smail3.1.28.1 #6 ready at Sun, 23 Jan 94 19:26 MET
QUIT
221 monad.swb.de closing connection
이 테스트에서 SMTP 배너(220코드로 시작하는 라인)가 출력되지 않는다면, smail을 컴파일하기전에 설정한 것이 정말로 올바른지 확인해야한다. smail의 컴파일에 관해선 아래에서 다룬다. 만약 smail이 생성하는 에러메시지에서 문제점을 찾을 수 없다면, 디버깅 메시지를 켜면된다. 디버깅메시지를 사용하려면, -d옵션을 주면되고, 그 옵션 뒤에 메시지 량의 레벨을 지정하는 수를 걱을 수도 있다(플래그와 숫자사이엔 공백이 없어야한다). 그러면 smail은, 무엇이 잘못되었는지에 관한 힌트를 주는, 자신의 작업과정을 스크린에 뿌릴 것이다. [사람들은 이런재미를 발견치 못한다:] 그 무엇도 당신을 도와줄 수 없다면, 커맨드라인에 -bR 옵션을 주어 Rouge모드로 smail을 소환할 수 있다. 매뉴얼 페이지는 이 옵션에관해 이와 같이 설명한다: "Enter the hostile domain of giant mail messages, and RFC standard scrolls. Attempt to make it down to protocol level 26 and back." 비록 이 옵션이 당신의 문제를 해결해 줄 수는 없을지라도, 이것에서 어떠한 안정과 위안을 느낄 수 있을 것이다. smail에 TCP 네트웍 지원기능이 빠져있다고 확신한다면, 소스를 구해야한다. 그것은 당신의 리눅스 배포판 CD-ROM에 들어 있을 것이나, 그렇지 않을 경우라도 FTP로 구할 수 있다. smail을 컴파일할 때 Vince Skahan의 newspak 배포본에서 설정파일 세트을 얻어서 시작하는 것이 최선이다. TCP 네트워킹 드라이버를 컴파일해 넣기 위해선 conf/EDITME의 DRIVER_CONFIGURATION 매크로를 bsd-network이나 arpa-network으로 지정해 주어야한다. 전자는 LAN 환경에 적합한 것이나, 인터넷을 위해선 arpa-network이 필요하다. 이 둘간의 차이점은 후자의 경우가 MX 레코드를 인식할 수 있는 BIND 서비스에대한 특수 드라이버를 갖고 있고, 전자는 그렇지 않다는 것이다.
위에서 언급한 적이 있지만, smail은 메시지를 즉시 전달하거나, 또는 그것을 나중에 처리하기위해 queue할 수 있다. 만약 메시지를 queue하도록 한다면, smail은 모든 메일을 메시지 디렉토리인 /var/spool/smail 아래로 저장한다. 그것은 별도로 시키지 않는한 그 메시지들을 처리하지 않는다. (이를 일컬어 "running the queue"라고 한다). config 파일의 delivery_mode 속성을 foreground, background, 또는 gueued중의 하나로 지정해주어 세가지 delivery mode중 하나를 선택할 수 있다. 이는 foreground에서(인커밍 메시지를 즉시 처리함), background에서(메시지는 수신 프로세스의 자식 프로세스에게 전달되며, 부모 프로세스는 fork시킨 뒤 즉시 종료한다), 그리고 queue되어 배달할 것인지를 선택한다. 만약 config 파일에 boolean 변수 queue_only가 지정되어 있다면, 이들 옵션에 관게없이 인커밍 메시지는 모두 queue된다. 메시지가 queue되도록 해놓는다면, 정기적으로 (10분 또는 15분마다) queue를 체크하는지도 확인해야한다. smail을 daemon mode로 돌릴경우, 커맨드 라인에 -g10m 옵션을 추가하여 매 10분마다 queue를 처리하게 해야한다. 다른 방법으로는, 이 인터벌로 cron에서 runq를 소한하는 것이 있는데, runq는 smail에대한 링크이다. smail에 -bp 옵션을 주어 현재 mail queue를 표시하게 할 수도 있다. 이와 비슷하게, mailq를 smail에 링크시키고 mailq를 실행할 수도 있다.
$ mailq -v
m0pvB1r-00023UB From: root (in /var/spool/smail/input)
Date: Sun, 24 Apr 94 07:12 MET DST
Args: -oem -oMP sendmail root@vstout.vbrew.com
Log of transactions:
Xdefer:
이는 하나의 메시지가 message queue에 있음을 보여준다. 트랜잭션 로그(tranaction log: mailq에 -v 옵션을 주었을때만 표시된다)는 그 메시지가 돼 전달되고 있지 않은지에 관한 부가적인 원인을 알려준다. 메시지를 배달하려는 시도가 아직 없었다면, 어떠한 트랜잭션 로그도 표시되지 않을 것이다. 메시지를 queue시키지 않을 경우에도, 이따금씩 smail은 일시적인 이유로인해 즉시 배달하지 못할 경우 메시지를 queue에 집어 넣는다. SMTP 커넥션의 경우, 이는 아마도 unreachable한 호스트일 것이다; 그러나 파일 시스템이 full일 때에도 메시지 배달이 연기될 수 있다. 그러므로 (runq를 써서) 매 시간마다 queue를 청소하 주어야하며, 그렇지 않을 경우 메시지는 영원히 queue에 머물러 있을 것이다.
14.5 Miscellaneous config Options config 파일에 지정할 수 일는 옵션이 꽤 많이 존재한다. 그것들은 유용하지만 smail을 돌리는데 근본적인 것이진 않으므로 여기서 그 전부를 논하는 대신, 단지 사용할 만한 몇가지들만 언급하도록 한다.
14.6 Message Routing and Delivery smail은 mail delivery를 router, director, transport 모듈(module)의 세가지 task로 나눈다. Router 모듈은 모든 remote address를 분석하여, 다음에 어떤 호스트에 어떤 transport를 사용하여 메시지를 보낼 것인지 결정한다. 링크의 성질에 따라, UUCP나 SMTP와 같은 다른 형태의 transport가 이용된다. Local address는 포워딩 또는 앨리어싱을 분석하는 director task에게 주어진다. 예를들어, 그 address는 앨리어스나 메일링리스트, 또는 다른 주소로 메일을 forward하고자 하는 유저의 것일 수 있다. 만약 그 결과가 remote address라면, 추가적인 라우팅을 위해 router 모듈로 넘겨지게되고, 그렇지 않다면 local delivery를 위해 transport 모듈에 할당된다. 대부분의 경우 메일박스로 전달될 것이나, 커맨드로 pipe되거나 임의의 파일에 덧붙여 질 수도 있다. 마지막으로 transport 모듈은 어떠한 delivery 방법을 선택할 것인지에 책임이 있다. 그것은 메시지를 전달하려 시도하고, 실패했을 경우 bounce 메시지를 생성하거나 이후에 다시 재시도 한다. smail에서는 이러한 task를 설정함에있어 많이 자유롭다. 그들 각각마다 많은 수의 드라이버들이 사용가능하며, 그것들에서 당신이 필요로 하는 것을 선택할 수 있다. /usr/lib/smail 내의 몇개의 파일, 즉 routers, directors, transports를 통해 smail에 알려주어야 한다. 만약 이러한 파일이 존재하지 않는다면 많은 사이트가 transport에 SMTP나 UUCP중의 하나를 사용하는데 적합하다고 디폴트로 간주된다. 만약 smail의 라우팅 방법을 변경하거나, transport를 수정하길 원한다면, smail 소스 배포판에서 샘플 파일을 얻어, 그 샘플 파일을 /usr/lib/smail에 복사하고 당신의 입맛에 따라 수정하라. 설정파일 예제는 Appendix B에 있다.
smail에 메시지를 주면, 그것은 메시지의 목적지가 로컬 호스트인지 리모트 사이트인지를 판별한다. 타겟 호스트 추소가 config에 설정된 로컬 호스트네임 중의 하나라면, 메시지는 director 모듈로 넘겨진다. 그 반대의 경우 smail은 목적지 주소를 몇몇 라우터 드라이버에 넘겨주어, 어떤 호스트에 메시지를 라우트할 것인지를 찾는다. 그들은 routers 파일에 수록되며, 이 파일이 없을 경우 디폴트 라우터 세트가 사용된다. 목적지 호스트의 주소는 모든 라우터에게 차례로 넘겨지고, 가장 특정한('좀 더 리모트 호스트 자체에 한정된'이라는 뜻임 - 역자주) 루트를 찾은 라우터가 선택된다. joe@foo.bar.com이라는 메시지 주소를 생각해 보자. 그러면 한 라우터는 bar.com 도메인 내 모든 호스트에 대한 디폴트 루트를 알고 있을 것이고, 또 다른 라우터는 foo.bar.com 자체에대한 정보를 갖고 있을 것이다. 이 경우, 후자의 경우가 더 특정하기 때문에 선택된다. 만약 "최선의 매치"를 제공하는 두개의 라우터가 있을 경우, routers파일에 먼저 적힌 것이 선택된다. 이 라우터는 이제 사용할 transport, 예를 들자면 UUCP를 선택하고 새로운 목적지 주소를 생성한다. 새로운 주소는 메시지를 포워드해주는 호스트를 따라 transport로 넘어간다. 위의 예제에서, smail은 foo.bar.com이 ernie!bert의 패스를 사용해 UUCP로 reachable하다는걸 알게 된다. 그러면 그것은 bert!foo.bar.com!user의 새로운 타겟을 생성하고, UUCP transport가 이를 envelope 주소로 사용하여 ernie에 넘겨주게 한다. 디폴트 세팅을 사용할 때, 다음의 라우터들이 사용가능하다.
이 디폴트는 단순한 셋업에 대해서 동작하나, 라우팅 요구가 좀 더 복잡해진다면 잘 동작하지 않는다. 만일 당신이 아래에 적힌 문제를 안고 있다면, 디폴트를 오버라이드하는 당신만의 routers 파일을 설치해 주어야 한다. 당신이 시작하는데 도와 줄 수 있는 샘풀 routers 파일은 Appendix B에서 싣고 있다. 몇몇 리눅스 배포판에서는, 이러한 어려움을 충족하게끔 맞춰진 설정파일 세트를 담고 있기도하다. 당신의 호스트가 다이얼업 IP와 UUCP 링크라는 이중의 세계에 존재할 때, 최악의 문제가 발생하지 않을까 한다. 이 경우 이따금씩 SLIP 링크를 통해서만 통신하는 호스트의 네임을 hosts 파일에 갖고 있을 것이므로, smail은 이 호스트에대한 메일을 SMTP로 배달하려할 것이다. 보통 이는 당신이 원치 않는 일일 것인데, 그 이유는 SLIP 링크가 정기적으로 활성화된다 하더라도 SMTP는 UUCP 상에서 메일을 보내는 것보다 훨씬 느리기 때문이다. 디폴트 셋업으론 smail에 탈출구는 없다. 이 문제점을 피하는 방법은, smail이 resolver에 query하기전에 pahts 파일을 체크하게 만들고, UUCP delivery로 강제하고 싶은 호스브를 paths에 넣는 것이다. 영원히 SMTP로 메일을 보내지 않을 작정이라면, resolver기반 라우터를 모두 comment out할 수도 있다. 또다른 문제점은, resolver 기반 라우터가 MX 레코드를 검토하지 않기 때문에, 디폴트 셋업이 실제 메일 라우팅에 대해서 준비되지 않았다는 점이다. 인터넷 메일 라우팅에대한 완전한 지원을 하기위해선, 이 라우터를 comment out하고, 그 대신 BIND를 사용하는 것을 uncomment하기 바란다. 그러나 몇몇 리눅스 배포판엔 BIND 지원 지능을 컴파일 해넣지 않은 smail 바이너리가 포함되어 있다. BIND를 켜 두었으나 "router inet-hosts: driver bind not found"라는 메시지가 paniclog에 남는다면, 소스를 얻어 smail을 재컴파일 해야한다(위의 14.2 섹션을 보라). 마지막으로, uuname 드라이버를 사용하는 것은 일반적으로 볼 때 좋은 생각이 아니다. 첫째로, 그것은 당신이 UUCP를 인스톨하지 않았을 때 uuname 커맨드가 존재하지 않으므로 설정에러를 내게된다. 둘째는 당신이 실제로 메일 링크를 가지고 있는 것보다 많은 사이트들이 UUCP System파일에 나열되어 있을 경우이다. 이들은 단순히 뉴스를 교환하거나 때때로 anonymous UUCP로 파일을 다운로드하지만 그 외의 경우에 대해선 traffic이 없는 사이트들일 수도 있다. 첫번째 문제에 대처하기 위해선, uuname 다신에 단순히 exit 0만을 하는 쉘 스크립트를 쓸 수 있다. 그러나 보다 일반적인 해결책은, routers 파일을 수정하여 이 모든 드라이버를 제거하는 것이다. smail은 /usr/lib/smail 아래에 패스 앨리어스 데이터베이스가 있다고 간주한다. 이 파일은 부수적인 것이므로, 패스 앨리어스 라우팅을 전혀 수행하지 않을 경우, 존재하는 paths 파일을 단순히 제거하면 된다. paths 파일은 목적지 사이트 네임을 UUCP bang path로 맵해주는 엔트리를 담은 정렬된 ASCII 파일이다. 그 파일은 정렬되어야만 하는데, 그 이유는 smail이 사이트를 찾는데 binary search를 사용하기 때문이다. 이 파일에 주석문의 사용은 허용되지 않으며, 사이트네임은 TAB을 구분으로 나뉘어야한다. 패스 앨리어스 데이터베이스에 관해선 이미 chapter 13에서 논한바 있다. 이 파일을 손수 만들고자 한다면, 사이트에 대한 합당한 네임들만이 포함되어 있는지 확인해야 한다. 예를 들어, 어떤 사이트가 평범한 UUCP 네임과 FQDN으로 알려져 있다면, 그들 각각에대한 엔트리를 추가해 주어야한다. 그 파일은 sort(1) 커맨드로 pipe하여 정렬할 수 있다. 그러나 당신 사이트가 단지 leaf 사이트라면 paths 파일은 전혀 필요 없다: 단지 config 파일에 스마트 호스트 속성만을 셋업해주고 모든 라우팅을 당신의 mail feed에 남기면된다.
14.8 Delivering Messages to Local Addresses 메시지가 메일박스, 즉 /var/spool/mail/user로 배달될 경우, 통상적으로 로컬 어드레스는 단지 유저의 로그인 네임이다. 앨리어스와 메일링리스트, 유저에의한 메일 포워드는 다른 경우에 속한다. 이 경우, 로컬 어드레스는 주소 목록으로 확장되며, 이는 리모트가 될 수도 로컬이 될 수도 있다. 이러한 "보통의" address와는 별개로, smail은 파일네임과 같은 다른 타입의 로컬 메시지의 목적지를 핸들하거나 커맨드로 파이프시킬 수 있다. 이는 address가 아니므로, 이를테면 /etc/passwd@vbrew.com에 메일을 보낼 수 없다; 그것들은 포워딩 파일이나 앨리어스 파일에 취해져야만 적합한 것이다. 파일네임은 슬래쉬(/)나 틸드(~)로 시작하는 것으로써, 틸드는 유저의 홈 디렉토리를 가리키며, 파일네임이 .forward 파일 또는 메일 박스 내의 포워딩 엔트리(아래를 보라)에서 주어질 때 가능한 것이다. 파일에 배달할 때 smail은 파일에 덧붙이고, 필요하다면 생성한다. 파이프 커맨드는 파이프 심톨(|)뒤에 붙은 UN*X의 커맨드이다. 이는 그 커맨드를 인자와 함께 쉘에 넘겨주게 하나, |는 앞에 붙이지 않는다. 메시지 자체는 표준 입력을 통해 커맨드에 주어진다. 예를 들어, 메일링 리스트를 로컬 뉴스 그룹으로 gate하고자 한다면, gateit이라는 쉘 수크립트를 사용하고, "--gateit"을 사용하여 이 메일링 리스트로부터의 모든 메시지를 스크립트로 배달하게 해주는 로컬 앨리어스를 셋업해 주어야한다. 만약 공백문자가 포함되어 있다면, 큰 따옴표로 싸 주어야한다. 보안상의 이유로, 의심스럽다고 생각되는 어떤 방법으로 주소가 얻어질 경우, 커맨드를 실행하지 않도록 조치가 취해진다. (예를 들어, 모든 이에게 쓰기가 허가딘 앨리어스 파일에서 주소가 얻어질 경우가 해당된다). 보통의 경우 로컬 어드레스는 유저의 메일박스를 지칭한다. 이 메일박스는 /var/spool/mail 내에 위치하는 유저네임과 같은 이름의 파일이다. 그것은 유저의 소유이고 mail 그룹에 속하며 660의 퍼미션 모드를 가지고 있다. 만약 그 파일이 존재하지 않는다면 smail은 새로 파일을 생성한다. /var/spool/mail이 현재 메일박스를 넣는 표준위치이긴 하지만 어떤 메일 소프트웨어는 다른 패스로, 예를 를어 /usr/spool/mail로 컴파일 될 수도 있다. 만약 당신 머신상의 유저로의 delivery 지속적으로 실패할 경우엔, 이를 /var/spool/mail로 심볼릭 링크를 시켜주는것도 도움이 될 수있다. smail은 반드시 두 개의 주소를 필요로 하는데, 그것은 MAILER-DAEMON과 Postmaster이다. 배달되지 못하는 메일에 대한 bounce 메시지가 만들어질때, (이것이 설정의 문제일 경우) postmaster 계정으로 carbon copy가 예로써 보내진다. MAILER-DAEMON은 bounce 메시지의 송신인의 주소로 사용된다. 만약 이 주소들이 당신 시스템의 계정으로 명시되어 있지 않다면, smail은 MAILER-DAEMON을 postmaster로, postmaster를 root로 각각 매핑한다. 이는 postmaster 계정을 메일 소프트웨어의 관리 책임자로 앨리어싱함으로써 오버라이드 될 수 있다. smail에서는 유저가 자신의 메일을 다른 주소로 포워드하여 메일을 리다이렉트시키는 두가지 방법을 지원한다. 한가지는 다음을
Forward to recipient,...
유저의 메일박스 첫 라인에 넣어두는 것이다. 이는 모든 인커밍 메일을 지정된 수취인 목록으로 보낸다. 또 다른 방법은, 유저의 홈 디렉토리에 .forward 파일을 생성하여, 수취인의 목록을 각각 쉼표로 구븐하여 넣어두는 것이다. 이 포워딩의 경우엔, 파일의 모든 라인을 읽고 해석한다. 어떠한 타입의 주소 형식도 쓰일 수 있다. 휴가 동안의 .forward 파일의 실전적인 예제는 다음과 같다.
janet, "|vacation"
첫번째 주소는 janet의 메일박스로 배달되고, vacation 커맨드는 송신인에게 짧은 알림말을 리턴한다.
smail은 Berkely의 sendmail과 호환되므로, 그것의 앨리어스 파일을 핸들링할 수 있다. 앨리어스 파일의 엔트리들은 다음의 형식을 취하고 있다.
recipients는 주소의 목록으로, 각 엔트리는 쉼표로 구분되며, 각각 앨리어스에 대응된다. 다음라인이 TAB으로 시작할 경우, recipient 리스트가 계속되는 것으로 취급한다. smail이 앨리어스 파일에서 메일링 리스트를 핸들할 수 있도록 하는 특수한 기능이 존재한다: ":include:filename"을 recipient란에 대입시키면, smail은 지정된 파일을 읽어 그것의 내용을 recipient 리스트로 대응시킨다. 주 앨리어스 파일은 /usr/lib/aliases이다. 만약 이 파일이 world-writable하다면 smail은 어떠한 메시지도 여기에 주어진 쉘 커맨드로 보내지 않을 것이다. 예제 파일은 아래와 같다.
# vbrew.com /usr/lib/aliases file
hostmaster: janet
postmaster: janet
usenet: phil
# The development mailing list.
development: joe, sue, mark, biff
/var/mail/log/development
owner-development: joe
# Announcements of general interest are mailed to all
# of the staff
announce: :include: /usr/lib/smail/staff,
/var/mail/log/announce
owner-announce: root
# gate the foobar mailing list ot a local newsgroup
ppp-list: "|/usr/local/lib/gateit local.lists.ppp"
alias 파일에서 생성된 주소로 메시지를 배달하는 과정에 에러가 발생한다면, smail은 "앨리어스 소유주"에게로 에러메시의 복사본을 보낸다. 예를 들어, 만약 development 메일링 리스트로 메시지를 배달할 때 biff로의 배달이 실패한다면, 에러메시지의 복사본이 postmaster와 owner-development, 그리고 송신인에게 메일로 보낸다. 만약 소유주의 주소가 존재하지 않는다면 추가적인 에러메시지는 발생되지 않는다. alias 파일에서 주어진 파일로 배달하거나 프로그램을 소환할 때, smail은 보안상 골치거리를 피하기위해 nobody 유저가 된다. 특히 파일로 배달할 때, 이는 정말 성가신 일일 수도 있다. 예를 들어, 위 파일에서 로그 파일은 nobody의 소유이며 쓰기 허가 되어 있어야한다. 그렇지 않다면 그 파일로의 delivery는 실패할 것이다. aliases 파일을 사용하는 대신, /usr/lib/smail/lists 디렉토리내의 파일에 의해서도 메일링리스트는 운영될 수 있다. nag-bugs라는 메일링 리스트는 lists/nag-bugs 파일에 적히는데, 이는 멤버의 주소를 위와 마찬가지로 각각 쉼표로 구분하여 포함한다. 리스트는 여러라인에 걸쳐 쓸 수 있으며, 해쉬 부호는 주석을 표시한다. 각 메일링 리스트마다, owner-listname이라는 유저(혹은 앨리어스)가 반드시 존재해야한다; 주소를 resolve할 때 일어나는 에러는 이 유저에게 보고된다. 이 주소는 outgoing 메시지 Sender: 헤더 필드내의 송신인 주소로 쓰이기도 한다.
UUCP 슈트를 활용하도록 smail에 컴파일 되어 들어가는 몇가지 transport가 존재한다. UUCP 환경에서 메시지는 다음 호스트의 rmail을 호출함으로써 넘겨진다. 이 때 메시지는 표준 입력으로, envelope 주소는 커맨드 라인으로 주어진다. 당신의 호스트 상에서, smail 커맨드로 rmail이 링크되어 있어야 한다. UUCP transport로의 메시지를 핸들링할 때, smail은 타겟 주소를 UUCP bang path로 변환한다. 예를 들어, user@host는 host!user로 변환된다. '%' 주소연산자가 존재하면 이는 보존되는데, 이를테면 user$host@gateway는 gateway!user%host가 된다. 그러나 smail 자신은 그런 주소를 절대 생성하지 않는다. smail은 UUCP로 BSMTP batch를 주고 받을 수도 있다. BSMTP로는 하나이성의 메시지가, 실제 SMTP 커넥션이 성립되었을 때 로컬 메일러가 쓸 커맨드를 포함한 단일 batch로 묶이게 돤다. BSMTP는 종종 store-and-forward(즉, UUCP 기반) 네트웍에서 디스크 공간을 줄이는데 사용된다. Appendix B의 샘플 transports 파일은 queue 디렉토리내에 부분적인 BSMTP batch를 발생시키도록 bsmtp라는 transport를 포함하고 있다. 그것들은 적절한 HELO와 QUIT 커맨드를 추가하는 쉘 스크립트를 사용하여, 최종 batch로 조합된다. 특정 UUCP 링크에대해 bsmtp transport를 사용하려한다면 method 파일(자세한 사항은 smail(5)를 참고하라)이라는 것을 사용해야한다. 오직 하나의 UUCP 링크만을 갖고 있고, 스마트 호스트 라우터를 사용한다면, smart_transport 설정 변수를 uux 대신 bsmtp에 지정해 주어 SMTP batch를 보내게 만들어 주어야 한다. UUCP 상에서 SMTP batch를 수신하기 위해선, batch를 보낼 리모트 사이트에 unbatching 커맨드가 있는지 확인해야한다. 만약 리모트 사이트도 smail을 사용한다면, smail에 rsmtp라는 링크를 만들어 줘야한다. 리모트 사이트가 sendmail을 돌린다면, 단순히 "exec rsmtp"만을 수행하는 /usr/bin/bsmtp라는 쉘 스크립트를 추가로 만들어주면 된다(심볼릭 링크는 동작하지 않는다).
현재 smail은 TCP 커넥션을 통해 메일을 배달하는 SMTP 드라이버를 지원한다. 싱글 호스트에 몇가지 다른 형태의 주소, 즉 FQDN으로 지정되어 네트워킹 소프트웨어에의해 reslove되거나, 또는 대괄호 내의 quad notation으로 호스트 네임을 지정하여 메시지를 보내는 것이 가능하다. 일반적으로 BIND나 gethostbyname(3), 또는 gethostbyaddr(3) 라우터 드라이버에의해 resolve된 주소는 SMTP transport로 배달된다. SMTP 드라이버는 즉시 /etc/services에 리스트된 smtp 포트를 통해 리모트 호스트에 연결을 시도한다. 만약 그것이 reachable하지 않거나, 커넥션 timeout이 일어난다면, 이후에 다시 배달을 재시도할 것이다. 인터넷 상에서의 mail delivery는 bang path가 아닌, chapter 13에서 논의한 route-addr 포맷으로 지정된 목적지 호스트로의 루트(route)를 필요로 한다. 그러므로 smail은 user%host@gateway라는 주소가 있고, gateway는 host1!host2!host3으로 reachable하다면, 그것을 source route 주소인 ¡@host2,@host3:user%host@gateway¿로 변환하여 이를 envelope 주소로 삼아 host1에 보낸다. 이러한 변환을 사용하려면(built0in BIND 드라이버에 따라), transports 파일 내에 smtp 드라이버에대한 엔트리를 수정해야한다. transports파일의 예제는 Appendix B에 있다.
때때로 송신인 또는 수신인 주소에 지정된 unqualified 호스트네임(즉 도메인 네임을 가지지 않는 것)을 catch할 필요가 있는데, 예를 들어 한 쪽에서 FQDN을 요하는 두 네트웍간에 gatewaying을 할 때가 그에 해당된다 하겠다. 인터넷 UUCP 릴레이상에선 unqualified 호스트 네임은 디폴트로 uucp로 매핑된다. 이들 외의 주소 수정은 미심쩍은 것이다. /usr/lib/smail/qualify파일은 smail에게 어느 호스트네임에 어느 도메인네임을 붙일지를 알리는 역할을 한다. qualify 파일 내의 엔트리는 첫번째 컬럼에서 시작하는 호스트네임과 그 뒤의 도메인 네임으로 이루어진다. 라인에서 공백이 아닌 첫번째 문자가 해쉬 기호라면 그것은 주석처리 된다. 각 엔트리는 나열된 순서대로 탐색된다. 만약 qualify 파일이 없다면, 호스트 네임 인증은 전혀 수행되지 않는다. * 기호는 어떠한 호스트네임과도 매치된다. 그리하여 앞에서 언급하지 않은 모든 호스트를 디폴트 도메인으로 매핑할 수 있다. 이는 마지막 엔트리로 사용되어야 한다. (만일 첫번째 엔트리로 이것이 쓰인다면 이 뒤에있는 보다 구체적인 엔트리들은 절대 탐색될 수 없다. - 역자주) Virtual Brewery에서 모든 호스트는 송신인 주소에 FQDN을 사용하도록 셋업되어 있다. 인증되지 않은 수신인 주소는 uucp 도메인으로 간주되므로, qualify 파일엔 단일 엔트리만이 필요하게 된다.
# /usr/lib/smail/qualify, last changed Feb 12, 1994 by janet
#
* uucp
| ||||||||||||
|
Other Chapters
1. Introduction to Networking | ||||||||||||
|
Appendix
A. A Null Printer Cable for PLIP | ||||||||||||