test

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

10장 MTA 서비스 및 구성 정보

이 장에서는 일반 MTA 서비스 및 구성에 대해 설명합니다. 더 구체적이고 자세한 설명은 다른 장에서 확인할 수 있습니다. 이 장은 다음 내용으로 구성되어 있습니다.

MTA 구성 컴파일

imta.cnf, mappings, aliases 또는 option.dat와 같은 MTA 구성 파일이 수정될 때마다 구성을 다시 컴파일해야 합니다. 이 명령은 구성 파일을 공유 메모리(UNIX) 또는 동적 링크 라이브러리(NT)의 단일 이미지로 컴파일합니다.

컴파일된 구성은 재로드 가능한 정적 및 동적 부분을 가집니다. 동적 부분이 변경되고 imsimta reload를 실행하면 실행 중인 프로그램에서 동적 데이터를 재로드합니다. 동적 부분은 매핑 테이블, 별칭 및 조회 테이블입니다.

구성 정보를 컴파일하는 주된 이유는 성능 때문입니다. 또한 컴파일된 구성이 사용 중일 때 구성 파일 자체가 “live” 상태가 아니므로 컴파일된 구성을 사용하면 구성 변경 사항을 더 편리하게 테스트할 수 있습니다.

MTA의 구성 요소(예: 채널 프로그램)는 구성 파일을 읽어야 할 때마다 컴파일된 구성이 존재하는지 먼저 확인합니다. 컴파일된 구성이 존재할 경우 실행 중인 프로그램에 이미지가 추가됩니다. 이미지 추가 작업이 실패할 경우 MTA는 텍스트 파일을 읽는 이전의 방법으로 돌아갑니다.

reverse, forward 또는 일반 데이터베이스를 변경한 경우 변경 내용을 적용하려면 imsimta reload 명령을 실행합니다. imta.cnf, mappings 파일, aliases, conversions 또는 option.dat 파일을 변경한 경우 이 변경 내용이 job_controller에 영향을 주지 않으면 imsimta restart smtp 뒤에 imsimta cnbuild 명령을 실행해야 합니다. dispatcher.cnf를 변경한 경우에는 imsimta restart dispatcher 명령을 실행해야 합니다. 컴파일된 구성에 포함된 구성 파일을 변경한 경우 이 변경 내용이 Job Controller에만 영향을 주고 SMTP 서버에는 영향을 주지 않으면 일반적으로 imsimta cnbuild 및 imsimta restart job_controller 명령을 실행해야 합니다.

컴파일된 구성에 포함된 구성 파일을 변경한 경우 이 변경 내용이 SMTP 서버와 Job Controller에 둘 다 영향을 주면 다음 명령을 실행해야 합니다.


imsimta cnbuild
imsimta restart smtp 
imsimta restart job_controller

이러한 명령에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 MTA Commands를 참조하십시오.

다음과 같은 경우에도 Job Controller를 다시 시작해야 합니다.

MTA 구성에는 imta.cnf와 이 파일에 포함된 모든 파일(예: internet.rules), alias 파일, mappings 파일, conversions 파일, option.dat 파일(및 이 파일에 포함된 모든 파일), imta.filter, reverse, forward 및 일반 데이터 파일, 일부 configutil 매개 변수가 포함됩니다.

imta.cnf에 대한 위의 모든 변경(예: 채널 정의에서 키워드 추가/변경) 시에는 Job Controller의 다시 시작 여부에 관계 없이 기본 명령인 imsimta cnbuild도 필요합니다.

위의 조건 중 하나로 인해 다시 시작해야 하는 경우가 아니면 특히 대기열에 많은 메일이 있는 경우 Job Controller를 다시 시작하지 않도록 하십시오.

Job Controller를 다시 시작하지 않아도 되는 경우가 많으며 Job Controller를 다시 시작하면 메일 재시도 횟수, 지연된 알림 메일, 바운스된 메일 등이 재설정되므로 imsimta refresh 명령을 사용하는 것은 권장되지 않습니다.

MTA 구성 파일

주 MTA 구성 파일은 imta.cnf입니다. 기본적으로 이 파일은 msg_svr_base/config/imta.cnf에 위치합니다. 이 파일은 채널 다시 쓰기 규칙뿐만 아니라 MTA 채널 정의를 포함합니다. 다시 쓰여진 대상 주소와 관련된 채널은 대상 채널이 됩니다. 일반적으로 기본 imta.cnf를 사용하면 시스템이 적절하게 작동합니다.

이 절에서는 MTA 구성 파일에 대해 간략하게 소개합니다. MTA 구성 파일을 구성하는 다시 쓰기 규칙과 채널 정의를 구성하는 방법에 대한 자세한 내용은 11 장, 다시 쓰기 규칙 구성 및 12 장, 채널 정의 구성을 참조하십시오.

MTA 구성 파일을 수정하여 사이트에서 사용되는 채널을 설정하고 어떤 채널이 다시 쓰기 규칙을 통해 어떤 종류의 주소를 담당하는지 지정합니다. 이 구성 파일은 주소 유형을 적절한 채널과 연관시키는 전송 경로(다시 쓰기 규칙)와 사용 가능한 전송 방법(채널)을 지정하여 전자 메일 시스템의 레이아웃을 설정합니다.

구성 파일은 도메인 다시 쓰기 규칙과 채널 정의의 두 부분으로 구성됩니다. 도메인 다시 쓰기 규칙은 파일에서 앞 부분에 나타나며 빈 행으로 채널 정의와 구분됩니다. 채널 정의는 통틀어서 채널 테이블이라고 합니다. 개별 채널 정의는 채널 블록을 구성합니다.

imta.cnf 구성 파일의 다음 예는 메일을 적절한 채널로 라우팅하는 데 다시 쓰기 규칙이 사용되는 방법을 보여 줍니다. 가능한 한 간단하게 하기 위해 도메인 이름은 사용되지 않았습니다. 다시 쓰기 규칙은 구성 파일의 상반부에 나타나며 채널 정의는 그 뒤를 이어 구성 파일의 하반부에 나타납니다.


! test.cnf - An example configuration file.   (1)!
! This is only an example of a configuration file. It serves
! no useful purpose and should not be used in a real system.
!
! Part I: Rewrite rules
a     $U@a-daemon           (2)
b     $U@b-daemon
c     $U%c@b-daemon
d     $U%d@a-daemon    
      (3)
! Part II: Channel definitions
l      (4)
local-host

a_channel defragment charset7 usascii      (5)
a-daemon

b_channel noreverse notices 1 2 3
b-daemon

</opt/SUNWmsgsr/msg-tango/table/internet.rules    (6)

다음 목록에는 위 구성 파일의 주요 항목(괄호로 묶인 굵은체의 숫자가 표시된)이 설명되어 있습니다.

  1. 느낌표(!)는 주석 행을 포함하는 데 사용됩니다. 느낌표는 첫 번째 열에 표시되어야 합니다. 그 밖의 다른 위치에 표시된 느낌표는 리터럴 느낌표로 해석됩니다.

  2. 다시 쓰기 규칙은 구성 파일의 상반부에 나타납니다. 다시 쓰기 규칙의 행에는 빈 행이 포함될 수 없습니다. 첫 번째 열에서 느낌표로 시작되는 주석 행은 허용됩니다.

  3. 구성 파일에 나타나는 첫 번째 빈 행은 다시 쓰기 규칙 섹션의 끝이자 채널 블록의 시작을 의미합니다. 이러한 정의를 통틀어서 MTA가 사용할 수 있는 채널 및 각 채널과 연관된 이름을 정의하는 채널 호스트 테이블이라고 합니다.

  4. 처음에 표시되는 채널 블록은 일반적으로 로컬 또는 l 채널입니다. 그런 다음 빈 행으로 각 채널 블록이 서로 분리됩니다. (l 채널 앞에 나타날 수 있는 defaults 채널은 예외입니다.)

  5. 일반 채널 정의는 채널 이름(a_channel), 채널 구성을 정의하는 일부 키워드(defragment charset7 usascii) 및 채널 태그라고도 부르는 라우팅 시스템(a-daemon)으로 구성됩니다.

  6. 구성 파일에는 다른 파일의 내용이 포함될 수 있습니다. 첫 번째 열에 보다 작음 기호(<)가 있을 경우 해당 행의 나머지 부분은 파일 이름으로 간주되며 파일 이름은 항상 절대 및 전체 파일 경로여야 합니다. 이 경우 파일이 열리고 파일의 내용이 해당 지점에서 구성 파일에 결합됩니다. 포함 파일은 최대 3개 수준 깊이까지 중첩될 수 있습니다. 구성 파일이 세계 공용인 것처럼 구성 파일에 포함된 모든 파일도 세계 공용이어야 합니다.

표 10–1에서는 앞의 구성에 의해 일부 예제 주소가 라우팅되는 방법을 보여 줍니다.

표 10–1 주소 및 관련 채널

주소 

다음 채널의 대기열에 넣음 

u@a

a_channel

u@b

b_channel

u@c

c_channel

u@d

d_channel

MTA 구성 파일에 대한 자세한 내용은 다시 쓰기 규칙, 채널 정의 및 11 장, 다시 쓰기 규칙 구성”을 참조하십시오.

주 –

imta.cnf 파일이 변경될 때마다 MTA 구성을 다시 컴파일해야 합니다. MTA 구성 컴파일을 참조하십시오.

매핑 파일

MTA의 구성 요소는 대부분 테이블 조회 지향의 정보를 사용합니다. 이 유형의 테이블은 입력 문자열을 출력 문자열로 변환, 즉 매핑하는 데 사용됩니다. 매핑 테이블이라고 부르는 이러한 테이블은 대개 두 개의 열로 제공됩니다. 첫 번째(왼쪽) 열은 일치시킬 가능한 입력 문자열(패턴)을 제공하며 두 번째(오른쪽) 열은 입력 문자열이 매핑되는 결과 출력 문자열(템플리트)을 제공합니다.

대부분의 MTA 데이터베이스(다른 유형의 MTA 데이터를 포함하는 데이터베이스로서 매핑 테이블과 혼동해서는 안 됨)는 바로 이 테이블 유형의 인스턴스입니다. 그러나 MTA 데이터베이스 파일은 와일드카드 조회 기능을 제공하지 않으므로 와일드카드 일치를 위해 전체 데이터베이스를 스캔해야 한다는 점에서 본질적으로 비효율적입니다.

MTA mappings 파일은 여러 매핑 테이블을 지원합니다. 와일드카드 기능뿐만 아니라 다단계 및 반복 매핑 방법이 제공합니다. 이 방식은 특히 항목 수가 많을 경우에 데이터베이스를 사용하는 것보다 컴퓨팅 작업이 많이 요구됩니다. 그러나 동일한 데이터베이스에서 대부분의 항목을 불필요하게 만드는 유연성이 있기 때문에 결과적으로 전체 오버헤드가 줄어들 수 있습니다.

매핑 테이블은 MTA mappings 파일에 저장됩니다. 이 파일은 MTA tailor 파일에서 IMTA_MAPPING_FILE 옵션으로 지정되며 기본적으로 msg_svr_base/config/mappings입니다. mappings 파일의 내용은 재로드 가능한 섹션의 일부로 컴파일된 구성에 통합됩니다( MTA 구성 컴파일 참조). 이 파일은 세계 공용이어야 합니다. 세계 공용 액세스를 허용하지 않을 경우 오류 동작이 발생합니다. mappings 파일이 변경될 때마다 MTA 구성을 다시 컴파일해야 합니다. MTA 구성 컴파일을 참조하십시오.

표 10–2에는 이 설명서에서 다루는 매핑 테이블이 나열되어 있습니다.

표 10–2 Messaging Server 매핑 테이블

매핑 테이블 

페이지 

설명 

AUTH_REWRITE

인증 작업(SASL)에서 얻은 주소 지정 정보를 사용하여 헤더 및 봉투 주소를 수정하기 위해 authrewrite 키워드와 함께 사용됩니다. TCP/IP 연결 및 DNS 조회 지원을 참조하십시오.

CHARSET-CONVERSION

어떤 종류의 채널 간 문자 세트 변환 및 메일 서식 재설정을 수행해야 하는지 지정하는 데 사용됩니다. 문자 세트 변환 및 메일 형식 다시 지정을 참조하십시오.

COMMENT_STRINGS

주소 헤더 주석(괄호로 묶인 문자열)을 수정하는 데 사용됩니다. 주소 헤더 행의 주석 처리를 참조하십시오.

CONVERSIONS

변환 채널에 대한 메일 트래픽을 선택하는 데 사용됩니다. 변환 처리를 위한 트래픽 선택을 참조하십시오.

FORWARD

별칭 파일이나 별칭 데이터베이스를 사용하여 수행하는 것과 비슷한 전달을 수행하는 데 사용됩니다. 정방향 조회 테이블 및 FORWARD 주소 매핑을 참조하십시오.

FROM_ACCESS

봉투의 보낸 사람 주소에 기초하여 메일을 필터링하는 데 사용됩니다. To 주소가 부적절한 경우 이 테이블을 사용합니다. 액세스 제어 매핑 테이블 - 작업을 참조하십시오.

INTERNAL_IP

내부의 시스템과 서브넷을 인식하는 데 사용됩니다. SMTP 릴레이 추가를 참조하십시오.

MAIL_ACCESS

SEND_ACCESS 및 PORT_ACCESS 테이블에서 발견한 결합된 정보에 기초하여 받는 연결을 차단하는 데 사용됩니다. 액세스 제어 매핑 테이블 - 작업을 참조하십시오.

NOTIFICATION_LANGUAGE

알림 메일을 사용자 정의 또는 현지화하는 데 사용됩니다. 전달 상태 알림 메일 제어를 참조하십시오.

ORIG_MAIL_ACCESS

ORIG_SEND_ACCESS 및 PORT_ACCESS 테이블에서 발견한 결합된 정보에 기초하여 받는 연결을 차단하는 데 사용됩니다. 액세스 제어 매핑 테이블 - 작업을 참조하십시오.

ORIG_SEND_ACCESS

봉투의 보낸 사람 주소, 봉투의 받는 사람 주소, 소스 및 대상 채널에 기초하여 받는 연결을 차단하는 데 사용됩니다. 액세스 제어 매핑 테이블 - 작업을 참조하십시오.

PERSONAL_NAMES

개인 이름(꺽쇠로 구분된 주소 앞의 문자열)을 수정하는 데 사용됩니다. 주소 헤더 행에서 개인 이름 처리를 참조하십시오.

PORT_ACCESS

IP 번호를 기준으로 받는 연결을 차단하는 데 사용됩니다. 액세스 제어 매핑 테이블 - 작업을 참조하십시오.

REVERSE

주소를 내부 형식에서 공용 광고 형식으로 변환하는 데 사용됩니다. 주소를 내부 형식에서 공용 형식으로 변환 을 참조하십시오.

SEND_ACCESS

봉투의 보낸 사람 주소, 봉투의 받는 사람 주소, 소스 및 대상 채널에 기초하여 받는 연결을 차단하는 데 사용됩니다. 액세스 제어 매핑 테이블 - 작업을 참조하십시오.

SMS_Channel_TEXT

사이트 정의 텍스트 변환에 사용됩니다. 사이트 정의 텍스트 변환을 참조하십시오.

X-ATT-NAMES

매핑 테이블에서 매개 변수 값을 검색하는 데 사용됩니다. 변환 항목에서 매핑 테이블 호출을 참조하십시오.

X-REWRITE-SMS-ADDRESS

로컬 SMS 주소 유효성 검사에 사용됩니다. 사이트 정의 주소 유효성 검사 및 변환을 참조하십시오.

매핑 파일의 파일 형식

mappings 파일은 일련의 개별 테이블로 구성됩니다. 각 테이블은 이름으로 시작되며이름의 첫 번째 열에는 항상 알파벳 문자가 옵니다. 테이블 이름 뒤에는 필수적으로 빈 행이 오고 이어서 테이블의 항목이 나타납니다. 항목은 0개 이상의 들여쓰기 행으로 구성되며 각 항목 행은 하나 이상의 공백 또는 탭으로 구분된 두 개의 열로 구성됩니다. 항목 안의 모든 공백은 $ 문자를 사용하여 인용해야 합니다. 각 매핑 테이블 이름 뒤와 각 매핑 테이블 사이에 빈 행이 있어야 하며 단일 테이블의 항목 사이에는 빈 행이 표시될 수 없습니다. 주석은 첫 번째 열에서 느낌표(!)로 시작해야 합니다.

결과 형식은 다음과 같이 나타납니다.


TABLE1_NAME
   pattern1-1    template1-1
   pattern1-2    template1-2
   pattern1-3    template1-3
      .              .
      .              .
      .              .
   pattern1-n    template1-n

TABLE2_NAME
   pattern2-1    template2-1
   pattern2-2    template2-2
   pattern2-3    template2-3
       .            .
       .            .
       .            .
   pattern2-n    template2-n
          .
          .
          .


TABLE3_NAME
           .
          .
          .

매핑 테이블 TABLE2_NAME을 사용하는 응용 프로그램은 pattern2-2 문자열을 template2-2에 지정된 것으로 매핑합니다. 각 패턴이나 템플리트는 최대 252자를 포함할 수 있습니다. 과도한 수의 항목이 막대한 양의 CPU와 메모리를 소비할 수 있지만 매핑에 표시될 수 있는 항목 수에는 제한이 없습니다. 252자를 초과하는 긴 행은 끝에 백슬래시(\)를 포함하여 계속 이어질 수 있습니다. 두 열 사이의 공백과 첫 번째 열 앞에 있는 공백은 생략할 수 없습니다.

중복된 매핑 테이블 이름은 mappings 파일에서 허용되지 않습니다.

매핑 파일에 다른 파일 포함

mappings 파일에 다른 파일이 포함될 수 있습니다. 이렇게 하려면 다음 형식의 행을 사용합니다.


<file-spec

이 행을 사용하면 포함이 나타나는 지점에서 file-spec 파일의 내용이 mappings 파일에 포함됩니다. 파일 지정은 전체 파일 경로(디렉토리 등)를 지정해야 합니다. 이 방식으로 포함된 모든 파일은 세계 공용이어야 합니다. 또한 이러한 포함된 mappings 파일에는 주석이 허용됩니다. 포함은 최대 3개 수준까지 중첩될 수 있습니다. 포함 파일은 mappings 파일이 로드될 때 동시에 로드됩니다. 즉, 포함 파일은 요청 시 로드되지 않으므로 포함 파일 사용과 관련하여 성능 또는 메모리가 절약되지는 않습니다.

매핑 작업

mappings 파일의 모든 매핑은 일관된 방식으로 적용됩니다. 특정 매핑과 다음 매핑 사이에서 변경되는 유일한 사항은 입력 문자열의 소스와 매핑 출력이 사용되는 대상입니다.

매핑 작업은 항상 입력 문자열과 매핑 테이블로부터 시작됩니다. 매핑 테이블의 항목은 테이블에 표시된 순서대로 위에서 아래로 한 번에 하나씩 스캔됩니다. 각 항목의 왼쪽은 패턴으로 사용되며 입력 문자열은 대소문자를 구분하지 않는 방식으로 해당 패턴과 비교됩니다.

매핑 항목 패턴

패턴은 와일드카드 문자를 포함할 수 있습니다. 특히 일반적인 와일드카드 문자가 허용됩니다. 별표(*)는 0개 이상의 문자와 일치하며 각 백분율 기호(%)는 하나의 문자와 일치합 니다. 별표, 백분율 기호, 공백 및 탭은 앞에 달러 기호($)를 추가하여 인용할 수 있습니다. 별표 또는 백분율 기호를 인용하면 특별한 의미가 사라집니다. 영구적으로 패턴이나 템플리트로 끝나는 것을 방지하기 위해 공백과 탭을 인용해야 합니다. 리터럴 달러 기호 문자는 이중($$)으로 표시해야 하며 첫 번째 달러 기호가 두 번째 기호를 인용합니다.

표 10–3 매핑 패턴 와일드카드

와일드카드

설명

% 

정확하게 하나의 문자와 일치합니다. 

* 

왼쪽에서 오른쪽으로의 “최대” 일치를 사용하여 0개 이상의 문자와 일치합니다. 

뒤로 일치

설명

$ n* 

n번째 와일드카드 또는 글롭과 일치합니다. 

수정자

설명

$_ 

왼쪽에서 오른쪽으로의 “최소” 일치를 사용합니다. 

$@ 

이어지는 와일드카드 또는 글롭의 “저장”을 해제합니다. 

$^ 

이어지는 와일드카드 또는 글롭의 “저장”을 설정합니다. 기본값입니다. 

글롭 와일드카드

설명

$A% 

하나의 알파벳 문자(A-Z 또는 a-z)와 일치합니다. 

$A* 

0개 이상의 알파벳 문자(A-Z 또는 a-z)와 일치합니다. 

$B% 

하나의 이진수(0 또는 1)와 일치합니다. 

$B* 

0개 이상의 이진수(0 또는 1)와 일치합니다. 

$D% 

하나의 십진수(0-9)와 일치합니다. 

$D* 

0개 이상의 십진수(0-9)와 일치합니다. 

$H% 

하나의 16진수(0-9 또는 A-F)와 일치합니다. 

$H* 

0개 이상의 16진수(0-9 또는 A-F)와 일치합니다. 

$O% 

하나의 8진수(0-7)와 일치합니다. 

$O* 

0 개 이상의 8진수(0-7)와 일치합니다. 

$S% 

하나의 기호 집합 문자(예: 0-9, A-Z, a-z, _, $)와 일치합니다. 

$S* 

0개 이상의 기호 집합 문자(예: 0-9, A-Z, a-z, _, $)와 일치합니다. 

$T% 

하나의 탭 또는 세로 탭이나 공백 문자와 일치합니다. 

$T* 

0개 이상의 탭 또는 세로 탭이나 공백 문자와 일치합니다. 

$X% 

$H%의 동의어입니다. 

$X* 

$H*의 동의어입니다. 

$[ c]% 

문자 c와 일치합니다. 

$[ c]* 

문자 c의 모든 경우와 일치합니다. 

$[ c1 c2 ... cn ]%

문자 c1, c2 또는 cn과 정확하게 한번 일치합니다.

$[ c1 c2 ... cn ]*

문자 c1, c2 또는 cn의 모든 경우와 일치합니다.

$[ c1 -cn ]%

c1에서 cn 범위에 있는 문자 하나와 일치합니다.

$[ c1 -cn ]*

c1에서 cn 범위에 있는 모든 문자와 일치합니다.

$< IPv4> 

IPv4 주소와 일치하며 비트를 무시합니다. 

$(IPv4) 

IPv4 주소와 일치하며 접두어 비트를 유지합니다. 

${IPv6} 

IPv6 주소와 일치합니다. 

글롭 내에서, 즉 $[...] 구조 내에서 백슬래시 문자(\)는 인용 문자입니다. 글롭 내에서 리터럴 하이픈(-) 또는 오른쪽 대괄호(])를 나타내려면 하이픈이나 오른쪽 대괄호를 백슬래시로 인용해야 합니다.

패턴의 다른 모든 문자는 해당 문자 자체를 표시 및 일치시킵니다. 특히 작은따옴표 및 큰따옴표 문자와 괄호는 매핑 패턴이나 템플리트에서 특별한 의미가 없는 보통 문자에 불과합니다. 따라서 유효하지 않은 주소나 부분 주소에 해당하는 항목을 쉽게 작성할 수 있습니다.

여러 수정자를 지정하거나 수정자와 뒤로 일치를 지정하려면 단지 하나의 달러 기호가 구문에 사용됩니다. 예를 들어, 뒤로 일치 자체를 저장하지 않고 처음 와일드카드를 뒤로 일치시키려면 $@$0이 아니라 $@0을 사용합니다.

imsimta test -match 유틸리티를 사용하여 매핑 패턴을 테스트하고 특히 패턴에서의 와일드카드 동작을 테스트할 수 있다는 점을 유의하십시오.

별표 와일드카드는 입력 문자열의 왼쪽에서 오른쪽으로 작동하여 항목을 최대한 일치시킵니다. 예를 들어, 입력 문자열 a/b/c가 패턴 */*와 비교되면 왼쪽 별표는 a/b와 일치하고 오른쪽 별표는 나머지 c와 일치합니다.

$_ 수정자는 패턴에서 왼쪽에서 오른쪽으로 작동하여 와일드카드 일치를 최소화므로 최소한의 가능한 일치만 일치로 간주됩니다. 예를 들어, 문자열 a/b/c가 패턴 $_*/$_*와 비교되면 왼쪽 $_*는 a와 일치하고 오른쪽 $_* 는 b/c와 일치합니다.

IP 일치

IPv4 접두어 일치의 경우 IP 주소나 서브넷이 지정되며 선택적으로 슬래시와 접두어의 비트 수(일치하는 항목을 비교할 때 고려되는)가 뒤에 올 수 있습니다. 예를 들어, 다음은 123.45.67.0 서브넷의 모든 항목과 일치합니다.

$(123.45.67.0/24)

IPv4 무시 비트 일치의 경우 IP 주소나 서브넷이 지정되며 선택적으로 슬래시와 비트 수(일치하는 항목을 검사할 때 무시되는)가 뒤에 올 수 있습니다. 예를 들어, 다음은 123.45.67.0 서브넷의 모든 항목과 일치합니다. 

$<123.45.67.0/8>

다음 예는 123.45.67.4에서 123.45.67.7까지의 범위에 속한 모든 항목과 일치합니다.

$<123.45.67.4/2>

IPv6 일치는 IPv6 주소 또는 서브넷과 일치합니다.

매핑 항목 템플리트

주어진 항목의 패턴 비교에 실패할 경우 어떠한 작업도 수행되지 않으며 다음 항목의 스캔이 진행됩니다. 비교에 성공할 경우 항목의 오른쪽이 출력 문자열을 생성하기 위한 템플리트로 사용됩니다. 템플리트가 사용되면 입력 문자열은 템플리트에 제공된 지침으로부터 생성된 출력 문자열로 효과적으로 대체됩니다.

템플리트의 거의 모든 문자는 단순히 그대로 출력됩니다. 단, 달러 기호($)의 경우는 예외입니다.

달러 기호 뒤에 달러 기호, 공백 또는 탭이 오면 출력 문자열에 달러 기호, 공백 또는 탭이 생성됩니다. 이러한 문자는 모두 출력 문자열에 삽입하기 위해 인용해야 한다는 점을 유의하십시오.

달러 기호 뒤에 오는 숫자 n은 대체를 요청하며 달러 기호 뒤에 알파벳 문자는 “메타 문자”라고 부릅니다. 메타 문자 자체는 템플리트가 생성한 출력 문자열에 나타나지 않지만 특수한 일부 대체 또는 처리를 생성합니다. 특수한 대체 또는 표준 처리 메타 문자의 목록은 표 10–4를 참조하십시오. 그 밖의 다른 메타 문자는 매핑 특정 응용 프로그램용으로 예약됩니다.

$C, $E, $L 또는 $R 메타 문자는 일치하는 패턴의 템플리트에 존재할 경우 매핑 프로세스에 영향을 주고 프로세스의 계속 또는 종료를 제어한다는 점을 유의하십시오. 즉, 한 항목의 출력이 다른 항목의 입력이 되는 반복 매핑 테이블 항목을 설정할 수 있습니다. 일치하는 패턴의 템플리트가 $C, $E, $L 또는 $R 메타 문자를 포함하지 않을 경우 $E(매핑 프로세스의 즉시 종료)가 가정됩니다.

무한 루프를 방지하기 위해 매핑 테이블의 반복 통과 횟수가 제한됩니다. 이전 통과보다 길거나 같은 패턴으로 통과가 다시 시작될 때마다 카운터가 증가합니다. 문자열의 길이가 이전 것보다 짧을 경우 카운터는 0으로 재설정됩니다. 카운터가 10을 초과하면 매핑을 반복하려는 요청은 무시됩니다.

표 10–4 매핑 템플리트 대체 및 메타 문자

대체 시퀀스 

대체 대상 

$n

0부터 시작하여 왼쪽에서 오른쪽으로 계산된 n번째 와일드카드 필드

$#...#

일련 번호 대체 

$]...[ 

LDAP 검색 URL 조회(결과에서 대체) 

$|...|

지정된 매핑 테이블을 제공된 문자열에 적용 

${...} 

일반 데이터베이스 대체 

$}domain,attribute{

도메인별 속성에 액세스하는 기능을 추가합니다. domain은 해당 도메인이고 attribute는 도메인과 연관된 속성입니다. 도메인이 있고 속성을 가지고 있는 경우 초기 값이 매핑 결과로 대체됩니다. 하지만 속성이나 도메인이 없으면 매핑 항목이 실패합니다.

attributes는 도메인 LDAP 속성이거나 아래에 정의되어 있는 특수한 속성일 수 있습니다.

_base_dn_ - 도메인의 사용자 항목에 대한 기본 DN

_domain_dn_ - 도메인 항목의 DN 그 자체

_domain_name_ - 도메인의 이름(별칭의 반대 개념)

_canonical_name_ - 도메인과 관련된 정규 이름

$[...]

사이트 제공 루틴 호출(결과에서 대체) 

메타 문자

설명

$C

다음 테이블 항목에서 시작하는 매핑 프로세스를 계속합니다. 이 항목의 출력 문자열을 매핑 프로세스의 새 입력 문자열로 사용합니다. 

$E

지금 매핑 프로세스를 종료합니다. 이 항목의 출력 문자열을 매핑 프로세스의 최종 결과로 사용합니다. 

$L

다음 테이블 항목에서 시작하는 매핑 프로세스를 계속합니다. 이 항목의 출력 문자열을 매핑 프로세스의 새 입력 문자열로 사용합니다. 테이블의 모든 항목이 사용되고 나면 첫 번째 테이블 항목에서 시작하는 통과를 하나 더 만듭니다. 이후의 일치하는 항목에서는 $C, $E 또는 $R 메타 문자를 사용하여 이 조건을 무시할 수 있습니다.

$R

매핑 테이블의 첫 번째 항목에서 시작하는 매핑 프로세스를 계속합니다. 이 항목의 출력 문자열을 매핑 프로세스의 새 입력 문자열로 사용합니다.  

$nA 

위치 0에서 시작하여 현재 주소의 n번째 왼쪽 문자를 삽입합니다. n을 생략하면 전체 주소가 삽입됩니다. 

$nX 

0에서 시작하여 메일 호스트의 n번째 왼쪽 구성 요소를 삽입합니다. n을 생략하면 전체 메일 호스트가 삽입됩니다. 

$?x?

매핑 항목이 x%의 시간 동안 성공합니다. 

$\

후속 텍스트를 소문자로 강제 지정합니다. 

$^

후속 텍스트를 대문자로 강제 지정합니다. 

$_

후속 텍스트를 원래 대소문자로 유지합니다. 

$=

대체된 후속 문자가 LDAP 검색 필터에 삽입하기 적합하게 인용되도록 합니다. 모두 대문자로 적용합니다. 

$:x

지정된 플래그가 설정된 경우에만 일치합니다. 

$;x

지정된 플래그가 지워진 경우에만 일치합니다. 

와일드카드 필드 대체($n)

숫자 n이 뒤에 오는 달러 기호는 패턴의 n번째 와일드카드와 일치했던 항목으로 대체됩니다. 와일드카드는 0부터 시작하여 번호가 매겨집니다. 예를 들어, 다음 항목은 입력 문자열 PSI%A::B와 일치하며 결과 출력 문자열 b@a.psi.siroe.com을 생성합니다.


PSI$%*::*    $1@$0.psi.siroe.com

또한 입력 문자열 PSI%1234::USER도 일치하여 USER@1234.psi.siroe.com을 출력 문자열로 생성합니다. 입력 문자열 PSIABC::DEF는 이 항목의 패턴과 일치하지 않으며 어떤 작업도 발생하지 않습니다. 즉, 이 항목으로부터 출력 문자열이 생성되지 않습니다.

텍스트 대소문자 제어($\, $^, $_)

메타 문자 $\는 후속 텍스트를 소문자로 강제 지정하고 $^는 후속 텍스트를 대문자로 강제 지정하며 $_는 후속 텍스트를 원래 대소문자로 유지합니다. 예를 들어, 이러한 메타 문자는 매핑을 사용하여 대소문자가 중요한 주소를 변환할 경우에 유용할 수 있습니다.

처리 제어($C, $L, $R, $E)

$C, $L, $R 및 $E 메타 문자는 매핑 프로세스의 종료 여부와 종료 시기를 제어하여 매핑 프로세스에 영향을 줍니다. 각 메타 문자는 다음과 같습니다.

매핑 테이블 템플리트는 왼쪽에서 오른쪽으로 스캔됩니다. “성공” 또는 “실패”할 수 있는 항목(예: 일반 데이터베이스 대체 또는 임의 값 제어 항목)에 $C, $L 또는 $R 플래그를 설정하려면 해당 항목의 왼쪽에 $C, $L 또는 $R 메타 문자를 추가합니다. 그렇지 않을 경우 항목의 나머지 부분이 실패하면 플래그가 표시되지 않습니다.

특수 플래그 검사

일부 매핑 검사에서는 특수한 플래그를 설정합니다. 이러한 플래그를 설정한 다음 $:, $; 테스트의 일반 매핑 테이블 기능을 사용하여 플래그의 존재/부재를 테스트할 수 있습니다. $:x는 플래그 x가 설정된 경우에만 항목이 일치하게 합니다. $;x는 플래그 x가 없는 경우에만 항목이 일치하게 합니다. 매핑 테이블에 적용될 수 있는 특수 플래그는 해당 매핑 테이블에 대한 설명을 참조하십시오. 표 17–2에서 $A, $T, $S, $F 및 $D를 참조하십시오.

플래그 검사가 성공하면 항목이 계속되고 종료되도록 하고 플래그 검사가 실패하면 매핑 프로세스가 계속되도록 하려는 경우 항목에서는 플래그 검사 왼쪽에 $C 메타 문자를 사용하고 플래그 검사 오른쪽에 $E 플래그를 사용해야 합니다.

항목의 임의적 성공 또는 실패($?x?)

매핑 테이블 항목의 $?x?메타 문자를 사용하면 x%의 시간 동안 항목이 “성공”합니다. 나머지 시간에는 항목이 “실패”하며 매핑 항목의 입력에 대한 출력이 변경되지 않은 채 출력으로 사용됩니다. (매핑에 따라 항목 실패의 결과가 처음에 일치하지 않은 항목과 반드시 같은 것은 아닙니다.)x는 성공 비율을 지정하는 실수여야 합니다.

예를 들어, IP 주소가 123.45.6.78인 시스템이 많은 양의 SMTP 전자 메일을 사이트로 전송하고 있으며 관리자가 그 속도를 줄이려는 경우 다음과 같은 방법으로 PORT_ACCESS 매핑 테이블을 사용할 수 있습니다. 여기에서 연결 시도의 25%만 허용하고 나머지 75%의 시도를 거부해야 한다고 가정해 봅니다. 다음 PORT_ACCESS 매핑 테이블은 $Y(연결 허용)를 가진 항목이 25%의 시간 동안만 성공하도록 $?25?를 사용합니다. 나머지 75%의 시간동안 이 항목이 실패하면 맨 앞의 $C로 인해 MTA는 다음 항목에서 매핑을 계속합니다. 결과적으로 SMTP 오류가 발생하고Try again later 메시지가 표시되면서 연결 시도가 거부됩니다. 


PORT_ACCESS

   TCP|*|25|123.45.6.78|*         $C$?25?$Y
   TCP|*|25|123.45.6.78|*         $N45s$ 4.40$ Try$ again$ later

일련 번호 대체($#...#)

$#...# 대체는 MTA 시퀀스 파일에 저장된 값을 증가시키고 해당 값을 템플리트로 대체합니다. 매핑 테이블 출력에 고유한 한정자가 존재하는 것이 바람직한 경우(예: 매핑 테이블을 사용하여 파일 이름을 생성하는 경우) 이 대체를 사용하여 증가하는 고유 문자열을 생성할 수 있습니다.

다음 구문 중 하나를 사용할 수 있습니다.


$#seq-file-spec|radix|width|m#
 

$#seq-file-spec|radix|width#
 

$#seq-file-spec|radix#
 

$#seq-file-spec#

필수 seq-file-spec 인수는 이미 존재하는 MTA 시퀀스 파일에 대한 전체 파일 지정입니다. 선택적 radix 및 width 인수는 각각 시퀀스 값을 출력하는 데 적용할 기수와 출력할 자릿수를 지정합니다. 기본 기수는 10이며 허용 범위는 -36에서 36까지입니다. 예를 들어, 기수 36은 숫자 0,...,9,A,...,Z로 표현되는 값을 제공합니다. 기본적으로 시퀀스 값은 본래 너비로 인쇄되지만 지정된 너비에 더 많은 자릿수가 요구될 경우 올바른 자릿수가 되도록 출력의 왼쪽 부분이 0으로 채워집니다. 너비가 명시적으로 지정된 경우 기수도 명시적으로 지정되어야 한다는 점을 유의하십시오.

선택적 m 인수는 모듈러스입니다. 이 네 번째 인수를 지정하면 삽입되는 값은 파일 mod m에서 검색되는 시퀀스 번호입니다. 기본값은 모듈러스 작업을 수행하지 않는 것입니다.

위에서 언급한 것처럼 매핑에서 참조되는 MTA 시퀀스 파일은 이미 존재해야 합니다. MTA 시퀀스 파일을 만들려면 다음 UNIX 명령을 사용합니다.


touch seq-file-spec

또는


cat >seq-file-spec

매핑 테이블을 사용하여 액세스하는 일련 번호 파일은 세계 공용일 경우에만 제대로 작동합니다. 또한 이러한 일련 번호 파일을 사용하려면 imta_tailor 파일에서 nobody로 구성된 MTA 사용자 계정이 있어야 합니다.

LDAP 쿼리 URL 대체($]...[)

$]ldap-url [ 형식의 대체는 특수하게 처리됩니다. ldap-url은 LDAP 쿼리 URL로 해석되며 LDAP 쿼리 결과가 대체됩니다. 호스트와 포트가 생략된 표준 LDAP URL이 사용되며 대신 LDAP_HOST 및 LDAP_PORT 옵션을 사용하여 호스트와 포트를 지정합니다. 즉, LDAP URL은 다음과 같이 지정해야 합니다.

ldap:///dn[?attributes[?scope?filter]]

여기에서 대괄호 문자 [ 및 ]는 URL의 선택적 부분을 나타냅니다. dn은 필수 항목으로서 검색 기준을 지정하는 고유 이름입니다. 선택 항목인 URL의 attributes, scope 및 filter 부분은 반환할 정보를 더 구제화합니다. 즉, attributes는 이 LDAP 쿼리와 일치하는 LDAP 디렉토리 항목에서 반환될 속성을 지정합니다. scope는 base(기본값), one 또는 sub가 될 수 있습니다. filter는 일치하는 항목의 특성을 설명합니다.

특정 LDAP URL 대체 시퀀스를 LDAP 쿼리 URL 내에서 사용할 수 있습니다.

매핑 테이블 대체($|...|)

$|mapping ;argument| 형식의 대체는 특수하게 처리됩니다. MTA는 MTA mappings 파일에서 mapping이라는 보조 매핑 테이블을 찾은 후 argument를 명명된 이 보조 매핑 테이블에 대한 입력으로 사용합니다. 명명된 보조 매핑 테이블은 존재해야 하며 성공할 경우 해당 출력에서 $Y 플래그를 설정해야 합니다. 명명된 보조 매핑 테이블이 존재하지 않거나 $Y 플래그를 설정하지 않을 경우 해당 보조 매핑 대체가 실패하고 원래 매핑 항목이 실패로 간주되어 원래 입력 문자열이 출력 문자열로 사용됩니다.

매핑 테이블 대체를 수행하는 매핑 테이블 항목에서 $C, $R 또는 $L과 같은 처리 제어 메타 문자를 사용하려는 경우 매핑 테이블 템플리트에서 매핑 테이블 대체의 왼쪽에 처리 제어 메타 문자를 두어야 한다는 점을 유의하십시오. 그렇지 않을 경우 매핑 테이블 대체가 “실패”하면 처리 제어 메타 문자가 표시되지 않습니다.

일반 조회 테이블 또는 데이터베이스 대체(${...})

$(text) 형식의 대체는 특수하게 처리됩니다. text 부분은 일반 조회 테이블이나 데이터베이스에 액세스하기 위한 키로 사용됩니다. 데이터베이스는 imsimta crdb 유틸리티를 사용하여 생성합니다. 테이블에서 text가 발견될 경우 테이블의 해당 템플리트가 대체됩니다. text가 테이블의 항목과 일치하지 않을 경우 입력 문자열이 변경되지 않은 채로 출력 문자열로 사용됩니다.

일반 조회 테이블을 사용하는 중이면 MTA 옵션 use_text_databases의 낮은 순서 하위 비트를 설정해야 합니다. 즉 기수로 설정합니다. imsimta cnbuild를 사용하여 컴파일을 수행하고 imsimta reload를 사용하여 재로드 가능한 데이터를 재로드함으로써 general.txt에 대한 변경 사항을 MTA 구성으로 컴파일해야 합니다.

일반 데이터베이스를 사용하는 경우 데이터베이스는 제대로 작동하기 위해 세계 공용이어야 합니다.

일반 테이블 대체를 수행하는 매핑 테이블 항목에서 $C, $R 또는 $L과 같은 처리 제어 메타 문자를 사용하려는 경우 매핑 테이블 템플리트에서 일반 테이블 대체의 왼쪽에 처리 제어 메타 문자를 두어야 합니다. 그렇지 않을 경우 일반 테이블 대체가 “실패”하면 처리 제어 메타 문자가 표시되지 않습니다.

사이트 제공 루틴 대체($[...])

$[image,routine,argument ] 형식의 대체는 특수하게 처리됩니다. image, routine, argument 부분은 사용자 제공 루틴을 검색 및 호출하는 데 사용됩니다. UNIX의 런타임에서 MTA는 dlopen 및 dlsym을 사용하여 공유 라이브러리 image에서 routine 루틴을 동적으로 로드 및 호출합니다. 이어서 routine 루틴은 다음 인수 목록을 가진 함수로 호출됩니다.


status = routine (argument, arglength, result, reslength)

argument 및 result는 252바이트 길이의 문자열 버퍼입니다. argument 및 result는 포인터로 문자열에 전달됩니다(예: C에서는 char*로). arglength 및 reslength는 참조에 의해 전달되는 서명된 정수(Long)입니다. 입력의 경우, argument는 매핑 테이블 템플리트의 argument 문자열을 포함하고 arglength는 해당 문자열의 길이를 포함합니다. 반환 시에 결과 문자열은 result에 포함되고 그 길이는 reslength에 포함되어야 합니다. 그런 다음 이 결과 문자열은 매핑 테이블 템플리트에서 $[image,routine,argument]를 대체합니다. routine 루틴은 매핑 테이블 대체가 실패할 경우에는 0을 반환하고 성공할 경우에는 1을 반환해야 합니다. 대체가 실패할 경우 일반적으로 원래 입력 문자열이 그대로 출력 문자열로 사용됩니다.

사이트 제공 루틴 대체를 수행하는 매핑 테이블 항목에서 $C, $R 또는 $L과 같은 처리 제어 메타 문자를 사용하려는 경우 매핑 테이블 템플리트에서 사이트 제공 루틴 대체의 왼쪽에 처리 제어 메타 문자를 두어야 합니다. 그렇지 않을 경우 매핑 테이블 대체가 “실패”하면 처리 제어 메타 문자가 표시되지 않습니다.

사이트 제공 루틴 설명선 기법을 사용하면 MTA의 매핑 프로세스를 모든 종류의 복잡한 방법으로 확장할 수 있습니다. 예를 들어, PORT_ACCESS 또는 ORIG_SEND_ACCESS 매핑 테이블에서 특정한 유형의 로드 모니터링 서비스를 호출할 수 있으며 결과를 사용하여 연결이나 메일을 수락할지 여부를 결정할 수 있습니다.

사이트 제공 공유 라이브러리 이미지 image는 세계 공용이어야 합니다.

UTF-8 문자열 생성

일반 매핑 테이블 기능의 유니코드 문자 값에서 UTF-8 문자열을 만들 수 있습니다. 유니코드 메타 문자의 순서는 다음 형식으로 나타납니다.

$&A0A0,20,A1A1&

이 형식에서 A0A0, 20 및 A1A1 위치에 문자가 포함되는 UTF-8 문자열을 만들어냅니다.

기타 MTA 구성 파일

imta.cnf 파일 외에 Messaging Server는 MTA 서비스를 구성하는 데 도움이 되는 다른 여러 구성 파일을 제공합니다. 표 10–5에는 이러한 파일이 요약되어 있습니다.

reverse, forward 또는 일반 데이터베이스를 변경한 경우 변경 내용을 적용하려면 imsimta reload 명령을 실행합니다. imta.cnf, mappings 파일, aliases, conversions 또는 option.dat 파일을 변경한 경우 이 변경 내용이 job_controller에 영향을 주지 않으면 imsimta restart smtp 뒤에 imsimta cnbuild 명령을 실행해야 합니다. dispatcher.cnf를 변경한 경우에는 imsimta restart dispatcher 명령을 실행해야 합니다. 컴파일된 구성에 포함된 구성 파일을 변경한 경우 이 변경 내용이 Job Controller에만 영향을 주고 SMTP 서버에는 영향을 주지 않으면 일반적으로 imsimta cnbuild 및 imsimta restart job_controller 명령을 실행해야 합니다.

이러한 명령에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 MTA Commands를 참조하십시오.

표 10–5 MTA 구성 파일

파일 

설명 

별칭 파일(필수)

디렉토리에 존재하지 않는 별칭을 구현합니다. msg_svr_base/config/aliases

TCP/IP(SMTP) 채널 옵션 파일(SMTP 옵션 파일이라고도 부 름)

채널 특정 옵션을 설정합니다. msg_svr_base/config/channel_option

변환 파일

메일 본문 부분의 변환을 제어하기 위해 변환 채널에 사용됩니다. msg_svr_base/config/conversions

디스패처 구성 파일(필수)

디스패처를 위한 구성 파일입니다. msg_svr_base/config/dispatcher.cnf

Job Controller 파일(필수)

Job Controller에 사용되는 구성 파일입니다. /msg_svr_base/config/job_controller.cnf

MTA 구성 파일(필수) 

채널 정의뿐만 아니라 주소 다시 쓰기 및 라우팅에 사용됩니다. /msg_svr_base/config/imta.cnf

매핑 파일(필수)

매핑 테이블의 저장소입니다. /msg_svr_base/ config/mappings

옵션 파일

전역 MTA 옵션 파일입니다. /msg_svr_base/config/option.dat

조정 파일(필수)

위치와 일부 조정 매개 변수를 지정하기 위한 파일입니다. /msg_svr_base/config/imta_tailor

일반 조회 테이블(선택 사항) 

일반 조회 기능은 일반 데이터베이스와 동일합니다. 재로드 가능한 컴파일된 구성의 일부입니다. 

위치와 일부 조정 매개 변수를 지정하기 위한 파일입니다. /msg_svr_base/config/general.txt

정방향 조회 테이블(선택 사항) 

To: 주소에 대한 주소에 적용되지 정방향 데이터베이스와 동일하며 재로드 가능한 컴파일된 구성의 일부입니다. 

/msg_svr_base/config/forward.txt

역방향 조회 테이블(선택 사항) 

From: 주소에 대한 주소에 적용되지 역방향 데이터베이스와 동일하며재로드 가능한 컴파일된 구성의 일부입니다. /msg_svr_base/config/reverse.txt

별칭 파일

별칭 파일 aliases는 디렉토리에서 설정되지 않은 별칭을 설정합니다. 특히 루트의 주소를 좋은 예로 들 수 있습니다. 이 파일에 설정된 별칭은 디렉토리에 동일한 별칭이 존재할 경우 무시됩니다. 별칭 및 aliases 파일에 대한 자세한 내용은 별칭을 참조하십시오.

aliases 파일을 변경한 후 MTA를 다시 시작하거나 imsimta reload 명령을 실행해야 합니다.

TCP/IP(SMTP) 채널 옵션 파일

TCP/IP 채널 옵션 파일은 TCP/IP 채널의 다양한 특성을 제어합니다. 채널 옵션 파일은 MTA 구성 디렉토리에 저장하고 x_option으로 이름을 지정해야 합니다. 여기서 x는 채널의 이름입니다. 예를 들어, msg_svr_base/config/imta/tcp_local_option입니다. 자세한 내용은 SMTP 채널 옵션 구성을 참조하십시오. 모든 채널 옵션 키워드 및 구문에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference를 참조하십시오.

변환 파일

변환 파일 conversions는 변환 채널이 MTA를 통과하는 메일에 대한 변환을 수행하는 방법을 지정합니다. MTA 트래픽의 모든 하위 집합을 변환하도록 선택할 수 있으며 임의의 프로그램 또는 명령 프로시저 집합을 사용하여 변환 처리를 수행할 수 있습니다. MTA는 각 본문 부분에 대한 적절한 변환을 선택하기 위해 변환 파일을 확인합니다.

이 파일의 구문에 대한 자세한 내용은 변환 채널을 참조하십시오.

디스패처 구성 파일

디스패처 구성 파일 dispatcher.cnf는 디스패처 구성 정보를 지정합니다. 기본 구성 파일은 설치 시 작성되며 변경 없이 사용할 수 있습니다. 그러나 보안이나 성능상의 이유로 기본 구성 파일을 수정하려는 경우 dispatcher.cnf 파일을 편집하여 원하는 사항을 수정할 수 있습니다. 이에 대한 개념적 정보는 디스패처를 참조하십시오.

디스패처 구성 파일 형식은 다른 MTA 구성 파일의 형식과 비슷합니다. 옵션을 지정하는 행은 다음 형식을 가집니다.

option=value

option은 옵션의 이름이며 value는 옵션이 설정되는 문자열 또는 정수입니다. option이 정수 값을 가질 경우 b%v 형식의 표기법을 사용하여 기수를 지정할 수 있습니다. 여기에서 b는 기수 10으로 표현되는 기수이며 v는 기수 b로 표현되는 실제 값입니다. 이러한 옵션 지정은 다음 형식의 행을 사용하여 다음 옵션 설정이 적용되는 서비스에 해당하는 섹션으로 그룹화됩니다.

[SERVICE=service-name ]

service-name은 서비스의 이름입니다. 이러한 섹션 태그 앞에 표시되는 초기 옵션 지정은 모든 섹션에 전역적으로 적용됩니다.

다음은 샘플 디스패처 구성 파일(dispatcher.cnf)입니다.


! The first set of options, listed without a [SERVICE=xxx]
! header, are the default options that will be applied to all
! services.
!
MIN_PROCS=0
MAX_PROCS=5
MIN_CONNS=5
MAX_CONNS=20
MAX_LIFE_TIME=86400
MAX_LIFE_CONNS=100
MAX_SHUTDOWN=2
!
! Define the services available to Dispatcher
!
[SERVICE=SMTP]
PORT=25
IMAGE=msg_svr_base/lib/tcp_smtp_server
LOGFILE=msg_svr_base/log/tcp_smtp_server.log

이 파일의 매개 변수에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference를 참조하십시오.

매핑 파일

mappings 파일은 MTA가 입력 문자열을 출력 문자열로 매핑하는 방법을 정의합니다.

MTA의 구성 요소는 대부분 테이블 조회 지향 정보를 사용합니다. 일반적으로 이러한 종류의 테이블은 입력 문자열을 출력 문자열로 변환(즉, 매핑)하는 데 사용됩니다. 매핑 테이블이라고 부르는 이러한 테이블은 두 개의 열, 즉 가능한 입력 문자열을 제공하는 첫 번째(왼쪽) 열과 연관된 입력에 대한 결과 출력 문자열을 제공하는 두 번째(오른쪽) 열로 제공됩니다. 대부분의 MTA 데이터베이스는 이러한 매핑 테이블 유형의 인스턴스입니다. 그러나 MTA 데이터베이스 파일은 와일드카드 조회 기능을 제공하지 않으므로 와일드카드 일치를 위해 전체 데이터베이스를 스캔해야 한다는 점에서 본질적으로 비효율적입니다.

mappings 파일은 여러 매핑 테이블을 지원하기 위한 기능을 MTA에 제공합니다. 완전한 와일드카드 기능이 제공되는 것 외에도 다단계 및 반복 매핑 방법을 사용할 수 있습니다. 이 방식은 특히 항목 수가 많을 경우에 데이터베이스를 사용하는 것보다 컴퓨팅 작업이 많이 요구됩니다. 그러나 동일한 데이터베이스에서 대부분의 항목을 불필요하게 만드는 유연성이 있기 때문에 결과적으로 전체 오버헤드가 줄어들 수 있습니다.

imsimta test -mapping 명령을 사용하여 매핑 테이블을 테스트할 수 있습니다. mappings 파일 및 test -mapping 명령의 구문에 대한 자세한 내용은 매핑 파일 및 Sun Java System Messaging Server 6 2005Q4 Administration Reference를 참조하십시오.

mappings 파일을 변경한 후 MTA를 다시 시작하거나 imsimta reload 명령을 실행해야 합니다.

옵션 파일

옵션 파일 option.dat는 채널 특정 옵션과 달리 전역 MAT 옵션을 지정합니다.

옵션 파일을 사용하면 MTA에 전체적으로 적용되는 다양한 매개 변수의 기본값을 무시할 수 있습니다. 특히 옵션 파일은 구성 및 별칭 파일을 읽어오는 다양한 테이블의 크기를 설정하는 데 사용됩니다. 또한 옵션 파일을 사용하여 MTA가 수락하는 메일의 크기를 제한하고 MTA 구성에 허용되는 채널 수를 지정하며 허용되는 다시 쓰기 규칙 수를 설정하는 등의 작업을 수행할 수 있습니다.

option.dat에서 #, ! 또는 ;으로 시작하는 행은 행이 계속된다는 것을 의미하는 후행 \가 바로 앞 행에 있는 경우에도 주석 행으로 처리됩니다. 이것은 이러한 문자를 포함할 수 있는 긴 옵션(특히 전달 옵션)에서 주의해야 한다는 것을 의미합니다.

일반적으로 # 또는 !로 시작하는 연속 행을 가지는 전달 옵션의 경우 이를 처리할 수 있는 안전하고 간단한 방법이 존재합니다.

옵션 파일의 구문에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference를 참조하십시오.

조정 파일

조정 파일 imta_tailor는 다양한 MTA 구성 요소의 위치를 설정합니다. MTA가 제대로 작동하려면 imta_tailor 파일이 항상 msg_svr_base/config 디렉토리에 상주해야 합니다.

이 파일을 편집하여 특정 설치의 변경 사항을 반영할 수 있지만 이렇게 하려면 주의를 기울여야 합니다. 이 파일을 변경한 후에는 MTA를 다시 시작해야 합니다. MTA를 종료한 상태에서 변경을 수행하는 것이 더 바람직합니다.

주 –

꼭 필요한 경우가 아니면 이 파일을 편집해서는 안 됩니다.

이 파일에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference를 참조하십시오.

Job Controller 파일

Job Controller는 메일 전달을 위해 채널 작업을 작성 및 관리합니다이러한 채널 작업은 Job Controller 내의 처리 풀 안에서 실행됩니다. 풀은 채널 작업이 실행되는 “장소”로 생각할 수 있습니다. 풀은 작업 세트가 풀 외부의 작업과 자원을 놓고 경쟁하지 않고도 작동할 수 있는 컴퓨팅 영역을 제공합니다. (Job Controller의 개념과 채널 키워드 구성에 대한 자세한 내용은 Job Controller, 채널 실행 작업의 처리 풀 및 서비스 작업 제한을 참조하십시오.

Job Controller 파일 job_controller.cnf는 다음 채널 처리 정보를 지정합니다.

imta.cnf 파일에서 pool 키워드를 사용하여 job_controller.cnf에서 정의된 프로세스 풀의 이름을 지정할 수 있습니다. 예를 들어, 샘플 job_controller.cnf 파일의 다음 단편은 MY_POOL 풀을 정의합니다.

[POOL=MY_POOL]
job_limit = 12

샘플 imta.cnf 파일의 다음 단편은 채널 블록에서 MY_POOL 풀을 지정합니다.

channel_x pool MY_POOL
channel_x-daemon

기본 풀 구성과 관련된 매개 변수를 수정하거나 추가 풀을 추가하려는 경우 job_controller.cnf 파일을 편집한 다음 Job Controller를 중지했다가 다시 시작할 수 있습니다.

Job Controller 구성 파일의 첫 번째 풀은 풀 이름을 지정하지 않는 모든 요청에 사용됩니다. MTA 구성 파일(imta.cnf)에 정의된 MTA 채널은 pool 채널 키워드 뒤에 풀 이름을 사용하여 처리 요청을 특정 풀을 향하도록 할 수 있습니다. 풀 이름은 Job Controller 구성의 풀 이름과 일치해야 합니다. Job Controller가 요청된 풀 이름을 인식하지 않을 경우 요청은 무시됩니다.

초기 구성에서는 DEFAULT, LOCAL_POOL, IMS_POOL, SMTP_POOL 풀이 정의됩니다.

사용 예

일반적으로 일부 채널의 처리를 다른 채널의 처리와 차별화하려는 경우 추가 풀 정의를 Job Controller 구성에 추가합니다. 또한 다른 특성을 가진 풀을 사용할 수도 있습니다. 예를 들어, 일부 채널에서 처리하도록 허용된 동시 요청의 개수를 제어해야 할 수 있습니다. 이렇게 하려면 작업 제한을 가진 새 풀을 만든 다음 pool 채널 키워드를 사용하여 이러한 채널을 더 적절한 새 풀로 향하게 합니다.

풀 정의 외에도 Job Controller 구성 파일은 각 채널에 대해 Job Controller가 요청을 처리하는 데 사용해야 하는 MTA 채널 및 명령 테이블을 포함합니다. 요청의 두가지 유형은 “마스터” 및 “슬레이브”로 한정됩니다. 일반적으로 채널 마스터 프로그램은 채널에 대한 MTA 메일 대기열에 저장된 메일이 있을 때 호출됩니다. 마스터 프로그램은 메일을 대기열에서 제외시킵니다.

슬레이브 프로그램은 채널을 폴하고 해당 채널에 대한 모든 인바운드 메일을 가져오기 위해 호출됩니다. 거의 모든 MTA 채널이 마스터 프로그램을 갖고 있지만 대부분은 경우 슬레이브 프로그램은 갖고 있지 않거나 불필요합니다. 예를 들어, TCP/IP를 통해 SMTP를 처리하는 채널은 슬레이브 프로그램을 사용하지 않는데 이는 임의 SMTP 서버에서 요청할 경우 네트워크 서비스인 SMTP 서버가 받는 SMTP 메일을 수신하기 때문입니다. SMTP 채널의 마스터 프로그램은 MTA의 SMTP 클라이언트입니다.

채널과 관련된 대상 시스템이 한 번에 하나의 메일만 처리할 수 있는 경우 작업 제한이 1인 새로운 유형의 풀을 만들어야 합니다. 

[POOL=single_job]
job_limit=1

이와 달리 대상 시스템에 충분한 병행성이 있을 경우 작업 제한을 더 높은 값으로 설정할 수 있습니다.

예 10–1은 샘플 Job Controller 구성 파일을 보여 줍니다. 사용 가능한 옵션은 표 10–6에 나와 있습니다.

예 10–1 UNIX의 샘플 작업 제어기 구성 파일


!MTA Job Controller configuration file
!
!Global defaults
tcp_port=27442         (1)
secret=never mind
slave_command=NULL     (2)
max_life_age=3600      (3)
!
!
!Pool definitions
!
[POOL=DEFAULT]         (4)
job_limit=10           (5)
!
[POOL=LOCAL_POOL]
job_limit=10
!
[POOL=IMS_POOL]
job_limit=1
!
[POOL=SMTP_POOL]
job_limit=1
!
!Channel definitions
!
!
[CHANNEL=l]             (6)
master_command=msg_svr_base/lib/l_master
!
[CHANNEL=ims-ms]
master_command=msg_svr_base/lib/ims_master
!
[CHANNEL=tcp_*]         (7)
anon_host=0
master_command=msg_svr_base/lib/tcp_smtp_client

위 예의 괄호로 묶인 굵은체의 숫자가 표시된 주요 항목은 다음과 같습니다.

  1. 이 전역 옵션은 Job Controller가 요청을 수신하는 TCP 포트 번호를 정의합니다.

  2. 후속 [CHANNEL ] 섹션에 대한 기본 SLAVE_COMMAND를 설정합니다.

  3. 후속 [CHANNEL] 섹션에 대한 기본 MAX_LIFE_AGE를 설정합니다.

  4. 이 [POOL] 섹션은 DEFAULT라는 풀을 정의합니다.

  5. 이 풀의 JOB_LIMIT를 10으로 설정합니다.

  6. 이 [CHANNEL] 섹션은 l이라는 UNIX 로컬 채널에 적용됩니다. 이 섹션에 필요한 유일한 정의는 Job Controller가 이 채널을 실행하기 위해 사용하는 master_command입니다. 채널 이름에 와일드카드가 없기 때문에 채널은 정확하게 일치해야 합니다.

  7. 이 [CHANNEL] 섹션은 이름이 tcp_*로 시작하는 모든 채널에 적용됩니다. 이 채널 이름은 와일드카드를 포함하므로 이름이 tcp_로 시작하는 모든 채널과 일치합니다.

추가 풀을 추가하는 예

Job Controller는 메일 전달을 위해 채널 작업을 작성 및 관리합니다이러한 채널 작업은 Job Controller 내의 처리 풀 안에서 실행됩니다. 풀은 채널 작업이 실행되는 “장소”로 생각할 수 있습니다. 풀은 작업 세트가 풀 외부의 작업과 자원을 놓고 경쟁하지 않고도 작동할 수 있는 컴퓨팅 영역을 제공합니다. job_controller에서 설정된 작업 제한이 해당 풀에만 적용된다는 점을 유의하십시오. 따라서, 예를 들어 job_limit가 10으로 설정된 SMTP_POOL을 정의할 경우 특정 시점에 10개의 tcp_smtp 클라이언트 프로세스만 해당 풀에서 실행될 수 있습니다.

경우에 따라서는 추가 tcp_* 채널을 만드는 것이 필요할 수 있습니다(예: 특히 느린 메일 사이트를 위한 tcp 채널). 이러한 채널은 다른 풀에서 실행하는 것이 좋습니다. 이는 예를 들어, 10개의 다른 tcp_* 채널을 만들어 SMTP_POOL에서 모두 실행할 경우 특정 시점에 각 tcp_* 채널에 대해 하나의 tcp_smtp 클라이언트만 실행될 수 있기 때문입니다(job_limit가 10인 SMTP_POOL을 정의한 경우에 해당하며 메일이 모든 tcp_* 채널을 대상으로 하는지 여부에 따라 달라짐). 시스템의 로드량이 많고 다양한 tcp_* 채널로 나가길 기다리는 메일을 모든 대기열이 갖고 있다고 가정하면 이는 비효율적입니다. 이러한 경우에는 경합이 발생하지 않도록 추가 tcp_* 채널에 대한 추가 풀을 정의할 수 있습니다.

예를 들어, 다음 tcp_* 채널을 설정한다고 가정해 봅니다. 


tcp_yahoo smtp mx pool yahoo_pool keyword keyword keyword
tcp-yahoo-daemon

tcp_aol smtp mx keyword keyword keyword pool aol_pool
tcp-aol-daemon

tcp_hotmail smtp mx pool hotmail_pool keyword keyword keyword 
tcp-hotmail-daemon
...
tcp_sun smtp mx pool sun_pool keyword keyword keyword
tcp-sun-daemon

각각의 새 채널에 대해 10개의 tcp_smtp_client 프로세스를 추가하기 위해 job_controller.cnf 파일에 다음을 추가할 수 있습니다.


[POOL=yahoo_pool]
job_limit=10

[POOL=aol_pool]
job_limit=10

[POOL=hotmail_pool]
job_limit=10

 ...

[POOL=sun_pool]
job_limit=10

풀에 대한 자세한 내용은 채널 실행 작업의 처리 풀을 참조하십시오. Sun Java System Messaging Server 6 2005Q4 Administration Reference를 참조하십시오.

표 10–6 Job Controller 구성 파일 옵션

옵션 

설명 

일반 옵션 

설명 

INTERFACE_ADDRESS=adapter

Job Controller가 바인드해야 하는 IP 주소 인터페이스를 지정합니다. 지정된 값(어댑터)은 ANY, ALL, LOCALHOST 또는 IP 주소 중 하나가 될 수 있습니다. 기본적으로 Job Controller는 모든 주소에 바인드됩니다(ALL 또는 ANY를 지정하는 것과 동일). INTERFACE_ADDRESS=LOCALHOST를 지정하면 Job Controller는 로컬 시스템 내의 연결만 수락합니다. 이 경우 Job Controller에 의해 지원되는 시스템 간 작업이 없이 때문에 정상적인 작업에 영향을 주지 않습니다. 그러나 이 지정은 Job Controller의 응답 여부를 HA 에이전트가 검사할 수 있는 HA 환경에서는 적합하지 않을 수 있습니다. Messaging Server가 실행 중인 시스템이 HA 환경에 있으며 “내부 네트워크” 어댑터 및 “외부 네트워크” 어댑터가 사용 중이고 높은 포트 번호에 대한 연결을 방화벽에서 차단할 수 있는지 확실하지 않을 경우, “내부 네트워크” 어댑터의 IP 주소를 지정하는 것을 고려해야 합니다.

MAX_MESSAGES=integer

Job Controller는 메일에 대한 정보를 메모리 내장 구조에서 유지합니다. 대량의 백로그가 작성될 경우에 대비하여 이 구조의 크기를 제한해야 할 수 있습니다. 백로그의 메일 수가 여기에서 지정된 매개 변수를 초과할 경우 후속 메일에 대한 정보를 메모리에 저장되지 않습니다. 메일 메시지는 항상 디스크에 기록되므로 손실되지 않지만 Job Controller가 알고 있는 메일 수가 이 숫자의 절반으로 줄어들 때까지 메일 전달이 고려되지 않습니다. 이 시점에서 Job Controller는 imsimta cache -sync 명령을 모방하는 대기열 디렉토리의 스캔을 수행합니다.

기본값은 100000입니다. 

SECRET=file_spec

Job Controller로 보내진 요청을 보호하는 데 사용되는 공유 비밀입니다. 

SYNCH_TIME=time_spec

Job Controller는 가끔씩 디스크상의 대기열 파일을 스캔하여 누락된 파일을 검사합니다. 기본적으로 이 작업은 Job Controller가 시작되고 4시간 후부터 4시간마다 수행됩니다. time_spec의 형식은 HH:MM/hh:mm 또는 /hh:mm입니다. 변수 hh.mm은 이벤트 사이의 간격을 나타내는 시간(h)과 분(m)입니다. 변수 HH:MM은 이벤트가 처음 발생해야 하는 시간입니다. 예를 들어, 15:45/7:15는 15시 45분에 이벤트를 시작하고 그 이후부터 7시간 15분마다 이벤트를 반복합니다.

TCP_PORT=integer

Job Controller가 요청 패킷을 수신해야 하는 TCP 포트를 지정합니다. 기본값이 시스템의 다른 TCP 응용 프로그램과 충돌하지 않을 경우 이 옵션을 변경하지 않습니다. 이 옵션을 변경할 경우 MTA 조정 파일 msg_svr_base/config/imta_tailor에서 해당 IMTA_JBC_SERVICE 옵션을 변경하여 일치시켜야 합니다. TCP_PORT 옵션은 전역적으로 적용되며 [CHANNEL] 또는 [POOL] 섹션에 있을 경우 무시됩니다.

풀 옵션

설명

JOB_LIMIT=integer

풀이 동시에(병렬로) 사용할 수 있는 최대 프로세스 수를 지정합니다. JOB_LIMIT는 각 풀에 개별적으로 적용되므로 작업의 최대 총 개수는 모든 풀의 JOB_LIMIT 매개 변수를 더한 값입니다. 이 옵션은 기본적으로 섹션 외부에 설정된 경우 JOB_LIMIT를 지정하지 않는 모든 [POOL] 섹션에 사용됩니다. [CHANNEL] 섹션 안에 있을 경우 이 옵션은 무시됩니다.

채널 옵션

설명

MASTER_COMMAND=file_spec

채널을 실행하고 해당 채널에 대한 아웃바운드 메일을 대기열에서 제외시키기 위해 Job Controller가 작성한 UNIX 시스템 프로세스에 의해 실행되는 명령의 전체 경로를 지정합니다. 이 옵션은 기본적으로 섹션 외부에 설정된 경우 MASTER_COMMAND를 지정하지 않는 모든 [CHANNEL] 섹션에 사용됩니다. [POOL] 섹션 안에 있을 경우 이 옵션은 무시됩니다.

MAX_LIFE_AGE=integer

채널 마스터 작업의 최대 수명 시간을 초 단위로 지정합니다. 채널에 이 매개 변수가 지정되지 않은 경우 전역 기본값이 사용됩니다. 기본값이 지정되지 않은 경우 1800(30분)이 사용됩니다. 

MAX_LIFE_CONNS=integer

최대 수명 매개 변수 외에 메일이 있는지 Job Controller에 물어볼 수 있는 횟수에 따라 채널 마스터 작업의 기대 수명이 제한됩니다. 채널에 이 매개 변수가 지정되지 않은 경우 전역 기본값이 사용됩니다. 기본값이 지정되지 않은 경우 300이 사용됩니다. 

SLAVE_COMMAND=file_spec

채널을 실행하고 해당 채널에 대한 모든 인바운드 메일을 폴하기 위해 Job Controller가 작성한 UNIX 시스템 프로세스에 의해 실행되는 명령의 전체 경로를 지정합니다. 대부분의 MTA 채널은 SLAVE_COMMAND를 갖지 않습니다. 이러한 경우 예약된 값 NULL을 지정해야 합니다. 이 옵션은 기본적으로 섹션 외부에 설정된 경우 SLAVE_COMMAND를 지정하지 않는 모든 [CHANNEL] 섹션에 사용됩니다. [POOL] 섹션 안에 있을 경우 이 옵션은 무시됩니다.

별칭

MTA는 실제 사용자와 반드시 일치할 필요가 없는 로컬 시스템과 연관된 메일함 이름, 즉 별칭을 지원하는 기능을 제공합니다. 별칭은 메일 목록 생성, 메일 전달 및 아이디에 대한 동의어 제공 등에 유용합니다. 별칭 지정이 처리되는 방법에 대한 자세한 내용은 $V 메타 문자를 참조하십시오.

aliases 파일 또는 별칭 데이터베이스에 정의되어 있는 이전 스타일의 메일 목록은 이제 nonpositional [capture] 매개 변수를 갖습니다. [capture] 매개 변수가 사용되는 경우, 이 매개 변수는 LDAP의 사용자나 그룹에 적용되는 LDAP_CAPTURE 속성에서 지정한 캡처 주소와 같은 의미의 캡처 주소를 지정합니다.

별칭 데이터베이스

별칭 데이터베이스 사용은 권장되지 않습니다. 대신, imsimta reload 명령을 사용하여 동적으로 재로드할 수 있는 aliases 파일을 사용합니다.

MTA는 디렉토리의 정보를 사용하여 별칭 데이터베이스를 만듭니다. 일반 별칭 파일이 참조될 때마다 별칭 데이터베이스가 한 번씩 참조됩니다. 그러나 별칭 데이터베이스는 일반 별칭 파일이 사용되기 전에 검사됩니다. 실제로 별칭 데이터베이스는 별칭 파일을 사용하기 전에 호출되는 일종의 주소 재작성기의 역할을 수행합니다.

주 –

데이터베이스 자체 형식은 개인적입니다. 데이터베이스를 직접 편집하려고 해서는 안 되며 필요한 모든 사항을 디렉토리에서 변경합니다.

별칭 파일

aliases 파일은 디렉토리에 설정되지 않은 별칭을 설정하는 데 사용됩니다. 특히 포스트마스터 별칭을 좋은 예로 들 수 있습니다. 이 파일에 설정된 별칭은 디렉토리에 동일한 별칭이 존재할 경우 무시됩니다. imsimta reload 명령을 실행하거나 MTA를 다시 시작하여 변경 사항을 활성화할 수 있습니다. 느낌표로 시작되는 모든 행은 주석으로 간주되어 무시됩니다. 또한 빈 행도 무시됩니다.

주 –

Messaging Server는 주소 역방향 데이터베이스 및 특수한 매핑 테이블과 같은 주소 조작을 위한 다른 기능을 제공합니다. 그러나 최상의 성능을 위해서는 주소 조작을 수행할 수 있을 때마다 다시 쓰기 규칙을 사용하는 것이 좋습니다. 11 장, 다시 쓰기 규칙 구성을 참조하십시오.

이 파일의 물리적 행은 1024자로 제한됩니다. 백슬래시(\) 연결 문자를 사용하여 논리적 행을 여러 물리적 행으로 분할할 수 있습니다.

이 파일의 형식은 다음과 같습니다.

user@domain: address (호스트된 도메인의 사용자인 경우)

user@domain: address (호스트되지 않은 도메인의 사용자인 경우. 예: default-domain)

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


! A /var/mail/ user
inetmail@siroe.com: inetmail@native-daemon

! A message store user
ms_testuser@siroe.com: mstestuser@ims-ms-daemon

별칭 파일에 다른 파일 포함

주 aliases 파일에 다른 파일을 포함할 수 있습니다. 다음 형식의 행은 file-spec 파일을 읽도록 MTA에 지시합니다. 

<file-spec

파일 지정은 완전한 파일 경로 지정이어야 하며 파일은 주 aliases 파일과 동일한 보호를 가져야 합니다. 예를 들어, 세계 공용이어야 합니다.

포함 파일의 내용은 해당 참조 지점에서 aliases 파일에 삽입됩니다. 포함 파일에 대한 참조를 파일의 실제 내용으로 대체하여 동일한 결과를 얻을 수 있습니다. 포함 파일의 형식은 주 aliases 파일 자체의 형식과 같습니다. 실제로 포함 파일 자체에 다른 파일이 포함될 수 있습니다. 최대 세 개 수준까지의 포함 파일 중첩이 허용됩니다.

명령줄 유틸리티

Messaging Server는 MAT에 대한 다양한 유지 관리, 테스트 및 관리 작업을 수행할 수 있는 여러 명령줄 유틸리티를 제공합니다. 예를 들어, imsimta cnbuild 명령을 사용하여 MTA 구성, 별칭, 매핑, 보안, 시스템 전체 필터 및 옵션 파일을 컴파일할 수 있습니다. MTA 명령줄 유틸리티에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference를 참조하십시오.

SMTP 보안 및 액세스 제어

SMTP 보안 및 액세스 제어에 대한 자세한 내용은 17 장, 메일 필터링 및 액세스 제어을 참조하십시오.

로그 파일

모든 MTA 특정 로그 파일은 로그 디렉토리(msg_svr_base/log)에 저장됩니다. 이 디렉토리는 MTA를 통과하는 메일 트래픽을 설명하는 로그 파일과 특정 마스터 또는 슬레이브 프로그램에 대한 정보를 설명하는 로그 파일을 포함합니다.

MTA 로그 파일에 대한 자세한 내용은 21 장, 로깅 관리을 참조하십시오.

주소를 내부 형식에서 공용 형식으로 변환

주소 역방향 데이터베이스(역방향 데이터베이스라고도 부름)와 REVERSE 매핑 테이블을 사용하여 주소를 내부 형식에서 공용 광고 형식으로 변환할 수 있습니다. 예를 들어, uid@mailhost.siroe.com은 siroe.com 도메인 내에서 유효 주소일 수 있지만 외부에 공개하기에는 적합하지 않을 수 있습니다. 이 경우에는 내부 주소 대신에 firstname.lastname@siroe.com과 같은 공용 주소를 사용하는 것이 필요합니다.

주 –

Messaging Server는 aliases 파일 및 특수한 매핑 테이블과 같은 주소 조작을 위한 다른 기능을 제공합니다. 그러나 최상의 성능을 위해서는 주소 조작을 수행할 수 있을 때마다 다시 쓰기 규칙을 사용하는 것이 좋습니다. 11 장, 다시 쓰기 규칙 구성을 참조하십시오.

역방향 데이터베이스에서 각 사용자의 공용 주소는 디렉토리에 있는 사용자 항목의 mail 속성에 의해 지정됩니다. 개인 또는 내부 주소는 mailAlternativeAddress 속성에 의해 지정됩니다. 이는 배포 목록의 경우에도 마찬가지입니다.

역방향 데이터베이스는 임의 유효 주소와 이 공용 주소 간의 매핑을 포함합니다. 역방향 데이터베이스는 일반적으로 MTA 데이터베이스 디렉토리에 위치합니다. 데이터베이스는 msg_svr_base/config/imta_tailor 파일에서 IMTA_REVERSE_DATABASE 옵션을 사용하여 이름을 지정하는 파일이며 기본적으로 msg_svr_base/data/db/reversedb.*입니다.

데이터베이스에서 주소가 발견될 경우 데이터베이스의 해당 오른쪽 부분이 주소로 대체됩니다. 주소가 발견되지 않을 경우 mappings 파일에서 REVERSE라는 매핑 테이블을 찾으려는 시도가 수행됩니다. 테이블이 존재하지 않거나 테이블의 항목이 일치하지 않을 경우 대체가 수행되지 않으며 다시 쓰기가 정상적으로 종료됩니다.

mappings 파일에서 REVERSE 매핑 테이블이 발견되고 주소가 매핑 항목과 일치할 경우 결과 문자열이 주소를 대체합니다(항목에서 $Y를 지정한 경우). $N이 지정된 경우에는 매핑 결과가 무시됩니다. 매핑 항목에서 $Y 외에 $D가 지정된 경우 결과 문자열은 역방향 데이터베이스에서 한 번 더 실행됩니다. 여기에서 일치하는 항목이 발생하면 데이터베이스의 템플리트가 매핑 결과(즉, 주소)를 대체합니다. 아래에는 일반 REVERSE 매핑 테이블 항목(즉, 모든 채널에 적용되는 항목)의 형식이 나와 있습니다. 플래그는 새 주소의 앞이나 끝에 올 수 있다는 점을 유의하십시오.


REVERSE

   OldAddress        $Y[Flags]NewAddress

아래에는 channel-specific 항목(즉, 특정 채널을 통과하는 메일에서만 발생하는 매핑)의 형식이 나와 있습니다. 채널 특정 항목이 작동하려면 option.dat에서 use_reverse_database를 13으로 설정해야 한다는 점을 유의하십시오.


REVERSE

   source-channel|destination-channel|OldAddress  $Y[Flags]NewAddresS

표 10–7은 REVERSE 매핑 테이블 플래그를 보여 줍니다.

표 10–7 REVERSE 매핑 테이블 플래그

플래그 

설명 

$Y 

출력을 새 주소로 사용합니다. 

$N 

주소가 변경되지 않고 그대로 유지됩니다. 

$D 

역방향 데이터베이스를 통해 출력을 실행합니다. 

$A 

역방향 데이터베이스 항목으로 패턴을 추가합니다. 

$F 

정방향 데이터베이스 항목으로 패턴을 추가합니다. 

플래그 비교

설명

$:B 

헤더(본문) 주소만 일치합니다. 

$:E 

봉투 주소만 일치합니다. 

$:F 

정방향 지정 주소만 일치합니다. 

$:R 

역방향 지정 주소만 일치합니다. 

$:I 

메일 아이디만 일치합니다. 

주소 역방향 제어 설정

reverse 및 noreverse 채널 키워드와 MTA 옵션 USE_REVERSE_DATABASE 및 REVERSE_ENVELOPE을 사용하여 주소 역방향을 적용할 시기와 방법에 대한 세부 사항을 제어합니다. 기본적으로 주소 역방향 작업은 단지 역방향 지정 주소가 아니라 모든 주소에 적용됩니다.

주소 역방향은 REVERSE_ENVELOPE 시스템 옵션 값(기본값: 1-on, 0-off)의 설정에 따라서 활성화 또는 비활성화됩니다.

대상 채널의 noreverse 는 메일의 주소에 주소 역방향이 적용되지 않도록 지정합니다. reverse는 주소 역방향을 적용하도록 지정합니다. 자세한 내용은 역방향 데이터베이스의 채널별 사용을 참조하십시오.

USE_REVERSE_DATABASE는 MTA가 주소 역방향 데이터베이스와 REVERSE 매핑을 대체 주소의 소스로 사용하는지 여부를 제어합니다. 값 0은 채널에서 주소 역방향이 사용되지 않는다는 것을 의미합니다. 기본값인 5는 단지 역방향 지정 주소가 아니라 모든 주소(MTA 주소 다시 쓰기 프로세스에 의해 재작성된 후)에 주소 역방향을 적용하도록 지정합니다. 값 13은 단지 역방향 지정 주소가 아니라 reverse 채널 키워드를 가진 주소(MTA 주소 다시 쓰기 프로세스에 의해 재작성된 후에)에 주소 역방향을 적용하도록 지정합니다. 더 세부적인 주소 역방향 작업은 USE_REVERSE_DATABASE 옵션의 비트 값을 설정하여 지정할 수 있습니다. 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 Option File Format and Available Options를 참조하십시오.

REVERSE_ENVELOPE 옵션은 주소 역방향이 메일 헤더 주소뿐만 아니라 봉투의 From 주소에 적용되는지 여부를 제어합니다.

구체적인 효과에 대해서는 Sun Java System Messaging Server Administration Reference에서 이러한 옵션과 키워드에 대한 자세한 설명을 참조하십시오.

일반 역방향 매핑 예

다음 예는 일반 REVERSE 매핑을 보여 줍니다. 여기서는 siroe.com의 내부 주소가 user@mailhost.siroe.com 형식을 갖는 것으로 가정합니다. 그러나 아이디 공간은 user@host1.siroe.com 및 user@host2.siroe.com이 siroe.com의 모든 호스트에 대해 동일한 사용자를 지정하는 것으로 간주됩니다. 다음 REVERSE 매핑은 주소 역방향 데이터베이스와 함께 사용될 수 있습니다. 

REVERSE

   *@*.siroe.com        $0@siroe.com$Y$D

이 예에서 name@anyhost.siroe.com 형식의 주소는 name@siroe.com으로 변경됩니다. $D 메타 문자는 주소 역방향 데이터베이스를 참조하도록 합니다. 주소 역방향 데이터베이스는 다음 형식의 항목을 포함해야 합니다.

user@mailhost.siroe.com     first.last@siroe.com

채널 특정 역방향 매핑 예

기본적으로 주소 역방향 데이터베이스는 라우팅 가능성 범위가 메일 서버 도메인으로 설정된 경우에 사용됩니다. 채널 특정 REVERSE 매핑 테이블 항목의 예는 다음과 같습니다.

REVERSE

   tcp_*|tcp_local|binky@macho.siroe.com    $D$YRebecca.Woods@siroe.com

이 항목은 tcp_local의 대상 채널에서 나가는 tcp_* 소스 채널을 가진 모든 메일에 대해 binky@macho.siroe.com 형식의 주소를 Rebecca.Woods@siroe.com으로 변경하도록 MTA에 지시합니다.

주 –

채널 특정 역방향 매핑을 사용하려면 option.dat에서 USE_REVERSE_DATABASE 옵션을 13(기본값=3)으로 설정해야 합니다.

정방향 조회 테이블 및 FORWARD 주소 매핑

주소 역방향은 봉투의 To: 주소에 적용되지 않습니다. 이는 메일이 메일 시스템을 통과할 때 봉투의 To: 주소가 계속해서 재작성 및 수정된다는 확실한 이유가 있기 때문입니다. 라우팅의 전체 목표는 봉투의 To: 주소를 점차적으로 시스템 및 메일함 특정 형식으로 변환하는 것입니다. 주소 역방향의 정형화 기능은 전반적으로 봉투의 To: 주소에 적용되지

어떠한 경우든 MTA에서 풍부한 기능을 사용하여 봉투의 To: 주소에 적용되지 별칭 파일, 별칭 데이터베이스 및 일반 조회 테이블이 바로 이 기능을 정확하게 제공합니다.

MTA에서는 또한 패턴 기반 전달, 소스 고유 전달 또는 주소 자동 등록과 같은 특수한 전달 목적에 사용되는 정방향 조회 테이블과 FORWARD 매핑을 사용할 수 있습니다. 정방향 조회 테이블과 FORWARD 매핑은 주로 특수한 종류의 주소 전달에 사용하도록 되어 있다는 점을 유의하십시오. 즉, 대부분의 주소 전달은 MTA의 다른 전달 기법 중 하나를 사용할 때 더 효율적으로 수행됩니다.

봉투의 To: 주소에 대한 다양한 대체 기법은 역방향 조회 테이블과 동일한 기능을 제공하지만 역방향 매핑과 동일한 기능에 대해서는 아직 언급된 것이 없습니다. 경우에 따라서는 봉투의 To: 주소에 대한 매핑 기능이 유용하고 바람직할 수 있습니다.

FORWARD 매핑 테이블

FORWARD 매핑 테이블은 패턴을 기반으로 하는 전달 기능을 제공하며 소스 고유 전달을 위한 기법도 제공합니다. FORWARD 매핑 테이블이 매핑 파일에 있으면 각 봉투의 To: 지시합니다. 이 매핑이 존재하지 않거나 매핑의 항목이 일치하지 않을 경우 변경이 수행되지 않습니다.

주소가 매핑 항목과 일치할 경우 매핑 결과가 테스트됩니다. 항목에 $Y가 지정될 경우 결과 문자열이 봉투의 To: 주소를 대체하며 $N이 지정될 경우 매핑 결과를 무시합니다. 추가 플래그 목록은 표 10–8을 참조하십시오.

표 10–8 FORWARD 매핑 테이블 플래그 설명

플래그 

설명 

$D 

다시 쓰기 프로세스를 통해 출력을 다시 실행합니다. 

$G 

정?항 조회 테이블을 통해 출력을 실행합니다(정방향 조회 테이블이 사용 가능하게 된 경우). 

$H 

추가 정방향 조회 테이블이나 FORWARD 매핑 조회를 사용 불가능하게 합니다. 

$I 

메일을 .HELD 파일로 보관합니다.

$N 

주소가 변경되지 않고 그대로 유지됩니다. 

$Y 

출력을 새 주소로 사용합니다. 

FORWARD 매핑(있을 경우)은 정방향 조회 테이블이 조회되기 전에 참조됩니다. FORWARD 매핑이 일치하고 플래그 $G가 있을 경우 정방향 조회 테이블에 대해 FORWARD 매핑의 결과가 검사됩니다(USE_FORWARD_DATABASE의 적절한 설정을 통해 정방향 조회 테이블이 사용 가능하게 된 경우). 채널 고유 정방향 조회 테이블 사용이 지정된 경우 정방향 조회 테이블에서 조회하기 전에 FORWARD 매핑의 결과에 소스 주소와 소스 채널이 접두어로 추가된다는 점을 유의하십시오. 일치하는 FORWARD 매핑 항목에 $D가 지정된 경우 FORWARD 매핑의 결과와 선택적 정방향 테이블 조회가 MTA 주소 다시 쓰기 프로세스를 통해 다시 실행됩니다. 일치하는 FORWARD 매핑 항목에 $H가 지정된 경우 $D 사용으로 인해 발생하는 후속 주소 다시 쓰기 프로세스 동안에 추가 FORWARD 매핑이나 데이터베이스 조회가 수행되지 않습니다.

아래 예는 복잡한 REVERSE 및 FORWARD 매핑의 사용을 보여 줍니다. 여기에서는 mr_local 채널과 연관된 am.sigurd.innosoft.com이라는 시스템 또는 의사 도메인이 일반적인 형식의 RFC 822 주소를 생성한다고 가정합니다.

"lastname, firstname"@am.sigurd.example.com

또는

"lastname,firstname"@am.sigurd.example.com

이러한 주소는 완전히 유효하지만 RFC 822 구문 규칙을 완벽하게 따르지 않는 전자 메일 프로그램(예: 인용된 주소를 제대로 처리하지 않은 전자 메일 프로그램)에서는 흔히 혼동을 일으킵니다. 결과적으로 인용이 필요하지 않는 주속 형식이 더 많은 전자 메일 프로그램에서 작동합니다. 이러한 형식 중 하나는 다음과 같습니다.

firstname.lastname@am.sigurd.example.com

복잡한 FORWARD 및 REVERSE 매핑 예

REVERSE

 *|mr_local|"*,$ *"@am.sigurd.example.com $Y"$1,$ $2"@am.sigurd.example.com
 *|mr_local|"*,*"@am.sigurd.example.com   $Y"$1,$ $2"@am.sigurd.example.com
 *|*|"*,$ *"@am.sigurd.example.com        $Y$3.$2@am.sigurd.example.com
 *|*|"*,*"@am.sigurd.example.com          $Y$3.$2@am.sigurd.example.com
 *|mr_local|*.*@am.sigurd.example.com     $Y"$2,$ $1"@am.sigurd.example.com
 *|*|*.*@am.sigurd.example.com            $Y$2.$3@am.sigurd.example.com

FORWARD

 "*,$ *"@am.sigurd.example.com            $Y"$0,$ $1"@am.sigurd.example.com
 "*,*"@am.sigurd.example.com              $Y"$0,$ $1"@am.sigurd.example.com
 *.*@am.sigurd.example.com                $Y"$1,$ $0"@am.sigurd.example.com

따라서 위 예에 나온 샘플 매핑 테이블은 (1) 이러한 세 개의 주소 형식을 모두 사용할 수 있도록 허용하고, (2) 원래 형식의 주소만 mr_local 채널에 제공하고 필요에 따라 형식을 변환하며, (3) 인용되지 않은 새 형식의 주소만 다른 모든 채널에 제공하고 필요에 따라 형식을 변환하는 세 가지 목적을 가집니다. (위의 REVERSE 매핑에서는 MTA 옵션 USE_REVERSE_DATABASE에 비트 3이 설정된 것으로 가정합니다.)

정방향 조회 테이블

주소 전달이 자동 등록되거나 소스별로 고유해야 할 경우 정방향 조회 테이블을 사용할 수 있습니다. 간단한 메일 전달에는 일반적으로 정방향 조회 테이블을 사용하는 것이 적합하지 않으며 aliases 파일 또는 별칭 조회 테이블이 이러한 전달을 수행하는 데 더 효율적인 방법이라는 점을 유의하십시오. 기본적으로 정방향 조회 테이블은 전혀 사용되지 않으므로 USE_FORWARD_DATABASE 옵션을 통해 명시적으로 사용 가능하게 해야 합니다. 정방향 테이블 조회는 주소 다시 쓰기 이후, 별칭 확장이 수행된 후, 그리고 임의의 FORWARD 매핑이 검사된 후에 수행됩니다. 정방향 테이블 조회에 성공할 경우 MTA 주소 다시 쓰기 프로세스를 통해 대체된 결과 주소가 다시 실행됩니다.

정방향 조회 테이블에는 메모리 내장 해시 테이블과 기본 데이터베이스의 두 가지 기법을 사용할 수 있습니다. 테이블의 크기가 너무 크지 않을 경우 해시 테이블이 권장됩니다(1,000은 너무 큰 것이 아니지만 100,000은 너무 크다고 할 수 있습니다). 해시 테이블은 use_text_database 옵션에서 비트 3(값 34)을 설정하고 use_forward_database를 설정하여 활성화합니다. 해시 테이블은 msg_svr_base/configure/forward.txt에서 읽어오고 구성의 재로드 가능 부분으로 컴파일되며 imsimta reload 명령에 의해 강제로 활성 MTA 프로세스로 재로드될 수 있습니다.

정방향 데이터베이스는 소스 텍스트 파일에서 crdb 유틸리티를 사용하여 만든 MTA crdb 데이터베이스입니다. 소스 텍스트 파일의 형식은 기본적으로 다음과 같습니다.


user1@domain1 changedmailbox1@changeddomain1
user2@domain2 changedmailbox@changeddomain2

그러나 USE_FORWARD_DATABASE 옵션의 비트 3을 설정하여 정방향 데이터베이스의 소스별 사용을 가능하게 한 경우 소스 텍스트 파일 형식은 다음과 같습니다.

source-channel|source-address|original-address changed-address

예를 들어, 다음과 같은 항목은


tcp_limited|bob@blue.com|helen@red.com  “helen of troy”@siroe.com

bob@blue.com에서 메일이 오고 대기열을 넣는 채널이 tcp_limited인 경우에만 To: 주소 helen@red.com을 “helen of troy”@siroe.com에 매핑합니다.

전달 상태 알림 메일 제어

전달 상태 알림 또는 상태 알림은 MTA가 보낸 사람이나 선택적으로 포스트마스터로 보내는 전자 메일 상태 메일입니다. Messaging Server를 사용하면 내용이나 언어별로 알림 메일을 사용자 정의할 수 있습니다. 또한 각 유형의 전달 상태(예: FAILED, BOUNCED, TIMEDOUT 등)에 대해 다른 메일을 만들 수 있습니다. 이외에도 특정 채널에서 보내지는 메일에 대한 상태 알림을 만들 수 있습니다.

기본적으로 상태 알림은 msg_svr_base/config/locale/C 디렉토리에 저장됩니다(msg_svr_base/config/imta_tailor 파일의 IMTA_LANG 설정에서 지정됨). 파일 이름은 다음과 같습니다.

return_bounced.txt, return_delivered.txt return_header.opt, return_timedout.txt, return_deferred.txt, return_failed.txt, return_prefix.txt, return_delayed.txt, return_forwarded.txt, return_suffix.txt

*.txt 파일의 메일 텍스트는 한 행당 78자로 제한되어야 합니다. 이러한 파일은 Messaging Server를 업그레이드할 때 덮어쓰게 되므로 이러한 파일을 직접 변경하면 안 됩니다. 이러한 파일을 수정하고 유일한 알림 메일 템플리트 집합(return_*.txt)으로 사용하려면 파일을 새 디렉토리로 복사하여 해당 위치에서 편집합니다. 그런 다음 이러한 템플리트를 포함하는 새 디렉토리를 가리키도록 imta_tailor 파일에서 IMTA_LANG 옵션을 설정합니다. 각 언어에 대한 집합이 필요한 경우처럼 여러 집합의 알림 파일을 원할 경우 NOTIFICATION_LANGUAGE 매핑 테이블을 설정해야 합니다.

상태 알림 생성 및 수정

단일 알림 메일은 세 파일 집합 return_prefix.txt + return_ActionStatus.txt + return_suffix.txt로부터 생성됩니다.

알림을 사용자 정의하거나 현지화하려면 각 로켈 및/또는 사용자 정의에 대해 전체 return_*.txt 파일을 만들어서 별도의 디렉토리에 저장합니다. 예를 들어 프랑스어 알림 파일을 한 디렉토리에 저장해 놓고 스페인어 알림 파일을 또 다른 디렉토리에 저장하고 원치 않는 대량 전자 메일 채널에 대한 알림을 다른 디렉토리에 저장할 수 있습니다.

주 –

이 릴리스에는 프랑스어, 독일어, 스페인어 샘플 파일이 포함되어 있습니다. 자신의 고유한 요구에 맞도록 이러한 파일을 수정할 수 있습니다.

일본어와 같은 더블바이트 언어의 경우 텍스트를 일본어로 생성한 다음 해당 텍스트를 ASCII인 것처럼 표시하여 % 문자를 검사합니다. % 문자가 잘못 들어가 있을 경우 이를 %%으로 대체합니다.

상태 알림 메일 집합의 형식과 구조는 다음과 같습니다.

  1. return_prefix.txt는 본문의 소개 부분뿐만 아니라 해당하는 헤더 텍스트를 제공합니다. 미국 영어 로켈에 대한 기본값은 다음과 같습니다.


    Content-type: text/plain; charset=us-asci
Content-language: EN-US

This report relates to a message you sent with the following
header fields: %H

    미국 ASCII가 아닌 상태 알림 메일의 경우 charset 매개 변수와 Content-Language 헤더 값을 적절하게 변경해야 합니다. 예를 들어, 현지화된 프랑스어 파일의 경우 이러한 값은 ISO-8859-1 및 fr입니다. %H는 표 10–9에 정의된 헤더 대체 시퀀스입니다.

  2. return_<ActionStatus >.txt는 상태 특정 텍스트를 포함합니다. ActionStatus는 메일의 MTA 상태 유형을 나타냅니다. 예를 들어, return_failed.txt의 기본 텍스트는 다음과 같습니다.

    Your message cannot be delivered to the following recipients:%R

    return_bounced.txt의 기본 텍스트는 다음과 같습니다.

    Your message is being returned. It was forced to return bythe postmaster.

    The recipient list for this message was:%R

  3. return_suffix.txt는 결과 텍스트를 포함합니다. 기본적으로 이 파일은 비어 있습니다.

표 10–9 알림 메일 대체 시퀀스

대체 

정의 

%H 

메일의 헤더로 확장됩니다. 

%C 

메일을 대기열에 포함했던 단위 수1로 확장됩니다.

%L 

메일이 반환되기 전에 대기열에 남아 있었던 메일의 단위 수1로 확장됩니다.

%F 

메일이 대기열에 머무르는 것이 허용되는 단위 수1로 확장됩니다.

%S [%s] 

이전에 확장된 숫자 값이 1이 아닐 경우 문자 S 또는 s로 확장됩니다. 예: 메일이 대기열에 포함되었던 일 수에 따라 “%C day%s”는 “1day” 또는 “2days”로 확장될 수 있습니다. 

%U [%u] 

사용 중인 시간 단위 Hour [hour] 또는 Day [day]로 확장됩니다. 예: 메일이 대기열에 포함되었던 일 또는 시간과 MTA 옵션 RETURN_UNITS에 따라 “%C %U%s”가 “2 days” 또는 “1 hour”로 확장될 수 있습니다. RETURN_UNITS=1(시간)을 설정했으며 사이트에서 현지화된 상태 알림 메일을 사용할 경우 return_delayed.txt 및 return_timedout.txt를 편집하여 영어가 아닌 모든 언어에 대해 “days” 단어를 hours로 대체해야 합니다. 예를 들어, 프랑스어는 jour(s)를 heure(s)로,독일어는 Tag(e)를 Stunde(n)로, 스페인어는 d?a(s)를 hora(s)로 바꿔야 합니다.

%R 

메일 수신자의 목록으로 확장됩니다. 

%% 

% (텍스트는 문자 세트에 상관 없이 대체 시퀀스에 대해 바이트 단위로 스캔된다는 것에 주의합니다. 더블바이트 문자 세트를 사용하는 중이면 % 기호가 잘못 들어가 있지 않은지 검사합니다.) 

1 단위는 MTA 옵션 파일의 RETURN_UNITS 옵션에 의해 정의되며 시간 또는 일(기본값)이 될 수 있습니다.

전달 상태 알림 메일 사용자 정의 및 현지화

전달 상태 알림 메일을 현지화하여 여러 다른 언어로 여러 사용자에게 메일을 반환할 수 있습니다. 예를 들어, 프랑스어를 선호하는 사용자에게 프랑스어 알림을 반환할 수 있습니다.

상태 알림 메일을 현지화 또는 사용자 정의하는 것은 다음 두 단계로 구성됩니다.

  1. 현지화/사용자 정의된 return_*.txt 메일 파일 집합을 만들어 각 집합을 별도의 디렉토리에 저장합니다. 이에 대해서는 상태 알림 생성 및 수정에 설명되어 있습니다.

  2. NOTIFICATION_LANGUAGE 매핑 테이블을 설정합니다.

msg_svr_base/config/mappings에 있는 NOTIFICATION_LANGUAGE 매핑 테이블은 원본 메일(알림을 보내는 원인이 되는 메일)의 속성(예: 언어, 국가, 도메인 또는 주소)에 따라 현지화되거나 사용자 정의된 알림 메일 파일 집합을 사용하도록 지정합니다.

상태 알림 유형, 소스 채널, 기본 언어, 반송 주소 및 첫 번째 수신자를 결정하기 위해 원래 보낸 사람의 메일이 구문 분석됩니다. 테이블의 구성 방법에 따라 이러한 속성 중 하나 이상에 기초하여 알림 파일 집합이 선택됩니다.

NOTIFICATION_LANGUAGE 매핑 테이블의 형식은 다음과 같습니다. 인쇄상의 이유로 샘플 항목에서는 줄 바꿈되었지만 실제 항목은 한 행에 표시됩니다.


NOTIFICATION_LANGUAGE

 dsn-type-list|source-channel|preferred-language|return-address \
|first-recipient $Idirectory-spec


NOTIFICATION_LANGUAGE
 
! Preferred-language: header value specified
!
    *|*|fr|*|*     $I/lc_messages/table/notify_french/
    *|*|es|*|*     $IIMTA_TABLE/notify_spanish/
    *|*|en|*|*     $I/imta/lang/
!
! If no Preferred-language value, then select notification based on the
! country code in the domain name. EX: PF=French Polynesia; BO=Bolivia
!
    *|*|*|*.fr|*   $I/imta/table/notify_french/
    *|*|*|*.fx|*   $I/imta/table/notify_french/
    *|*|*|*.pf|*   $I/imta/table/notify_french/
    *|*|*|*.tf|*   $I/imta/table/notify_french/
    *|*|*|*.ar|*   $I/imta/table/notify_spanish/
    *|*|*|*.bo|*   $I/imta/table/notify_spanish/
    *|*|*|*.cl|*   $I/imta/table/notify_spanish/
    *|*|*|*.co|*   $I/imta/table/notify_spanish/
    *|*|*|*.cr|*   $I/imta/table/notify_spanish/
    *|*|*|*.cu|*   $I/imta/table/notify_spanish/
    *|*|*|*.ec|*   $I/imta/table/notify_spanish/
    *|*|*|*.es|*   $I/imta/table/notify_spanish/
    *|*|*|*.gp|*   $I/imta/table/notify_spanish/
    *|*|*|*.gt|*   $I/imta/table/notify_spanish/
    *|*|*|*.gy|*   $I/imta/table/notify_spanish/
    *|*|*|*.mx|*   $I/imta/table/notify_spanish/
    *|*|*|*.ni|*   $I/imta/table/notify_spanish/
    *|*|*|*.pa|*   $I/imta/table/notify_spanish/
    *|*|*|*.ve|*   $I/imta/table/notify_spanish/
주 –

알림 언어 매핑이 사용 가능하도록 기본 mappings.locale 파일이 설치 시 함께 제공되어 mappings 파일에 포함됩니다. 알림 언어 매핑을 사용 불가능하게 하려면 다음과 같이 포함 줄을 주석 처리합니다.

! <IMTA_TABLE:mappings.locale

(파일에서 주석을 읽은 다음 자신의 요구에 맞게 적절하게 수정합니다.)

생성된 알림 국제화

DSN(Delivery Status Notification) 및 MDN(Message Disposition Notification)을 위한 두 개의 옵션 파일을 사용할 수 있습니다. 생성된 알림의 국제화를 더 유연하게 수행할 수 있게 하는 이러한 파일은 다음과 같습니다.


IMTA_LANG:return_option.dat (DSN)IMTA_LANG:disposition_option.dat (MDN)

표 10–10에는 이러한 파일에 사용할 수 있는 옵션이 설명되어 있습니다.

표 10–10 DSN(Delivery Status Notification) 및 MDN(Message Disposition Notification) 옵션

옵션 

설명 

DAY(DSN)

RETURN_UNITS=0(기본값)을 설정하는 경우 %U 또는 %u 대체에 대해 삽입되는 텍스트입니다. 영어의 “Day” 또는 “day” 각각을 대체하는 기본적인 경우와는 달리 %U 및 %u 간에는 차이점이 없습니다.

DIAGNOSTIC_CODE(DSN)

DSN의 첫 번째 부분에서 수신자별 섹션의 구성에 사용되는 “Diagnostic code:“ 텍스트보다 우선합니다. 이 필드는 DSN의 첫 번째 부분에 사용되는 문자 세트와 같은 문자 세트로 지정해야 합니다.

HOUR(DSN)

RETURN_UNITS=1을 설정하는 경우 %U 또는 %u 대체에 대해 삽입되는 텍스트입니다. 영어의 “Hour” 또는 “hour” 각각을 대체하는 기본적인 경우와는 달리 %U 및 %u 간에는 차이점이 없습니다.

n.n.n(DSN)

DSN의 수신자별 부분을 구성할 때 이름이 수신자별 숫자 상태와 일치하는 옵션이 있는지 확인하는 검사가 수행됩니다. 일치하는 항목이 있는 경우 해당 텍스트가 DSN에 삽입됩니다. 또한 위에서 설명한 REASON 옵션이 길이가 0인 결과를 생성하는 경우 REASON 필드는 삽입되지 않습니다.

ORIGINAL_ADDRESS(DSN)

DSN의 첫 번째 부분에서 수신자별 섹션의 구성에 사용되는 “Original address:” 텍스트보다 우선합니다. 이 필드는 DSN의 첫 번째 부분에 사용되는 문자 세트와 같은 문자 세트로 지정해야 합니다. 

REASON(DSN)

DSN의 첫 번째 부분에서 수신자별 섹션의 구성에 사용되는 “Reason:” 텍스트보다 우선합니다. 이 필드는 DSN의 첫 번째 부분에 사용되는 문자 세트와 같은 문자 세트로 지정해야 합니다.

RECIPIENT_ADDRESS(DSN)

DSN의 첫 번째 부분에서 수신자별 섹션의 구성에 사용되는 “Recipient address:” 텍스트보다 우선합니다. 이 필드는 DSN의 첫 번째 부분에 사용되는 문자 세트와 같은 문자 세트로 지정해야 합니다. 

RETURN_PERSONAL(DSN 및 MDN)

From: 필드와 함께 사용되는 개인 이름 필드보다 우선합니다. 이 필드는 RFC 2047로 인코딩되어야 합니다. 이 옵션을 지정하지 않을 경우 RETURN_PERSONAL MTA 옵션에 설정된 값이 사용됩니다.

SUBJECT(DSN 및 MDN)

Subject: 우선합니다. 이 값은 알림에서 자체의 제목 필드를 제공하지 않은 경우에만 사용됩니다. 이 필드는 RFC 2047로 인코딩되어야 합니다. 이 옵션을 사용하지 않고 알림에서 제목을 제공하지 않은 경우 적절한 제목이 생성됩니다. 

TEXT_CHARSET(MDN)

MDN의 첫 번째 부분과 제목의 문자 세트 텍스트를 변환해야 합니다. 기본값은 변환을 수행하지 않는 것입니다. 

추가 상태 알림 메일 기능

앞의 절에서는 상태 알림 메일을 설정하기 위한 필수 절차에 대해 설명했습니다. 다음 절에서는 추가 기능에 대해 설명합니다.

큰 메일의 내용 반환 차단

일반적으로 메일이 바운스 또는 차단되면 메일 내용이 보낸 사람과 알림 메일의 로컬 도메인 포스트마스터에게 반환됩니다. 이것은 매우 큰 여러 메일이 반환될 경우 자원에 적지 않은 부담이 될 수 있습니다. 일정 크기 이상의 메일 내용이 반환되는 것을 차단하려면 MTA 옵션 파일에서 CONTENT_RETURN_BLOCK_LIMIT 옵션을 설정합니다.

상태 알림 메일의 포함 헤더에서 미국 ASCII가 아닌 문자 제거

인터넷 메일 헤더의 원시 형식은 미국 ASCII가 아닌 문자를 허용하지 않습니다. 미국 ASCII가 아닌 문자가 메일 헤더에 사용된 경우 이러한 문자는 RFC 2047에 설명된 “MIME 헤더 인코딩”을 통해 인코딩됩니다. 따라서 전자 메일의 중국어 “Subject” 행은 실제로 다음과 같이 나타납니다.

Subject: =?big5?Q?=A4j=AB=AC=A8=B1=AD=B1=B0=D3=F5=A5X=AF=B2?=

이 경우 헤더를 표시할 때 인코딩을 제거하는 작업을 전자 메일 클라이언트가 수행합니다.

%H 템플리트가 헤더를 알림 메일의 본문에 복사하므로 인코딩된 헤더 텍스트가 정상적으로 표시됩니다. 그러나 제목의 문자 세트(이 경우에는 “big5”)가 return_prefix.txt의 Content-Type 헤더 문자 세트 매개 변수에 있는 문자 세트와 일치할 경우 Messaging Server는 인코딩을 제거합니다. 이러한 문자 세트가 일치하지 않을 경우 Messaging Server는 인코딩을 그대로 둡니다.

알림 메일 전달 간격 설정

키워드: notices, nonurgentnotices, normalnotices, urgentnotices

전달할 수 없는 메일은 보낸 사람에게 반환하기 전에 지정된 시간 동안 주어진 채널 대기열에 보관됩니다. 또한 Messaging Server가 전달을 시도하는 동안에 일련의 상태/경고 메일이 보낸 사람에게 반환될 수 있습니다. 메일 간의 시간 및 간격은 notices, nonurgentnotices, normalnotices 또는 urgentnotices 키워드를 사용하여 지정할 수 있습니다. 예를 들면 다음과 같습니다.

notices 1 2 3

모든 메일에 대해 1일 및 2일 후에 일시적인 실패 상태 알림 메일이 보내집니다. 3일 후에도 여전히 전달되지 않은 경우 해당 메일은 메일 발송자에게 반환됩니다.

urgentnotices 2,4,6,8

높은 우선 순위를 가진 메일에 대해 2일, 4일 및 6일 후에 일시적인 실패 알림이 보내집니다. 8일 후에도 여전히 전달되지 않은 경우 해당 메일은 메일 발송자에게 반환됩니다.

MTA 옵션 파일의 RETURN_UNITS 옵션에서는 시간(1) 또는 일(0) 단위를 지정할 수 있다는 것에 주의합니다. 기본값은 (0)일입니다. RETURN_UNITS=1을 설정할 경우 반송 작업을 1시간마다 실행하고 알림을 1시간마다 가져오도록 예약해야 합니다. 반송 작업이 1시간마다 실행되면 또한 1시간마다 mail.log* 파일을 롤오버합니다. mail.log 파일이 1시간마다 롤오버되는 것을 방지하려면 imta.tailor 파일의 IMTA_RETURN_SPLIT_PERIOD 조정 파일 옵션을 24로 설정합니다. 반송 작업 예약은 local.schedule.return_job configutil 매개 변수에 의해 제어됩니다.

notices 키워드가 지정되지 않은 경우 기본값은 로컬 l 채널에 대한 notices 설정을 사용하는 것입니다. 로컬 채널에 대한 설정이 없을 경우 notices 3, 6, 9, 12가 기본값으로 사용됩니다.

상태 알림 메일에 변경된 주소 포함

키워드: includefinal, suppressfinal, useintermediate

MTA가 알림 메일(바운스 메일, 전달 수신 확인 메일 등)을 생성할 때 “원래” 형식의 수신자 주소와 MTA에서 사용할 수 있는 변경된 “최종” 형식의 수신자 주소가 모두 존재할 수 있습니다. 알림 메일의 수신자(알림 메일이 관련된 원래 메일을 보낸 사람)가 대개 원래 형식을 인식하므로 MTA는 항상 원래 형식(존재할 경우)을 알림 메일에 포함합니다.

includefinal 및 suppressfinal 채널 키워드는 MTA가 또한 최종 형식의 주소를 포함하는지 여부를 제어합니다. 내부 메일함 이름을 외부에서 볼 수 없도록 “숨기는” 사이트에서는 최종 형식의 주소를 포함하지 않을 수 있습니다. 이러한 사이트는 원래 “외부” 형식의 주소만 상태 알림 메일에 포함하기를 원할 것입니다. 기본값은 최종 형식의 수신자 주소를 포함하는 includefinal입니다. suppressfinal을 사용하면 원래 주소 형식이 존재할 경우 최종 주소 형식이 상태 알림 메일에 표시되지 않습니다.

useintermediate 키워드는 목록이 확장되었지만 사용자 메일함 이름이 생성되기 전에 만들어진 중간 형식의 주소를 사용합니다. 이 정보를 사용할 수 없는 경우 최종 형식이 사용됩니다.

포스트마스터에 대해 상태 알림 메일을 전송, 차단 및 지정

기본적으로 실패 및 경고 상태 알림 메일의 복사본은 오류 반환 및 경고가 빈 Errors-to: 헤더 행 또는 빈 봉투 From: 주소로 완전히 억제되지 않은 경우 포스트마스터에게 보내집니다. 다음 절과 표 10–11에 설명된 여러 채널 키워드를 사용하면 포스트마스터에 대한 알림 메일 전달을 더 세부적으로 제어할 수 있습니다.

반환되는 실패 메일

키워드: sendpost, nosendpost, copysendpost, errsendpost

채널 프로그램은 장기적인 서비스 실패나 잘못된 주소로 인해 메일을 전달하지 못할 수 있습니다. 이 경우 MTA 채널 프로그램은 메일을 전달할 수 없는 이유에 대한 설명과 함께 메일을 보낸 사람에게 반환합니다. 또한 선택적으로 모든 실패 메일의 복사본이 로컬 포스트마스터에게 보내집니다. 이것은 메일 실패를 모니터링하는 데 유용하지만 포스트마스터가 처리해야 하는 과도한 양의 트래픽을 발생시킬 수 있습니다. 표 10–11을 참조하십시오.

경고 메일

키워드:warnpost, nowarnpost, copywarnpost, errwarnpost

메일을 반환하는 것 외에도 MTA는 전달되지 않은 메일에 대한 자세한 경고를 보낼 수 있습니다. 경우에 따라 채널 프로그램이 실패한 전달 시도 이후에 경고 메일을 생성할 수 있지만 이러한 경고는 일반적으로 notices 채널 키워드 설정에 기초한 시간 초과로 인해 발생합니다. 경고 메일은 무엇이 잘못되었는지와 전달 시도가 얼마나 오랫동안 계속되었는지에 대한 설명을 포함합니다. 또한 대부분의 경우 경고 메일은 문제가 된 메일의 헤더와 처음 몇 개의 행을 포함합니다.

선택적으로 모든 경고 메일의 복사본을 로컬 포스트마스터에게 보낼 수 있습니다. 이것은 포스트마스터가 처리해야 하는 많은 양의 트래픽을 발생시키지만 다양한 대기열의 상태를 모니터하는 데 유용할 수 있습니다. 경고 메일을 포스트마스터에게 보내는 것을 제어하기 위해 warnpost, copywarnpost, errwarnpost 및 nowarnpost 키워드가 사용됩니다. 표 10–11을 참조하십시오.

빈 봉투 반송 주소

키워드: returnenvelope

returnenvelope 키워드는 비트 플래그 집합으로 해석되는 단일 정수 값을 가집니다. 비트 0(값 = 1)은 MTA에 의해 생성된 반송 알림이 빈 봉투 주소 또는 로컬 포스트마스터의 주소로 작성되는지 여부를 제어합니다. 이 비트를 설정하면 로컬 마스터 주소가 사용되고 이 비트를 지우면 빈 주소가 사용됩니다.

주 –

RFC 1123에는 빈 주소를 사용하도록 명시되어 있지만 일부 시스템은 빈 봉투의 From: 주소를 적절하게 처리하지 않으므로 이 옵션을 사용하는 것이 필요할 수 있습니다.

비트 1(값 = 2)은 MTA가 모든 빈 봉투 주소를 로컬 포스트마스터의 주소로 대체하는지 여부를 제어합니다. 이 비트는 RFC 821, RFC 822 또는 RFC 1123을 따르지 않는 비호환 시스템을 수용하는 데 사용됩니다.

비트 2(값 = 4)는 구문적으로 잘못된 반송 주소를 사용할 수 없게 합니다.

비트 3(값 = 8)은 mailfromdnsverify 키워드와 동일합니다.

포스트마스터에게 반환되는 메일 내용

키워드:postheadonly, postheadbody

채널 프로그램이나 정기적인 메일 반송 작업이 포스트마스터와 원래의 보낸 사람 모두에게 메일을 반환할 경우 포스트마스터 복사본은 전체 메일이나 헤더가 될 수 있습니다. 포스트마스터 복사본을 단지 헤더로 제한하면 사용자 메일의 프라이버시 수준이 향상됩니다. 그러나 일반적으로 포스트마스터와 시스템 관리자는 원할 경우 root 시스템 권한을 사용하여 메일 내용을 읽을 수 있으므로 이러한 제한만으로 메일 보안이 보장되지는 않습니다. 표 10–11을 참조하십시오.

채널별 포스트마스터 주소 설정

키워드: aliaspostmaster, returnaddress, noreturnaddress, returnpersonal, noreturnpersonal

기본적으로 MTA가 바운스 또는 상태 알림 메일을 생성할 때 사용되는 포스트마스터의 반송 주소는 postmaster@local-host입니다. 여기서 local-host는 공식 로컬 호스트 이름(로컬 채널에 있는 이름)이고 포스트마스터 개인 이름은 “MTA e-Mail Interconnect”입니다. 잘못된 포스트마스터 주소를 선택할 경우 급격한 메일 루핑과 많은 오류 메시지가 발생할 수 있으므로 주의해야 합니다.

RETURN_ADDRESS 및 RETURN_PERSONAL 옵션을 사용하면 포스트마스터 주소 및 개인 이름에 대한 MTA 시스템 기본값을 설정할 수 있습니다. 또는 채널별 제어를 원할 경우 returnaddress 및 returnpersonal 채널 키워드를 사용할 수 있습니다. returnaddress 및 returnpersonal은 각각 포스트마스터 주소와 포스트마스터 개인 이름을 지정하는 필수 인수를 가집니다. 기본적으로 noreturnaddress와 noreturnpersonal이 지정되며 이것은 기본값이 사용되어야 한다는 것을 의미합니다. 기본값은 RETURN_ADDRESS 및 RETURN_PERSONAL 옵션을 통해 지정하거나 이러한 옵션이 설정되지 않은 경우 보통의 기본값으로 지정됩니다.

aliaspostmaster 키워드가 채널에 있을 경우 사용자 이름 postmaster(소문자, 대문자 또는 대소문자 혼합)로 주소 지정된 모든 메일은 postmaster@local-host로 리디렉션됩니다. 여기서 local-host는 공식 로컬 호스트 이름(로컬 채널의 이름)입니다. 인터넷 표준에 따르면 메일을 수락하는 DNS의 모든 도메인이 메일을 수신하는 유효한 포스트마스트 계정을 가져야 한다는 것에 주의합니다. 따라서 여러 다른 도메인에 대해 별개의 포스트마스터 계정을 설정하는 대신 포스트마스터의 책임을 중앙 집중화하려는 경우 이 키워드가 유용할 수 있습니다. 즉, returnaddress가 MTA에서 포스트마스터의 알림 메일을 생성할 때 사용되는 반송 포스트마스터 주소를 제어하는 것과 달리 aliaspostmaster는 포스트마스터로 주소 지정된 메일을 MTA에서 처리하는 방법에 영향을 줍니다.

표 10–11 포스트마스터 및 보낸 사람에게 알림 메일을 보내는 데 사용되는 키워드

키워드 

설명 

반환되는 메일 내용

알림에 대한 주소 지정

notices

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

nonurgentnotices

낮음 우선 순위를 갖는 메일에 대해 알림을 보낸 후 메일을 반환되기 전에 경과할 수 있는 시간을 지정합니다. 

normalnotices

중간 우선 순위를 갖는 메일에 대해 알림을 보낸 후 메일을 반환되기 전에 경과할 수 있는 시간을 지정합니다. 

urgentnotices

높음 우선 순위를 갖는 메일에 대해 알림을 보낸 후 메일을 반환되기 전에 경과할 수 있는 시간을 지정합니다. 

반환되는 메일

반환되는 메일에 대한 실패 알림 처리 방법

sendpost

실패한 모든 메일의 복사본을 포스트마스터에게 보냅니다. 

copysendpost

전송 실패 메일에서 메일 발송자 주소가 비어 있지 않는 한 실패 알림 복사본을 포스트마스터에게 보냅니다. 이 경우 포스트마스터는 실제로 바운스 또는 알림인 메일을 제외하고 실패한 모든 메일의 복사본을 갖게 됩니다.  

errsendpost

메일 발송자에게 알림을 보낼 수 없는 경우 실패 알림 복사본을 포스트마스터에게 보냅니다. nosendpost가 지정된 경우 실패한 메일은 포스트마스터에게 보내지지 않습니다.

nosendpost

전달이 실패한 모든 메일의 복사본을 포스트마스터에게 보내지 않습니다. 

경고 메일

경고 메일 처리 방법

warnpost

경고 메일의 복사본을 포스트마스터에게 보냅니다. 빈 Warningsto: 헤더 또는 빈 봉투 From: 주소로 경고가 완전히 억제되지 않은 경우 기본값은 경고 복사본을 포스트마스터에게 보내는 것입니다.

copywarnpost

전달되지 않은 메일에서 보낸 사람 주소가 비어 있지 않는 한 경고 메일 복사본을 포스트마스터에게 보냅니다. 

errwarnpost

메일 발송자에게 알림을 보낼 수 없는 경우 경고 메일 복사본을 포스트마스터에게 보냅니다. 

nowarnpost

경고 메일의 복사본을 포스트마스터에게 보내지 않습니다. 

반환되는 메일 내용

포스트마스터에게 전체 메일을 보낼 것인지 아니면 단순히 헤더만 보낼 것인지 지정

postheadonly

헤더만 포스트마스터에게 반환됩니다. 포스트마스터 복사본을 단지 헤더로 제한하면 사용자 메일의 프라이버시 수준이 향상됩니다. 그러나 포스트마스터와 시스템 관리자는 원할 경우 root 시스템 권한을 사용하여 메일 내용을 읽을 수 있으므로 이러한 제한만으로 메일 보안이 보장되지는 않습니다.

postheadbody

헤더와 메일 내용을 모두 반환합니다. 

반환되는 메일 내용

알림에 대한 주소 지정

includefinal

전달 알림에 최종 수신자 주소 형식을 포함합니다.  

returnenvelope

빈 봉투 반송 주소 사용을 제어합니다. returnenvelope 키워드는 비트 플래그 집합으로 해석되는 단일 정수 값을 가집니다.

비트 0(값 = 1)은 MTA에 의해 생성된 반송 알림이 빈 봉투 주소 또는 로컬 포스트마스터의 주소로 작성되는지 여부를 제어합니다. 이 비트를 설정하면 로컬 마스터 주소가 사용되고 이 비트를 지우면 빈 주소가 사용됩니다. 

비트 1(값 = 2)은 MTA가 모든 빈 봉투 주소를 로컬 포스트마스터의 주소로 대체하는지 여부를 제어합니다. 이 비트는 RFC 821, RFC 822 또는 RFC 1123을 따르지 않는 비호환 시스템을 수용하는 데 사용됩니다.

비트 2(값 = 4)는 구문적으로 잘못된 반송 주소를 사용할 수 없게 합니다. 

비트 3(값 = 8)은 mailfromdnsverify 키워드와 동일합니다.

suppressfinal

원본 주소 형식이 있는 경우 알림 메일에서 최종 주소 형식을 생략합니다. 

useintermediate

목록을 확장한 이후 사용자 메일함 이름이 생성되기 이전에 생성되는 중간 주소 형식을 사용합니다. 이 정보를 사용할 수 없는 경우 최종 형식이 사용됩니다. 

반환되는 메일 내용

알림에 대한 주소 지정

aliaspostmaster

공식 채널 이름에서 포스트마스터 아이디로 주소 지정된 메일은 postmaster@local-host로 리디렉션됩니다. 여기서 local-host는 로컬 호스트 이름(로컬 채널에 있는 이름)입니다. 

returnaddress

로컬 포스트마스터에 대한 반송 주소를 지정합니다. 

noreturnaddress

RETURN_ADDRESS 옵션 값을 포스트마스터 주소 이름으로 사용합니다.

returnpersonal

로컬 포스트마스터에 대한 개인 이름을 설정합니다. 

noreturnpersonal

RETURN_PERSONAL 옵션 값을 포스트마스터 개인 이름으로 사용합니다.

MDN(Message Disposition Notification) 제어

MDN(Message Disposition Notification)은 MTA가 보낸 사람 및/또는 포스트마스터에게 보내는 전자 메일 보고서로서 메일의 전달 처리를 보고합니다. 예를 들어, Sieve 필터에 의해 메일이 거부된 경우 MDN이 보낸 사람에게 보내집니다. MDN은 또한 읽음 확인, 확인, 수신 알림 또는 전달 확인이라고도 합니다. Sieve 스크립트 언어는 일반적으로 메일 필터링 및 휴가 메일에 사용됩니다.

MDN(Message Disposition Notification) 메일 사용자 정의 및 현지화

MDN을 수정 및 현지화하기 위한 지침은 여기에 설명된 약간의 차이점을 제외하고 전달 상태 알림 메일을 사용자 정의 및 현지화하기 위한 지침과 비슷합니다. 전달 상태 알림 메일 사용자 정의 및 현지화 및 생성된 알림 국제화를 참조하십시오.

매핑(DISPOSITION_LANGUAGE 매핑이라고 부름)은 상태 알림을 국제화하는 데 사용되는 notification_language 매핑 테이블( 전달 상태 알림 메일 사용자 정의 및 현지화 )과 비슷합니다.

그러나 이 매핑에 대한 MDN 검사는 다음 형식을 가집니다.

type|modifiers|source-channel|header-language|return|recipient

여기서

type은 배포 유형이며 displayed, dispatched, processed, deleted, denied 또는 failed 중 하나를 사용할 수 있습니다.

modifiers는 쉼표로 구분된 처리 수정자 목록입니다. 현재 목록은 error, warning, superseded 및 expired입니다.

source-channel은 MDN을 생성하는 소스 채널입니다.

header-language는 accept-language, preferred-language 또는 x-accept-language 중 하나에 지정된 언어입니다. MTA는 이러한 옵션 중에서 존재하는 첫 번째 옵션을 사용합니다.

return은 알림이 반환되는 주소입니다.

recipient는 배포 대상 주소입니다.

처리 매핑의 결과는 세로 막대(|)로 구분되는 둘 또는 세 개의 정보로 구성됩니다. 첫 번째 정보는 배포 알림의 템플리트 파일이 있는 디렉토리입니다. 두 번째 정보는 독립형 배포 텍스트에 적용될 문자 세트입니다. 이 정보가 필요한 것은 특히 휴가 Sieve 작업에 대한 :mime 매개 변수 사용이나 자동 회신 에코에 의해 생성된 처리를 비롯한 일부 처리가 템플리트 파일을 사용하지 않으며 결과적으로 이러한 파일로부터 문자 세트를 상속할 수 없기 때문입니다. 마지막으로 세 번째 정보는 알림에 대한 대체 제목 행입니다. 이 정보는 $T 플래그 역시 매핑에 의해 설정된 경우에만 사용됩니다.

다음의 추가 템플리트 파일이 MDN을 구성하는 데 사용됩니다.

disposition_deleted.txt disposition_failed.txtdisposition_denied.txt disposition_prefix.txtdisposition_dispatched.txt disposition_processed.txtdisposition_displayed.txt disposition_suffix.txtdisposition_option.opt

이러한 템플리트 파일은 상태 알림 메일에 대한 다양한 return_*.txt 파일과 비슷한 방식으로 사용됩니다. *.txt 파일의 메일 텍스트는 한 행당 78자로 제한되어야 합니다.