도메인의 로컬 여부 확인

user@domain 형식의 주소에서 시작되는 주소 변환 및 라우팅 프로세스는 우선 domain이 로컬인지 여부를 검사합니다.

다시 쓰기 규칙 방법

주어진 문자열을 검사하여 로컬로 처리해야 하는 도메인인지 여부를 확인하는 기능이 MTA 다시 쓰기 규칙 방법에 추가되었습니다. 이 새 기능은 $V 또는 $Z 메타 문자에 의해 활성화됩니다. 이러한 새 메타 문자는 기존 $N, $M, $Q 및 $C 메타 문자와 구문적으로 유사합니다. 즉, 뒤에 패턴 문자열이 옵니다. $N, $M, $Q 및 $C의 경우 소스 또는 대상 채널에 대해 패턴이 일치됩니다. $V 및 $Z의 경우 패턴은 도메인이며 로컬인지 여부를 확인하는 검사가 수행됩니다. $V의 경우 로컬이 아닌 도메인에 대해 규칙이 실패하며 $Z의 경우 로컬 도메인에 대해 규칙이 실패합니다.

이러한 메타 문자의 처리는 다음 절차에 따라 구현됩니다.

1. Messaging Server는 현재 도메인이 디렉토리의 유효한 도메인 항목과 일치하는지 여부를 확인합니다. 항목이 없으면 단계 3으로 가십시오.

2. 도메인에 디렉토리의 항목이 있을 때는 LDAP_DOMAIN_ATTR_ROUTING_HOSTS MTA 옵션에서 지정한 속성(기본 mailRoutingHosts)이 해당 도메인 항목에서 검색됩니다. 이 속성이 존재할 경우 이 도메인의 사용자를 처리할 수 있는 호스트 집합이 나열됩니다. 이 목록은 local.hostname configutil 매개 변수에 지정된 호스트 및 local.imta.hostnamealiases configutil 매개 변수에 지정된 호스트 목록과 비교됩니다. 이러한 옵션은 각각 LDAP_LOCAL_HOST 및 LDAP_HOST_ALIAS_LIST MTA 옵션으로 무시할 수 있습니다. 일치하는 항목이 있거나 도메인에 속성이 존재하지 않을 경우 도메인은 로컬입니다. 일치하는 항목이 없으면 도메인은 로컬이 아닙니다.

   mailRoutingHosts 속성으로 인해 로컬이 아닌 것으로 간주되는 도메인의 처리는 ROUTE_TO_ROUTING_HOST MTA 옵션의 설정에 따라 달라집니다. 이 옵션이 0(기본값)으로 설정된 경우 주소는 단순히 로컬이 아닌 것으로 간주되며 MTA 다시 쓰기 규칙을 사용하여 라우팅을 결정합니다. 이 옵션이 1로 설정된 경우 LDAP_DOMAIN_ATTR_ROUTING_HOSTS MTA 옵션에 나열된 첫 번째 값으로 구성된 소스 경로가 주소의 앞에 놓입니다.

3. 도메인 항목을 찾을 수 없는 경우 도메인의 왼쪽에서 구성 요소를 제거하고 단계 1로 이동합니다. 구성 요소가 남아 있지 않으면 단계 4를 진행합니다.

   도메인 트리를 거슬러 올라가는 이 방법은 결과적으로 domain.com이 로컬로 인식될 경우 domain.com의 모든 하위 도메인이 로컬로 인식되게 합니다. 이 동작이 바람직하지 않은 상황이 발생할 수 있으므로 동작을 제어하기 위한 MTA 옵션 DOMAIN_UPLEVEL이 제공됩니다. 특히 DOMAIN_UPLEVEL의 비트 0(값 = 1)이 지워진 경우 제거된 도메인 구성 요소로 재시도할 수 없게 됩니다. DOMAIN_UPLEVEL의 기본값은 0입니다.

4. 이제 부속 도메인 검사를 수행해야 합니다. 부속 도메인에는 도메인 항목이 없고, 오히려 하나 이상의 사용자 항목에 특별한 도메인 속성을 추가함으로써 지정됩니다. 후속 도메인 검사는 DOMAIN_MATCH_URL MTA 옵션에 지정된 LDAP URL을 사용하여 LDAP 검색을 시작하는 방법으로 수행됩니다. 이 옵션의 값은 다음과 같이 설정해야 합니다.

   ldap:///$B?msgVanityDomain?sub?(msgVanityDomain=$D)

   $B는 local.ugldapbasedn configutil 매개 변수의 값을 대체합니다(이는 디렉토리에서 사용자 트리의 기반임). LDAP_USER_ROOT MTA 옵션을 사용하여 특히 MTA에 대해 이 configutil 옵션의 값을 무시할 수 있습니다.

   이 검색의 실제 반환 값은 중요하지 않습니다. 중요한 것은 반환할 값이 존재하는지 여부입니다. 반환 값이 존재할 경우 도메인은 로컬로 간주되며 그렇지 않을 경우 도메인은 로컬이 아닌 것으로 간주됩니다.

도메인 로컬 여부의 도메인 맵 확인

디렉토리에서 유효한 도메인 항목을 찾기 위해 수행되는 단계가 무엇인지 잘 기억하는 것이 좋습니다. 이러한 단계는 스키마 수준별로 다릅니다. Sun LDAP Schema, v.1의 경우 이러한 단계는 다음과 같습니다.

1. 도메인을 도메인 트리의 기본 DN으로 변환합니다. 이 작업은 도메인을 일련의 dc 구성 요소로 변환한 다음 도메인 루트 접미어를 추가하는 방법으로 수행합니다. 기본 접미어는 service.dcroot configutil 매개 변수에서 얻습니다. 기본 접미어는 o=internet입니다. 따라서 a.b.c.d 형식의 도메인은 일반적으로 dc=a,dc=b,dc=c,dc=d,o=internet으로 변환됩니다. service.dcroot configutil 매개 변수는 LDAP_DOMAIN_ROOT MTA 옵션을 설정하여 무시할 수 있습니다.

2. 단계 1에서 발견된 기본 DN과 inetDomain 또는 inetDomainAlias 객체 클래스를 가진 항목을 찾습니다. 이 목적에 사용되는 검색 필터는 LDAP_DOMAIN_FILTER_SCHEMA1 MTA 옵션을 설정하여 무시할 수 있습니다. 이 옵션의 기본값은 (|(objectclass=inetDomain)(objectclass=inetdomainalias))입니다.

3. 아무 것도 발견되지 않을 경우 실패와 함께 종료합니다.

4. 항목의 객체 클래스를 inetDomain에서 찾은 경우, 해당 도메인 항목에 관련된 inetDomainBaseDn 속성이 있는지 확인하십시오. 이 속성이 있으면 사용자 항목에 대한 후속 검색에 사용되도록 저장한 다음 처리가 종료됩니다. 이 속성이 없으면 해당 항목은 도메인 별칭으로 가정되고 단계 5로 처리가 계속됩니다. inetDomainBaseDN 대신 MTA 옵션 LDAP_DOMAIN_ATTR_BASEDN을 사용할 수 있습니다.

5. 항목은 도메인 별칭이어야 합니다. aliasedObjectName 속성에서 참조한 새 항목을 찾아 단계 4로 돌아가십시오. aliasedObjectName 속성이 없으면 오류와 함께 처리가 종료됩니다. MTA 옵션 LDAP_DOMAIN_ATTR_ALIAS를 사용하여 aliasedObjectName 속성 사용을 대체할 수 있습니다.

   처리가 단계 4로 돌아가는 일은 한 번 정도만 발생할 수 있다는 점을 주의하십시오. 도메인 별칭에서 도메인 별칭을 가리키는 일은 허용되지 않습니다.

Sun LDAP Schema 2에서는 수행되는 작업이 훨씬 더 간단합니다. 디렉토리에서 도메인이 sunPreferredDomain 또는 associatedDomain 속성 값으로 표시되는 sunManagedOrganization 객체 클래스가 있는 항목을 검색합니다. 필요한 경우 sunPreferredDomain 및 associatedDomain 속성의 사용을 각각 MTA 옵션 LDAP_ATTR_DOMAIN1_SCHEMA2 및 LDAP_ATTR_DOMAIN2_SCHEMA2를 사용하여 무시할 수 있습니다. 검색은 service.dcroot configutil 매개 변수로 지정된 루트 하에서 수행됩니다. service.dcroot configutil 매개 변수는 LDAP_DOMAIN_ROOT MTA 옵션을 설정하여 무시할 수 있습니다. 아울러 스키마 2의 도메인 항목은 inetDomainBaseDn 속성을 가지지 않아도 됩니다. 해당 속성을 가지지 않은 경우 사용자 트리의 기본이 도메인 항목 자체인 것으로 간주됩니다.

도메인 로컬 여부 정보의 캐싱

도메인 다시 쓰기 작업이 수행되는 빈도와 디렉토리 쿼리(특히 부속 도메인 검사)의 비용으로 인해 도메인에 대한 부정적 및 긍정적 표시를 모두 캐시해야 합니다. 이 작업은 동적으로 확장되는 메모리 내장의 개방형 체인 해시 테이블을 통해 구현됩니다. 캐시의 최대 크기는 DOMAIN_MATCH_CACHE_SIZE MTA 옵션(기본값 100000)으로 설정하며 캐시의 항목에 대한 시간 초과는 DOMAIN_MATCH_CACHE_TIMEOUT MTA 옵션(기본값 600초)으로 설정합니다.

오류 처리

이 프로세스 도중에 발생하는 임시 서버 오류를 신중하게 처리해야 하는데 이는 이 오류가 발생할 경우 주어진 도메인이 로컬인지 여부를 알 수 없기 때문입니다. 기본적으로 이러한 경우에는 두 가지 결과가 가능합니다.

1. 주소를 나중에 다시 시도하라는 임시(4xx) 오류를 클라이언트에게 반환합니다.

2. 주소를 수락하지만 재처리 채널에서 주소를 대기시켜 나중에 로컬로 다시 시도할 수 있게 합니다.

이러한 두 옵션이 모든 경우에 적합한 것은 아닙니다. 예를 들어, 결과 1은 원격 SMTP 중계와 통신할 때 적합합니다. 그러나 결과 2는 로컬 사용자로부터의 SMTP 제출을 처리할 때 적합합니다.

동일한 패턴을 가진 여러 규칙을 사용하여 일시적인 오류를 처리하는 것이 이론적으로 가능하지만 이러한 쿼리를 반복할 경우 발생하는 오버헤드는 캐시로도 처리할 수 없는 큰 부담이 됩니다. 이러한 이유로 도메인 다시 쓰기의 다음 규칙까지의 성공/실패 일치 모델은 적합하지 않습니다. 대신 MTA 옵션 DOMAIN_FAILURE에 지정된 특수한 템플리트가 도메인 조회 실패의 경우에 사용됩니다. $V 작업이 실패하면 이 템플리트는 처리 중인 현재 다시 쓰기 규칙 템플리트의 나머지 부분을 대체합니다.

도메인 검사 다시 쓰기 규칙을 위한 패턴

다른 다시 쓰기 규칙이 수행되기 전에 이 도메인 검사를 수행해야 합니다. 이 순서는 규칙의 왼쪽에서 특수한 $*를 사용하여 지정합니다. $* 패턴은 다른 모든 규칙에 앞서 검사됩니다.

모든 방법 사용

지금까지 설명된 모든 방법을 고려할 때 imta.cnf에서 필요한 새 다시 쓰기 규칙은 다음과 같습니다.

$*     $E$F$U%$H$V$H@localhost

또한 option.dat 파일에서 DOMAIN_FAILURE MTA 옵션 값은 다음과 같아야 합니다.

reprocess-daemon$Mtcp_local$1M$1~-error$4000000?Temporary lookup failure

이 다시 쓰기 규칙에서 localhost는 로컬 채널과 연관된 호스트 이름입니다. 여기에 표시된 DOMAIN_FAILURE 옵션 값이 기본값이므로 정상적인 환경에서 option.dat에 표시될 필요가 없습니다.

여기에서 순서는 특히 까다롭습니다. MTA는 주소가 재작성되었지만 경로가 아직 추가되기 전에 $V를 검사합니다. 따라서 일시적인 조회 실패가 발생할 경우에 MTA에서 경로를 변경할 수 있습니다. 보류 중인 채널 일치 검사는 삽입 지점이 변경될 때마다 적용되므로 $H초 후에 @이 검사를 호출합니다. 이 검사에 성공할 경우 템플리트의 나머지 부분이 적용되며 다시 쓰기 처리가 완료됩니다. 검사에 실패할 경우 다시 쓰기는 실패하며 적용 가능한 다음 다시 쓰기 규칙을 사용하여 다시 쓰기가 계속됩니다. 일시적인 오류로 인해 검사를 수행할 수 없는 경우 DOMAIN_FAILURE MTA 옵션에 지정된 값에서 템플리트 처리가 계속됩니다. 이 템플리트 값은 우선 라우팅 호스트를 reprocess-daemon으로 설정합니다. 그런 다음 템플리트는 MTA가 동일한 종류 또는 tcp_local의 재처리 채널을 처리하고 있는지 여부를 확인합니다. MTA가 이러한 채널을 처리하는 중이면 규칙이 계속 진행되어 라우팅 호스트를 잘못된 것으로 만들고 일시적인 오류를 결과로 지정합니다. MTA가 이러한 채널을 처리하는 중이 아니면 규칙이 잘리고 성공적으로 종료하므로 재처리 채널에 주소가 다시 쓰여집니다.