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 서버의 로드가 감소합니다.

메일 대기열의 수가 감소합니다.

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

그림 15-1은 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계층 배포의 메일 처리

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

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

디렉토리에서 사용자 조회

사용자가 이 전자 메일 배포로 호스팅되는 도메인 내에 있는지 확인

사용자가 도메인에 유효한 사용자인지 확인

사용자에 대한 메일함을 호스팅하는 백엔드 메시지 저장소 시스템 결정

주소를 @mailhost:uid@domain.LMTP 또는 @mailhost:uid@domain.LMTPNATIVE로 다시 쓰기

메일 호스트에 전달할 메일 대기열에 포함시키기

user@domain.LMTP 및 user@domain.LMTPNATIVE 형식으로 된 주소가 각각 tcp_lmtp 채널 또는 tcp_lmtpnative 채널을 통해 메시지 저장소 시스템에 라우팅됩니다. 이러한 채널은 SMTP 대신 LMTP를 사용하여 백엔드 메시지 저장소와 통신합니다. 저장소 시스템에서는 디스패처가 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 릴레이를 구성하려면 다음을 수행합니다.

다음 행을 option.dat에 추가하여 텍스트 데이터베이스를 활성화합니다.

USE_TEXT_DATABASES=1

이 단계에서는 일반 데이터베이스의 일반적인 텍스트 파일을 MTA에서 사용할 수 있습니다. 이미 일반 데이터베이스를 사용하는 경우에는 이 단계를 건너뛸 수 있습니다.

일반 데이터베이스 텍스트 파일을 만들거나 수정합니다.

# cd /opt/SUNWmsgsr/config/
# vi general.txt

LMTP_CS|msg-store.siroe.com lmtpcs-daemon
LMTP_CS|name-1-lmtp-store.siroe.com lmtpcs-daemon
LMTP_CS|name-2-lmtp-store.siroe.com lmtpcs-daemon
..
..
LMTP_CN|Zmar.Talek@siroe.com lmtpcn-daemon
..
LMTP_CN|Fred.Bloggs@siroe.com lmtpcn-daemon

# chown mailsrv general.txt

lmtpnative 채널에 대한 사용자별 전달을 처리하기 위한 것과 tcp_lmtpcs 채널을 통해 전달하기 위해 저장소 전체 설정을 처리하기 위한 두 가지 유형의 항목이 있습니다.

options.dat 파일에서 DELIVERY_OPTIONS 변수를 만들거나 수정합니다.

DELIVERY_OPTIONS의 값을 변경해야 합니다. 전달 옵션의 현재 값은 다음과 같습니다.

DELIVERY_OPTIONS=\
     *mailbox=$M%$\$2I$_+$2S@ims-ms-daemon,\
     &members=*,\
     *native=$M@native-daemon, \
     *unix=$M@native-daemon, \
     /hold=$L%$D@hold-daemon,\
     &file=+$F@native-daemon, \
     &@members_offline=*,\
     ,program=$M%$P@pipe-daemon,\
     #forward=**,\
     *^!autoreply=$M+$D@bitbucket

이 값을 다음과 같이 바꿉니다.

DELIVERY_OPTIONS=\
    #*mailbox=@$X:$M$_+$2S%$\$2I@ims-ms-daemon,\
    &members=*,\
    #*native=@$X:$M,\
    #*unix=@$X:$M,\
    #/hold=$L%$D@hold,\
    #*file=@$X:+$F,\
    &@members_offline=*,\
    #program=$M%$P@pipe-daemon,\
    #forward=**,\
    #*^!autoreply=$M+$D@bitbucket

메일함 전달 옵션의 패턴에 발생한 변경 사항과 함께 이제 자동 회신 전달 옵션 앞에 # 문자가 표시되어 릴레이 시스템에서 작업이 수행되도록 강제한다는 사실에 유의하십시오. $X 대체로 인해 사용자에 대한 mailhost 속성의 값이 삽입됩니다. 그로 인해 라우트된 원본 주소가 생성됩니다.

원시의 UNIX 파일 및 프로그램 전달 방법이 유용하게 사용되기 위해서는 대상 컴퓨터에서 MTA를 실행하고 있어야 한다는 점도 중요합니다.

LMTP 다시 쓰기 규칙을 imta.cnf 파일에 다음과 같이 추가합니다.

# cd /opt/SUNWmsgsr/config/
# cp imta.cnf imta.cnf.orig
# vi imta.cnf

!
! pipe
.pipe-daemon $U%$H.pipe-daemon@pipe-daemon
!
! tcp_local
! Rules for top level internet domains
<IMTA_TABLE:internet.rules
!
! Do mapping lookup for internal IP addresses
[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon
!
! Do general.txt lookup for lmtp hosts
.domain-name.com $S$U%$H$D@$(LMTP_CN|$U@$H$D)
.domain-name.com $S$U%$H$D@$(LMTP_CS|$H$D)
!
! tcp_intranet
! Do mapping lookup for internal IP addresses
[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon
.domain-name.com $U%$H.domain-name.com@tcp_intranet-daemon

이 단계에서 다시 쓰기 규칙 쌍은 주소의 소스 루트 부분이 LMTP 전달을 수행하기 위한 항목과 일치하는지 확인하기 위해 일반 데이터베이스의 태그된 검사를 수행합니다. 단계 2에서 만든 general.txt 파일에는 적절한 채널을 통해 백엔드 메시지 저장소에 전달을 지정하도록 태그된 항목이 있습니다. 여기서 다시 쓰기 규칙의 $S는 주소에 소스 루트가 포함된 경우에만 다시 쓰기 규칙이 적용됨을 의미합니다. 일반 데이터베이스의 항목과 일치하는 항목이 있을 경우 다시 쓰기 규칙이 성공하고 LMTP를 통해 전달을 수행하는 tcp_lmtpX 채널을 통해 소스 루트 백엔드 호스트에 메시지가 전달됩니다.

일치하는 항목이 없을 경우 다른 다시 쓰기 규칙에 일치하는 항목이 있을 때까지 다시 쓰기 프로세스가 계속됩니다. 대부분의 경우 일반 데이터베이스의 검사를 통해 일치하는 항목을 찾지 못하면 SMTP를 통해 전달을 수행하는 tcp_intranet 채널을 통해 메시지가 라우팅됩니다.

새로운 채널 블록을 imta.cnf에 추가합니다.

imta.cnf 파일의 채널 정의 섹션에 lmtp 및 lmtpn 채널에 대한 채널 정의도 포함시켜야 합니다. 예를 들면 다음과 같습니다.

! tcp_lmtpcs (LMTP client - store)
tcp_lmtpcs defragment lmtp port 225 nomx single_sys subdirs 20 maxjobs 7 pool SMTP_POOL dequeue_removeroute
lmtpcs-daemon
!
! tcp_lmtpcn (LMTP client - native)
tcp_lmtpcn defragment lmtp port 226 nomx single_sys subdirs 20 maxjobs 7 pool SMTP_POOL dequeue_removeroute
!lmtpcn-daemon

구성 변경 사항을 적용합니다.

# cd /opt/SUNWmsgsr/bin
# ./imsimta refresh

Compiled configuration done

Killing Dispatcher : 23021

Dispatcher startup requested

Job Controller shutdown requested

Job Controller startup requested



주	LMTP 채널에는 lmtp 채널 키워드를 사용해야 합니다. LMTP 채널에 smtp 및 lmtp 채널 키워드를 함께 사용하지 마십시오. 기본적으로 LMTP 채널 정의는 주석 처리되어 있습니다. LMTP를 작동하려면 LMTP의 주석 처리를 제거해야 합니다.

조직에서 Sun Java System Messaging Server 사용자와 비Sun Java System Messaging Server 사용자가 함께 있는 경우, 어떤 사용자가 비Sun Java System Messaging Server 컴퓨터에 있는지 알 수 있어야 합니다. 이들의 delivery 옵션은 mailbox으로 설정할 수 없습니다. 대신 delivery 옵션은 forward로 설정되어야 합니다. 전달 주소는 라우트된 원본 형식이어야 하며 다음 예 중 하나일 수 있습니다(다음 예에만 국한되는 것은 아님).

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

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

기본적으로 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 매핑 테이블에 지정된 샘플 IP 주소를 백엔드 저장소에 연결되는 네트워크에 있는 릴레이 시스템의 IP 주소로 바꾸어야 합니다.

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

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

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

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

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

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

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

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

구현된 LMTP 프로토콜

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

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

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

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

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

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

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

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

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

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

표 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 채널을 통해 백엔드 서버에 전달되도록 주소를 생성하는 것입니다. 생성된 주소는 라우팅된 원본 주소이며 그 형식은 다음과 같습니다.

이전 목차 색인 다음
Sun Java System Messaging Server 6 2005Q1 관리 설명서