20장 로깅 및 로그 분석

Messaging Server는 관리, 서버가 지원하는 프로토콜(SMTP, POP, IMAP 및 HTTP)을 사용한 통신 및 서버가 수행하는 기타 프로세스에 관련된 이벤트가 기록되는 로그 파일을 생성할 수 있습니다. 이러한 로그 파일을 분석하면 서버 동작의 여러 측면을 모니터할 수 있습니다.

MTA는 다른 서비스와 별개의 로깅 기능을 사용하기 때문에 콘솔을 사용하여 로깅 서비스를 구성하거나 로그를 볼 수 없습니다. 대신 구성 파일에 정보를 지정하여 MTA 로깅을 구성할 수 있습니다. 이 장은 세 부분으로 구성됩니다. 1부에서는 일반적인 소개 정보에 대해 설명하고, 2부에서는 메일 저장소 및 관리 서버에 대한 로깅에 대해 설명하며, 3부에서는 MTA 서비스에 대한 로깅에 대해 설명합니다.

제1부: 소개

Messaging Server 로그 파일을 만들고 관리하기 위한 정책을 사용자 정의할 수 있습니다. 이 장에서는 로그 파일의 유형과 구조에 대해 설명하고 로그 파일을 관리하고 보는 방법에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

기록되는 서비스

Messaging Server는 지원하는 각 주요 프로토콜이나 서비스에 대해 별도의 로그 파일 집합을 생성합니다. 이러한 로그 파일은 msg_svr_base/data/log에 위치합니다. 각 유형의 로그 파일을 개별적으로 사용자 정의하고 볼 수 있습니다. 표 20-1에는 기록할 수 있는 서비스가 나열되어 있고 각 서비스에 대한 로그 파일에 대한 설명이 있습니다.

표 20-1 기록되는 서비스
서비스	로그 파일 설명
Admin	Administration Server에 의해 콘솔과 Messaging Server 사이에 수행되는(대부분 CGI 프로세스를 통해 수행됨) 통신에 관련된 기록 이벤트가 포함됩니다.
SMTP	이 서버의 SMTP 활동에 관련된 기록 이벤트가 포함됩니다.
IMAP	이 서버의 IMAP4 활동에 관련된 기록 이벤트가 포함됩니다.
POP	이 서버의 POP3 활동에 관련된 기록 이벤트가 포함됩니다.
HTTP	이 서버의 HTTP 활동에 관련된 기록 이벤트가 포함됩니다.
Default	명령줄 유틸리티 및 기타 프로세스 등과 같은 이 서버의 다른 활동에 관련된 기록 이벤트가 포함됩니다.

타사 도구를 사용하여 로그 분석

Messaging Server에서 제공하지 않는 로그 분석 및 보고서 생성 기능을 사용하려면 다른 도구를 사용해야 합니다. 로그 파일은 텍스트 편집기나 표준 시스템 도구로 조작할 수 있습니다.

정규 표현식 구문 분석을 지원하는 스크립트 가능 텍스트 편집기를 사용하면 이 장에서 설명하는 모든 조건을 기준으로 로그 항목을 추출하고 검색할 수 있으며, 결과를 정렬하거나 합계나 기타 통계를 낼 수도 있습니다.

UNIX 환경에서는 UNIX syslog 파일을 조작하기 위해 개발된 기존 보고서 생성 도구를 수정하고 사용할 수도 있습니다. 공개 도메인 syslog 조작 도구를 사용하려면 다른 날짜/시간 형식과 Messaging Server 로그 항목에는 있지만 syslog 항목에는 없는 두 개의 추가 구성 요소(facility 및 logLevel)를 고려하여 수정해야 합니다.

제2부: 서비스 로그(Message Store, Administration Server 및 MTA)

이 절에서는 POP, IMAP, HTTP, MTA, Admin, Default 등의 서비스에 대한 로깅을 설명합니다(표 20-1 참조).

이 서비스에 대해서는 콘솔을 사용하여 로그 설정을 지정하고 로그를 볼 수 있습니다. 지정하는 설정은 기록되는 이벤트 및 기록되는 이벤트의 수에 영향을 미칩니다. 로그 파일을 분석할 때 이러한 설정 및 기타 특성을 사용하여 기록되는 이벤트를 자세히 검색할 수 있습니다. MTA에 대한 서비스 로그에 대한 자세한 정보는 제3부: 서비스 로그(MTA)를 참조하십시오.

로그 특성

이 절에서는 메일 저장소 및 관리 서비스에 대한 로깅 수준, 기록되는 이벤트 범주, 로그의 파일 이름 규칙, 로그 파일 디렉토리 등과 같은 로그 특징을 설명합니다.

로깅 수준

로깅의 수준 또는 우선 순위는 로깅 작업 수행의 세밀함 정도를 정의합니다. 우선 순위 수준이 높을수록 세밀도가 떨어집니다. 즉, 우선 순위가 높은(높은 심각도) 이벤트가 기록됩니다. 수준이 낮으면 세밀도가 높아집니다. 즉, 더 많은 이벤트가 로그 파일에 기록됩니다.

logfile.service.loglevel 구성 매개 변수(로깅 옵션 정의 및 설정 참조)를 사용하여 각 서버(POP, IMAP, HTTP, Admin 및 Default)마다 별도의 로깅 수준을 설정할 수 있습니다. 또한 로깅 수준을 사용하여 로그 이벤트에 대한 검색을 필터링할 수도 있습니다. 사용 가능한 수준은 표 20-2에서 설명합니다. 이러한 로깅 수준은 UNIX syslog 기능에 의해 정의된 수준의 하위 집합입니다.

표 20-2 저장소 및 관리 서비스의 로깅 수준
수준	설명
Critical	최소의 로깅 세밀도입니다. 서버 문제 또는 중요한 조건이 발생(예: 서버가 메일함에 액세스할 수 없거나 서버를 실행하려면 라이브러리가 필요한 경우)할 때마다 이벤트가 로그에 기록됩니다.
Error	오류 조건(예: 클라이언트나 다른 서버에 대한 연결 시도가 실패한 경우)이 발생할 때마다 이벤트가 로그에 기록됩니다.
Warning	경고 조건이 발생할 때마다(예: 클라이언트가 보낸 통신을 서버가 인식할 수 없는 경우) 이벤트가 로그에 기록됩니다.
Notice	알림(일반적이지만 중요한 조건)이 발생할 때마다(예: 사용자 로그인 실패 또는 세션 종료시) 이벤트가 로그에 기록됩니다.
Information	수행되는 모든 중요 작업(예: 사용자가 성공적으로 로그온했거나 메일함을 만들거나 메일함 이름을 변경한 경우)에 대한 이벤트를 로그에 기록합니다.
Debug	가장 세밀한 로깅입니다. 디버깅 용도에만 적합합니다. 문제를 나타내기 위해 각 프로세스나 작업 내의 개별 단계에서 이벤트가 로그에 기록됩니다.

특정 로깅 수준을 선택하면 해당 수준과 그보다 높은(세밀도는 더 낮은) 모든 수준에 해당하는 이벤트가 기록됩니다. 기본 로깅 수준은 Notice입니다.

기록되는 이벤트의 범주


주	로깅을 세밀하게 지정할수록 로그 파일이 차지하는 디스크 공간은 많아집니다. 이에 대한 지침은 로깅 옵션 정의 및 설정을 참조하십시오.

지원되는 각 서비스 또는 프로토콜 내에서 Messaging Server는 기능 또는 기능 영역에 따라 기록되는 이벤트를 범주화합니다. 기록되는 모든 이벤트에는 해당 이벤트를 생성한 기능의 이름이 포함됩니다. 이러한 범주는 검색 중에 이벤트를 필터링하는 데 도움이 됩니다. 표 20-3에는 로깅을 위해 Messaging Server가 인식하는 범주가 나열되어 있습니다.

표 20-3 로그 이벤트가 발생하는 범주
기능	설명
General	이 프로토콜 또는 서비스에 관련된 구분되지 않은 작업입니다.
LDAP	LDAP 디렉토리 데이터베이스에 액세스하는 Messaging Server에 관련된 작업입니다.
Network	네트워크 연결에 관련된 작업(소켓 오류가 이 범주에 속함)입니다.
Account	사용자 계정에 관련된 작업(사용자 로그인이 이 범주에 속함)입니다.
Protocol	프로토콜별 명령에 관련된 프로토콜 수준 작업(POP, IMAP 또는 HTTP 기능에서 반환되는 오류가 이 범주에 속함)입니다.
Stats	서버 통계의 수집에 관련된 작업입니다.
Store	메일 저장소 액세스에 관련된 낮은 수준의 작업(읽기/쓰기 오류가 이 범주에 속함)입니다.

로그 검색에서 범주를 필터로 사용하는 예에 대해서는 로그 검색 및 보기를 참조하십시오.

메일 저장소 및 관리 로그의 파일 이름 규칙

POP, IMAP, HTTP, Admin 및 Default 서비스에 대한 로그 파일은 동일한 이름 지정 규칙을 사용합니다. 각 로그 파일에는 다음 형식의 파일 이름이 사용됩니다.

표 20-4에는 메일 저장소 로그 파일 이름 규칙이 나열되어 있습니다.

표 20-4 저장소 및 관리 로그에 대한 파일 이름 변환
구성 요소	정의
service	POP, IMAP, HTTP, Admin, Default 등 기록되는 서비스입니다.
sequenceNum	로그 파일 디렉토리에 있는 다른 로그 파일과 비교하여 이 로그 파일의 생성 순서를 지정하는 정수입니다. 일련 번호가 높은 로그 파일은 이 번호가 낮은 로그 파일보다 최신 파일입니다. 일련 번호는 롤오버되지 않습니다. 즉 서버 설치부터 시작하여 서버 수명 동안 계속 증가합니다.
timeStamp	파일 생성 날짜 및 시간을 지정하는 큰 정수입니다. 이 값은 1970년 1월 1일 자정부터 시작하여 계산한 초의 수인 표준 UNIX 시간으로 표시됩니다.

예를 들어 imap.63.915107696이라는 이름의 로그 파일은 1998년 12월 31일 12:34:56 PM에 생성되었으며 IMAP 로그 파일의 디렉토리에 만들어진 63번째 로그 파일입니다.

타임스탬프를 사용하여 개방형 일련 번호 지정의 조합을 통해, 분석을 위한 파일의 회전, 만료 및 선택에 더 큰 유연성을 가질 수 있습니다. 자세한 내용은 로깅 옵션 정의 및 설정을 참조하십시오.

로그 파일 디렉토리

기록되는 모든 서비스에는 로그 파일이 저장되는 하나의 디렉토리가 할당됩니다. 모든 POP 로그 파일과 기타 모든 서비스의 로그 파일과 마찬가지로 모든 IMAP 로그 파일이 함께 저장됩니다. 각 디렉토리의 위치를 정의할 수 있으며 디렉토리에 허용되는 로그 파일의 최대 크기와 수를 지정할 수 있습니다.

로그 파일을 모두 저장할 수 있을 만큼 저장소 용량이 충분한지 확인하십시오. 로그 데이터는 용량이 매우 커질 수 있습니다(특히 낮은 로깅 수준에서).

또한 모든 로그 파일 디렉토리가 백업되고 오버로드되지 않도록 로깅 수준, 로그 회전, 로그 만료 및 서버 백업 정책을 적절하게 정의해야 합니다. 그렇지 않으면 정보가 손실될 수 있습니다. 로깅 옵션 정의 및 설정을 참조하십시오.

로그 파일 형식

Messaging Server에 의해 생성된 모든 메일 저장소와 관리 서비스 로그 파일의 내용 형식은 서로 동일합니다. 로그 파일은 여러 행의 텍스트 파일로, 각 행이 기록된 하나의 이벤트를 설명합니다. 지원되는 각 서비스에 대한 모든 이벤트 설명에는 다음과 같은 일반 형식이 있습니다.

dateTime hostName processName[pid]: category logLevel: eventMessage

표 20-5에는 로그 파일 구성 요소가 나열되어 있습니다. 이러한 이벤트 설명의 형식은, 날짜/시간 형식이 다르고 형식에 두 개의 추가 구성 요소(category와 logLevel)가 추가된다는 점을 제외하면 UNIX syslog 기능에 의해 정의된 것과 동일합니다.

표 20-5 저장소 및 관리 로그 파일 구성 요소
구성 요소	정의
dateTime	이벤트가 기록된 날짜 및 시간이며, dd/mm/yyyy hh:mm:ss 형식으로 표현됩니다. 여기서 시간대 필드는 GMT로부터의 +/-hhmm으로 표현됩니다. 예를 들면 다음과 같습니다. 02/Jan/1999:13:08:21 -0700
hostName	서버가 실행되고 있는 호스트 시스템의 이름입니다. 예: showshoe 주: 호스트에 두 개 이상의 Messaging Server 인스턴스가 있는 경우 프로세스 아이디(pid)를 사용하여 각 인스턴스의 기록된 이벤트를 구분할 수 있습니다.
processName	이벤트를 생성한 프로세스의 이름입니다. 예: cgi_store
pid	이벤트를 생성한 프로세스의 프로세스 아이디입니다. 예: 18753
category	이벤트가 속하는 범주(예: General)입니다(표 20-3 참조).
logLevel	이벤트가 표시되는 로깅 수준(예: Notice)입니다(표 20-2 참조).
eventMessage	이벤트별 설명 메일로 길이는 임의적일 수 있습니다. 예: Log created (894305624)

다음은 콘솔을 사용하여 표시되는 기록된 세 개의 이벤트입니다.

02/May/1998:17:37:32 -0700 showshoe cgi_store[18753]:
General Notice:
Log created (894155852)

04/May/1998:11:07:44 -0400 xyzmail cgi_service[343]: General Error:
function=getserverhello|port=2500|error=failed to connect

03/Dec/1998:06:54:32 +0200 SiroePost imapd[232]: Account Notice:
close [127.0.0.1] [unauthenticated] 1998/12/3 6:54:32
0:00:00 0 115 0

IMAP와 POP 이벤트 항목은 세 개의 번호로 끝날 수 있습니다. 위의 예에서는
0 115 0입니다. 첫 번째 번호는 클라이언트가 전송한 바이트 수이고, 두 번째 번호는 서버가 전송한 바이트 수이고, 세 번째 숫자는 선택한 메일함(POP의 경우 항상 1)입니다.

Log Viewer 창에서 로그 파일을 볼 때는 특정 로깅 수준이나 범주 또는 특정 프로세스 ID 등과 같은 이벤트의 특정 구성 요소를 검색하여, 표시되는 이벤트를 제한할 수 있습니다. 자세한 내용은 로그 검색 및 보기를 참조하십시오.

각 로그 항목의 이벤트 메일에는 기록되는 이벤트 유형에 한정된 형식이 사용됩니다. 즉, 각 서비스는 이벤트 메일에 표시되는 내용을 정의합니다. 대부분의 이벤트 메일은 간단하며 설명적입니다. 다른 메일은 좀 더 복잡할 수 있습니다.

로깅 옵션 정의 및 설정

관리에 필요한 가장 적합한 메일 저장소와 관리 서비스 로깅 구성을 정의할 수 있습니다. 이 절에서는 최적의 구성과 정책을 결정하는 데 도움이 되는 문제에 대해 설명하고 이를 구현하는 방법에 대해 설명합니다.

유연한 로깅 구조

로그 파일의 이름 지정 스키마(service.sequenceNum.timeStamp)는 유연한 로그 회전과 백업 정책을 지정하는 데 도움이 됩니다. 각 서비스에 대한 이벤트가 서로 다른 파일에 기록되기 때문에 문제를 빠르게 차단할 수 있습니다. 또한 파일 이름의 일련 번호가 계속 커지고 타임스탬프가 항상 고유하기 때문에 제한된 일련 번호 집합을 모두 사용한 후 새 로그 파일이 기존 로그 파일을 덮어쓰지 않습니다. 대신 보다 유연한 수명 제한, 파일 수 또는 전체 저장소 용량에 도달하였을 때만 기존 로그 파일을 삭제하거나 덮어쓰게 됩니다.

Messaging Server는 관리 작업을 단순화하고 백업 작업을 수월히 하는 로그 파일의 자동 회전 기능을 지원합니다. 이후의 기록되는 이벤트를 저장하기 위해 수동으로 현재 로그 파일을 지우고 새 파일을 만들 필요가 없습니다. 서버를 중단하거나 새 로그 파일을 시작하도록 서버에 수동으로 알리지 않고도 디렉토리에서 현재 로그 파일을 제외한 모든 파일을 언제든지 백업할 수 있습니다.

로깅 정책 설정 시 전체 로그 저장소 제한, 최대 로그 파일 수, 개별 파일 크기, 최대 파일 수명 및 로그 파일 회전 비율을 제어하는 옵션을 설정할 수 있습니다(각 옵션별).

원하는 옵션 계획

로그 파일의 회전이나 삭제를 시작할 수 있는 두 개 이상의 제한을 설정해야 합니다. 먼저 도달한 제한이 작업을 제어합니다. 예를 들어 최대 로그 파일 크기가 3.5MB이고 매일 새 로그가 생성되도록 지정한 경우, 로그 데이터가 24시간 동안 3.5MB 이상 작성되면 매일 하나 이상의 로그 파일이 생성됩니다. 또한 최대 로그 파일 수가 10이고 최대 수명이 8일인 경우, 로그 회전이 더 빠르게 수행되면 8일이 되기 전에 10개의 파일이 생성되므로 로그 파일의 수명 제한에는 도달하지 않게 됩니다.

Messaging Server 관리 로그에 대해 제공되는 다음 기본값을 계획의 시작점으로 사용할 수 있습니다.

디렉토리의 최대 로그 파일 수: 10
최대 로그 파일 크기: 2MB
모든 로그 파일에 허용되는 총 최대 크기: 20MB
허용되는 빈 디스크 최대 공간: 5MB
로그 롤오버 시간: 1일
만료 전 최대 수명: 7일
로깅 수준: 주

이 구성에서는 서버 관리 로그 데이터가 매일 약 2MB 정도 누적될 것이며, 1주에 한 번 백업하고, 관리 로그의 저장소에 할당된 총 크기는 최소한 25MB가 되는 것으로 가정합니다. 로깅 수준이 더 세밀한 경우 이 설정이 충분하지 않을 수 있습니다.

POP, IMAP 또는 HTTP 로그의 경우에도 처음에는 동일한 값을 사용할 수 있습니다. 모든 서비스에 대략 여기에 표시된 기본값과 동일한 로그 저장소 요구 사항이 있는 경우 처음에는 총 로그 저장소 용량을 약 150MB로 설정해야 합니다. 이는 일반적인 저장소 요구 사항이며 실제 요구 사항은 환경에 따라 크게 다를 수 있습니다.

로깅 옵션 설정

콘솔 또는 명령줄을 사용하여 메일 저장소 로깅 구성을 제어하는 옵션을 구성할 수 있습니다.

이러한 옵션의 최적 설정은 로그 데이터가 누적되는 비율에 따라 다릅니다. 1MB의 저장소 공간에는 4,000개에서 10,000개의 로그 항목이 들어갈 수 있습니다. 알림과 같은 보다 세밀한 로깅 수준에서는, 작업량이 중간 정도인 서버가 매주 수백 MB의 로그 데이터를 생성할 수 있습니다. 이 경우 다음과 같은 방법을 사용할 수 있습니다.

로그 정보를 서버 제공 로그 파일이 아니라 syslog로 보낼 수 있습니다. syslogfacility 옵션을 다음과 같이 설정하면 로그 정보를 syslog로 보낼 수 있습니다.

여기서 service는 admin, pop, imap, imta 또는 http이며, value는 user, mail, daemon, local0 ~ local7 또는 none입니다.

값을 설정하면 메일은 설정 값에 따라 syslog에 기록되며 다른 모든 로그 파일 서비스 옵션은 무시됩니다. 옵션이 설정되지 않았거나 값이 none이면 로깅은 Messaging Server 로그 파일을 사용합니다.

시스템이 http 메일 액세스 즉, 웹 메일을 지원하지 않는 경우 다음 변수를 설정하여 http 로깅을 비활성화할 수 있습니다. 시스템이 웹 메일을 지원해야 하는 경우(예: Messenger Express) 이 변수를 설정하지 마십시오.

configutil -o service.http.enable -v no
configutil -o service.http.enablesslport -v no

여기서 service는 admin, pop, imap, imta 또는 http이며 loglevel은 Nolog, Critical, Error, Warning, Notice, Information 또는 Debug입니다.

로그 파일의 디렉토리 경로를 지정하려면 다음을 수행합니다.

각 로그의 최대 파일 크기를 지정하려면 다음을 수행합니다.

디렉토리당 최대 로그 파일 수를 지정하려면 다음을 수행합니다.

보존하려는 빈 디스크 공간 최소 크기를 지정하려면 다음을 수행합니다.

로그 파일이 만료되는 시기를 지정하려면 다음을 수행합니다.

로그 검색 및 보기

콘솔에서는 메일 저장소와 관리 로그 데이터를 볼 수 있는 기본 인터페이스를 제공합니다. 이를 통해 개별 로그 파일을 선택하고 해당 파일 내에서 로그 항목의 필터링된 유연한 검색을 수행할 수 있습니다.

특정 서비스에 대한 로그 파일은 날짜 순으로 나열됩니다. 검색할 로그 파일을 선택한 다음에는 검색 매개 변수를 지정하여 개별 이벤트에 대한 검색 범위를 좁힐 수 있습니다.

검색 매개 변수

다음은 로그 데이터를 보기 위해 지정할 수 있는 검색 매개 변수입니다.

시간. 이벤트를 검색할 특정 시간의 시작과 끝을 지정하거나 검색할 일 수(현재 날짜 이전)를 지정할 수 있습니다. 서버 충돌 시간 또는 알고 있는 다른 발생 시간까지 기록된 이벤트를 확인할 시간 범위를 지정할 수 있습니다. 또는 현재 로그 파일 중 오늘의 이벤트만 보도록 범위를 지정할 수도 있습니다.

로깅 수준. 로깅 수준(로깅 수준 참조)을 지정할 수 있습니다. 특정 문제를 해결할 특정 수준을 선택할 수 있습니다. 예를 들어 서버 다운의 원인을 알려면 Critical을 선택하고 실패한 프로토콜 호출을 찾으려면 Error를 선택합니다.

facility(기능). 기능을 지정할 수 있습니다(기록되는 이벤트의 범주 참조). 문제가 포함된 기능 영역을 알고 있는 경우 특정 기능을 선택할 수 있습니다. 예를 들어 디스크 오류 때문에 서버가 크래시된 것으로 생각되면 Store를 선택하고, IMAP 프로토콜 명령 오류에 문제가 있는 경우 Protocol을 선택합니다.

텍스트 검색 패턴. 보다 세밀한 검색을 위해 텍스트 검색 패턴을 지정할 수 있습니다. 알고 있는 이벤트 시간, 프로세스 이름, 프로세스 아이디 및 이벤트 메일의 일부(예: 원격 호스트 이름, 함수 이름, 오류 번호 등) 등과 같이 와일드카드 형식의 검색으로 표현할 수 있는 이벤트의 모든 구성 요소(로그 파일 형식 참조)를 포함시킬 수 있습니다.

로그를 볼 때 로깅 수준과 기능을 조합하는 예는 다음과 같습니다.

검색 및 보기 결과 지정

지정된 서비스에 속한 특정 특성으로 기록되는 이벤트를 검색하려면 다음 단계를 수행합니다.

제3부: 서비스 로그(MTA)

MTA는 각 메일이 대기열에 포함되고 제외될 때마다 로깅할 수 있는 기능을 제공합니다. 또한 디스패처 오류 및 디버깅 출력도 제공합니다. 제3부는 다음 내용으로 구성되어 있습니다.

로깅은 채널별로 제어하거나 모든 채널의 메일 활동이 기록되도록 지정할 수 있습니다. 초기 구성에서는 모든 채널에 대해 로깅이 비활성화됩니다.

로깅을 활성화하면 MTA는 메일이 MTA 채널을 통과할 때마다 mail.log* 파일에 항목을 기록합니다. 이러한 로그 항목은 MTA를 통해(또는 특정 채널을 통해) 전달된 메일의 수에 대한 통계를 얻으려는 경우 또는 메일의 전송/전달 여부와 시점 등의 다른 질문을 조사하는 경우 유용합니다.

몇 개의 특정 MTA 채널을 통과한 메일의 수에 대한 통계 수집에만 관심이 있는 경우에는 해당 MTA 채널에 대한 로깅 채널 키워드만 활성화할 수 있습니다. 모든 MTA 채널에 대한 로깅을 활성화하는 사이트가 많이 있습니다. 특히 문제를 추적하는 경우 문제 진단의 첫 번째 단계로 예상하거나 의도한 채널로 메일이 전달되는지 알아내고 모든 채널에 대해 로깅을 활성화하면 이러한 문제의 진단에 도움이 됩니다.

MTA 로깅 활성화


주의	로깅을 활성화하면 mail.log가 지속적으로 증가하므로 확인하지 않는 경우 디스크 공간을 모두 차지해버릴 수 있습니다. 따라서 이 파일의 크기를 주기적으로 모니터하여 불필요한 내용은 삭제해야 합니다. 또한 필요에 따라 전체 파일을 삭제하여 다른 버전이 생성되도록 할 수도 있습니다.

특정 채널에 대한 로깅을 활성화하려면 다음 예에서처럼 MTA 구성 파일의 채널 정의에 logging 키워드를 추가합니다.

모든 채널 로그 메일 활동이 로깅 파일에 기록되도록 하려면 MTA 구성 파일의 채널 블록 섹션의 기본 채널에 logging 키워드만 추가하면 됩니다(채널 기본값 구성 참조). 예를 들면 다음과 같습니다.

defaults logging notices 1 2 4 7 copywarnpost copysendpost postheadonly noswitchchannel immnonurgent maxjobs 7 defaulthost siroe.com

l defragment charset7 us-ascii charset8 iso-8859-01
siroe.com

각 메일은 대기열에 포함되거나 제외될 때마다 기록됩니다. 모든 로그 항목은 msg_svr_base/data/logmail.log_current에 기록됩니다.

매일밤 자정 정도에 실행되는 메일 반환 작업은 기존 mail.log_yesterday를 누적 로그 파일인 mail.log에 추가하고, 현재 mail.log_current 파일의 이름을 mail.log_yesterday로 바꾼 다음 새 mail.log_current 파일을 시작합니다. 또한 모든 connection.log* 파일에 대해 비슷한 작업을 수행합니다.

LOG_MESSAGES_SYSLOG 옵션을 1로 설정하여 MTA 로그 메일을 syslog (UNIX)로 전송할 수 있습니다. 기본값인 0은 syslog (이벤트 로그) 로깅이 수행되지 않도록 지정합니다.

추가 MTA 로깅 옵션 지정

로깅이 활성화되면 기본 정보가 항상 제공될 뿐 아니라 MTA 옵션 파일에 다양한 LOG_* MTA 옵션을 구성하여 선택적 정보 필드가 추가로 포함되도록 할 수 있습니다. 옵션 파일에 대한 자세한 내용은 Messaging Server Reference Manual을 참조하십시오.

LOG_MESSAGE_ID. 이 옵션을 사용하면 메일과 항목을 서로 관련시킬 수 있습니다.

LOG_FILENAME. 이 옵션을 사용하면 특정 메일 파일이 몇 번 다시 전달되었는지 바로 알 수 있으며, MTA가 여러 수신자에게 전송되는 메일을 디스크에 별도의 메일 파일 사본으로 분리하는지 여부를 확인하는 데 유용할 수 있습니다.

LOG_CONNECTION. 이 옵션을 사용하면 MTA는 메일 트래픽 뿐만 아니라 TCP/IP 연결을 기록합니다. 연결 로그 항목은 기본적으로 mail.log* 파일에 기록되며, 선택적으로 connection.log* 파일에 기록될 수도 있습니다. SEPARATE_CONNECTION_LOG 옵션을 참조하십시오.

SEPARATE_CONNECTION_LOG. 이 옵션은 연결 로그 항목을 connection.log 파일에 대신 기록하도록 지정합니다.

LOG_PROCESS. 이 옵션을 LOG_CONNECTION과 함께 사용하면 연결 항목과 메일 항목을 프로세스 아이디로 상호 관련시킬 수 있습니다.

LOG_USERNAME. 이 옵션은 메일을 대기열에 포함시키는 프로세스에 연관된 아이디를 mail.log 파일에 저장할지 여부를 제어합니다. SASL (SMTP AUTH)이 사용된 SMTP 제출의 경우 아이디 필드는 인증된 아이디(앞에 별표 문자가 접두사로 붙음)가 됩니다.

MTA 로그 항목 형식

MTA 로그 파일은 ASCII 텍스트로 기록됩니다. 기본적으로 각 로그 파일 항목에는 아래 예와 같이 8개나 9개의 필드가 포함됩니다.

19-Jan-1998 19:16:57.64 l tcp_local E 1 adam@sesta.com
rfc822;marlowe@siroe.com marlowe@siroe.com

표 20-6 로깅 항목 코드
항목	설명
D	대기열에서 제외 성공
DA	SASL (인증)을 사용한 대기열에서 제외 성공
DS	TLS (보안)을 사용한 대기열에서 제외 성공
DSA	TLS 및 SASL (보안 및 인증)을 사용한 대기열에서 제외 성공
E	대기열에 포함
EA	SASL (인증)을 사용한 대기열에 포함 성공
ES	TLS (보안)를 사용한 대기열에 포함 성공
ESA	TLS 및 SASL (보안 및 인증)을 사용한 대기열에 포함 성공
J	대기열에 포함 시도 거부(슬레이브 채널 프로그램에 의한 거부)
K	수신자 메일 거부됨. 보낸 사람이 NOTIFY=NEVER DSN 플래그를 요청하거나 메일이 시간 초과하거나 메일을 수동으로 반환하는 경우(예: imsimta qm "delete" 명령은 각 수신자에 대해 항상 "K" 레코드를 생성하고 qm "return" 명령은 "R" 레코드 대신 "K" 레코드 생성). 보낸 사람의 요청에 따라 보낸 사람에게 알림을 보내지 않았음을 나타냅니다. rejection/time-out과 동일한 종류이지만 실패한 메일에 대한 새 알림 메일(원래의 보낸 사람에게 보냄)이 생성되는 "R" 레코드와 비교될 수 있습니다.
Q	대기열에서 제외 일시적으로 실패
R	대기열에서 제외 시도에서 수신자 주소 거부(마스터 채널 프로그램에 의한 거부) 또는 실패/바운스 메일의 생성
W	메일이 아직 전달되지 않았지만 아직 대기열에서 시도 중에 있음을 원래 전송자에게 알려주기 위해 전송되는 경고 메일
Z	일부 수신자는 성공했지만 이 수신자는 일시적으로 성공하지 못했습니다. 모든 수신자의 원본 메일 파일이 대기열에서 제외되었으며 대신 이 수신자와 다른 성공하지 못한 수신자를 위한 새 메일 파일이 곧 대기열에 포함됩니다.
SMTP 채널의 LOG_CONNECTION + 또는 - 항목
C	연결 끊김
O	연결 열림
X	연결 거부됨
Y	연결이 설정되기 전에 연결 시도가 실패했음
I	ETRN 명령이 수신됨

LOG_CONNECTION, LOG_FILENAME, LOG_MESSAGE_ID, LOG_NOTARY, LOG_PROCESS 및 LOG_USERNAME을 모두 활성화하면 형식은 아래 예와 같이 됩니다. (인쇄상의 이유로 샘플 로그 항목에서는 행이 바뀌어졌지만 실제 로그 항목은 한 행에 표시됩니다.)

채널 프로세스가 실행 중인 노드의 이름(이 예의 경우 HOSTA).

점(.) 문자와 카운트가 뒤에 붙은 프로세스 아이디. 다중 스레드 채널 항목인 경우(예: tcp_* 채널 항목) 프로세스 아이디와 카운트 사이에 스레드 아이디도 있습니다. 이 예에서 프로세스 아이디는 2e2d.2.1입니다.

정수로 표현된 메일의 NOTARY (전달 수신 요청) 플래그(이 예의 경우 276)입니다.

MTA 대기열 영역의 파일 이름(이 예의 경우 /imta/queue/l/ZZ01IWFY9ELGWM00094D.00)입니다.

메일 아이디(이 예의 경우 <01IWFVYLGTS499EC9Y@siroe.com>)입니다.

실행 프로세스의 이름(이 예의 경우 inetmail). UNIX에서는 SMTP 서버와 같은 디스패처 프로세스를 위한 것입니다. 이는 일반적으로 inetmail (SASL이 사용되지 않은 경우)입니다.

연결 정보(이 예의 경우 siroe.com (siroe.com [192.160.253.66]). 연결 정보는 HELO/EHLO 행(받는 SMTP 메일)에서 전송 시스템이 나타내는 이름 또는 대기열에 포함 채널의 공식 호스트 이름(다른 종류의 채널) 등의 전송 시스템이나 채널 이름으로 구성됩니다. TCP/IP 채널의 경우 전송 시스템의 "실제" 이름, 즉 DNS 역조회 및/또는 IP 주소에 의해 보고되는 심볼릭 이름은 ident* 채널 키워드에 의해 제어되어 괄호 안에 표시될 수 있습니다. IDENT 조회를 참조하십시오. 이 샘플에서는 이러한 키워드 중 하나를 사용한 것으로 가정합니다. 이 경우 DNS와 IP 주소에서 발견된 이름을 모두 표시하는 기본 identnone 키워드를 사용합니다.

MTA 로그 파일 관리

MTA는 현재 파일을 유지하기 위해 자동 롤오버를 수행하지만 파일 백업, 파일 자르기, 파일 삭제 등의 작업에 대한 정책을 결정하기 위해 누적 mail.log 파일을 관리해야 합니다.

로그 파일 관리 방법에 대해 고려할 때는 MTA의 주기적 반환 작업이 사이트에서 제공하는 msg_svr_base/bin/daily_cleanup 프로시저(있을 경우)를 실행한다는 것에 주의합니다. 따라서 일부 사이트는 매주 한 번 기존 mail.log 파일의 이름을 바꾸는 등의 자체적인 정리 절차를 제공할 수 있습니다.

MTA 메일 로깅의 예

MTA 메일 파일에 기록되는 정확한 필드 형식 및 필드 목록은 설정하는 로깅 옵션에 따라 다릅니다. 이 절에서는 일반적인 로그 항목의 몇 가지 예를 보여 줍니다. 추가적인 옵션 필드에 대한 설명은 추가 MTA 로깅 옵션 지정을 참조하십시오.

로그 파일을 검토하는 경우, 일반적인 시스템에서는 많은 메일이 한 번에 처리된다는 점을 유의하십시오. 일반적으로 특정 메일에 관련된 항목은 같은 시간에 처리되고 있는 다른 메일과 관련된 항목 간에 산재해 있게 됩니다. 기본 로깅 정보는 MTA를 통해 이동하는 전체 메일을 이해하는 데 적합합니다.


주	인쇄상의 이유로 로그 파일 항목이 여러 행으로 표시되어 있지만 실제 로그 파일 항목은 한 항목당 한 행으로 표시됩니다.

같은 메일에 관련된 특정 항목을 같은 수신자에게 연관시키려면 LOG_MESSAGE_ID를 활성화해야 합니다. 특정 메일을 MTA 대기열 영역의 특정 파일과 연관시키거나, 아직 성공적으로 대기열에서 제외되지 않은 메일의 배달 시도가 몇 번 있었는지 알아내려면 LOG_FILENAME을 활성화해야 합니다. SMTP 메일의 경우(TCP/IP 채널을 통해 처리됨) 원격 시스템의 TCP 연결을 전송된 메일과 연관시키려면 LOG_PROCESS와 LOG_CONNECTION의 몇 가지 수준을 활성화해야 합니다.

아래 예는 로컬 사용자가 보내는 TCP/IP 채널(예: 인터넷)로 메일을 전송하는 경우 볼 수 있는 로그 항목의 기본 예를 보여 줍니다. 이 예에서는 LOG_CONNECTION이 활성화되어 있습니다. (1)과 (2)로 표시된 행은 하나의 항목입니다. 실제 로그 파일에서는 한 행으로 표시됩니다. 마찬가지로 (3) - (7)로 표시된 행도 하나의 항목이며 실제로 한 행으로 표시됩니다.

이 행은 한(1) 블록 메일의 l 채널부터 tcp_local 채널까지의 대기열에 포함(E) 날짜 및 시간을 표시합니다.

이 부분은 로그 파일에서 (1)과 같은 행의 일부이며 여기서는 인쇄 편의상 별도의 행으로 표시했습니다. 이것은 봉투의 From: 주소(이 경우에는 adam@sesta.com)와 봉투의 From: 주소의 원래 버전과 현재 버전(이 경우 marlowe@siroe.com)을 나타냅니다.

이 행은 (1) 블록 메일의 tcp_local 채널의 대기열에서 제외(D) 날짜와 시간을 표시합니다. 즉 tcp_local 채널에 의한 일부 원격 SMTP 서버로의 성공적 전송을 표시합니다.

봉투의 From: 주소, 원래 봉투의 To: 주소 및 봉투의 To: 주소의 현재 형식을 표시합니다.

연결이 이루어진 실제 시스템의 이름이 DNS에서 thor.siroe.com이며, 로컬 전송 시스템의 IP 주소가 206.184.139.12이고 포트 2788에서 전송되고, 원격 대상 시스템의 IP 주소가 192.160.253.66이고 원격 대상 시스템의 연결 포트는 포트 25임을 보여 줍니다.

원격 SMTP 서버의 SMTP 배너 행을 표시합니다.

이 주소에 대해 반환된 SMTP 상태 코드를 표시합니다. 250은 기본 SMTP 성공 코드이며 이 원격 SMTP 서버는 확장된 SMTP 상태 코드와 추가 텍스트로 응답합니다.

코드 예 20-2는 코드 예 20-3과 비슷한 로깅 항목을 보여 주지만, LOG_FILENAME=1과 LOG_MESSAGE_ID=1을 설정하여(파일 이름과 메일 아이디 표시) 기록된 추가 정보를 함께 표시합니다. (1)과 (2)를 참조하십시오. 특히 메일 아이디를 사용하여 항목과 메일을 연관시킬 수 있습니다.

코드 예 20-3은 LOG_FILENAME=1, LOG_MESSAGE_ID=1 및 LOG_CONNECTION=1을 활성화하여 여러 수신자에게 전송하는 예를 보여 줍니다. 여기서 사용자 adam@sesta.com은 MTA 메일링 목록 test-list@sesta.com으로 전송하였고 이 메일링 목록은 bob@sesta.com, carol@varrius.com 및 david@varrius.com으로 확장됩니다. 현재 봉투의 To: 주소는 각각의 해당 주소이지만 원래 봉투의 To: 주소는 각 수신자에 대해 test-list@sesta.com이라는 것에 주의합니다. 두 개의 별도 파일(l 채널에 대해 하나, tcp_local 채널에서 나가는 파일 하나)이 관련되어 있지만 메일 아이디는 동일하게 유지됩니다.

19-Jan-1998 20:01:44.10 l    l            E 1
adam@sesta.com rfc822;test-list@sesta.com bob
imta/queue/l/ZZ01ISKND3DE1K90N15M.00
<01ISKND2H8MS90N15M@sesta.com>

19-Jan-1998 20:01:44.81 l            tcp_local    E 1
adam@sesta.com rfc822;test-list@sesta.com carol@varrius.com
imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
<01ISKND2H8MS90N15M@sesta.com>

19-Jan-1998 20:01:44.81 l            tcp_local    E 1
adam@sesta.com rfc822;test-list@sesta.com david@varrius.com
imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
<01ISKND2H8MS90N15M@sesta.com>

19-Jan-1998 20:01:50.69 l                         D 1
adam@sesta.com rfc822;test-list@sesta.com bob
imta/queue/l/ZZ01ISKND3DE1K90N15M.00
<01ISKND2H8MS90N15M@sesta.com>

19-Jan-1998 20:01:57.36 tcp_local                  D 1
adam@sesta.com rfc822;test-list@sesta.com carol@varrius.com
imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
<01ISKND2H8MS90N15M@sesta.com>
dns;gw.varrius.com (TCP|206.184.139.12|2788|192.160.253.66|25)
(gw.varrius.com -- SMTP Sendmail)
smtp;250 OK.

19-Jan-1998 20:02:06.14 tcp_local                  D 1
adam@sesta.com rfc822;test-list@sesta.com david@varrius.com
imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
<01ISKND2H8MS90N15M@sesta.com>
dns;gw.varrius.com (TCP|206.184.139.12|2788|192.160.253.66|25)
(gw.varrius.com -- SMTP Sendmail)
smtp;250 OK.

코드 예 20-4는 존재하지 않는 도메인(여기에서는 very.bogus.com)으로의 전송 시도를 보여 줍니다. 즉, MTA의 다시 쓰기 규칙에 의해 존재하지 않는 것으로 알려지지 않으며 MTA가 보내는 TCP/IP 채널에 일치하는 도메인 이름으로 전송을 시도합니다. 이 예에서는 MTA 옵션을 LOG_FILENAME=1 및 LOG_MESSAGE_ID=1로 설정한 것으로 가정합니다.

TCP/IP 채널이 실행되어 DNS에서 도메인 이름을 검사할 때 DNS는 이름이 존재하지 않는다는 오류를 반환합니다. (5)에 있는 “rejection” 항목(R)과 (6)에 있는 유효한 도메인 이름이 아니라는 오류를 반환하는 DNS를 주의하십시오.

메일이 제출된 뒤 주소가 거부되었기 때문에 MTA는 원래 전송자에게 바운스 메일을 생성합니다. MTA는 새 거부 메일을 원래의 전송자(1)에게 보내도록 대기열에 포함시키고 복사본은 포스트마스터에게 전송한 다음(4) 원래의 아웃바운드 메일을 삭제합니다((5)에 있는 R 항목).

바운스 메일 등의 알림 메일에는 봉투의 From: 필드가 빈 공간으로 표시되어 있는 빈 봉투의 From: 주소((2) 및 (8))가 있습니다. MTA가 생성한 바운스 메일의 초기 포함된 대기열은 새 알림 메일의 메일 아이디와 원래 메일의 메일 아이디(3)를 보여 줍니다. 이러한 정보가 항상 MTA에 사용 가능한 것은 아니지만 기록할 수 있는 경우에는 아웃바운드 실패 메일에 해당하는 로그 항목을 결과 알림 메일에 해당하는 로그 항목에 연관시킬 수 있도록 해줍니다. 이러한 알림 메일은 프로세스 채널의 대기열에 포함되고 그런 다음 적절한 대상 채널(7)의 대기열에 포함됩니다.

19-JAN-1998 20:49:04 l            tcp_local    E 1
adam@sesta.com rfc822;user@very.bogus.com user@very.bogus.com
imta/queue/tcp_local/ZZ01ISKP0S0LVQ94DU0K.00
<01ISKP0RYMAS94DU0K@SESTA.COM>

19-JAN-1998 20:49:33 tcp_local    process      E 1              (1)
rfc822;adam@sesta.com adam@sesta.com                           (2)
imta/queue/process/ZZ01ISKP0S0LVQ94DTZB.00
<01ISKP22MW8894DTAS@SESTA.COM>,<01ISKP0RYMAS94DU0K@SESTA.COM>   (3)

19-JAN-1998 20:49:33 tcp_local    process      E 1               (4)
rfc822;postmaster@sesta.com postmaster@sesta.com
imta/queue/process/ZZ01ISKP0S0LVQ94DTZB.00
<01ISKP22MW8894DTAS@SESTA.COM>,<01ISKP0RYMAS94DU0K@SESTA.COM>

19-JAN-1998 20:50:07 tcp_local                  R 1              (5)
adam@sesta.com rfc822;user@very.bogus.com user@very.bogus.com
imta/queue/tcp_local/ZZ01ISKP0S0LVQ94DU0K.00
<01ISKP0RYMAS94DU0K@SESTA.COM>
Illegal host/domain name found                                  (6)

19-JAN-1998 20:50:08 process      l            E 3               (7)
rfc822;adam@sesta.com adam                                      (8)
imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
<01ISKP22MW8894DTAS@SESTA.COM>

19-JAN-1998 20:50:08 process      l            E 3
rfc822;postmaster@sesta.com postmaster
imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
<01ISKP22MW8894DTAS@SESTA.COM>

19-JAN-1998 20:50:12 l                         D 3
rfc822;adam@sesta.com adam
imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
<01ISKP22MW8894DTAS@SESTA.COM>

19-JAN-1998 20:50:12 l                         D 3
rfc822;postmaster@sesta.com postmaster
imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
<01ISKP22MW8894DTAS@SIROE.COM>

코드 예 20-5은 원격 시스템의 잘못된 주소로 전송을 시도하는 예입니다. 이 예에서는 MTA 옵션이 LOG_FILENAME=1 및 LOG_MESSAGE_ID=1이고 채널 옵션이 LOG_BANNER=1 및 LOG_TRANSPORTINFO=1인 것으로 가정합니다. (1)에 있는 거부 항목 (R)에 주의하십시오. 하지만 코드 예 20-4의 거부 항목과는 대조적으로 여기에 있는 거부 항목은 원격 시스템으로 연결되었음을 보여주고 원격 SMTP 서버, (2) 및 (3)에 의해 발생한 SMTP 오류 코드를 보여 줍니다. (2)에 있는 정보가 포함된 이유는 채널 옵션이 LOG_BANNER=1 및 LOG_TRANSPORTINFO=1로 설정되었기 때문입니다.

20-JAN-1998 13:11:05 l            tcp_local    E 1
adam@sesta.com rfc822;nonesuch@siroe.com nonesuch@siroe.com
imta/queue/tcp_local/ZZ01ISLNBB1JOE94DUWH.00
<01ISLNBAWV3094DUWH@sesta.com>

20-JAN-1998 13:11:08 tcp_local    process      E 1
rfc822;adam@sesta.com adam@sesta.com
imta/queue/process/ZZ01ISLNBB1JOE94DSGB.00
<01ISLNBFKIDS94DUJ8@sesta.com>,<01ISLNBAWV3094DUWH@sesta.com>

20-JAN-1998 13:11:08 tcp_local    process      E 1
rfc822;postmaster@sesta.com postmaster@sesta.com
imta/queue/process/ZZ01ISLNBB1JOE94DSGB.00
<01ISLNBFKIDS94DUJ8@sesta.com>,<01ISLNBAWV3094DUWH@sesta.com>

20-JAN-1998 13:11:11 tcp_local                  R 1      (1)
adam@sesta.com rfc822;nonesuch@siroe.com nonesuch@siroe.com
imta/queue/tcp_local/ZZ01ISLNBB1JOE94DUWH.00
<01ISLNBAWV3094DUWH@sesta.com>
dns;thor.siroe.com
(TCP|206.184.139.12|2788|192.160.253.66|25)             (2)
(THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])
smtp; 553 unknown or illegal user: nonesuch@siroe.com   (3)

20-JAN-1998 13:11:12 process      l            E 3
rfc822;adam@sesta.com adam
imta/queue/l/ZZ01ISLNBGND1094DQDP.00
<01ISLNBFKIDS94DUJ8@sesta.com>

20-JAN-1998 13:11:12 process      l            E 3
rfc822;postmaster@sesta.com postmaster
imta/queue/l/ZZ01ISLNBGND1094DQDP.00
<01ISLNBFKIDS94DUJ8@sesta.com>

20-JAN-1998 13:11:13 l                         D 3
rfc822;adam@sesta.com adam@sesta.com
imta/queue/l/ZZ01ISLNBGND1094DQDP.00
<01ISLNBFKIDS94DUJ8@sesta.com>

20-JAN-1998 13:11:13 l                         D 3
rfc822;postmaster@sesta.com postmaster@sesta.com
imta/queue/l/ZZ01ISLNBGND1094DQDP.00
<01ISLNBFKIDS94DUJ8@sesta.com>

코드 예 20-6은 MTA가 원격 메일 제출 시도를 거부할 때 발생하는 로그 파일 항목을 보여 줍니다. 이 예에서는 선택적인 LOG_* 옵션을 활성화하지 않은 것으로 간주하므로 항목에 기본적인 필드가 기록됩니다. 특히 LOG_CONNECTION 옵션을 활성화하면 J 항목 등과 같은 추가 필드가 표시됩니다. 이 경우에는 다음을 포함하여 ORIG_SEND_ACCESS 매핑을 사용하여 SMTP 릴레이 차단을 설정한(SMTP 중계 차단 구성 참조) MTA에 대한 예입니다.

ORIG_SEND_ACCESS

! ...numerous entries omitted...
!
tcp_local|*|tcp_local|* $NRelaying$ not$ permitted

여기서 alan@very.bogus.com은 내부 주소가 아닙니다. 따라서 원격 사용자 harold@varrius.com이 MTA 시스템을 통해 원격 사용자 alan@very.bogus.com에게 릴레이하려는 시도는 거부됩니다.

코드 예 20-7은 첫 번째 시도에서 메일을 배달을 할 수 없어서 MTA가 메일 전송을 여러 번 시도한 경우의 로그 파일 항목입니다. 이 예에서는 옵션이 LOG_FILENAME=1 및 LOG_MESSAGE_ID=1으로 구성되었다고 가정합니다.

15-Jan-1998 10:31:05.18 tcp_internal   tcp_local   E 3    (1)
adam@hosta.sesta.com rfc822;user@some.org user@some.org
imta/queue/tcp_local/ZZ01IS3D2ZP7FQ9UN54R.00
<01IRUD7SVA3Q9UN2D4@sesta.com>

15-Jan-1998 10:31:10.37 tcp_local                  Q 3    (2)
adam@hosta.sesta.com rfc822;user@some.org user@some.org
imta/queue/tcp_local/ZZ01IS3D2ZP7FQ9UN54R.00             (3)
<01IRUD7SVA3Q9UN2D4@sesta.com>
TCP active open: Failed connect()    Error: no route to host (4)

...several hours worth of entries...

15-Jan-1998 12:45:39.48 tcp_local                  Q 3     (5)
adam@hosta.sesta.com rfc822;user@some.org user@some.org
imta/queue/tcp_local/ZY01IS3D2ZP7FQ9UN54R.00              (6)
<01IRUD7SVA3Q9UN2D4@sesta.com>
TCP active open: Failed connect()    Error: no route to host

...several hours worth of entries...

15-Jan-1998 16:45:24.72 tcp_local                  Q 3
adam@hosta.sesta.com rfc822;user@some.org user@some.org
imta/queue/tcp_local/ZX01IS67NY4RRK9UN7GP.00                (7)
<01IRUD7SVA3Q9UN2D4@sesta.com>
TCP active open: Failed connect() Error: connection refused (8)

...several hours worth of entries...

15-Jan-1998 20:45:51.55 tcp_local                  D 3       (9)
adam@hosta.sesta.com rfc822;user@some.org user@some.org
imta/queue/tcp_local/ZX01IS67NY4RRK9UN7GP.00
<01IRUD7SVA3Q9UN2D4@sesta.com>
dns;host.some.org (TCP|206.184.139.12|2788|192.1.1.1|25)
(All set, fire away)
smtp; 250 Ok

메일은 tcp_internal 채널로 보내집니다. 일반적으로 POP 또는 IMAP 클라이언트 또는 MTA를 SMTP 릴레이로 사용하여 조직 내의 다른 호스트가 보내는 것이며, MTA는 이것을 보내는 tcp_local 채널의 대기열에 포함시킵니다.

Q 항목에 표시되어 있는 것처럼 첫 번째 전달 시도는 실패했습니다.

이는 ZZ* 파일 이름에서 볼 수 있는 첫 번째 전달 시도입니다.

TCP/IP 패키지가 원격측으로의 경로를 찾을 수 없어서 이 전달 시도는 실패했습니다. 코드 예 20-4와는 반대로 DNS가 대상 도메인 이름인 some.org의 문제를 나타내는 것이 아니라, "no route to host" 오류 메시지가 전송측과 수신측 사이에 어떤 네트워크 문제가 있음을 나타냅니다.

MTA 주기적 작업이 다음에 전달을 재시도하면 또 실패하게 됩니다.

이제 파일 이름은 두 번째 시도임을 나타내는 ZY*로 바뀝니다.

세 번째로 시도가 실패한 경우 파일 이름은 ZX*입니다.

다음에 주기적 작업이 재시도하는 전달이 실패하면, 이번에는 TCP/IP 패키지가 원격 SMTP 서버에 도달할 수 없다고 표시하는 것이 아니라 원격 SMTP 서버가 연결을 설정하지 않음을 나타냅니다. 원격측에서 네트워크 문제는 해결했지만 아직 SMTP 서버를 실행하지 않았을 수 있습니다. 즉, 해당 SMTP 서버가 다른 메일을 처리할 수 없어서 MTA가 연결을 시도할 때 그 연결을 설정하지 못했을 수 있습니다.

마지막으로 메일이 대기열에서 제외됩니다.

코드 예 20-8은 메일이 변환 채널을 통해 경로 지정되는 경우를 보여 줍니다. 해당 사이트에는 다음과 같은 CONVERSIONS 매핑 테이블이 있는 것으로 가정합니다.

이 예에서는 옵션이 LOG_FILENAME=1 및 LOG_MESSAGE_ID=1으로 구성되었다고 가정합니다.

코드 예 20-9는 LOG_CONNECTION=3을 통해 연결 로깅이 활성화된 경우 보내는 메일에 대한 로그 출력을 보여 줍니다. 이 예에서도 LOG_PROCESS=1, LOG_MESSAGE_ID=1, LOG_FILENAME=1이라고 가정합니다. 이 예는 사용자 adam@sesta.com이 세 명의 수신자(bobby@hosta.sesta.com, carl@hosta.sesta.com 및 dave@hostb.sesta.com)에게 같은 메일을 보내는 경우를 보여 줍니다(각 메일 사본의 메일 아이디는 동일함). 이 예에서는 일반적으로 채널이 그러하듯이 single_sys 채널 키워드로 표시된 tcp_local 채널로 메일이 나가는 것으로 가정합니다. 따라서 (1), (2), (3)에서 볼 수 있듯이 각 수신자 집합에 대해 별도의 메일 파일이 디스크에 별도의 호스트 이름으로 생성됩니다. 여기서 bobby@hosta.sesta.com 및 carl@hosta.sesta.com 수신자는 같은 메일 파일에 저장되지만 dave@hostb.sesta.com 수신자는 다른 메일 파일에 저장됩니다.


19-Feb-1998 10:52:05.41 1e488.0 l tcp_local E 1
adam@sesta.com rfc822;bobby@hosta.sesta.com bobby@hosta.sesta.com
imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00 (1) <01ITRF7BDHS6000FCN@SESTA.COM>

19-Feb-1998 10:52:05.41 1e488.0 l tcp_local E 1
adam@sesta.com rfc822;carl@hosta.sesta.com carl@hosta.sesta.com
imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00 (2) <01ITRF7BDHS6000FCN@SESTA.COM>

19-Feb-1998 10:52:05.74 1e488.1 l tcp_local E 1
adam@sesta.com rfc822;dave@hostb.sesta.com dave@hostb.sesta.com
imta/queue/tcp_local/ZZ01ITRF7C11FU000FCN.00 (3) <01ITRF7BDHS6000FCN@SESTA.COM>

19-Feb-1998 10:52:10.79 1f625.2.0 tcp_local - O (4)
TCP\|206.184.139.12\|5900\|206.184.139.66\|25 SMTP/hostb.sesta.com/mailhub.sesta.com (5)

19-Feb-1998 10:52:10.87 1f625.3.0 tcp_local - O (6)
TCP\|206.184.139.12\|5901\|206.184.139.70\|25 SMTP/hosta.sesta.com/hosta.sesta.com (7)

19-Feb-1998 10:52:12.28 1f625.3.1 tcp_local D 1
adam@sesta.com rfc822;bobby@hosta.sesta.com bobby@hosta.sesta.com
imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00 <01ITRF7BDHS6000FCN@SESTA.COM>
hosta.sesta.com dns;hosta.sesta.com (8)
(TCP\|206.184.139.12\|5901\|206.184.139.70\|25)
(hosta.sesta.com -- Server ESMTP [iMS V5.0 #8790])
(TCP\|206.184.139.12\|5901\|206.184.139.70\|25)
smtp;250 2.1.5 bobby@hosta.sesta.com and options OK.

19-Feb-1998 10:52:12.28 1f625.3.1 tcp_local D 1
adam@sesta.com rfc822;carl@hosta.sesta.com carl@hosta.sesta.com
imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00 <01ITRF7BDHS6000FCN@SESTA.COM>
hosta.sesta.com dns;hosta.sesta.com
(TCP\|206.184.139.12\|5901\|206.184.139.70\|25)
(hosta.sesta.com -- Server ESMTP [iMS V5.0 #8790])
(TCP\|206.184.139.12\|5901\|206.184.139.70\|25)
smtp;250 2.1.5 carl@hosta.sesta.com and options OK.

19-Feb-1998 10:52:12.40 1f625.3.2 tcp_local - C (9)
TCP\|206.184.139.12\|5901\|206.184.139.70\|25
SMTP/hosta.sesta.com/hosta.sesta.com

19-Feb-1998 10:52:13.01 1f625.2.1 tcp_local D 1
adam@sesta.com rfc822;dave@hostb.sesta.com dave@hostb.sesta.com
imta/queue/tcp_local/ZZ01ITRF7C11FU000FCN.00 <01ITRF7BDHS6000FCN@SESTA.COM>
mailhub.sesta.com dns;mailhub.sesta.com
(TCP\|206.184.139.12\|5900\|206.184.139.66\|25)
(MAILHUB.SESTA.COM -- Server ESMTP [iMS V5.0 #8694])
(TCP\|206.184.139.12\|5900\|206.184.139.66\|25)
smtp;250 2.1.5 dave@hostb.sesta.com and options OK.

19-Feb-1998 10:52:13.05 1f625.2.2 tcp_local - C (10)
TCP\|206.184.139.12\|5900\|206.184.139.66\|25
SMTP/hostb.sesta.com/mailhub.sesta.com

메일이 첫 번째 수신자의 대기열에 포함됩니다.

그리고 두 번째 수신자의 대기열에 포함됩니다.

그리고 세 번째 수신자의 대기열에 포함됩니다.

LOG_CONNECTION=3으로 설정하면 MTA가 이 항목을 기록합니다. 마이너스 기호(-)는 이 항목이 보내는 연결을 참조한다는 것을 나타냅니다. O는 이 항목이 연결 열기에 해당한다는 것을 나타냅니다. 이러한 별도의 연결을 열 때 다중 스레드 TCP/IP 채널에 같은 프로세스가 사용되기 때문에(열기는 스레드 2 및 스레드 3에 의해 수행되지만) 여기서 프로세스 아이디는 모두 1f625임을 알 수 있습니다.

두 개의 개별적인 원격 시스템에 연결해야 하기 때문에 별도 스레드의 다중 스레드 SMTP 클라이언트는 각각(이 항목에서는 첫 번째, 7에 표시된 두 번째)에 대한 연결을 엽니다. 이 항목 부분은 전송 및 대상 IP 번호와 포트 번호를 표시하며 초기 호스트 이름 및 DNS 조회로 발견된 호스트 이름을 표시합니다. SMTP/initial-host/dns-host 절에서는 초기 호스트 이름이 모두 표시되며, 초기 호스트 이름에 대한 DNS MX 레코드 조회를 수행한 뒤에 사용된다는 것을 알 수 있습니다. mailhub.sesta.com은 hostb.sesta.com의 MX 서버입니다.

다중 스레드 SMTP 클라이언트는 동일한 프로세스를 통해 별도의 스레드에서 두 번째 시스템에 대한 연결을 엽니다.

두 개의 개별적인 원격 시스템에 연결해야 하기 때문에 별도 스레드의 다중 스레드 SMTP 클라이언트는 각각에 대해(이 항목에서는 두 번째, 5에 표시된 첫 번째) 연결을 엽니다. 이 항목 부분은 전송 및 대상 IP 번호와 포트 번호를 표시하며 초기 호스트 이름 및 DNS 조회로 발견된 호스트 이름을 표시합니다. 이 예에서는 hosta.sesta.com 시스템이 직접 메일을 수신합니다.

특정 연결 항목 이외에도 LOG_CONNECTION=3으로 설정하면 여기에서 예로 표시된 바와 같이 정규 메일 항목에 연결 관련 정보가 포함됩니다.

LOG_CONNECTION=3으로 설정하면 MTA는 이 항목을 기록합니다. 메일이 대기열에 포함된 뒤(이 예에서는 bobby와 carl 메일) 이 항목의 C에 표시된 봐아 같이 연결이 닫힙니다.

LOG_CONNECTION=3으로 설정하면 MTA는 이 항목을 기록합니다. 메일이 대기열에서 제외된 후(이 예의 경우 dave 메일) 이 항목의 C에서 표시하는 대로 연결이 닫힙니다.

코드 예 20-10은 LOG_CONNECTION=3을 통해 연결 로깅이 활성화된 경우 받는 SMTP 메일에 대한 로그 출력을 보여 줍니다.

원격 시스템이 연결을 엽니다. O 문자는 이 항목이 연결 열기에 관련되어 있음을 나타냅니다. + 문자는 이 항목이 받는 연결에 관련되어 있음을 나타냅니다.

연결에 대한 IP 번호와 포트가 표시됩니다. 이 항목에서 수신 시스템(로그 파일 항목을 만드는 시스템)의 IP 주소는 206.184.139.12이고 포트 25로 연결됩니다. 송신 시스템의 IP 주소는 192.160.253.66이고 포트 1244에서 전송됩니다.

받는 TCP/IP 채널(tcp_local)에서 l 채널 수신자로 메일을 대기열에 포함하는 항목에서는, LOG_CONNECTION=3이 활성화되어 있기 때문에 기본값 이외의 정보를 포함할 수 있습니다. 특히 전송 시스템이 HELO 또는 EHLO 행에 표시한 이름, 연결 IP 번호에 대한 DNS 역조회로 발견된 전송 시스템 이름 및 전송 시스템의 IP 주소가 모두 기록되어 있습니다. 이 기능에 영향을 주는 채널 키워드에 대한 설명은 12장, "채널 정의 구성"을 참조하십시오.

인바운드 연결이 닫힙니다. C 문자는 이 항목이 연결 닫기에 관련되어 있음을 나타냅니다. + 문자는 이 항목이 받는 연결에 관련되어 있음을 나타냅니다.

디스패처 디버깅 및 로그 파일

디스패처 오류 및 디버깅 출력(활성화된 경우)은 MTA 로그 디렉토리의 dispatcher.log 파일에 기록됩니다.

디버깅 출력은 디스패처 구성 파일에 DEBUG 옵션을 사용하여 활성화되거나 IMTA_DISPATCHER_DEBUG 환경 변수(UNIX)를 사용하여 프로세스별 수준으로 활성화됩니다.

DEBUG 옵션 또는 IMTA_DISPATCHER_DEBUG 환경 변수(UNIX)는 32비트 디버그 마스크를 16진수로 정의합니다. 옵션을 -1로 설정하거나 논리 또는 환경 변수를 시스템 전반에 걸쳐 FFFFFFFF 값으로 정의하면 모든 디버깅이 활성화됩니다. 각 비트의 실제 의미는 표 20-7에 설명되어 있습니다.

표 20-7 디스패처 디버깅 비트
비트	16진수 값	10진수 값	사용
0	x 00001	1	기본 서비스 디스패처 주 모듈 디버깅
1	x 00002	2	추가 서비스 디스패처 주 모듈 디버깅
2	x 00004	4	서비스 디스패처 구성 파일 로깅
3	x 00008	8	기본 서비스 디스패처 기타 디버깅
4	x 00010	16	기본 서비스 디버깅
5	x 00020	32	추가 서비스 디버깅
6	x 00040	64	프로세스 관련 서비스 디버깅
7	x 00080	128	사용되지 않음
8	x 00100	256	기본 서비스 디스패처 및 프로세스 통신 디버깅
9	x 00200	512	추가 서비스 디스패처 및 프로세스 통신 디버깅
10	x 00400	1024	패킷 수준 통신 디버깅
11	x 00800	2048	사용되지 않음
12	x 01000	4096	기본 작업자 프로세스 디버깅
13	x 02000	8192	추가 작업자 프로세스 디버깅
14	x 04000	16384	추가 작업자 프로세스 디버깅, 특히 연결 핸드오프
15	x 08000	32768	사용되지 않음
16	x 10000	65536	서비스 디스패처 I/O에 대한 기본 작업자 프로세스 디버깅
17	x 20000	131072	서비스 디스패처 I/O에 대한 기타 작업자 프로세스 디버깅
20	x 100000	1048576	기본 통계 디버깅
21	x 200000	2097152	추가 통계 디버깅
24	x 1000000	16777216	dispatcher.log 파일에 대한 PORT_ACCESS 거부 기록

Solaris의 시스템 매개 변수

시스템의 힙 크기(datasize)는 디스패처의 스레드 스택을 사용하기에 충분해야 합니다. 각 디스패처 서비스에 대해 STACKSIZE*MAX_CONNS를 계산한 다음 각 서비스에 대해 계산된 값을 모두 더합니다. 시스템의 힙 크기는 이 숫자의 두 배 이상이 되어야 합니다.

디스패처 구성 파일에서 제공되는 디스패처 서비스는 다양한 시스템 매개 변수의 요구 사항에 영향을 미칩니다.

이전 목차 색인 다음
Sun Java System Messaging Server 6 2004Q2 관리 설명서