| ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
D.M.Z
CONTENT
PRE
NEXT
13.1 What is a Mail Message? 최초의 네트웍이 고안된 이래, 네트워킹을 사용함에 있어 가장 두드러진 것 중 하나는 바로 전자우편(electronic mail)이다. 처음에 그것은 한 머신에서 다른 곳으로 파일을 카피하여 수취인의 mailbox 파일에 덧붙이는 단순한 서비스에서 출발하였다. 기본적으로 이것은 여전히 email의 전부이다. 비록 계속 성장하고 있는 네트웍에서의 복잡한 라우팅 요구와, 계속 증가하는 메시지의 로드로 인한 보다 정교한 체계에대한 필요성에도 불구하고 말이다. 메일 교환에 대한 표준은 여러가지가 고안되었다. 인터넷상의 사이트들은 RFC822에서 설계하고, 특수 캐릭터를 머신 독립적인 방법으로 전송하는 법 등을 기술한 몇몇 RFC에서 확장된 안을 고수한다. 최근에 "멀티미디어 메일"이란 것도 많이 고려되는데, 이는 그림과 소리를 메일 메시지에 포함시키는 것이다. 또다른 표준인 X.400은 CCITT에서 정의하였다. UN*X 시스템을 위한 꽤 많은 수의 메일 전송 프로그램이 나왔는데, 그 중 가장 잘 알려진 것 하나가 바로 Berkeley 대학의 sendmail로, 많은 플랫폼에서 사용된다. 그 원 저자는 Eric Allman으로, 이제 또다시 sendmail 팀에서 일하고 있다. 두가지 sendmail-5.56c 리눅스 포트가 사용가능한데, 그 중 하나는 chapter 15에서 거론될 것이다. 현재 sendmail은 8.6.5로 발전하였다. 리눅스에서 통상적으로 사용되는 메일 에이전트는 smail-3.128로, Curt Landon Noll과 Ronald S. Karr가 쓰고 카피라이트를 갖고 있다. 이는 대부분의 리눅스 배포판에 포함되어 있는 것이다. 전반적으로 다른 구조를 가진 또다른 버전이 존재하지만, 앞으로는 그 버전을 smail이라고 언급할 것이다. sendmail에 비해 smail은 다소 젊은 편이다. 복잡한 라우팅 요구가 없는 소규모 사이브의 메일을 핸들링할 때 둘간의 능력차이는 별로 없어 보인다. 그러나 대규모 사이트의 경우, sendmail의 설정체계가 훨씬 유연성있기 때문에 월등한 능력차이를 보인다. smail과 sendmail 양쪽 모두 커스터마이즈할 수 있는 설정파일 세트를 지원한다. 메일 서브시스템을 동작하게하는데 필요한 정보와는 별개로(로컬 호스트 네임같은), 조절할 수 있는 많은 파라미터가 존재한다. sendmail의 주 설정파일은 처음엔 이해하기 상당히 어렵다. 그것은 마치 당신의 고양이가 쉬프트 키를 누른채 키보드를 두들겨댄 것처럼 보인다. smail 설정파일은 sendmail의 그것보다 체계적이고 이해하기도 쉬우나, 유저에게 mailer의 동작을 조절할 권한을 많이 주진 못한다. 그러나 소규모 UUCP나 인터넷 사이트에서는 그들 중 어떤것을 쓰든지 거의 비슷하다. 이 장에서 우리는 무엇이 email이고, 무엇이 관리자로써 다루어야할 이슈인가를 다룬다. chapter 14와 15는 처음 접하는 사람들을 위해 smail과 sendmail을 셋업하는 방법을 가르쳐준다. 그것이 제공하는 정보가 소규모 사이트에선 충분한 것이나, 그 보다 더 많은 옵션들이 존재하며, 환상적인 기능을 설정하는데 수 많은 행복한 시간들을 컴퓨터 앞에서 써버릴 것이다. 이 장의 끝까지 우리는, 리눅스를 포함한 대부분의 UN*X 시스템의 통상적인 메일 유저 에이전트인, elm의 셋업에대해 간략하게 다룰 것이다. 리눅스 상의 전자우편에 관한 이슈에 관해 더 많은 정보를 원한다면, 정기적으로 Vince Skahan이 comp.os.linux.announce에 포스팅하는 Electronic Mail HOWTO를 참고하라. elm, smail, sendmail의 소스 배포판 역시, 그것들을 셋업하는데 의문되는 사항들에대한 해답의 대부분을 제시해 줄 수 있는 폭넓은 문서를 보유하고 있다. 만약 email에 관한 일반적인 정보를 찾는다면, 이 주제를 다루는 수 많는 RFC들이 있으며, 이 책의 말미에 있는 bibliography에서 나열하고 있다.
메일 메시지는 일반적으로 보내는 이가 적은 텍스트인 message body와, 편지봉투에서 볼 수 있는 것과 비슷하게 수취인과 전송 매개체 등에 특성화된 특수데이터로 이루어져 있다. 이러한 관리적 용도의 데이터는 2가지 범주로 나뉘는데, 첫번째 범주는 보내는 이와 받는 이의 주소와 같은 전송 매개체에 특성화된 데이터이다. 그리고 그것들은 envelope이라 불린다. 그것은 메시지가 넘겨질때마다, 전송 소프트웨어에 의해 변형될 수 있다. 두번째는 메일 메시지를 핸들링할 때 필요한 데이터로, 메시지의 제목 라인과 모든 수취인의 목록, 그리고 메시지가 보내진 날짜와 같은, 어떠한 전송 메카니즘에도 종속되지 않은 것이다. 많은 네트웍에서, 메일 메시지 앞에 mail header라 불리는 형태의 데이터를 붙이는 것이 표준화되었다. 이것과 mail body는 공백라인으로 구분지워진다. UN*X 세계에서 대부분의 메일 전송 소프트웨어는 RFC 822에서 윤곽을 잡아놓은 헤더 포맷을 따른다. 그것의 원래 목적은 사용의 표준을 지정하기 위해서였으나, 어떠한 환경에서도 독립적으로 디자인되었기 때문에, 수많은 UUCP 네트웍을 포함한 다른 종류의 네트웍에서도 쉽게 채택되었다. 그러나 RFC 822는 단지 보편적인 큰 기준일 뿐이다. 보다 최근의 표준은, 예를 들어, 데이터 암호화, 국제적 캐릭터지원, 그리고 멀티미디어 메일 확장(multi-media mail extention)같은 증가하는 요구에 대처하도록 만들어졌다. 이들 모든 표준들에서, 헤더는 뉴라인 캐릭터로 구분된 몇개의 라인으로 구성된다. 하나의 라인은 첫번째 컬럼에서 시작하는 필드네임과, 그것에 콜론과 공백을 구분으로 붙어있는 필드로 이루어진다. 각 필드의 포맷과 의미는 필드네임에 따라 다양하다. 만약 라인이 TAB으로 시작한다면, 이는 위 라인의 헤더필드가 계속됨을 의미한다. 필드는 어떤 순서로도 나열될 수 있다. 다음은 일반적인 메일헤더이다.
From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994
Return-Path:
보통 모든 필요한 헤더필드는 당신이 사용하는 메일러 인터페이스(mailer interface), elm, pine, mush, mailx같은 것들에 의해 생성된다. 그러나 몇가지는 선택적인 것이고, 유저에 의해 추가될 수 있다. 예를 들어 elm은 메시지 헤더부분을 편집할 수 있게 한다. 그 외의 것들은 메일 전송 소프트웨어가 추가한다. 다음은 통상적인 헤더필드와 그 의미를 나열한 것이다.
이러한 구조에서 한가지 예외되는 것은 맨 첫번째 라인이다. 그것은 From 키워드로 시작하고 뒤에 콜론 대신 공백문자가 붙는다. 보통의 From: 필드와 그것을 구분하기위해 흔히 그것을 From_으로 지칭한다. 그것은 UUCP bang-path 스타일(아래에서 설명한다)로 표현된 메시지의 라우트 경로, 메시지에 마지막 처리를 하는 머신에서 그것을 수신한 시간과 날짜, 그리고 선택적으로 어느 호스트에서 메시지를 수신하였는지를 지정하였는지를 지정하는 부분을 포함한다. 이 필드가 메시지를 처리하는 각 호스트에서 재생성하는 것이기 때문에, 그것은 때때로 envelope 데이터에 포함되기도 한다. From_필드의 배후엔 오래된 메일러와의 호환성이라는 것이 깔려있으나, 유저의 메일박스내에서 메시지의 시작을 표시하는데 그것을 사용하는 메일 유저 인터페이스를 제외하곤, 그다지 많이 사용되진 않는다. 메시지 body에서 "From"으로 시작하는 라인과의 잠재적인 문제점을 피하기 위해서, 그러한 경우 ">"을 앞에 붙이는 것이 표준화 되었다.
일반적으로 당신은 mail이나 mailx, 혹슨 elm, mush, pine같은 좀 더 복잡한 메일러 인터페이스를 사용하여 메일을 작성한다. 이들 프로그램들을 일컬어 mail user agents(MTA)라 부른다. 당신이 메일 메시지를 보낼 때, 인터페이스 프로그램은 대부분의 경우, 배달을 목적으로하는 또다른 프로그램에 그것을 넘겨주는데, 이를 mail transfer agents(MTA)라고 한다 몇몇 시스템에서는 로컬과 리모트 전송을 위한 서로다른 MTA가 있으나, 그 외의 경우엔 오직 하나가 있다. 리모트로 배달하기위한 커맨드는 rmail이라 하며, 그 외의 것들은 (존재한다면) lmail이라 한다. 로컬 딜리버리는, 물론 메일박스에 인커밍 메시지를 덧붙이는 것 뿐이다. 보통, 로컬 MTA는 앨리어싱(로컬 수취인의 주소가 다른 주소를 가리키도록 지정하는 것)을 이해한다. 물론, 배달되지 못하는 메시지들은 bounce, 즉 에러메시지와 함께 송신인에게로 되돌아간다. 리모트 딜리버리의 경우는, 링크의 성질에따른 전송 소프트웨어가 사용된다. 만약 메일이 TCP/IP를 사용하는 네트웍을 통해 배달되어야 한다면, SMTP가 사용된다. SMTP는 Simple Mail Transfer Protocol의 약어로, RFC 788과 RFC 821에서 정의하고 있다. SMTP는 보통 수취인의 머신에 직접 연결하여 리모트 측의 SMTP 데몬과 메시지 전송을 교섭한다. UUCP 네트웍에서 메일은 보통 직접 배달되지 않고, 그 대신 여러 중계 시스템에 의해 목적지 호스트로 포워드된다. UUCP 링크 상에서 메시지를 보내기 위해, 보내는 쪽의 MTA는 uux를 사용하여 포워드해주는 시스템의 rmail을 실행하고 표준 입력으로 메시지를 그것에 전해 준다. 이것이 각 메시지를 별개로 다루어 이루어지기 때문에, 메이저 메일 허브에서 심각한 로드를 발생시킬 수 있으며, 마찬가지로 수백개의 작은 파일로 난장판이 된 UUCP spool queue는 불균형한 디스크 공간을 잡아먹을 수 있다. 그리하여 어떤 MTA는 싱글 배치(batch) 파일에 리모트 시스템에대한 여러 메시지를 수집하는데, 그 배치파일엔 로컬 호스트가 다이렉트 SMTP 커넥션을 사용할 때 사용하는 SMTP 커맨드가 들어 있다. 이를 가리켜 BSMTP 또는 batched SMTP라고 부른다. 그 batch는 리모트 시스템상에서, 입력을 마치 보통의 SMTP 커넥션이 일어난 것처럼 처리하는 rsmtp 또는 bsmtp에 주어진다.
전자 메일의 주소는, 최소한 그 사람의 메일을 핸들링하는 메신의 네임과, 그 시스템에서 인식하는 유저의 신원이 들어있다. 이것은 수취인의 로그인 네임일 수 있으나, 그 외 다른 것일 수도 있다. X.400과 같은 다른 메일 주소화 체계는, 수취인의 호스트를 X.500 디렉토리 서버에서 검색하는데 사용하는 보다 일반적인 "attribute" 세트를 사용한다. 머신 네임이 해석되는 방법, 즉 당신의 메시지가 최종적으로 날아가는 사이트가 어디인지, 그리고 이 네임을 수취인의 유저네임과 어떻게 조합하는지는 당신이 속한 네트웍의 성격에 따른다. 인터넷 사이트를은, user@host.domain (host.domain은 호스트의 FQDN이다)의 notation을 요하는 RFC 822표준을 고수한다. 중간에 있는 것을 가리켜 "at" 기호라한다. 이 notation이 목적지 호스트로의 로트를 포함하지는 않으나, 대신 (고유한) 호스트 네임을 주므로, 이를 가리켜 absolute address라 한다. 원래 UUCP 환경에서 널리 사용되고 있던 형태는 path!host!user로, path는 목적지 host에 도달하기전에 메시지가 경유하는 호스트의 시퀀스를 나열한 것이다. 이러한 구성을 일컬어 bang path notation이라 하는데, 그 이유는 느낌표를 "bang"이라고도 하기 때문이다. 오늘날에는, 많은 UUCP 기반 네트웍이 RFC 822를 채택하고있고, 이러한 타입의 주소를 이해할 것이다. 이들 두가지 어드레싱 타입은 잘 혼합할 수 없다. hostA!user@hostB의 주소를 생각해보자. '@' 포시가 패스에 우선하는지, 혹슨 그 반대인지가 명확하지 않다. 극, 우리가 hostA!user로 메일을 보내는 hostB로 메시지를 보낼 것일까, 아니면 user@hostB로 포워드해주는 hostA로 보내는 것일까? 서로다는 주소 연산자 타입을 섞은 주소를 일컬어 hybrid address라 한다. 대부분 위의 예제와 같은 것이 악명 높은 것들이다. 그것은 보통 '@' 부호가 패스에 우선하게 하여 해결되는데, 위의 여제는 메시지를 hostB에 먼저 보냄을 의미한다. 그러나, RFC 822에 따르는 방법으로 라우트를 지정하는 방법이 있는데, <@hostA,@hostB:user@hostC>는 hostC상의 user의 주소를 뜻한다. hostC는 hostA나 hostB를 (순서대로) 통하여 도달할 수 있다. 이러한 주소 타입을 흔히 route-addr address라 부른다. '%'의 주소 연산자도 존재한다: user%hostB@hostA는 먼저 >hostA로 보내고, hostA는 (이러한 경우에만) 가장 오른쪽의 퍼센트 기호를 '@'기호로 바꾼다. 이조 그 주소는 user@hostB이고, 메일러는 행복하게 hostB로 메시지를 포워드하고, hostB는 user에 그것을 배달한다. 이러한 타입의 주소는 때때로 "Ye Olde ARPANET Kludge"라고 언급되며, 사용은 실망적이다. 그러함에도 많은 MTA들이 이런 타입의 주소를 생성한다. 그 외의 네트웍들은 여전히 다른 방식의 어드레싱을 하고 있다. DEC 기반 네트웍을 예로들어 보자면, 두 개의 콜론을 어드레스 구분자로 하여 host::user의 주소를 생성한다. X.400 표준은 수취인을 국가나 조직같은 attribute 값 세트로 묘사하는, 왼전히 다른 체계를 사용한다. FidoNet에서 각 유저들은 2:300/204.9와 같은 코드에 의해 식별되는데, 이 코드는 zone(유럽의 경우 2)과 net(Paris와 Banlieue는 320), node(로컬 허브), 그리고 point(개인 유저의 PC)를 가리키는 4개의 수로 이루어져 있다. Fidonet 주소는 RFC 822로 매핑될 수 있는데, 위의 여제를 Thomas.Quinet@p9.f204.z2.fidonet.org으로 적을 수도 있다. 이쯤되면 도메인 네임이 기억하기 쉽다는 말은 무색하지 않을까? 다음장을 통해 기술할 것이지만, 이러한 다른 타입의 어드레싱을 사용해야 할 경우도 있을 수 있다. 그러나, RFC 822 완경에선 user@host.domain과 같은 절대 주소(absolute address)외엔 별로 사용할 일이 없을 것이다.
13.4 How does Mail Routing Work? 메시지를 수취인의 호스트로 향하게하는 프로세스를 라우팅(routing)>이라 한다. 보내는 사이트에서 목적지로의 경로를 찾는 것과는 별도로, 속도와 비용 최적화, 그리고 에러 체킹 또한 그것에 포함된다. UUCP 사이트가 라우팅을 핸들잉하는 방법과 인터넷 사이트에서 하는 방법간에는 큰 채이점이 있다. 인터넷 상에서 데이터를 수취 호스트(그것의 IP 주소로 일려진다)로 형하게 하는 주 job은 IP 네트워킹 레이어에 의해 이루어지고, UUCP zone에서 루트(route)는 유저에의해 제공되거나 MTA에 의해 생성된다. 13.4.1 Mail Routing on the Internet 인터넷 상에서 메일 라우팅은, 특정 라우팅이 수행되든지 않든지 간에 목적지 호스트에 전적으로 의존한다. 디폴트는 IP주소를 검색하여 IP 전송 레이어에 실제 데이터 라우팅을 맡겨 버림으로써, 목적지 호스트로 직접 메시지를 배달하는 것이다. 대부분의 사이트를은 모든 인바운드 메일(inbound mail: 일정 그룹 또는 도메인 내부로 전달되는 메일)을, 이러한 traffic 모두를 핸들링할 수 있고, 이러한 메일을 로컬상에서 전파하는 메일 서버로 향하게 하고자 할 것이다. 이러한 서비스를 제공함을 나타내기 위해, DNS 데이터 베이서 내에 로컬 도메인에대한 MS 레코드를 집어 넣는다. MX는 Mail Exchanger의 약어이고, 기본적으로 미 도메인 내의 모든 머신에 대한 메일 포워더(forwarder) 역할을 하는 서버 호스트를 지정한다. MX 레코드는, UUCP 네트웍 또는 기밀 사항을 가지고 있는 호스트들로 이루어진 기업의 네트웍이, 인터넷 그 자체에 직접 연결되어 있지 않는 호스트에 대한 traffic을 핸들링하는데 사용된다. MX 레코드는 그와 관련딘 preference 또한 갖고 있으며, 이는 자연수이다. 만약 한 호스트에대한 여러 메일 익스체인저가 존재한다면, MTA는 메시지를 가장 낮은 preference값을 가진 익스체인저에 전송할 것이고, 이것이 실패할 경우엔 그보다 높은 값을 가진 호스트에 시도할 것이다. 만약 로컬호스트 자신이 목적지 주소에 대한 메일 익스체인저라면, 그것은 자신보다 높은 preference를 지닌 어떠한 MX 호스트에도 메시지를 포워드 시키지 않을 것이다. 이것은 메일 루프(loop)를 피하기 위한 안전책이다. Foobar Inc.라는 조직에서, 그들의 메일이 mailhub라는 그들의 머신에서 핸들링되길 원한다고 가정해보자. 그들은 DNS 데이터 베이스내에 이와 같은 MX 레코드를 넣을 것이다.
foobar.com IN MX 5 mailhub.foobar.com
이는 mailhub.foobar.com을 foobar.com에대한 5 값의 preference를 가진 메일 익스체인저임을 나타낸다.
joe@greenhouse.foobar.com으로 메시지를 전달하고자하는 호스트는 foobar.com에 대한 DNS를 체크하여, mailhub를 지시하는 MX 레코드가 있음을 발견한다.
만약 5 보다 낮은 preference를 가진 MX가 존재하지 않은다면 그 메시지는 mailhub로 배달되며, mailhub는 그 메시지를 greenhouse로 급송해준다.
위는 단지 MX 레코드가 어떻게 동작하는지에 대한 스케치일 뿐이다. 인터넷 상에서의 메일 라우팅에 관해 더 많은 젓보를 구하고자한다면, RFC 974를 참조하기 바란다. 13.4.2 Mail Routing in the UUCP World UUCP 네트웍에서의 메일라우팅은 인터넷 상에서의 그것보다 훨씬 더 복잡하다. 왜냐하면, 전송 소프트웨어가 그 자체로는 어떠한 라우팅도 수행할 수 없기 때문이다. 이전에 모든 메일은 bang path를 써서 주소화 되어야 했다. bang path는 메시지를 포워드해주는 호스트를 느낌표로 구분하여 나열하고, 뒤에 유저 네임을 지정한다. moria라는 머신의 유저인 Janet에 보내는 메일의 주소엔 eek!swim!moria!janet의 패스가 사용된다. 이는 메일을 당신의 호스트에서 eek으로, 거기에서 swim으로, 그리고 마지막으로 moria로 보낸다. 이러한 기법이 가지는 명백한 결점은, 당신이 네트웍 토폴로지와 빠른 링크에대해 많이 외워야 한다는 것이다. 이보다 더 나쁜 경우는 네트웍 토폴로지의 변경 - 링크의 삭제나 호스트의 제거와 같은 - 이 있을때, 당신이 이 변화를 알고 있지 못하기 때문에 메시지 전송이 실패로 끝나게 되는 것이다. 그리고 마지막으로, 당신이 다른 장소로 옮길 경우, 이 모든 루트들을 업데이트 해야 할 것이다. 그러나, 소스 라우팅(source routing)의 사용이 필요하게 만드는 한 가지는, 분명치 않은 호스트 네임의 존재이다. 예를 들어, moria라는 이름의 두 사이트가 있는데, 하나는 U.S에 또 하나는 프랑스에 있다고 가정하자. 그러면 moria!janet이 지시하는 사이트는 어디인가? 이는 moria에 도달할 수 있는 패스를 지정함으로써 명료해 질 수 있다. 호스트 네임의 명료성을 부여하기 위한 첫 발걸음은 UUCP Mapping Project의 설립이다. 그것은 Rutgers 대학에 위치하며, 모든 공식 UUCP 호스트네임을 그들의 이웃 UUCP와 지리적 위치에 관련된 겅로에따라 호스트 네임의 중복없이 등록한다. Mapping Project에 의해 얻어진 정보는 Usenet Maps으로 Usenet을 통해 정기적으로 배포된다. 보편적인 Map의 시스템 엑트리는 (주석문을 뺀) 다음과 같다.
moria
bert(DAILY/2),
swim(WEEKLY)
이 엔트리는 moria가 하루에 두번 전화거는 bert와 일주일에 한번 전화거는 swim으로의 링크를 갖고 있음을 나타낸다.
아래에서 다시 Map 파일 포맷에 관해 상세히 다루어 볼 것이다.
맵 내에 제공된 연결정보를 사용하여, 당신의 호스트에서 목적지 사이트로의 full path를 생성할 수 있다. 이러한 정보는 흔히 path파일에 저장되며, 때때로 pathless database라 불리워지기도 한다. 가령 그 맵이, 당신이 ernie를 통해 bert에 닿을 수 있도록 지정하고 있다고 가정해보자. 그러면 위의 맵 일부에서 생성딘 moria에 대한 패스 앨리어스 엔트리는 다음과 같을 것이다.
moria ernie!bert!moria!%s
당신이 janet@moria.uucp라는 목적지 주소를 주었다면, 당신의 MTA는 위와 같은 루트를 뽑아내어 bert!moria!janet이라는 envelope 주소로 그 메시지를 ernie에 넘길 것이다. 그러나 full Usenet map에서 path파일을 만들어 내는 것은 그리 좋은 생각이 아니다. 거기에 제공되는 정보는 흔히, 다소 왜곡되었거나 가끔씩 expired된 것들이다. 따라서 오직 일정수의 메이저 호스트들만이, 그들의 path 파일을 만드는데, 완전한 UUCP world map을 사용한다. 대부분의 사이트들은 그저 그들 근처에 있는 사이트에대한 라우팅 정보만을 유지하고, 그 데이터베이스에서 찾을 수 없는 사이트로의 메일은 좀 더 안전한 라우팅정보를 가진, 보다 스마트한 호스트로 보낸다. 이러한 체계를 smart-host routing이라 한다. 단 하나의 메일 링크를 가진 호스트들(흔히 leaf site라 불린다)은 자체적으로 어떠한 라우팅도 수행하지 않고, 전적으로 스마트 호스트에 의존한다. 13.4.3 Mixing UUCP and RFC 822 UUCP 네트웍에서의 메일 라우팅이 가지는 문제에대한 최선의 대책은 UUCP 네트웍에 도메인 네임 시스템을 도입하는 것이다. 물론, UUCP를 통해 네임 서버에 쿼리할 수는 없다. 그러나 많은 UUCP 사이트들이 그들의 내부적 라우팅을 통합하는 소규모 도메인을 형성하고있다. Map에서, 이들 도메인은 그들의 메일 게이트웨이로서 하나 또는 둘의 호스트를 지정해 놓으므로, 꼭 도메인 내의 각 호스트에대한 맵 엔트리일 필요는 없다. 그 게이트웨이는 도메인 내외로 흐르는 모든 메일을 핸들한다. 그 도메인 내의 라우팅체계는 외부세계에 완전히 가려져 있다. 이것은 위에서 적은바 있는 스마트 호스트 라우팅과 잘 어울려 동작한다. 전역적 라우팅 정보는 오직 게이트웨이에 의해 유지된다; 도메인 내의 마이너 호스트들은 그들 도메인 내부의 루트와 메일 허브로의 루트를 리스트하는, 손수 적은 작은 path 파일에 따라서만 연계할 수 있다. 심지어 이제 메일 게이트웨이는 세계의 모든 싱글 UUCP 호스트에 대한 라우팅 정보를 가지지 않아도 되며, 그들이 제공하는 그 도메인에 대한 완전한 라우팅 정보와, 그들의 데이터베이스 내부에 있는 모든 도메인들로의 루트만을 가지기만 하면된다. 예를 들어, 아래에 적힌 패스 앨리어스 엔트리는 sub.org 도메인 내 사이트들에 대한 모든 메일을 smurf로 라우트해 줄 것이다.
.sub org swim!smurf!%s
claire@jones.sub.org로의 메일은 smurf!jones!claire의 envelope 주소로 swim에 보내진다. 도메인 네임 스페이스(domain name space)의 계층적 조진은 메일 서버가 적은 수의 도메인 네임을 지정하면서도 보다 많은 루트를 사용할 수 있게 해준다. 예를 들어 프랑스의 시스템은 fr의 서브 도메인에 대한 특정 루트를 가지나, us 도메인 내의 호스트에 대한 메일은 U.S내의 시스템으로 라우트된다. 이러한 방법으로, 도메인 기반 라우팅(이러한 기법을 일컫는 말이다)은 라우팅 데이터베이스의 사이즈와 관리상 필요한 오버헤드를 크게 줄여준다. 그러나 UUCP 환경에서의 도메인 네임 사용이 가져다 주는 가장 큰 이점은, RFC 822에 따름으로써 UUCP 네트웍과 인터넷간의 쉬운 게이트웨잉을 허용한다는 것이다. 오늘날 많은 UUCP 도메인은 그들의 스마트 호스트 역할을 하는 인터넷 게이트웨이와의 링크를 가지고 있다. 인터넷을 통해 메시지를 보내는 것이 훨씬 빠르고, 라우팅 정보 또한 보다 신뢰도 높은데, 왜냐하면 인터넷 호스트는 Usenet Map 대신 DNS를 사용할 수 있기 때문이다. 인터넷에서 reachable하기위해, UUCP 기반 도메인은 그들에 대한 MX 레코드를 알리는 인터넷 게이트웨이를 갖고 있다. (MX 레코드는 앞에서 논한 바 있다) 예를 들어, moria가 orcnet.org 도메인에 속해있다고 가정해보자. gcc2.groucho.edu는 그것들의 게이트웨이 역할을 한다. 그러면 moria는 gcc2를 스마트 호스트로 사용하여, 외부도메인에 대한 모든 메일은 인터넷을 통해 배달된다. 반면에 gcc2는 orcnet.org에 대한 MX 레코드를 알려주고, orcnet 사이트로의 모든 인커밍 메일을 moria로 배달한다. 이제 남아있는 단 한가지 문제점은 UUCP 전송 프로그램이 FQDN을 다룰 수 없다는 것이다. 대부분의 UUCP 슈트는 8 캐릭터까지의 사이트 네임에 대처하도록(어떤 것은 그보다 더 적은 캐릭터만을 지원한다) 디자인되었고, 도트같은 알파 育 갼틈� 캐릭터는 대부분의 경우 사용이 불가능하다. 그러므로, RFC 822 네임과 UUCP 호스트네임간의 매핑은 필수적이다. 이 매핑이 수행되는 방법은 왼전히 implementation 의존적이다. FQDN을 UUCP 네임으로 매핑하는 통상적인 한 방법은 이에대한 패스 앨리어스 파일을 사용하는 것이다.
moria.orcnet.org ernie!bert!moria!%s
이는 FQDN으로 지정된 주소에서 순수한 UUCP 스타일의 bang path를 생성해 낸다. 몇몇 메일러는 이를 위한 특수 파일을 제공하는데, 예를 들어 sendmail은 이를 위해 uucptable을 사용한다. 역 변환(reverse transformation) - 흔히 도메이나이징(domainizing)이라고도 부른다 - 은 UUCP 네트웍에서 인터넷으로 메일을 보낼때 필요하다. 메일을 보내는 사람이 목적지 주소에 FQDN을 사용하는 한, 이러한 문제점은 스마트 호스트로 메시지를 포워딩할 때 envelope 주소에서 도메인 네임을 제거하지 않음으로써 피할 수 있다. 그러나 어떠한 도메인에도 속하지 않은 몇몇 UUCP 사이트가 여전히 존재하는데, 그들은 보통 pseudo-도메인인 uucp를 뒤에 덧붙임으로써 도메이나이징된다.
13.5 Pathalias and Map File Format 패스 앨리어스 데이터베이스는 UUCP 기반 네트웍내의 주요 라우팅 정보를 제공한다. 일반적인 엔트리는 이와 같다.
moria.orcnet.org ernie!bert!moria!%s
moria ernie!bert!moria!%s
이것은 moria로의 메시지가 ernie와 bert를 통해 배달되게 한다. moria의 FQDN과 UUCP 네임 모두는, 메일러가 이들 네임 스페이스간에 맵할 별도의 방법을 갖고 있지 않을 경우 주어져야만한다. 만약 어떤 도메인 내부의 호스트들로의 모든 메시지를 그것이 메일 릴레이로 향하게 하고자 한다면, 패스 앨리어스 데이터베이스 내에 타겟으로 도메인 네임을 앞에 점을 붙여주어 path를 지정할 수도 있다. 예를 들어, sub.org 내의 모든 호스트가 swim!smurf를 통해 도달할 수 있다면, 그 패스 앨리어스 엔트리는 이와 같을 것이다.
.sub.org swim!smurf!%s
당신이 라우팅을 크게 수행할 필요가 없는 사이트를 운영하고 있을 때만 패스 앨리어스 파일을 적어야한다. 만약 많은 수의 호스트에 대한 라우팅을 해야할 경우, pathalias 커맨드를 사용하여 맵 파일에서 그 파일을 만들어내는 것이 더 나은 방법이다. 맵은 보다 쉽게 관리될 수 있는데, 그 이유는 단순히 시스템의 맵 파일을 수정하여 그 시스템을 추가 또는 삭제하고, 다시 맵 파일을 재 생성시키면 되기 때문이다. Usenet Mapping Project에서 publish한 맵이 더이상 라우팅을 위해 많이 사용되지 않을지라도, 소규모 UUCP 네트웍은 자신들의 고유 맵 세트에 라우팅 정보를 제공할 수 있다. 맵 파일은 주로, 각 시스템이 poll하거나 poll되는 사이트의 목록으로 이루어져 있다. 시스템 네임은 첫번째 컬럼에서 시작하고, 뒤에는 링크의 목록이 들어가며, 목록 내 엔트리 하나하나는 쉼표로 구분된다. 중간에 뉴라인 캐릭터가 있더라도, 그 다음 줄의 처음이 탭으로 시작된다면 목록이 계속 되는 것으로 취급된다. 각 목록은 사이트의 네임과 그 뒤에 괄호에 싸인 cost로 이루어진다. 코스트(cost)는 숫자와 심볼릭 코스트로 이루어진 산술적 표현(arithmetic expression)이다. 해쉬 부호로 시작하는 라인은 무시된다. 예로써 moria가 swim.twobirds.com에 하루에 두번, bert.sesame.com에 일주일에 한번꼴로 poll한다고 가정하자. 거기다 bert로의 링크는 느린 2400bps 모뎀만을 사용한다. moria에선 다음의 맵 엔트리를 publish할 것이다.
moria.orcnet.org
bert.sesame.com(DAILY/2),
swim.twobirds.com(WEEKLY+LOW)
moria.orcnet.org = moria
마지막 라인은 그것을 UUCP 네임으로도 알리는 역할을 한다. 그리고, DAILY/2여야 한다는데 주목하자. 왜냐하면, 하루에 두번 전화건다는 건 실체 이 링크에 대한 코스트의 반을 의미하기 때문이다. 이와 같은 맵 파일 정보를 사용하여, pathalias는 패스 파일에 나열된 어떤 목적지 사이트로의 최적 루트를 산출해 낼 수 있고, 이들 사이트에 대한 라우팅에 사용될 수 있는 패스 앨리어스 데이터 베이스를 만들어 낼 수도 있다. pathalias는 사이트 하이딩(site-hiding: 즉, 사이트를 게이트웨이에서만 억세스할 수 있도록 만드는 것) 등과 같은 몇가지 또다른 기능을 제공한다. 링크 코스트의 완전한 목록과 같은, pathalias에 대한 좀 더 상세한 정보를 원한다면 매뉴얼 페이지를 참고하라. 맵 파일 내의 주석문은, 그것에 적혀있는 사이트에 관한 추가적인 정보를 담고 있다. 이를 지정하기 위해선 엄격한 포맷에 따라야하는데, 그 때문에 맵에서 그것을 얻을 수 있는 것이다. 예를 들어, uuwho라는 프로그램은 이러한 정보를 나이스하게 포맷된 방법으로 표시하기 위해, 맵파일에서 생성된 데이터베이스를 사용한다. 멤버들에게 맵파일을 배포하는 조직에 당신의 사이트를 등록할 때, 보통 이와 같은 맵 엔트리를 체워넣어야한다. 다음은 맵 엔트리의 예제이다. (사실, 이것은 내 사이트에 있는 것 중의 하나이다.)
#N monad, monad.swb.de, monad.swb.sub.org
#S AT 486DX50; Linux 0.99
#O private
#C Olaf Kirch
#E okir@monad.swb.de
#P Kattreinstr. 38, D-64295 Darmstadt, FRG
#L 49 52 03 N / 08 38 40 E
#U brewhq
#W okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993
#
monad brewhq(DAILY/2)
# Domains
monad = monad.swb.de
monad = monad.swb.sub.org
처음의 두 글자 뒤의 공백은 TAB이다. 필드의 대부분이 가지는 의미는 직관적인 것이다ㅂ 당신이 등록한 도메인이 어떤 것이든, 그것에서 자세한 정보를 받을 것이다. L 필드는 가장 재미있는 것으로, 그것은 당신의 지리적 위치를 위도/경도로 준 것이며, 각 나라나 세계의 모든 사이트를 보여주는 포스트 스크립트 지도를 그려낼 때 사용한다.
elm은 "electronic mail"의 약어로, UN*X 툴 중의 하나이다. 썩 좋은 도움말 기능과 full-screen 인터페이스를 제공한다. 여기서 elm을 어떻게 사용하는지 논의하진 않고, 단지 그것의 설정 옵션에 관해서만 깊게 생각해 보도록 한다. 이론적으로는, elm을 아무런 설정을 하지 않고서도 사용할 수 있고, - 재수가 좋을때 - 또한 실제로 잘 동작한다. 그러나, 이따금씩 필요할 뿐이지만, 설정해 줘야만하는 몇가지 옵션이 존재한다. 고동시에 elm은 /usr/lib/elm내에 있는 elm.rc파일에서 설정변수 세트를 읽고, 당신의 홈 디렉토리내의 .elm/elmrc파일을 읽으려 시도한다. 이 파일을 당신이 직접 만들필요는 없다. 그것은 elm의 옵션 메뉴에서 "save options"를 선택하면 자동으로 생성된다. 개인의 elmrc 파일의 옵션 세트는 전역 elm.rc 파일에서도 사용가능하다. 개인 elmrc 파일에 쓰인 대부분의 세팅은 전역파일의 그것을 오버라이드한다. 전역 elm.rc파일에 당신의 호스트네임에 관계된 옵션 세트를 지정해 줘야한다. 예를 들어, Virtual Brewery에서 vlager의 파일은 다음을 담고있다.
#
# The local hostname
hostname = vlager
#
# Domain name
hostdomain = .vbrew.com
#
# Fully qualified domain name
hostfullname = vlager.vbrew.com
이들 옵션은 로컬 호스트네임에관해 elm에게 알려준다. 비록 이 정보가 거의 사용되지 않는다고 하더라도, 이들 옵션을 반드시 지정해 줘야 한다. 이 옵션은 전역 설정 파일에 주어질 때만 효력이 있다. 개인 elmrc에서 이것은 무시된다. 13.6.2 National Character Sets 최근, RFC 822 표준안을 여러개지 메시지 타입, 이를테면 평범한 텍스트나 바이너리 데이터, 포스트 스크립트 파일등과 같은 것을 지원하도록 개선하자는 의견이 제시되고 있다. 이러한 면을 다루는 표준안 세트와 RFC들은 MIME, 즉 Multipurpose Internet Mail Extention이라고 언급된다. 이는, 메시지를 쓸때 사용한 것이 표준 ASCII 캐릭터인지 아닌지, 예를 들자면 프랑스식 액센트나 독일식 움라우트를 사용한 것인지를 수취인이 알 수 있게 해준다. 이는 elm에 의해 다소나마 지원된다. 리눅스에서 캐릭터를 나타내기 위해 내부적으로 사용되는 캐릭터 세트를 일컬어, ISO-8859-1이라하며, 이는 그것을 따르는 표준안의 이름이다. 이를 Latin-1이라고도 하는데, 이 캐릭터 세트의 캐릭터들을 사용한 메시지는 다음의 라인을 헤더에 갖고 있을 것이다.
Content-type: text/plain; character=iso-8859-1
수신한는 시스템에선 이 필드를 인식하고, 적절한 기준아래 이 메시지를 표현한다. text/plain 메시지의 디폴트 charset은 us-ascii이다. ASCII가 아는 캐릭터 세트로 적힌 메시지를 출력할 수 있게 하기위해선, 이들 캐릭터를 출력하는 방법을 elm에 알려줘야한다. 디폴트로, elm이 charset 필드가 us-ascii가 아닌(또는 content type이 text/plain이 아닌) 메시지를 수신하면, 그것은 metamail이라는 커맨드를 사용하여 이를 표시한다. metamail로 표현되어야하는 메시지는 overview 와면에서 첫번째 컬럼에 'M'이 표시된다. 리눅스의 고야 캐릭터 세트가 ISO-8859-1이기 때문에, 이 캐릭터 세트를 사용한 메시지를 표시할 때엔 metamail의 호출이 불필요하다. elm이 ISO-8859-1을 인식하게 해 준다면, metamail을 사용하지 않고 그 대신 메시지를 직접 출력할 것이다. 이것은 전역 elm.rc 파일에 다음의 옵션을 세팅해 중으로써 할 수 있다.
displaycharset = iso-8859-1
심지어 당신이 ASCII가 아닌 다른 캐릭터를 실제로 포함한 메시지를 보내거나 받지 않을 지라도 이 옵션을 지정해 주어야 한다는데 주의하자. 이것은 그러한 메시지를 보내는 사람들이, ASCII만 적힌 메시지를 보내든지 그렇지 않든지 간에, 적당한 Content-type: 필드를 디폴트로 메일 헤더에 넣도록 그들의 메일러를 설정하기 때문이다. 그러나, elm.rc에 이 옵션을 세팅해 주는 것만으로는 충분치 않다. 문제점은 그것의 builtin pager로 메시지를 표시할 때, 각 캐릭터가 프린트할 수 있는 것인지 없는지를 검사하는 라이브러리 함수를 elm이 호출한다는 것이다. 디폴트로 이 함수는 오직 ASCII 캐릭터만이 프린트 가능한 것이라고 인식하고 그 외의 모든 캐릭터는 "^?"로 표시한다. 환경변수 LC_CTYPE을 ISO-8859-1로 설정하여 라이브러리가 Latin-1 캐릭터를 프린트가응한 것으로 인정하게 만들어 이를 해결할 수 있다. 이것과 그외 기능은 libc-4.5.8에서부터 지원된다. ISO-8859-1의 특수캐릭터가 포함된 메시지를 보내려면 다음의 두 변수를 elm.rc 파일에 더 지정해 주었는지 확인해야 한다.
charset = iso-8859-1
textencoding = 8bit
이것은 elm이 메일 헤더에 캐릭터 세트를 ISO-8859-1라고 보고하고, 그것을 8비트 값으로 보내게 만든다. (디폴트로는 모든 캐릭터를 8비트로 strip한다). 물론, 이들 옵션 중 어느것도 전역 파일 대신, 개인 elmrc파일에서 지정할 수 있다.
| ||||||||||||||||||
|
Other Chapters
1. Introduction to Networking | ||||||||||||||||||
|
Appendix
A. A Null Printer Cable for PLIP |