|
| |
| Sun Java System Messaging Server 6 2004Q2 관리 설명서 | |
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 전달 기능MTA의 LMTP 서버가 백엔드 메일 저장소에 메일을 전달하는 데 보다 효율적인 이유는 다음과 같습니다.
LMTP를 사용하지 않는 2계층 배포의 메일 처리그림 15-1은 LMTP를 사용하지 않는 2계층 배포 시나리오의 다음 메일 처리 설명을 그림 형식으로 설명합니다.
그림 15-1 LMTP를 사용하지 않는 2계층 배포
LMTP 없이 저장소 시스템의 앞면에 중계가 있는 2수준 배포에서 인바운드 메일 처리는 중계 시스템의 디스패처가 선택하고 tcp_smtp_server 프로세스에 전달되는 SMTP 포트에 대한 연결에서 시작됩니다. 이 프로세스에서는 인바운드 메일에 대해 다음을 포함한 많은 작업을 수행합니다.
그러면 smtp_client 프로세스가 대기열에서 메일 메시지를 선택하여 메일 호스트에 보냅니다. 메일 호스트에서도 비슷한 프로세스가 수행됩니다. 디스패처에서 SMTP에 대한 연결을 선택하여 tcp_smtp_server 프로세스에 전달합니다. 이 프로세스에서는 다음을 포함하여 많은 메일 작업을 수행합니다.
그런 다음 ims_ms 프로세스가 메일 메시지를 선택하여 저장소에 전달하려고 시도합니다.
이 시나리오에서는 대기열에 포함시키는 프로세스가 두 번 수행되고 각 MTA에서 LDAP 조회를 수행합니다.
LMTP를 사용하는 2계층 배포의 메일 처리그림 15-2는 LMTP를 사용하는 2계층 배포 시나리오의 다음 메일 처리 설명을 그림 형식으로 설명합니다.
그림 15-2 LMTP를 사용하는 2계층 배포
LMTP를 배치하고 디스패처에서 중계 시스템의 SMTP에 대한 연결을 선택하여 tcp_smtp_server 프로세스에 전달합니다. 이 프로세스에서는 인바운드 메일에 대해 다음을 포함한 많은 작업을 수행합니다.
user@domain.LMTP 및 user@domain.LMTPNATIVE 형식으로 된 주소가 각각 tcp_lmtp 채널 또는 tcp_lmtpnative 채널을 통해 메일 저장소 시스템에 라우팅됩니다. 이러한 채널은 SMTP 대신 LMTP를 사용하여 백엔드 메일 저장소와 통신합니다. 저장소 시스템에서는 디스패처가 LMTP 포트에 대한 연결을 수신한 다음 lmtp_server 프로세스에 전달합니다. 그런 다음 LMTP가 메일을 사용자의 메일함이나 UNIX 원시 메일함에 넣습니다. 메일이 성공적으로 전달되면 메일이 중계 시스템의 대기열에서 제거됩니다. 성공적으로 전달되지 않은 경우 메일이 중계 시스템에 그대로 남아 있습니다. 메일 저장소의 LMTP 프로세스에서는 주소 또는 메일 처리를 위해 MTA 방법을 사용하지 않습니다.
LMTP 개요대부분의 경우 MTA 자체는 기본적으로 백엔드 서버에 존재하지 않을 수 있습니다. 필요한 유일한 MTA 구성 요소는 다음과 같습니다.
디스패처에는 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에서 사용할 수 있습니다. 이미 일반 데이터베이스를 사용하는 경우에는 이 단계를 건너뛸 수 있습니다.
- 일반 데이터베이스 텍스트 파일을 만들거나 수정합니다.
표시된 것처럼 lmtpnative에 대한 사용자의 특정 전달을 처리하는 항목과 tcp_lmtpcs 채널을 통한 저장소 차원 전달 설정을 처리하는 항목의 두 종류의 항목이 있습니다.
- imta.cnf 파일에 LMTP 다시 쓰기 규칙을 추가합니다.
# 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,$LU%[$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,$LU%[$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
- 구성 변경 사항을 적용합니다.
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 subdirs 20
tcp_lmtpss-daemon
!
! tcp_lmtpsn (LMTP server - native)
tcp_lmtpsn lmtp subdirs 20
tcp_lmtpsn-daemon
기본적으로 LMTP 채널 정의는 주석 처리됩니다. LMTP를 작동하려면 LMTP의 주석 처리를 제거해야 합니다.
LMTP를 통해 메일 저장소와 전체 MTA를 갖는 백엔드 시스템에 메일을 보내도록 중계 구성
백엔드 저장소에 MTA의 전체 기능을 제공하면서 LMTP를 사용하여 로드를 절약해야 하는 경우가 있습니다. 예를 들어, 백엔드 저장소에서 프로그램을 전달할 수 있습니다. 이 경우 위에서 설명한 것처럼 LMTP를 사용하여 백엔드 저장소에 전달하도록 중계를 구성해야 합니다.
전체 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입니다.
메일 발송자 주소를 검사하거나 변환하지 않습니다. size= 매개 변수는 전달할 메일의 크기(바이트)를 지정합니다. 이 값은 프로토콜에 표시되는 메일의 정확한 크기입니다. 정확한 메일 크기가 꼭 필요한 것은 아니지만 대개 실제 메일 크기는 이 크기를 초과하지 않습니다. LMTP 서버는 메일을 받도록 메모리에 이 크기의 버퍼를 할당합니다.
받을 때는 수신자 주소를 확인하지 않지만 나중에 사용할 수 있도록 수신자 목록이 작성됩니다. 주소의 @domain 부분은 주 도메인의 uids에서는 생략되고 +folder 부분은 선택 사항입니다. 이 형식은 MTA의 메일 저장소 채널에 사용되는 것과 동일한 주소 형식입니다.
xquota= 매개 변수는 최대 총 크기와 최대 메일 수로 구성되는 사용자의 메일 할당량을 지정합니다. MTA는 사용자에 대한 LDAP 조회를 통해 주소 변환을 수행하는 동안 검색되는 이 메일 할당량 정보를 제공합니다. 이 정보는 메일 저장소의 할당량 정보를 디렉토리와 동기화된 상태로 유지하는 데 사용됩니다. 할당량 정보를 가져오는 것은 성능에 영향을 미치지 않습니다.
xdflg= 매개 변수는 비트 필드로 해석되는 숫자를 지정합니다. 이러한 비트 수는 메일이 전달되는 방법을 제어합니다. 예를 들어, 비트 값을 2로 설정하면 사용자에 대해 할당량이 초과하더라도 메일이 전달됩니다.
이 상호 작용은 수신자마다 한 번씩 여러 번 반복될 수 있습니다.
그런 다음 LMTP 클라이언트가 SMTP에서처럼 전체 메일을 점으로 표시하여 보냅니다. 메일은 한 행에 점(.) 하나로 끝납니다. 메일 크기가 초과될 경우 LMTP 서버는 다음을 보냅니다.
그런 다음 연결을 종료합니다.
메일이 올바르게 전달되면 LMTP 서버는 RCPT TO:행에 지정된 각 수신자에 대한 상태를 LMTP 클라이언트에게 다시 보냅니다. 예를 들어, 메일이 성공적으로 전달될 경우 다음과 같은 응답을 받습니다.
여기서 address는 RCPT TO:행에 표시된 주소입니다.
변환은 다른 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 채널을 통해 백엔드 서버에 전달되도록 주소를 생성하는 것입니다. 생성된 주소는 라우팅된 원본 주소이며 그 형식은 다음과 같습니다.
