MTA가 다시 쓰기 규칙을 주소에 적용하는 방법

다음 단계는 MTA가 다시 쓰기 규칙을 특정 주소에 적용하는 방법을 설명합니다.

1. MTA는 주소에서 첫 번째 호스트 또는 도메인 지정을 추출합니다.

   주소는 다음과 같이 둘 이상의 호스트 또는 도메인 이름을 지정할 수 있습니다.

   jdoe%hostname@siroe.com.

2. 첫 번째 호스트 또는 도메인 이름을 식별한 후에 MTA는 다시 쓰기 규칙 패턴이 호스트 또는 도메인 이름과 일치하는 다시 쓰기 규칙을 스캔하는 검색을 수행합니다.

3. 일치하는 다시 쓰기 규칙이 발견되면 MTA는 해당 규칙의 템플리트 부분에 따라 주소를 다시 씁니다.

4. 마지막으로 MTA는 채널 태그를 각 채널과 연관된 호스트 이름과 비교합니다.

   일치하는 항목이 발견된 경우 MTA는 연관된 채널의 대기열에 메일을 넣고, 그렇지 않을 경우 다시 쓰기 프로세스가 실패합니다. 일치하는 채널이 로컬 채널일 경우 별칭 데이터베이스와 별칭 파일을 조회하여 주소의 일부 추가 다시 쓰기가 발생할 수 있습니다.

이러한 단계는 다음 하위 절에 더욱 자세하게 설명되어 있습니다.

기존 채널에 속하지 않은 채널 태그를 사용하면 주소가 이 규칙과 일치하는 메일이 바운스됩니다. 즉, 일치하는 메일을 라우팅할 수 없게 됩니다.

단계 1. 첫 번째 호스트 또는 도메인 지정 추출

주소 다시 쓰기 프로세스는 첫 번째 호스트나 도메인 지정을 주소에서 추출하는 것으로 시작됩니다(RRFC 822 주소 규칙에 익숙하지 않은 경우에는 다음 내용을 이해할 수 있도록 이 표준을 읽어보는 것이 좋습니다). 주소의 호스트/도메인 지정이 스캔되는 순서는 다음과 같습니다.

1. 소스 경로의 호스트(왼쪽에서 오른쪽으로 읽음)

2. “at” 기호(@) 오른쪽에 있는 호스트

3. 마지막 단일 백분율 기호(%) 오른쪽에 있는 호스트

4. 첫 번째 느낌표(!)

주소 다시 쓰기를 수행하는 채널에서 bangoverpercent 키워드가 적용될 경우(즉, 메일을 대기열에 넣으려고 시도하는 채널 자체가 bangoverpercent 채널 키워드로 표시된 경우) 마지막 두 개 항목의 순서가 바뀝니다.

표 11–3에는 몇 개의 주소와 첫 번째로 추출할 수 있는 호스트 이름의 예가 나와 있습니다.

RFC 822는 주소에 있는 느낌표(!)와 백분율 기호(%)의 해석을 다루지 않습니다. at 기호(@)가 존재하지 않을 경우 백분율 기호는 관례상 at 기호와 동일한 방식으로 해석되며 따라서 Messaging Server MTA에 이 규칙이 적용됩니다.

반복되는 백분율 기호의 특수한 해석은 백분율 기호를 로컬 아이디의 일부로 허용하는 데 사용됩니다. 이것은 일부 외국 메일 시스템 주소를 처리하는 데 유용할 수 있습니다. 느낌표에 대한 해석은 RFC 976의 “뱅 스타일” 주소 규칙을 따르며 Messaging Server MTA에서 UUCP 주소를 사용할 수 있게 합니다.

이러한 해석의 순서는 RFC 822 또는 RFC 976에 지정되어 있지 않으므로 bangoverpercent 및 nobangoverpercent 키워드를 사용하여 다시 쓰기를 수행하는 채널에 의해 적용되는 순서를 제어할 수 있습니다. 대부분 기본값이 "표준"이지만 경우에 따라서는 대체 설정이 유용할 수 있습니다.

주소에서는 느낌표(!) 또는 백분율 기호(%)를 사용하지 않는 것이 좋습니다.

단계 2. 다시 쓰기 규칙 스캔

첫 번째 호스트 또는 도메인 지정이 주소에서 추출된 후 MTA는 다시 쓰기 규칙을 참조하여 그 처리 방법을 결정합니다. 호스트/도메인 지정은 각 규칙의 패턴 부분(즉, 각 규칙의 왼쪽)과 비교됩니다. 이 비교는 RFC 822에 명시된 대로대소문자를 구분하지 않습니다. MTA에서는 대소문자를 구분하지 않지만 가능하면 대소문자를 유지합니다.

호스트 또는 도메인 지정이 어떠한 패턴과도 일치하지 않으면(이러한 경우를 "어떠한 규칙과도 일치하지 않음"이라고 함) 호스트 또는 도메인 지정의 첫 번째 부분, 즉 첫 번째 마침표의 앞 부분(대개 호스트 이름)이 제거되고 별표(*)로 대체된 다음, 구성 파일 다시 쓰기 규칙에서만 결과 호스트 또는 도메인 지정을 찾으려는 또 다른 시도가 수행됩니다(도메인 데이터베이스는 참조되지 않음).

이 시도가 실패하면 첫 번째 부분이 제거되고 프로세스가 반복됩니다. 또 다시 실패할 경우에는 다음 부분(일반적으로 하위 도메인)이 제거되고 다시 쓰기 프로세스가 처음에는 별표를 사용하고 그 다음에는 별표 없이 다시 시도됩니다. 별표를 포함하는 모든 검사는 구성 파일 다시 쓰기 규칙 테이블에서만 수행되며 도메인 데이터베이스는 검사되지 않습니다. 이 프로세스는 일치하는 항목이 발견되거나 전체 호스트 또는 도메인 지정이 사용될 때까지 계속됩니다. 이 절차는 가장 구체적인 도메인을 우선 일치시키고 점차 덜 구체적이면서 더 일반적인 도메인을 일치시키는 방향으로 진행됩니다.

일치 절차의 알고리즘에 대한 자세한 내용은 다음과 같습니다.

• 호스트/도메인 지정이 비교 문자열 spec_1 및 spec_2의 초기 값으로 사용됩니다(예: spec_1 = spec_2 = a.b.c).

• 일치하는 항목이 발견될 때까지 비교 문자열 spec_1이 구성 파일에 이어 도메인 데이터베이스에 있는 각 다시 쓰기 규칙의 패턴 부분과 비교됩니다. 일치하는 항목이 발견되면 일치 절차가 종료합니다.

• 일치하는 항목이 발견되지 않을 경우 spec_2의 별표가 아닌 맨 왼쪽 부분이 별표로 변환됩니다. 예를 들어, spec_2가 a.b.c인 경우 *.b.c로 변경되고 spec_2가 *.b.c인 경우 *.*.c로 변경됩니다. 일치하는 항목이 발견되면 일치 절차가 종료합니다.

• 일치하는 항목이 발견되지 않을 경우 선행 마침표를 포함한 비교 문자열 spec_1의 첫 번째 부분이 제거됩니다. spec_1 이 한 부분으로만 구성된 경우(예: .c 또는 c) 문자열은 마침표 "."으로 바뀝니다. 결과 문자열 spec_1의 길이가 0이 아닌 경우 단계 1로 돌아갑니다. 결과 문자열의 길이가 0인 경우(예: 이전에 "."인 경우) 조회 프로세스가 실패하고 일치 절차가 종료됩니다.

예를 들어, dan@sc.cs.siroe.edu 주소를 다시 작성한다고 가정해 봅니다. 이 경우 MTA는 다음 패턴을 주어진 순서대로 찾습니다.

sc.cs.siroe.edu
*.cs.siroe.edu
.cs.siroe.edu
*.*.siroe.edu
.siroe.edu
*.*.*.edu
.edu
*.*.*.*
.
 

단계 3. 템플리트에 따라 주소 다시 쓰기

호스트/도메인 지정은 다시 쓰기 규칙과 일치할 경우 규칙의 템플리트 부분에 따라 다시 작성됩니다. 템플리트는 다음 세 가지 정보를 지정합니다.

1. 주소의 새 아이디

2. 주소의 새 호스트/도메인 지정

3. 이 주소에 대한 메일을 보내야 하는 기존 MTA 채널을 식별하는 채널 태그

단계 4. 다시 쓰기 프로세스 완료

호스트/도메인 지정이 다시 작성된 후 다음 작업 중 하나가 수행될 수 있습니다.

• 채널 태그가 로컬 채널 및 routelocal 채널 키워드로 표시된 채널과 관련이 없거나 주소에 추가 호스트/도메인 지정이 없을 경우 다시 작성된 지정은 다시 쓰기를 위해 추출된 원래 지정을 대체하는 주소로 대체되고 다시 쓰기 프로세스가 종료합니다.

• 채널 태그가 로컬 채널이나 routelocal로 표시된 채널과 일치하거나 주소에 추가 호스트/도메인 지정이 있을 경우 다시 작성된 주소를 버리고 원래(초기) 호스트/도메인 지정이 주소에서 제거되며 새 호스트/도메인 지정이 주소에서 추출된 후 전체 프로세스가 반복됩니다. 다시 쓰기는 모든 호스트/도메인 지정이 사라지거나 로컬이 아닌 채널 또는 routelocal이 아닌 채널을 통한 경로가 발견될 때까지 계속됩니다. 이 반복 기법은 MTA가 소스 라우팅에 대한 지원을 제공하는 방법입니다. 실제로 로컬 시스템 및 routelocal 시스템을 통과하는 여분의 경로는 이 프로세스에 의해 주소에서 제거됩니다.

다시 쓰기 규칙 실패

호스트 도메인 지정이 다시 쓰기 규칙과 일치하는 데 실패하거나 기본 규칙이 존재하지 않을 경우 MTA는 지정을 "있는 그대로" 사용합니다. 예를 들어, 원래 지정은 새 지정과 라우팅 시스템 모두가 됩니다. 주소에 유효하지 않은 호스트/도메인 지정이 있을 경우 라우팅 시스템이 임의 채널과 연관된 어떠한 시스템 이름과도 일치하지 않을 때 이점이 감지되며 메일이 바운스됩니다.

다시 쓰기 후의 구문 검사

다시 쓰기 규칙이 주소에 적용된 후 추가 구문 검사가 수행되지 않습니다. RFC 822를 따르지 않는 형식으로 주소를 변환하는 데 다시 쓰기 규칙이 사용될 수 있다는 점에서 일부러 이러한 검사가 수행되지 않는 것입니다. 그러나 이것은 또한 구성 파일의 실수로 인해 MTA에서 잘못된 또는 유효하지 않은 주소를 가진 메일이 보내질 수 있다는 것을 의미합니다.

도메인 리터럴 처리

도메인 리터럴은 다시 쓰기 프로세스 동안 특수하게 처리됩니다. 주소의 도메인 부분에 있는 도메인 리터럴이 다시 쓰기 규칙 패턴과 일치하지 않을 경우 이러한 리터럴은 마침표로 구분하고 대괄호로 묶은 문자열 그룹으로 해석됩니다. 맨 오른쪽의 문자열이 제거되며 검색이 반복됩니다. 이 작업이 수행되지 않을 경우 빈 대괄호만 남을 때까지 다음 문자열이 제거됩니다. 빈 대괄호에 대한 검색이 실패하면 전체 도메인 리터럴이 제거되고 도메인 주소의 다음 섹션(있을 경우)에서 다시 쓰기가 진행됩니다. 도메인 리터럴의 내부 처리에서 별표는 사용되지 않습니다. 전체 도메인 리터럴이 별표로 대체될 경우 별표 수는 도메인 리터럴의 요소 수에 해당합니다.

일반 도메인 또는 호스트 지정과 마찬가지로 도메인 리터럴은 또한 가장 구체적인 순서에서 가장 일반적인 순서로 시도됩니다. 해당 패턴이 일치하는 첫 번째 규칙은 호스트 또는 도메인 지정을 다시 쓰는 데 사용되는 규칙입니다. 규칙 목록에 두 개의 동일한 패턴이 있을 경우 먼저 표시된 규칙이 사용됩니다.

예를 들어, dan@[128.6.3.40] 주소를 다시 작성한다고 가정해 봅니다. 다시 쓰기 프로세스는 [128.6.3.40], [128.6.3.], [128.6.], [128.], [], [*.*.*.*]를 차례로 찾은 다음 마지막으로 모두 일치 규칙 “.”를 찾습니다.