Sun Java System Messaging Server 6 2005Q4 관리 설명서

15장 LMTP 전달

Sun Java System Messaging Server MTA는 다중 계층 Messaging Server 배포가 사용되는 상황에서 메시지 저장소로의 전달을 위해 LMTP(RFC 2033에 정의된 Local Mail Transfer Protocol)를 사용할 수 있습니다. 인바운드 중계와 백엔드 메일 저장소를 사용하는 이 시나리오에서는 중계가 주소 확장 및 전달 방법(예: 자동 회신, 전달)뿐만 아니라 메일 목록 확장을 담당합니다. 기본적으로 백엔드 저장소에 대한 전달은 백엔드 시스템이 LDAP 디렉토리에서 수신자 주소를 다시 조회해야 하는 SMTP를 통해 이루어지므로 전체 MTA 방법이 사용됩니다. 빠르고 효율적인 전달을 위해 MTA는 SMTP 대신 LMTP를 사용하여 메일을 백엔드 저장소에 전달할 수 있습니다. Sun Java System Messaging Server의 LMTP 서버는 일반적인 용도의 LMTP 서버가 아니라 릴레이와 백엔드 메시지 저장소 사이의 개인 프로토콜 역할을 합니다. 설명의 단순화를 위해 2계층 배포를 포함하는 예를 사용합니다.

주 –

LMTP는 다중 계층 배포에서 사용하도록 설계되었기 때문에 단일 시스템 배포에서는 사용할 수 없습니다. 또한 Messaging Server의 LMTP 서비스는 다른 LMTP 서버나 다른 LMTP 클라이언트와 함께 작동하도록 설계되지 않았습니다.

이 장은 다음 내용으로 구성되어 있습니다.

LMTP 전달 기능

MTA의 LMTP 서버가 백엔드 메일 저장소에 메일을 전달하는 데 보다 효율적인 이유는 다음과 같습니다.

백엔드 저장소의 로드가 감소합니다.

중계는 수평적으로 확장 가능하지만 백엔드 저장소는 그럴 수 없기 때문에 가능한 중계에서 프로세스를 처리하는 것이 좋습니다.
LDAP 서버의 로드가 감소합니다.

LDAP 인프라가 대용량 메시징 배포의 제한 요소가 되는 경우가 있습니다.
메일 대기열의 수가 감소합니다.

대기열을 중계와 백엔드 저장소 모두에 두면 메시징 배포 관리자가 손실된 메일을 찾기가 훨씬 어려워집니다.

LMTP를 사용하지 않는 2계층 배포의 메일 처리

그림 15–1은 LMTP를 사용하지 않는 2계층 배포 시나리오의 다음 메일 처리 설명을 그림 형식으로 설명합니다.

그림 15–1 LMTP를 사용하지 않는 2계층 배포

이 그림은 LMTP를 사용하지 않는 2계층 배포 시나리오의 메일 처리를 보여 줍니다.

LMTP 없이 저장소 시스템의 앞면에 릴레이가 있는 2수준 배포에서 인바운드 메일 처리는 릴레이 시스템의 디스패처가 선택하고 tcp_smtp_server 프로세스에 전달되는 SMTP 포트에 대한 연결에서 시작됩니다. 이 프로세스에서는 인바운드 메일에 대해 다음을 포함한 많은 작업을 수행합니다.

디렉토리에서 사용자 조회
사용자가 이 전자 메일 배포로 호스팅되는 도메인 내에 있는지 확인
사용자가 도메인에 유효한 사용자인지 확인
메일 봉투 주소를 @mailhost:user@domain으로 다시 쓰기
메일 호스트에 전달할 메일 대기열에 포함시키기

그러면 smtp_client 프로세스가 대기열에서 메일 메시지를 선택하여 메일 호스트에 보냅니다. 메일 호스트에서도 비슷한 프로세스가 수행됩니다. 디스패처에서 SMTP에 대한 연결을 선택하여 tcp_smtp_server 프로세스에 전달합니다. 이 프로세스에서는 다음을 포함하여 많은 메일 작업을 수행합니다.

디렉토리에서 사용자 조회
사용자가 이 전자 메일 배포로 호스팅되는 도메인 내에 있는지 확인
사용자가 도메인에 유효한 사용자인지 확인
메일을 ims_ms 채널에 전달하도록 메일 봉투 주소 다시 쓰기
저장소에 전달할 메일 대기열에 포함시키기

그런 다음 ims_ms 프로세스가 메일 메시지를 선택하여 저장소에 전달하려고 시도합니다. 이 시나리오에서는 대기열에 포함시키는 프로세스가 두 번 수행되고 각 MTA에서 LDAP 조회를 수행합니다.

LMTP를 사용하는 2계층 배포의 메일 처리

LMTP를 사용하는 2계층 배포의 메일 처리는 LMTP를 사용하는 2계층 배포 시나리오의 다음 메일 처리를 그림 형식으로 설명합니다.

그림 15–2 LMTP를 사용하는 2계층 배포

이 그림은 LMTP를 사용하는 2계층 배포 시나리오의 메일 처리를 보여 줍니다.

LMTP를 배치하고 디스패처에서 중계 시스템의 SMTP에 대한 연결을 선택하여 tcp_smtp_server 프로세스에 전달합니다. 이 프로세스에서는 인바운드 메일에 대해 다음을 포함한 많은 작업을 수행합니다.

디렉토리에서 사용자 조회
사용자가 이 전자 메일 배포로 호스팅되는 도메인 내에 있는지 확인
사용자가 도메인에 유효한 사용자인지 확인
사용자에 대한 메일함을 호스팅하는 백엔드 메일 저장소 시스템 결정
메일 호스트에 전달할 메일 대기열에 포함시키기

저장소 시스템에서는 디스패처가 LMTP 포트에 대한 연결을 수신한 다음 lmtp_server 프로세스에 전달합니다. 그런 다음 LMTP가 메일을 사용자의 메일함이나 UNIX 원시 메일함에 넣습니다. 메일이 성공적으로 전달되면 메일이 중계 시스템의 대기열에서 제거됩니다. 성공적으로 전달되지 않은 경우 메일이 중계 시스템에 그대로 남아 있습니다. 메일 저장소의 LMTP 프로세스에서는 주소 또는 메일 처리를 위해 MTA 방법을 사용하지 않습니다.

LMTP 개요

대부분의 경우 MTA 자체는 기본적으로 백엔드 서버에 존재하지 않을 수 있습니다. 필요한 유일한 MTA 구성 요소는 다음과 같습니다.

디스패처
libimta
LMTP 서버
imta.cnf파일
mappings 파일
imta.tailor 파일

디스패처에는 MTA 구성 파일이 필요한데, 이러한 파일은 너무 짧을 수 있습니다. 디스패처를 백엔드 서버에서 실행해야 LMTP 서버를 시작할 수 있습니다. 디스패처와 LMTP 서버는 libimta의 다양한 기능을 사용하기 때문에 백엔드 서버에 위치할 필요가 없습니다.

LMTP 서버는 일반적인 MTA 대기열에 포함 또는 대기열에서 제외 기능, 헤더 처리 또는 주소 변환 작업을 수행하지 않습니다. 중계 시스템이 모든 메일 내용 조작을 수행합니다. 이러한 조작을 통해 메일을 메일 저장소에 전달할 형식으로 표시하고 저장소에 필요한 형식으로 된 전달 주소를 표시합니다. 사용자 할당량과 같이 메일을 저장소에 전달할 때 일반적으로 사용할 수 있는 추가 수신자 정보는 수신자 주소와 함께 LMTP 매개 변수로 표시됩니다. 전달이 실패할 경우 메일이 중계 시스템의 LMTP 대기열에 그대로 포함되어 있습니다.

LMTP 전달 구성

LMTP 전달 기법은 릴레이 시스템과 백엔드 저장소 모두에서 구성해야 합니다. 릴레이 시스템에서는 저장소에 전달할 메일이 LMTP 채널에 전달되도록 DELIVERY_OPTIONS MTA 옵션(option.dat에서)을 변경해야 합니다. 백엔드 저장소는 디스패처를 사용하여 구성해야 하지만 Job Controller는 필요하지 않습니다. 디스패처는 LMTP 서버를 실행하도록 구성해야 합니다.

일반적인 다중 계층 배포에서는 서로 다른 백엔드 메시지 저장소 시스템에 사용자가 제공됩니다. 이 백엔드 시스템 중 하나 이상에 LMTP가 설정되지 않을 수 있으므로 프런트엔드 릴레이에서는 LMTP를 인식하는 저장소 시스템을 알고 있어야 합니다. 이는 LMTP 전달을 수락하도록 구성된 메시지 저장소를 명시적으로 지정하는 일반 데이터베이스 기능을사용하면 가능합니다.

LMTP를 사용하는 인바운드 MTA 중계 구성

LMTP를 사용하도록 인바운드 MTA 릴레이를 구성하려면 다음을 수행합니다.

단계

imta.cnf 파일을 수정하여 LMTP 다시 쓰기 규칙을 다음과 같이 변경합니다.

! lmtp
.lmtp   $E$F$U%$H.lmtp@lmtpcs-daemon
.lmtp   $B$F$U%$H@$H@lmtpcs-daemon
!
! lmtp native
.lmtpn  $E$F$U%$H.lmtpn@lmtpcn-daemon
.lmtpn  $B$F$U%$H@$H@lmtpcn-daemon
!

DELIVERY_OPTIONS 메일함을 다음과 같이 설정합니다.
#*mailbox=@$X.LMTP:$M%$\$2I$_+$2S@lmtpcs-daemon

원시 DELIVERY_OPTIONS 절을 다음과 같이 설정합니다.
#*native=@$X.LMTPN:$M+$2S@native-daemon

multigate connectcanonical 채널 키워드를 각 tcp_lmtp* 채널 블록에 추가합니다.

다음 채널 키워드를 tcp_lmtpcs 채널에 추가합니다.
fileinto @$4O:$U+$S@$D
위의 키워드에서 'O'는 숫자 0이 아닌 대문자 O입니다.

받는 MTA 릴레이 구성 설정은 다음과 같아야 합니다.

DELIVERY_OPTIONS에 대한 option.dat 항목은 다음과 같아야 합니다.

!------------------------------------------
! Modified DELIVERY_OPTIONS to activate LMTP 
! delivery from a frontend to the backend store
!--------------------------------------------
!
DELIVERY_OPTIONS=\
    #*mailbox=@$X.LMTP:$M%$\$2I$_+$2S@lmtpcs-daemon,\
    #&members=*,\
    #*native=@$X.LMTPN:$M+$2S@native-daemon,\
    #*unix=@$X.LMTPN:$M,\
    #*file=@$X.LMTPN:+$F,\
    #&@members_offline=*,\
    #/hold=@hold-daemon:$A,\
    #program=$M%$P@pipe-daemon,\
    #forward=**,\
    #*^!autoreply=$M+$D@bitbucket
!

변경 이후 수정된 imta.cnf 다시 쓰기 규칙은 다음과 같아야 합니다.

! lmtp
.lmtp   $E$F$U%$H.lmtp@lmtpcs-daemon
.lmtp   $B$F$U%$H@$H@lmtpcs-daemon
!
! lmtp native
.lmtpn  $E$F$U%$H.lmtpn@lmtpcn-daemon
.lmtpn  $B$F$U%$H@$H@lmtpcn-daemon
!

변경된 채널 블록은 다음과 같아야 합니다.

!
! tcp_lmtpcs (LMTP client - store)
tcp_lmtpcs defragment lmtp  multigate connectcanonical \
   fileinto @$4O:$U+$S@$D port 225 nodns single_sys \
   subdirs 20 maxjobs 7 pool SMTP_POOL dequeue_removeroute
lmtpcs-daemon

!
! tcp_lmtpcn (LMTP client - native)
tcp_lmtpcn defragment lmtp multigate connectcanonical port 226 \
   nodns single_sys subdirs 20 maxjobs 7 pool SMTP_POOL 
   dequeue_removeroute
lmtpcn-daemon

LMTP를 사용하고 MTA 없이 백엔드 저장소 구성 방법

LMTP를 통해 메일을 받는 경우 백엔드 저장소에 MTA가 필요하지 않습니다. 이것은 Job Controller가 없고 MTA와 연결된 주소 다시 쓰기 방법이 없음을 의미합니다. 디스패처와 단순 MTA 구성은 여전히 필요합니다. 특히, MTA 구성의 유일한 중요 부분을 구성하는 dispatcher.cnf 파일과 mappings 파일이 필요합니다.

dispatcher.cnf 파일에는 다음이 포함되어 있어야 합니다.

! rfc 2033 LMTP server - store 
!
[SERVICE=LMTPSS]
PORT=225
IMAGE=IMTA_BIN:tcp_lmtp_server
LOGFILE=IMTA_LOG:tcp_lmtpss_server.log
PARAMETER=CHANNEL=tcp_lmtpss
STACKSIZE=2048000
! Uncomment the following line and set INTERFACE_ADDRESS to an 
! appropriate host IP (dotted quad) if the dispatcher needs to 
! listen on a specific interface (e.g. in a HA environment).
! INTERFACE_ADDRESS=!
! rfc 2033 LMTP server - native
!
[SERVICE=LMTPSN]
PORT=226
IMAGE=IMTA_BIN:tcp_lmtpn_server
LOGFILE=IMTA_LOG:tcp_lmtpsn_server.log
PARAMETER=CHANNEL=tcp_lmtpsn
STACKSIZE=2048000
! Uncomment the following line and set INTERFACE_ADDRESS to an 
! appropriate host IP (dotted quad) if the dispatcher needs to 
!listen on a specific interface (e.g. in a HA environment).
!INTERFACE_ADDRESS=

기본적으로 dispatcher.cnf 파일의 LMTP 서비스는 주석 처리됩니다. LMTP가 작동하려면 이러한 주석 처리를 제거해야 합니다.

MAX_CONNS, MAX_PROCS, MAX_LIFE_CONNS 및 MAX_LIFE_TIME의 일반 디스패처 옵션을 지정할 수 있습니다. 그럴 경우 해당 하드웨어에 맞게 설정해야 합니다.

PORT_ACCESS 매핑이 중요합니다. 백엔드 서버에 대한 LMTP 구현은 Sun Java System Messaging Server 릴레이 시스템과 백엔드 저장소 사이의 개인 프로토콜로 사용됩니다. PORT_ACCESS 매핑을 사용하여 그런 릴레이만 이러한 서비스에 연결될 수 있도록 확인해야 합니다. 매핑 파일의 모양은 다음과 같습니다.

PORT_ACCESS

  TCP|*|225|1.2.3.4|* $Y
  TCP|*|226|1.2.3.4|* $Y
  TCP|*|225|1.2.3.5|* $Y
  TCP|*|226|1.2.3.5|* $Y
  TCP|*|*|*|*   $N500$ Do$ not$ connect$ to$ this$ machine

이 PORT_ACCESS 매핑 테이블에 지정된 샘플 IP 주소를 백엔드 저장소에 연결되는 네트워크에 있는 릴레이 시스템의 IP 주소로 바꾸어야 합니다.

imta.cnf 파일이 있어야 하지만 이것만으로 완벽한 구성이 이뤄지지는 않습니다. 최소 imta.cnf 파일은 다음 채널 정의로 구성됩니다.

! tcp_lmtpss (LMTP server - store)
tcp_lmtpss lmtp 
tcp_lmtpss-daemon

!
! tcp_lmtpsn (LMTP server - native)
tcp_lmtpsn lmtp 
tcp_lmtpsn-daemon

기본적으로 LMTP 채널 정의는 주석 처리됩니다. LMTP를 작동하려면 LMTP의 주석 처리를 제거해야 합니다.

LMTP를 통해 메일 저장소와 전체 MTA를 갖는 백엔드 시스템에 메일을 보내도록 중계 구성

백엔드 저장소에 MTA의 전체 기능을 제공하면서 LMTP를 사용하여 로드를 절약해야 하는 경우가 있습니다. 예를 들어, 백엔드 저장소에서 프로그램을 전달할 수 있습니다. 이 경우에는 위의 LMTP를 사용하는 인바운드 MTA 중계 구성에서 설명한 대로 릴레이를 구성해야 합니다.

전체 MTA가 있는 백엔드 메일 저장소 시스템의 LMTP 구성

백엔드 저장소 메시징 시스템 구성은 LMTP를 사용하여 저장소에 직접 전달하는 구성에서 dispatcher.cnf 파일의 끝에 다음 행이 추가되는 점만 다릅니다.

! rfc 2033 LMTP server - store
![SERVICE=LMTPSS]
PORT=225
IMAGE=IMTA_BIN:tcp_lmtp_server
LOGFILE=IMTA_LOG:tcp_lmtpss_server.log
PARAMETER=CHANNEL=tcp_lmtpss
STACKSIZE=2048000
! Uncomment the following line and set INTERFACE_ADDRESS to an 
! appropriate host IP (dotted quad) if the dispatcher needs to 
! listen on a specific interface (e.g. in a HA environment).
!INTERFACE_ADDRESS=
!
! rfc 2033 LMTP server - native
!
[SERVICE=LMTPSN]
PORT=226
IMAGE=IMTA_BIN:tcp_lmtpn_server
LOGFILE=IMTA_LOG:tcp_lmtpsn_server.log
PARAMETER=CHANNEL=tcp_lmtpsn
STACKSIZE=2048000
! Uncomment the following line and set INTERFACE_ADDRESS to an 
! appropriate host IP (dotted quad) if the dispatcher needs to 
! listen on a specific! interface (e.g. in a HA environment).
!INTERFACE_ADDRESS=
!

기본적으로 dispatcher.cnf 파일의 LMTP 서비스는 주석 처리됩니다. LMTP가 작동하려면 이러한 주석 처리를 제거해야 합니다. 또한 LMTP 포트 번호는 예일 뿐이므로 사용자가 선택한 임의의 번호가 될 수 있습니다.

백엔드 저장소를 LMTP에 대해서만 구성할 경우에는 위에서 설명한 dispatcher.cnf 파일과 동일합니다. 또한, 매핑 파일에는 LMTP 전용 백엔드 저장소에 대해 설명한 PORT_ACCESS 매핑이 필요합니다.

구현된 LMTP 프로토콜

이 절에서는 샘플 LMTP 대화 상자를 제공하여 해당 대화 상자에 표시되는 내용을 설명합니다. 중계 시스템의 LMTP 클라이언트는 표준 LMTP 프로토콜을 사용하여 백엔드 저장소의 MLTP 서버와 대화합니다. 프로토콜은 특정 방법으로 사용됩니다. 예를 들면 다음과 같습니다.

---> LHLO
<--- 250 OK

LHLO 메일에 대한 작업이 수행되지 않습니다. 회신은 항상 250 OK입니다.

---> MAIL FROM: address size=messageSizeInBytes
<--- 250 OK

메일 발송자 주소를 검사하거나 변환하지 않습니다. size= 매개 변수는 전달할 메일의 크기(바이트)를 지정합니다. 이 값은 프로토콜에 표시되는 메일의 정확한 크기입니다. 정확한 메일 크기가 꼭 필요한 것은 아니지만 대개 실제 메일 크기는 이 크기를 초과하지 않습니다. LMTP 서버는 메일을 받도록 메모리에 이 크기의 버퍼를 할당합니다.

---> RCPT TO: uid+folder@domain xquota=size,number xdflg=xxx
<--- 250 OK

받을 때는 수신자 주소를 확인하지 않지만 나중에 사용할 수 있도록 수신자 목록이 작성됩니다. 주소의 @domain 부분은 주 도메인의 uids에서는 생략되고 +folder 부분은 선택 사항입니다. 이 형식은 MTA의 메일 저장소 채널에 사용되는 것과 동일한 주소 형식입니다.

xquota= 매개 변수는 최대 총 크기와 최대 메일 수로 구성되는 사용자의 메일 할당량을 지정합니다. MTA는 사용자에 대한 LDAP 조회를 통해 주소 변환을 수행하는 동안 검색되는 이 메일 할당량 정보를 제공합니다. 이 정보는 메일 저장소의 할당량 정보를 디렉토리와 동기화된 상태로 유지하는 데 사용됩니다. 할당량 정보를 가져오는 것은 성능에 영향을 미치지 않습니다.

xdflg= 매개 변수는 비트 필드로 해석되는 숫자를 지정합니다. 이러한 비트 수는 메일이 전달되는 방법을 제어합니다. 예를 들어, 비트 값을 2로 설정하면 사용자에 대해 할당량이 초과하더라도 메일이 전달됩니다. (xdflg는 내부 매개 변수이며 포함된 비트가 예고 없이 변경되거나 추가될 수 있다는 것에 주의합니다. Sun 서버에서 이 확장을 사용하는 다른 클라이언트나 일부 다른 서버에서 이 매개 변수를 사용하는 Sun 클라이언트나 모두 지원되지 않습니다.)

이 상호 작용은 수신자마다 한 번씩 여러 번 반복될 수 있습니다.

--->DATA
---> <the message text>
--->.

그런 다음 LMTP 클라이언트가 SMTP에서처럼 전체 메일을 점으로 표시하여 보냅니다. 메일은 한 행에 점(.) 하나로 끝납니다. 메일 크기가 초과될 경우 LMTP 서버는 다음을 보냅니다.

<--- 500 message too big

그런 다음 연결을 종료합니다.

메일이 올바르게 전달되면 LMTP 서버는 RCPT TO: 행에 지정된 각 수신자에 대한 상태를 LMTP 클라이언트에게 다시 보냅니다. 예를 들어, 메일이 성공적으로 전달될 경우 다음과 같은 응답을 받습니다.

<--- 250 2.5.0 address OK

여기서 address는 RCPT TO: 행에 표시된 주소입니다.

변환은 다른 MAIL FROM: 행에서 반복되거나 다음 상호 작용으로 종료될 수 있습니다.

---> quit
<--- 221 OK

표 15–1에서는 각 수신자에 대한 가능한 상태 코드를 나타냅니다. 이 3열 테이블의 첫 번째 열에는 짧은 코드가 표시되고, 두 번째 열에는 긴 코드가 표시되며, 세 번째 열에는 상태 텍스트가 표시됩니다. 2.x.x 상태 코드는 성공 코드이고, 4.x.x 코드는 재시도 가능한 오류이고, 5.x.x 코드는 재시도할 수 없는 오류입니다.

표 15–1 수신자에 대한 LMTP 상태 코드


짧은 코드	긴 코드	상태 텍스트
250	2.5.0	확인
420	4.2.0	메일함 잠김
422	4.2.2	할당량 초과
420	4.2.0	잘못된 메일함 형식
420	4.2.0	메일함 지원 안 함
430	4.3.0	IMAP IOERROR
522	5.2.2	지속적인 할당량 초과
523	5.2.3	길이가 너무 긴 메일
511	5.1.1	메일함 없음
560	5.6.0	메일에 null 포함
560	5.6.0	메일에 nl 포함
560	5.6.0	메일에 잘못된 헤더 있음
560	5.6.0	메일에 빈 행 없음

그렇지 않으면 메일함, 원시(UNIX) 및 파일에 대한 전달 옵션이 변경된 것입니다. 이러한 규칙의 목적은 메일이 해당 LMTP 채널을 통해 백엔드 서버에 전달되도록 주소를 생성하는 것입니다. 생성된 주소는 라우팅된 원본 주소이며 그 형식은 다음과 같습니다.

@sourceroute:localpart@domain