test

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

메일 처리 및 전달 구성

서버가 특정 기준에 따라 메일 전달을 시도하도록 구성할 수 있습니다. 또한, 서비스 작업 처리 제한, 새 SMTP 채널 스레드 생성 시기 등과 같은 작업 처리 매개 변수를 지정할 수 있습니다. 이 절은 다음 내용으로 구성되어 있습니다.

메일 처리 및 전달에 대한 개념 정보는 표 12–24를 참조하십시오.

메일 처리 및 전달 구성은 이 절에서 설명하는 키워드를 요약해서 보여 줍니다.

표 12–24 메일 처리 및 전달 키워드

키워드 

정의 

즉시 전달

메일 즉시 전달에 대한 사양을 정의합니다.

immnonurgent

높음, 중간 및 낮음 우선 순위 메일을 제출하면 바로 전달을 시작합니다. 

채널 방향

채널을 사용하는 프로그램 유형을 지정합니다.

bidirectional 

마스터 및 슬레이브 프로그램에서 사용되는 채널입니다. 

master 

마스터 프로그램에서 사용되는 채널(master)입니다.

slave 

슬레이브 프로그램에서 사용되는 채널(slave)입니다.

지연 전달

지연 작업 전달에 대한 사양을 정의합니다.

backoff

지연 메일의 재전달 시도 간격을 지정합니다. normalbackoff, nonurgentbackoff, urgentbackoff에 의해 대체될 수 있습니다.

deferred

Deferred-delivery: 헤더 행을 수락하고 인식합니다.

nodeferred

기본값입니다. Deferred-delivery: 헤더 행을 수락하지 않음을 지정합니다.

nonurgentbackoff

낮음 우선 순위 메일의 재전달 시도 간격입니다. 

normalbackoff

중간 우선 순위 메일의 재전달 시도 간격입니다. 

urgentbackoff

높음 우선 순위 메일의 재전달 시도 간격입니다. 

크기 기반 메일 우선 순위

메일 크기를 기반으로 메일의 우선 순위를 정의합니다.

nonurgentblocklimit

이 크기 이상인 메일의 우선 순위를 낮음(두 번째 우선 순위 클래스) 이하로 지정합니다. 즉, 해당 메일은 항상 다음 정기 작업이 처리되는 동안 대기한 후 처리됩니다. 

normalblocklimit

이 크기 이상인 메일의 우선 순위를 낮음으로 지정합니다. 

urgentblocklimit

이 크기 이상인 메일의 우선 순위를 중간으로 지정합니다. 

채널 실행 작업의 처리 풀

작업 우선 순위와 지연 수준이 서로 다른 메일 처리를 위한 풀을 지정합니다.

pool

채널이 실행되는 풀을 지정합니다. 

after

채널이 실행되기 이전의 시간 지연을 지정합니다. 

서비스 작업 제한

서비스 작업 수와 작업당 처리할 최대 메일 파일 수를 지정합니다.

maxjobs

채널에 대해 동시에 실행될 수 있는 최대 작업 수를 지정합니다. 

filesperjob

단일 작업에서 처리할 대기열 항목 수를 지정합니다. 

SMTP 채널 스레드

 

threaddepth

다중 스레드 SMTP 클라이언트를 사용하여 새 스레드를 트리거하는 메일 수입니다. 

다중 주소 확장

수신자가 여러 명인 메일의 처리를 정의합니다.

expandlimit

주소 수가 이 제한을 초과할 경우 받는 메일을 “오프라인”으로 처리합니다. 

expandchannel

expandlimit 적용으로 인해 지연된 확장을 수행할 채널을 지정합니다. 

holdlimit

주소 수가 이 제한을 초과할 경우 받는 메일을 보관합니다. 

트랜잭션 제한

연결 트랜잭션 제한을 지정합니다.

transactionlimit 

연결당 허용되는 메일 수를 제한합니다. 

전달할 수 없는 메일 알림

전달할 수 없는 메일 알림을 보내는 시기를 지정합니다.

notices

알림을 보낸 후 메일이 반환되기 이전에 경과할 수 있는 시간을 지정합니다. 

nonurgentnotices

우선 순위가 낮은 메일에 대해 알림을 보내고 메일을 반환하기 전에 경과할 수 있는 시간을 지정합니다. 

normalnotices

우선 순위가 중간인 메일에 대해 알림을 보내고 메일을 반환하기 전에 경과할 수 있는 시간을 지정합니다. 

urgentnotices

우선 순위가 높은 메일에 대해 알림을 보내고 메일을 반환하기 전에 경과할 수 있는 시간을 지정합니다. 

채널 방향 설정

키워드: master, slave, bidirectional

세 키워드를 사용하여 채널이 마스터 프로그램(master), 슬레이브 프로그램(slave) 또는 두 프로그램 모두(bidirectional )에서 사용되는지 여부를 지정합니다. 이 키워드를 지정하지 않을 경우 기본값은 bidirectional입니다. 이러한 키워드는 메일을 채널의 대기열에 넣을 때 MTA가 전달 작업을 시작하는지 여부를 지정합니다.

이러한 키워드의 사용은 해당 채널 프로그램의 기본 특성을 반영합니다. MTA가 지원하는 다양한 채널 설명은 이러한 키워드를 사용해야 하는 시기와 위치를 나타냅니다.

지연 전달 날짜 구현

키워드: deferred, nodeferred, immnonurgent

deferred 채널 키워드는 Deferred-delivery: 헤더 행을 인식하고 준수합니다. deferred 전달 날짜가 미래 날짜인 메일은 해당 날짜가 만료되어 반환되거나 지연 전달 날짜가 될 때까지 채널 대기열에 보관됩니다. Deferred-delivery: 헤더 행의 형식 및 작업에 대한 자세한 내용은 RFC 1327을 참조하십시오.

기본값은 nodeferred 키워드입니다. 지연 메일 처리에 대한 지원이 RFC 1327에 규정되어 있지만 지연 메일 처리를 실제로 구현하면 메일 시스템을 디스크 할당량의 확장으로 효과적으로 사용할 수 있습니다.

키워드 immnonurgent는 높음, 중간 및 낮음 우선 순위 메일을 제출하면 바로 전달을 시작합니다.

전달에 실패한 메일에 대한 재시도 간격 지정

키워드: backoff, nonurgentbackoff, normalbackoff, urgentbackoff, notices

기본적으로 전달에 실패한 메일에 대한 전달 재시도 간격은 메일의 우선 순위에 따라 다릅니다. 전달 시도 사이의 기본 간격(분)은 아래에 나와 있습니다. 우선 순위 뒤의 첫 번째 숫자는 최초 전달 실패 후 첫 번째 전달 재시도가 시도될 때까지의 시간(분)을 나타냅니다.

urgent: 30, 60, 60, 120, 120, 120, 240
normal: 60, 120, 120, 240, 240, 240, 480
nonurgent: 120, 240, 240, 480, 480, 480, 960

우선 순위가 높은 메일의 경우 최초 전달 실패 후 30분 뒤, 첫 번째 전달 재시도 후 60분 뒤, 두 번째 재시도 후 60분 뒤, 세 번째 재시도 후 120분 뒤 등의 간격으로 재시도가 시도됩니다. 지정된 마지막 시도 이후의 재시도는 동일한 간격으로 반복됩니다. 따라서, 우선 순위가 높은 메일은 이러한 전달 재시도가 240분 간격으로 수행됩니다.

전달 시도는 notices, nonurgentnotices, normalnotices 또는 urgentnotices 키워드에 지정된 기간 동안 계속됩니다. 전달이 성공적으로 이루어질 수 없으면 전달 실패 알림이 생성되고 메일은 보낸 사람에게 반환됩니다. notices 키워드에 대한 자세한 내용은 알림 메일 전달 간격 설정을 참조하십시오.

backoff 키워드를 사용하면 다양한 우선 순위를 갖는 메일에 대한 전달 재시도 간격 설정을 사용자 정의할 수 있습니다. nonurgentbackoff는 우선 순위가 낮은 메일에 대한 간격을 지정하고, normalbackoff는 우선 순위가 보통인 메일에 대한 간격을 지정하고, urgentbackoff는 우선 순위가 높은 메일에 대한 간격을 지정합니다. 이러한 키워드를 지정하지 않으면 우선 순위에 관계 없이 backoff에 의해 모든 메일에 대한 간격이 지정됩니다.

예를 들면 다음과 같습니다.

urgentbackoff "pt30m" "pt1h" "pt2h" "pt3h" "pt4h" "pt5h" "pt8h" "pt16h"

여기서 우선 순위가 높은 메일의 경우 최초 전달 실패 후 30분 뒤, 첫 번째 전달 시도 후 1시간 뒤(최초 실패 후 1시간 30분 뒤), 두 번째 전달 시도 후 2시간 뒤, 세 번째 시도 후 3시간 뒤, 네 번째 시도 후 4시간 뒤, 다섯 번째 시도 후 5시간 뒤, 여섯 번째 시도 후 8시간 뒤, 일곱 번째 전달 시도 후 16시간 뒤에 각각 전달 재시도가 수행됩니다. 후속 시도는 notices 키워드에 지정된 기간까지 16시간마다 수행됩니다. 전달이 성공적으로 이루어질 수 없으면 전달 실패 알림이 생성되고 메일은 보낸 사람에게 반환됩니다. 간격 구문은 ISO 8601P에 나와 있으며 Sun Java System Messaging Server Administration Reference에도 설명되어 있습니다.

다음 예에서,

normalbackoff "pt30m" "pt1h" "pt8h" "p1d" "p2d” "p1w"

우선 순위가 보통인 메일의 경우 최초 전달 실패 후 30분 뒤, 첫 번째 전달 시도 후 1시간 뒤, 두 번째 시도 후 8시간 뒤, 세 번째 시도 후 1일 뒤, 네 번째 시도 후 2일 뒤, 다섯 번째 시도 후 1주일 뒤에 전달 재시도가 각각 수행되고 이후에는 notices 키워드에 지정된 기간까지 1주일마다 전달 재시도가 반복됩니다. 전달이 성공적으로 이루어질 수 없으면 전달 실패 알림이 생성되고 메일은 보낸 사람에게 반환됩니다.

마지막 예에서,

backoff "pt30m" "pt120m" "pt16h" "pt36h" "p3d"

모든 실패한 메일의 경우 nonurgentbackoff, normalbackoff 또는 urgentbackoff 키워드에 의해 대체되지 않는 한, 메일 우선 순위에 관계 없이 최초 전달 실패 후 30분 뒤, 첫 번째 재시도 후 2시간 뒤, 두 번째 재시도 후 16시간 뒤, 세 번째 재시도 후 36시간 뒤, 네 번째 재시도 후 3일 뒤에 전달 재시도가 각각 수행되고 이후에는 notices 키워드에 지정된 기간까지 3일마다 전달 재시도가 수행됩니다. 전달이 성공적으로 이루어질 수 없으면 전달 실패 알림이 생성되고 메일은 보낸 사람에게 반환됩니다.

채널 실행 작업의 처리 풀

키워드: pool

채널을 동일한 풀 내에서 실행하여 여러 채널이 자원을 공유하도록 구성할 수 있습니다. 다른 채널을 특정 채널에 전용인 풀에서 실행하도록 구성할 수 있습니다. 각 풀 내에서 메일은 메일 우선 순위에 따라 서로 다른 처리 대기열에 자동으로 정렬됩니다. 풀 내에서 우선 순위가 높은 메일이 우선 순위가 낮은 메일보다 먼저 처리됩니다. 크기 기반 메일 우선 순위를 참조하십시오.

pool 키워드를 사용하면 작업이 만들어지는 풀을 채널 단위로 선택할 수 있습니다. pool 키워드는 현재 채널에 대한 전달 작업을 풀링해야 하는 풀 이름 앞에 와야 합니다. 풀 이름은 11자를 초과할 수 없습니다.

Job Controller 개념 및 구성에 대한 자세한 내용은 Job Controller 파일, Job Controller 파일 및 서비스 작업 제한을 참조하십시오.

서비스 작업 제한

키워드: maxjobs, filesperjob

메일이 채널의 대기열에 배치될 때마다 Job Controller는 해당 메일을 전달하기 위해 실행 중인 작업이 있는지 확인합니다. 여기에는 새 작업 프로세스를 시작하거나, 스레드를 추가하거나, 단순히 작업이 이미 실행 중인지 확인하는 것이 포함됩니다. 단일 서비스 작업으로 모든 메일 전달을 확인하지 못할 수도 있습니다. Job Controller 개념 및 구성에 대한 자세한 내용은 Job Controller 파일, 채널 실행 작업의 처리 풀 및 Job Controller를 참조하십시오.

특정 설치의 경우 메일 전달을 위해 시작할 프로세스 및 스레드에 대한 합리적인 최대 수가 있습니다. 이 최대 수는 프로세서 수, 디스크 속도, 연결 특징 등의 요인에 따라 다릅니다. MTA 구성에서는 다음을 제어할 수 있습니다.

지정된 채널에 대해 실행을 시작하는 최대 프로세스 수는 채널에 설정된 maxjobs의 최대값이며 채널이 실행되는 풀에 대해 설정된 JOB_LIMIT입니다.

메일을 처리해야 한다고 가정합니다. 일반적으로 Job Controller는 새 프로세스를 다음과 같이 시작합니다.

특히, SMTP 채널의 경우 서로 다른 호스트에 대한 대기열에 메일이 포함될 경우 새 스레드 또는 프로세스가 시작됩니다. 따라서, SMTP 채널의 경우 Job Controller는 새 프로세스를 다음과 같이 시작합니다. 메일을 처리해야 한다고 가정합니다.

SMTP 채널 스레드를 참조하십시오.

filesperjob 키워드를 사용하여 MTA에서 추가 서비스 작업을 만들 수 있습니다. 이 키워드는 여러 서비스 작업을 만들어 처리하기 전에 연결된 채널로 보내야 하는 대기열 항목(파일) 수를 지정하는 단일의 양의 정수 매개 변수를 가집니다. 0보다 작거나 같은 값을 지정하면 하나의 서비스 작업만 대기열에 포함하라는 요청으로 해석됩니다. 키워드를 지정하지 않으면 0의 값을 지정한 것과 같습니다. 이 키워드의 효과는 최대화됩니다. 즉, 계산된 높은 숫자가 실제로 만들어지는 서비스 작업 수가 됩니다.

filesperjob 키워드는 실제 대기열 항목 또는 파일 수를 지정된 값으로 나눕니다. 지정된 메일의 대기열 항목 수는 single 및 single_sys 키워드의 사용, 메일링 목록의 헤더 수정 작업 사양 등 많은 요소에 의해 제어됩니다.

maxjobs 키워드는 동시에 실행될 수 있는 총 서비스 작업 수에 대한 최대값을 지정합니다. 이 키워드는 정수 값이 뒤에 와야 합니다. 계산된 서비스 작업 수가 이 값보다 더 큰 경우 maxjobs 작업만 실제로 만들어집니다. maxjobs를 지정하지 않은 경우 이 값의 기본값은 100입니다. 일반적으로 maxjobs는 채널이 사용되는 서비스 풀에 관계 없이 동시에 실행될 수 있는 총 작업 수보다 작거나 같은 값으로 설정됩니다.

연결 트랜잭션 제한 설정

키워드: transactionlimit

transactionlimit는 연결당 허용되는 메일 수를 제한합니다. 이 키워드를 사용하여 다음과 같은 방법으로 공격자를 차단할 수 있습니다.

공격자가 SMTP를 통해 연결한 다음 많은 RCPT TO 명령을 보내 합법적인 전자 메일 주소를 추측하려고 시도할 수 있습니다. 트랜잭션에 허용되는 유효하지 않은 RCPT TO 수를 제한하여 그런 공격을 차단할 수 있습니다. 공격자는 SMTP 세션에 허용되는 트랜잭션 수를 제한할 수 있는 transactionlimit가 있는 여러 트랜잭션을 사용하여 응답할 수 있습니다. 공격자가 여러 세션을 사용할 수 있지만 과도한 비용이 듭니다. 연결 억제를 사용하여 대부분의 경우에 실제로 많은 비용이 들게 하는 다양한 방법으로 세션 수를 제한할 수 있습니다.

이 비용은 우리 쪽에 부과되는 비용이지만,일부 SMTP 클라이언트는 수신자 제한, 트랜잭션 제한 또는 두 가지 모두에 잘못된 반응을 나타내는 경우도 있습니다. 이러한 클라이언트에 대한 예외를 만들어야 합니다. 그러나, TCP 채널 옵션은 SMTP 서버에 무조건적으로 적용됩니다. 솔루션은 채널 키워드와 switchchannel을 사용하여 문제가 있는 에이전트의 경로를 더 큰 제한이 있는 채널로 지정하는 것입니다.

크기 기반 메일 우선 순위

키워드: urgentblocklimit, normalblocklimit, nonurgentblocklimit

urgentblocklimit, normalblocklimit 및 nonurgentblocklimit 키워드를 사용하여 MTA에 크기 기반 메일의 우선 순위를 낮추도록 지시할 수 있습니다. 이러한 키워드는 메일을 처리할 때 Job Controller가 적용하는 우선 순위에 영향을 미칩니다.

SMTP 채널 스레드

키워드: threaddepth,

다중 스레드 SMTP 클라이언트는 각 스레드에 대한 대상별로 보내는 메일을 정렬합니다. threaddepth 키워드를 사용하면 다중 스레드 SMTP 클라이언트에 한 스레드에서 지정된 수의 메일만 처리하도록 지시하여 대상이 같은 메일(일반적으로 한 스레드에서 모두 처리됨)일 경우에도 추가 스레드를 사용하게 할 수 있습니다. 이 키워드의 기본값은 10입니다.

채널의 백로그가 threaddepth의 배 이상으로 증가할 때마다 Job Controller는 해당 채널의 대기열에 포함된 메일 처리를 전담하는 처리량을 높이려고 시도합니다. 다중 스레드 채널의 경우 Job Controller는 해당 채널에 대한 메일을 처리하는 작업에서 새 스레드를 시작하게 합니다. 또는 모든 작업이 해당 채널에 대해 허용된 최대 수의 스레드(tcp_* 채널에 대한 옵션의 MAX_CLIENT_THREADS)를 갖는 경우 새 프로세스를 시작합니다. 단일 스레드 채널의 경우 새 프로세스를 시작합니다. 채널에 대한 작업 제한(maxjobs) 또는 풀에 대한 작업 제한(JOB_LIMIT)에 도달한 경우 Job Controller는 새 작업을 시작하지 않습니다.

기본적으로 threaddepth는 적극적인 작업을 예약하는 방법을 제어합니다. 다음의 두 가지 다른 상황을 고려해 보겠습니다.

(1) 일반(아웃바운드) SMTP 채널

(2) 스마트 호스트에 전달하는 SMTP 채널

Job Controller는 특정 채널을 대상으로 하는 메일을 대상 호스트별로 정렬하고 이러한 대상 호스트의 백로그에 기초하여 메일을 처리하기 위한 작업을 예약합니다.

첫 번째 경우는 많은 수의 대상 호스트가 있고 대상 호스트의 백로그가 대부분 작습니다. 실행되는 스레드의 수가 많으며 aol, yahoo, hotmail 등과 같이 대량의 트래픽이 있을 수 있는 대상 호스트를 제외하고는 모두 제대로 작동합니다. 스레드 깊이가 128인 경우 백로그가 128에 도달하면 yahoo에 전달되는 두 번째 스레드만 가져오게 됩니다. 이는 바람직하지 않습니다.

두 번째 경우는 대상 호스트가 하나만 존재하며 해당 호스트에 많은 수의 스레드를 전달 하는 것이 바람직합니다. 어느 경우든 기본값 10은 너무 작을 수 있습니다.

threaddepth를 사용하면 채널이 연결하는 SMTP 서버에서 여러 동시 연결을 처리할 수 있을 때 데몬 라우터 TCP/IP 채널(단일의 특정 SMTP에 연결하는 TCP/IP 채널)에서 다중 스레딩을 수행하는 데 특히 유용합니다.

여러 주소 확장

키워드: expandlimit, expandchannel, holdlimit

대부분의 채널은 각 인바운드 메일 전송에서 여러 수신자 주소 사양을 지원합니다. 단일 메일에 많은 수신자 주소가 있는 사양에서는 메일 전송 처리가 지연될 수 있습니다(온라인 지연). 너무 오래 지연될 경우 네트워크 시간 초과가 발생하여 메일 제출 시도가 반복되거나 기타 문제가 발생할 수 있습니다.

MTA는 단일 메일에 대해 지정된 수보다 더 많은 주소를 지정할 경우 지연(오프라인) 처리를 강제하는 특수 기능을 제공합니다. 메일 처리 지연은 온라인 지연을 대폭 줄일 수 있습니다. 그러나 처리 오버헤드가 지연되지만 완전히 제거되지는 않습니다.

예를 들어, 일반 reprocessing 채널과 expandlimit 키워드를 함께 사용하면 이 특수 기능이 활성화됩니다. expandlimit 키워드는 지연 처리 이전에 채널에서 받은 메일에 허용되는 주소 수를 지정하는 정수 인수를 가집니다. expandlimit 키워드를 지정하지 않은 경우 기본값은 무제한입니다. 값이 0이면 채널에서 수신하는 모든 주소에서 지연 처리를 수행합니다.

로컬 채널 또는 reprocessing 채널 자체에는 expandlimit 키워드를 지정하면 안 됩니다. 이러한 키워드를 지정하면 예상치 못한 결과가 발생할 수 있습니다.

지연 처리를 수행하는 데 실제로 사용되는 채널은 expandchannel 키워드를 사용하여 지정할 수 있습니다. expandchannel을 지정하지 않은 경우 reprocessing 채널이 기본적으로 사용되지만 다른 reprocessing 또는 processing 채널을 사용하는 것이 유용한 경우도 있습니다. expandchannel을 통해 지연 처리를 위한 채널을 지정하는 경우 해당 채널이 reprocessing 또는 processing 채널이어야 합니다. 다른 종류의 채널 사양은 예측할 수 없는 결과를 초래할 수 있습니다.

expandlimit 키워드를 적용하려면 reprocessing 채널이나 지연 처리를 수행하는 데 사용되는 모든 채널을 MTA 구성 파일에 추가해야 합니다. MTA 구성 유틸리티를 사용하여 구성을 작성한 경우 reprocessing 채널이 이미 있어야 합니다.

지나치게 큰 수신자 주소 목록은 UBE(Unsolicited Bulk Email) 특성을 가질 수 있습니다. holdlimit 키워드는 수신자가 지정된 수보다 많은 채널에서 수신하는 메일에 .HELD 메일 표시를 하고 reprocess 채널 또는 expandchannel 키워드를 통해 지정한 모든 채널의 대기열에 포함하도록 MTA에 지시합니다. 이러한 파일은 MTA 포스트마스터가 수동으로 처리할 때까지 reprocess 대기열에 처리되지 않은 상태로 유지됩니다.

서비스 변환 사용

키워드: service, noservice

service 키워드는 CHARSET-CONVERSION 항목에 관계 없이 서비스 변환을 무조건적으로 사용합니다. noservice 키워드를 설정하면 이 채널에 수신되는 메일에 대해 CHARSET-CONVERSION을 통해 서비스 변환을 사용해야 합니다.