procmail은 많이 쓰는 Message Delivery Agent (MDA)이다. MDA가 하는 일은 특정 사용자나 멜복스에 대한 메세지를 MTA로부터 받아서 사용자의 요구대로 전달하는 것입니다. procmail은 다양한 헤더필드내용이나 메세지본문에 따라서 메세지를 필터하는테 쓰이기도 합니다. 예를 들면, 특정인이 보낸 메세지를 그 사람의 멜복스에만 전달하도록 할 수 있습니다.
procmail을 큐메일과 함께 운영하는 방법이 두 가지 있습니다. 첫째는, procmail은 보통 /var/spool/mail에 있는 mbox멜복스로 전달하도록 컴파일됩니다. procmail을 다시 컴파일해서 $HOME를 기본으로 하도록 하거나, 사용자들에게 알려서 procmail이 mobx를 기본위치로 하지 않도록 합니다. $HOME전달에 대해 패치하지 않으면, 임시파일에 대해서 procmail은 여전히 /var/spool/mail을 씁니다.
문제가 하나 더 있는데, qmail-command와 procmail에는 어떤 엑싯코드가 무엇을 말하는 지에 대한 공통이해가 없습니다. procmail은 표준 유닉스 엑싯코드를 쓰는데, 0은 성공, 그외는 실패이며, 실패의 원인은 /usr/include/sys/errno.h에 정의되어 있습니다. qmail-command에서는 0이외의 일정한 숫자로 영구에러를 일러주고, 그 이외는 임시로 간주합니다. qmail-command에 대한 엑싯코드를 해석하기 위해서 소규모의 셸스크립트 wrapper를 만들 수도 있습니다. 이런 wrapper는 큐메일멜링리스트에 부처졌고, 다음주소의 문서보관에서 얻을 수 있습니다. http://www.ornl.gov/its/archives/mailing-lists/qmail/1998/04/msg00487.html
또한 procmail은 maildir형식의 멜복스로 직접 전달하지 않습니다. procmail에서 maildir로 직접전달하는 패치를 얻을 수 있습니다. ( http://www.qmail.org/top.html#maildir를 보십시오.) 다른 방법에는 특정 maildir로 향하는 표준입력으로 메세지를 작성하는 프로그램인 safecat입니다. 사용자는 safe가 메세지를 파일처리하도록 procmail 비법 (전달지시사항)을 적을 수 있습니다. procmail을 아예 씨즈 말고 maildrop을 사용할 수 도 있습니다.
끝으로 procmail은 메세지를 받을 때 mbox형식으로 인식합니다. 대개 큐메일프로그램의 전달에는 진짜 멜메세지만 포함하지 "From "줄이 없습니다. preline명령어를 써서 procmail이 인식하는 메세지형식으로 만들 수 있습니다.
예를 들면, dave사용자가 procmail로 멜을 처리하고 싶다고 합시다. 시스애드민이 procmail을 기본으로 $HOME로 전달하도록 컴파일했고, /usr/local/bin/qmail-procmail이라는 엑싯코드 wrapper를 제공한다고 할 때, .qmail파일은 다음과 같습니다.
|/var/qmail/bin/preline /usr/local/bin/qmail-procmail dave
큐메일은 POP서버와 qmail-pop3d를 포함하지만, 큐메일설치과정으로 설정하거나 설치하지는 않습니다. 다른 POP나 IMAP 등의 서버를 얻을 수 있으면 그것들을 사용해도 되지만, 대부분이 Sendmail용으로 만들어졌으므로 큐메일과 함께 쓰려면 손을 봐야 합니다.
qmail-pop3d는 큐메일이 포함하는 POP서버입니다. 매우 좋은 POP서버로서 여러 큐메일사이트가 사용합니다. 모듈기능이고, 대체인증모듈을 통해 복합인증구성을 지원합니다.
--------e----------------------------------------------------------------------------
유의점: qmail-pop3d는 maildir형태의 멜복스만 지원하므로, 로컬 사용자들이 POP서버에
로긴해서 MUA를 운영한다면 모두들 maildir를 지원해야 합니다. 사용자들이 POP를
통해서 멜을 읽는다면 서버의 멜복스형태는 문제가 되지 않습니다.
-------------------------------------------------------------------------------------
다음의 세모듈로 구성합니다.
으례 qmail-popup은 POP3포트인 110번 포트를 듣는 inetd나 tcpserver로 움직입니다. 연결을 하면 사용자명과 암호를 대라고 합니다. 그리고서는 checkpassword를 불러서 사용자명과 암호를 검증하고 맞다면 qmail-pop3d를 부릅니다.
pop3 stream tcp nowait root /var/qmail/bin/qmail-popup qmail-popup \
hostname.domain /bin/checkpassword /var/qmail/bin/qmail-pop3d Maildir
--------------------------------------------------------------------------------------
유의점: 어떤 시스템들, 그중에서도 레드햇리눅스,는 POP3포트를 "pop3"로 부르지
않습니다. /etc/services에서 110번 포트 서비스의 이름을 확인하십시오. 또한
inetd 맨페지를 확인하셔서 기재사항을 형식에 맞추십시오. 잘 보셔야 하는 것이,
어떤 inetd에는 프로그램(본 예제에서는 qmail-popup)에 대한 첫번째 인수가 그
프로그램의 이름이어야 합니다. 다른 inetd들에게는 "사실상의" 인수만 있으면
됩니다.
--------------------------------------------------------------------------------------
tctpserver를 쓰려면 다음사항을 큐메일 (inetd.conf가 아니고) 기동스크립트에 더하십시오.
tcpserver -v -R 0 pop3 /var/qmail/bin/qmail-popup FQDN \
/bin/checkpassword /var/qmail/bin/qmail-pop3d Maildir 2>&1 | \
/var/qmail/bin/splogger pop3d &
여기에서 pop3는 /etc/services에 기재된 POP3서비스의 이름이고, FQDN은 지금 설치하시는 POP서버의 완전도메인명으로서, 예를 들면 pop.example.net입니다.
mbox형 멜복스와 동작하는 POP데몬이 필요하면 Qualcomm의 qpopper을 쓰십시오. Vince Vielhaber는 http://www.qmail.org/qpopper2.53.patch.tar.gz에 사용자홈디렉토리의 멜복스와 동작하는 패치를 갖고 있습니다. qpopper는 http://www.eudora.com/freeware/qpop.html에서 구할 수 있습니다.
Jason van Zyl이 qmail/Cyrus 하우투를 썼습니다. http://www.compusense.com/qmail-cyrus/를 보십시오.
LDAP를 Cyrus에 결합하는 정보가 http://www.linc-dev.com/auth.html에 있습니다.
David R. Harris가 Washington대학의 IMAP서버에 대한 maildir지원을 추가하는 패치를 정리했으며 설치과정을 문서화했습니다. http://www.davideous.com/imap-maildir/를 보십시오.
POP나 IMAP 등의 서버에서 멜을 꺼내서 로컬에 재삽입하는 프로그램입니다. 큐메일에서 멜을 꺼내는 데 문제가 없지만, 큐메일클라이언트에서 잘 동작하게 하는 두세가지 기술이 있습니다.
큐메일시스템상의 사용자를 위한 .fetchmailrc샘플은 다음과 같습니다.
poll mail.example.net proto pop3 nodns
user dsill with password flubgart is dave here
fetchall forcecr to * here
이렇게 하면 fetchmail은 mail.example.net을 POP3를 통해서 접속하고, dsill 사용자, flubgart암호로 로긴해서, 메세지를 모두 꺼낸다음에 dave@localhost로 전달합니다. forcecr은 각줄에 carriage return을 붙여서 로컬시스템에 메세지를 SMTP를 통해서 삽입합니다. 큐메일에게는 이것이 필요합니다.
----------------------------------------------------------------------------------
유의점: fetchmail은 확실하지 않습니다. (포맷에러로 바운스를 일으키거나 SMTP서버가
동작중이지 않는 등) 이유야 어쨌든 재삽입이 실패하면 메세지가 없어집니다.
-----------------------------------------------------------------------------------
예를 들어서, 당신이 MTA이고, 한 사용자가 hostx.example.com의 세사람에게 메세지를 보낸다고 합시다. 이것을 하는데 몇가지 방법이 있습니다.
첫번째 방법은 세번째 방법보다 분명히 뒤집니다. 메세지가 작더라도 적어도 그만큼 시간이 걸립니다. 그리고 메세지가 크다면 더 오래 걸리고, 게다가 넷웍대역을 쓸것입니다.
그러니 그것은 뺍시다.
두번째와 세번째 방법은 좀더 재미있습니다.
세번째 방법은 hostx에 접속을 단 한번 열고서 메세지 사본을 단 하나만 보냅니다. 넷웍대역을 효율사용하는 데 도움이 됩니다.
두번째 방법은 여러번 접속해서 메세지사본을 여러개 보냅니다. 넷웍대역을 "낭비"하지만 SMTP프로토콜의 성질때문에 세번째 방법보다 왕복지연이 더 적고, 더 빠릅니다. 게다가 세번째 방법보다 더 간단하므로 MTA를 더 수월하게 작성할 수 있습니다. 그리고 끝으로, 각 수신인이 그만의 메세지사본을 받으므로 MTA가 VERP를 구현할 수 있습니다. (다음항목을 보십시오.)
큐메일은 언제나 두번째 방법 (단일 RCPT)을 사용합니다. 세번째방법 (복수 RCPT)를 구현하는 패치는 없습니다. 그것은 많은 작업을 하여야 합니다.
단일 RCPT 전달이 복수 RCPT 전달보다 넷웍대역을 더많이 사용하지만, 그 차이는 종종 과장되었습니다. 메세지 대부분은 기껏해야 두세 수신인에게 보내지는데다가 그들은 보통 서로 다른 호스트에 있기때문에, 복수 RCPT전달은 얻는게 아무것도 없습니다. 복수 RCPT전달이 유효할 수 있는 멜링리스트서버에서조차 이익가능성은 적은데, SMTP는 대부분의 연결에 걸쳐서 넷웍대역의 조금만 쓰고, HTTP가 엄청나게 많이 쓰기 때문입니다.
예를 들어 상향연결의 10퍼센트가 SMTP 대역으로 가고, 그중 25퍼센트를 복수 RCPT를 사용해서 줄여 봐야 SMTP 대역은 7.5%로 될 뿐입니다.
메세지를 전달할 수 없으면, MTA는 Envelope Return Path (ERP)로 바운스메세지를 돌려보내야 한다고 결정합니다. 바운스 메세지에는 수신인주소, 메세지부전달사유, 그리고 문제가 임시인지 오래갈 지 등을 포함해야 합니다. 그렇지만 많은 MTA가 제대로 하지 않습니다. 그것들은 바운스를 From 헤더필드에 있는 주소로 보내기도 하지만, 수신인을 파악하지 못하기조차 합니다.
사용자대사용자 메세지의 대부분에서 이런 문제들은 그렇게 나쁘지 않습니다. 대개는 바운스시각과 그 내용에 기초해서 사태를 이해할 수 있습니다. 멜링리스트에서는 잘못된 바운스문제가 더 심각합니다. 가입자들은 새주소로 멜을 옮기고 포워딩합니다. 새주소에 전달문제가 생기기 시작했는데, 바운스메세지에는 오직 새주소만 포함되어 있다면 어느 가입자의 멜이 바운스되는 지 알 수 없습니다.
Dan Bernstein은 VERP (Variable Envelope Return Path)라 불리는 굉장한 것을 제안했습니다. VERP를 사용하면, 각 가입자는 고유리턴경로를 갖습니다. 이렇게 해야 바운스 처리기가 문제가입자를 식별하도록 할 수 있습니다.
예를 들어서, 대개의 비 VERP 멜링리스트에는 리턴주소가 listname-owner@domain의 형식으로 됩니다. VERP 멜링리스트에서는 리턴주소가 listname-owner-subscriber=sdomain@ldomain으로 되는데, 가입자주소 subscriber@sdomein이 "소유자"와 "@"사이에 묻혀있습니다. (가입자주소의 "@"는 "="로 대체됩니다.)
ezmlm리스트매니저는 바운스를 자동으로 처리하기 위해서 VERP를 씁니다. 가입자에세 빠뜨린 메세지리스트의 임시전달문제를 알려줘서 보관문서에서 꺼낼 수 있게 합니다.
Russell Nelson이 큐메일에서의 메이저도모를 위한 바운스메니저를 썼지만, 더이상 유지하지 않습니다. http://www.qmail.org/bounceman-0.4.sha에서 구할 수 있습니다.
제대로 작동하고 완전하지만 최소한의 큐메일설치는 다음의 네과정이면 됩니다.
사용중인 유닉스기종에 따라서 다음명령중 하나로 이 과정들을, 어쩌면 몇개 더, 나열할 수 있습니다.
ps -ef | grep qmail ps waux | grep qmail
예를 들면 다음과 같습니다.
[dave@sparge dave]$ ps waux|grep qmail dave 2222 0.0 0.8 836 348 p4 S 10:25 0:00 grep qmail qmaild 351 0.0 1.0 840 400 ? S N 12:43 0:00 /usr/local/bin/tcpserver -v -x / qmaild 2220 0.0 1.0 844 420 ? S N 10:25 0:00 /usr/local/bin/tcpserver -v -x / qmaill 365 0.0 0.8 748 344 ? S N 12:43 0:00 splogger qmail qmailq 368 0.0 0.7 736 292 ? S N 12:43 0:00 qmail-clean qmailr 367 0.0 0.6 732 272 ? S N 12:43 0:00 qmail-rspawn qmails 350 0.0 0.8 776 336 ? S N 12:43 0:00 qmail-send root 340 0.0 0.6 724 252 ? S N 12:43 0:00 /usr/local/sbin/supervise /var/s root 341 0.0 0.6 724 252 ? S N 12:43 0:00 /usr/local/sbin/supervise /var/s root 366 0.0 0.7 736 276 ? S N 12:43 0:00 qmail-lspawn ./Mailbox [dave@sparge dave]$
위의 예에서와 같이 supervise하에서 qmail이나 qmail-smtpd를 실행하면 그 과정들도 볼 수 있습니다. tcpserver하에서 qmail-smtpd를 실행하면, 부모 tcpserver와 각 활성 입력 SMTP 접속에 대한 추가 tcpserver 과정도 볼 수 있습니다.
로깅을 처리하기 위해 splogger (또는 cyclog)을 사용하면, qmaill사용자로서 운행하는 splogger (또는 cyclog)과정을 갖습니다.
게다가 큐메일이 로컬이나 원격 메세지전달로 바쁘면 관계되는 로컬수만큼의 qmail-local과정과 관계되는 원격수만큼의 qmail-remote과정을 볼 수 있습니다.
메세지에 시간찍기하기 위해서 syslog의 로깅시스템을 사용해서 syslog 데몬으로 보냅니다. syslog은 /etc/syslog.conf에서 설정합니다. syslog로 보내는 메세지는 장치와 우선순위가 있습니다. /etc/syslog.conf의 기재사항은 장치와 우선순위에 따라서 필터해서 메세지를 원하는 로그파일, 원격로그호스트, 또는 콘솔에 보냅니다. splogger는 기본으로 멜장치에 로그하므로, syslog.conf파일에서 "mail"을 grep하면 큐메일의 로그메세지처리를 볼 수 있습니다.
대개 다음장소에 위치합니다.
대개의 syslog 로그기재사항은 다음과 같습니다.
Jun 3 11:35:23 sparge qmail: 928424123.963558 delivery 153: success: did_1+0+0/
"Jun 3 11:35:23" is the syslog timestamp.
"sparge" is the name of the system that sent the message.
"qmail:" is the tag splogger places on all qmail log entries.
"928424123.963558" is an optional TAI timestamp (see next section).
"delivery 153: success: did_1+0+0/" is the log message itself.
daemontools 패케지의 일부로서 특정한 디렉토리내의 파일에 메세지를 로그합니다. syslog와는 달리 기재사항을 시간찍기하지 않습니다. daemontools패케지의 accustamp를 사용하면 됩니다.
로그디렉토리는 cyclog명령행에 명시하므로 큐메일기동스크립트를 살펴보시면 찾을 수 있습니다.
로그디렉토리내의 파일수와 각파일의 최대크기는 cyclog 옵션으로 정합니다. 로그파일명은 파일을 시작한 시간의 TAI (Temps Atomique International) 시간찍기입니다. daemontools의 tailocal명령은 TAI 시간찍기를 사람이 읽을 수 있는 로컬 시간찍기로 변환합니다.
보통의 cyclog 록기재사항은 다음과 같습니다.
928424123.963558 delivery 153: success: did_1+0+0/
"928424123.963558" is the optional, but recommended, TAI timestamp.
"delivery 153: success: did_1+0+0/" is the log message itself.
로컬시스템에서 원격시스템으로 보내는 메세지에 대한 록은 다음과 같습니다.
1 928427555.143178 new msg 94030 2 928427555.145873 info msg 94030: bytes 189 from <dave@sparge.sill> qp 2594 uid 500 3 928427555.210992 starting delivery 158: msg 94030 to remote lwq@w3.to 4 928427555.213816 status: local 0/10 remote 1/20 5 928427572.640642 delivery 158: success: 209.85.127.177_accepted_message. /Remote_host_said:_250_CAA01516_Message_accepted_for_delivery/ 6 928427572.643845 status: local 0/10 remote 0/20 7 928427572.644381 end msg 94030
제1번줄은 큐메일이 새메제지를 받았음을 나타내고, 큐아이디는 94030입니다. 큐아이디는 메세지를 담는 큐파일인 /var/qmail/queue/mess/NN/파일의 아이노드번호입니다. 큐아이디는 메세지가 큐에 있는 동안은 고유합니다.
제2번줄은 메세지가 dave@sparge.sill에서 왔고 189바잇이라고 알려줍니다.
제3번줄은 qmail-remote가 메세지를 lwq@w3.to로 전달하려고 기동한다고 알려주며, 아이디 158을 전달에 부여합니다.
제4번줄은 로컬전달은 0개, 리못전달은 1개가 계류중이라고 알려줍니다.
제5번줄은 158번 전달이 성공으로 끝났고, 원격서버의 반응을 되돌리는데, 때때로 원격멜애드민이 전달을 추적하는데 유용한 정보를 포함합니다. 이번경우에서 "CAA01516"은 원격시스템의 전달아이딥니다.
제6번줄은 로컬전달 0개, 원격전달 0개가 계류중이라고, 즉 전달을 끝마쳤다고, 알려줍니다.
제7번줄은 메세지를 완전히 전달하고 큐에서 지웠다고 알려줍니다. 여기에서 큐아이디인 94030은 다른 전달에 또 사용할 수 있습니다.
qmail-ldap도 보십시오.
사용자디렉토리를 저장하려면 빠른 NFS넷웍파일서버를 사용하십시오. 파일서버상의 maildir멜복스에 전달하는 복합 동등선호 SMTP서버를 설치하십시오.
먼저, Dan Berstein의 Sendmail->qmail페지를 http://pobox.com/~djb/qmail/sendmail.html에서 보시기 바랍니다.
멜링리스트소유자가 멜링리스트를 운영하는 것을 돕는 시스템입니다. 하는 일은 두 가지입니다. 가입자들의 리스트를 관리하고, 가입자들에게 메세지를 재송부하는 일입니다.
유닉스멜링리스트매니저 대부분이 (또는 전부가) 큐메일과 작동할 수 있습니다.
큐메일의 저자인 Dan Bernstein이 작성했습니다. 큐메일과 사용하도록 썼으며, 큐메일의 몇몇 특징에 의존합니다. 가장 두드러진 점은 바운스메세지를 안정하게 처리하도록 VERP를 사용합니다. MLM중에서 ezmlm이 다소 독특한 점은 중앙 MLM주소로 보내진 명령을 처리하지 않고, 리스트의 이름에 덧붙입니다. 예) "foo@list.example.net"에 가입하려면 "foo-subscribe@list.example.net"으로 메세지를 보냅니다.
더 알고 싶으시면 비공식웹사이트이고, 매우 많은 특징을 포함하는 아주 훌륭한 애드온인 ezmlm-idx의 공식홈페지인 http://www.ezmlm.org를 보십시오.
가장 많이 보급된 유닉스 MLM입니다. 두세가지만 고치면 큐메일과 멋지게 작용합니다. Russ Allbery가 큐메일/메이저도모에 관한 FAQ를 썼는데, http://www.eyrie.org/~eagle/faqs/mjqmail.html에서 구할 수 있습니다.
큐메일에 대한 여러 소스코드패치를 구할 수 있습니다. 패치를 설치하려면, 다운로드하고, 큐메일소스트리로 가서 패치명령을 씁니다.
cd /usr/local/src/qmail/qmail-1.03 patch -p0 < /tmp/patchfile
큐메일을 멈춰야 하는데, qmail-send를 끝내거나, 설치항목에 있는 큐메일스크립트를 설치하셨다면 다음과 같이 합니다.
/usr/local/sbin/qmail stop
그리고나서 다시 컴파일하고 바이너리를 설치합니다.
make setup check
예로부터 DNS응답은 512바잇으로 제한되었다. 몇몇 대형사이트들, 그중에서도 America Online,은 MX응답을 더 길게해서 되돌리기 시작했습니다. 큐메일과 기타 많은 프로그램들은 매우 큰결과를 되돌리는 Domain Name Server (DNS)질의에는 문제가 있습니다. 큐메일에서는 이것을 해결하는데 두가지 방법이 있습니다.
회답이 절단빗셋과 돌아도면 라입러리코드내에서 TCP질의를 자동으로 하는 최근의 BIND resolver 라입러리와 동작합니다. 가장 간단한 해결이지만, 해당시스템의 페이징처리방법에 따라서 메모리낭비가 가장 클 수 있습니다. dns.c의 PACKETSZ를 65536으로 바꾸고 큐메일을 다시 컴파일하면 됩니다.
http://www.ckdhr.com/ckd/qmail-103.patch)
아무리 오래되었어도, 그리고 "버퍼에 놓이는 바잇수"라입러리버그를 피하려고 가드(guard)바잇을 사용하는 어떤 리졸버라입러리와도 동작하는 Chuck Foster의 패치를 개조한 것입니다. 필요한 크기로 하기보다는 (원래패치와 같이 응답이 기본 512바잇인 PACKETSZ보다 커야지만 재할당하지만) 65536으로 단 한번만 재할당하므로 Chuck의 패치보다 메모리효율에서는 떨어집니다. 재할당후에, TCP질의를, 리졸버라입러리가 하게하지 않고, (큐메일과 네임서버가 같은 기계 또는 로컬넷웍에 있으면 큰걱정이 아니지만, 그것들간 여분의 왕복을 피하면서) 강제로 합니다.
Andre Oppermann 등의 이 패치는 Lightweight Directory Access Protocol (LDAP)지원을 큐메일에 구현합니다. LDAP는 넷웍전화책과 같습니다. qmail-ldap를 사용하면 POP서버를 수천명의 사용자에게 편의를 제공할 수 있습니다. http://www.nrg4u.com/를 보십시오.
Dan Bernstein이 설계한 SMTP대체프로토콜입니다. 해당 프로토콜은 http://pobox.com/~djb/proto/qmtp.txt에 정의되어 있습니다. SMTP와 유사하지만, 더 간단하고, 더 빠르고, SMTP와는 호환되지 않습니다. 큐메일은 qmail-qmtp라는 QMTP서버를 포함하는데, qmail-smtp와 매우 흡사하게 동작합니다. 대개 209포트를 이용합니다.
큐메일은 QMTP클라이언트를 포함하지 않지만, serialmail패케지는 그것을 포함합니다. maildir2qmtp는 maildir멜복스에 있는 메세지를 QMTP를 통해서 지정한 QMTP서버로 전달합니다.
SMTP에 대한 drop-in 대체품이 아니며, 아직까지는 인터넷상에서 많이 퍼지지 않았습니다.