test

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

21장 로깅 관리

이 장에서는 Messaging Server MTA, 메시지 저장소 및 서비스의 로깅 기능에 대해 개괄적으로 설명합니다. 또한 이 장에서는 이러한 로깅 기능을 관리하는 방법에 대해 설명합니다.

이 장은 다음 내용으로 구성되어 있습니다.

로깅 개요

로깅은 시스템이 시스템 서비스에 대한 시간이 기록되고 레이블이 지정된 정보를 제공하는 수단입니다. 로깅에서는 시스템의 현재 스냅샷뿐 아니라 기록 보기도 제공합니다.

Messaging Server 로그 파일을 이해하고 사용하면 다음을 수행할 수 있습니다.

예를 들어, 사용자 수가 증가하여 더 많은 디스크 저장소를 사이트에 추가해야 할 경우 Messaging Server 로그 파일을 사용하여 시스템 수요의 증가 비율을 확인하고 필요한 새 디스크 저장소의 양을 계획할 수 있습니다.

또한 Messaging Server 로그를 사용하여 하루 동안의 메시징 패턴을 파악할 수 있습니다. 매일 최고 부하가 발생하는 시점을 파악하면 용량 계획을 수행하는 데 도움이 됩니다.

또한 로깅은 사용자 문제를 해결하는 데 도움이 됩니다. 예를 들어, 사용자가 예상한 메일 메시지를 받지 못할 경우 Messaging Server 로깅 기능을 사용하여 사용자의 메일 메시지를 추적할 수 있습니다. 이렇게 함으로써 메일이 자동으로 필터링되어 SPAM 폴더로 보내졌기 때문에 도착하지 않았음을 확인할 수도 있습니다.

로깅 데이터의 유형

일반적으로 로깅은 두 가지 유형의 정보를 제공합니다.

대부분의 경우 Messaging Server 로깅에서는 작업 데이터를 제공합니다. 이 작업 데이터에는 메일이 시스템에 들어온 날짜와 시간, 메일의 보낸 사람 및 받는 사람, 메일이 디스크에 기록된 시간, 이후에 메일이 디스크에서 제거되고 사용자의 메일함에 삽입된 시간 등의 정보가 포함됩니다.

또한 Messaging Server 로깅에서는 이벤트 로깅 데이터도 제공합니다. 이벤트 로깅 데이터를 얻으려면 다른 로그 파일에서 여러 항목을 모아야 합니다. 그런 다음 메시지 아이디와 같은 고유한 상수를 사용하여 시스템을 통해 지점 간에 전달된 메일의 주기를 검색하고 연관시킬 수 있습니다.

Messaging Server 로그 파일의 유형

Messaging Server 로깅은 세 가지 유형의 로그 파일로 구성됩니다.

  1. MTA 로그. 앞에서 설명한 Message Transfer Agent에 대한 작업 데이터를 제공합니다.

  2. 오류 로그. 이 오류 로그는 MTA 디버그 로그이며 MTA 하위 구성 요소 로그(즉, Job Controller, 디스패처 등)입니다.

  3. 메일 저장소 및 서비스 로그.http 서버, mshttpd, imap, pop 서비스 및 Admin 서비스의 메일을 제공합니다. 이 로그의 형식은 처음 두 로그 유형과 다릅니다.

다음 표에는 다양한 유형의 로그 파일이 나열되어 있습니다. 기본적으로 로그 파일은 msg_svr_base/data/log 디렉토리에 있습니다. 각 로그 파일의 유형을 개별적으로 사용자 정의하고 볼 수 있습니다.

표 21–1 Messaging Server 로그 파일

로그 파일 유형 

로그 파일 설명 

기본 이름 

MTA 

날짜 및 시간 정보, 대기열에 포함 및 대기열에서 제외 정보 등을 비롯하여 MTA를 통과하는 메일 트래픽에 대한 정보를 보여 줍니다. 

mail.log, mail.log_current, mail.log_yesterday 

연결 

전자 메일을 보내기 위해 이 시스템에 연결하는 원격 시스템(MTA)을 포함합니다. 

connection.log 

카운터 

채널별로 송수신된 메일에 관한 메일 추세를 포함합니다. 

counters 

Job Controller 

마스터, Job Controller, 보낸 사람 및 대기열에서 제외 채널 프로그램에 대한 데이터를 포함합니다.  

job_controller.log 

디스패처 

디스패처에 관한 오류를 포함합니다. 디스패처 디버깅을 설정하면 정보가 증가합니다. 

dispatcher.log 

채널 

채널에 관한 오류를 기록합니다. master_debug 및 slave_debug 키워드는 채널 디버깅을 설정하여 채널 로그 파일의 자세한 표시 수준을 늘립니다. 정보 수준과 유형은 option.dat에서 여러 *_DEBUG MTA 옵션을 사용하여 제어합니다. 

channelname_master.log*(예: tcp_local_master.log*)

channelname_slave.log*(예: tcp_local_slave.log*)

Admin 

Administration Server에 의해 콘솔과 Messaging Server 사이에 수행되는(대부분 CGI 프로세스를 통해 수행됨) 통신에 관련된 기록 이벤트가 포함됩니다.  

admin, admin.sequenceNum.timeStamp

IMAP 

이 서버의 IMAP4 활동에 관련된 기록 이벤트가 포함됩니다. 

imap, imap.sequenceNum.timeStamp

POP 

이 서버의 POP3 활동에 관련된 기록 이벤트가 포함됩니다. 

pop, pop.sequenceNum.timeStamp

HTTP 

이 서버의 HTTP 활동에 관련된 기록 이벤트가 포함됩니다. 

http, http.sequenceNum.timeStamp

기본값 

명령줄 유틸리티 및 기타 프로세스 등과 같은 이 서버의 다른 활동에 관련된 기록 이벤트가 포함됩니다. 

default, default.sequenceNum.timeStamp

msgtrace 

메시지 저장소에 대한 추적 정보를 포함합니다. 파일이 매우 빠른 속도로 아주 커질 수 있습니다. 적절히 모니터하십시오. 

msgtrace 

watcher 

프로세스 실패와 응답하지 않는 서비스(표 4–4 참조)를 모니터하고 특정 실패를 나타내는 오류 메시지를 기록합니다.

watcher 

여기서

sequenceNum - 로그 파일 디렉토리에 있는 다른 로그 파일과 비교하여 이 로그 파일의 생성 순서를 지정하는 정수를 지정합니다. 일련 번호가 높은 로그 파일은 이 번호가 낮은 로그 파일보다 최신 파일입니다. 일련 번호는 롤오버되지 않습니다. 즉 서버 설치부터 시작하여 서버 수명 동안 계속 증가합니다.

timeStamp - 파일 생성 날짜 및 시간을 지정하는 큰 정수를 지정합니다. 이 값은 1970년 1월 1일 자정부터 시작하여 계산한 초의 수인 표준 UNIX 시간으로 표시됩니다.

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

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

여러 로그 파일에서 메일 추적

시스템에서 메일이 전달되는 방법과 여러 로그 파일에 정보가 기록되는 시점은 아래에 설명되어 있습니다. 이러한 설명을 통해 Message Server의 로그 파일을 사용하여 문제를 해결하는 방법을 이해할 수 있습니다. 그림 8–2를 참조하십시오.

  1. 원격 호스트가 메시징 호스트의 TCP 소켓에 연결하여 SMTP 서비스를 요청합니다.

  2. MTA 디스패처가 요청에 응답하고 메시징 호스트의 SMTP 서비스에 연결을 넘겨 줍니다.

    MTA는 모듈식으로 설계되므로 Job Controller 및 SMTP 서비스 디스패처를 포함하는 일련의 프로세스로 구성됩니다. 디스패처는 받는 TCP 연결을 가져와 SMTP 서비스로 보냅니다. SMTP 서비스는 메일을 디스크의 채널 영역에 기록합니다. SMTP 서비스는 메일의 봉투 매개 변수(예: 보낸 사람 및 받는 사람)를 인식합니다. 시스템의 구성 항목에서 시스템이 속한 대상 채널을 알려줍니다.

  3. 디스패처가 스레드를 포크했고 특정 IP 주소에서 받는 연결에 대해 스레드를 사용할 수 있게 만들었다고 dispatcher.log 파일에 기록합니다.

  4. SMTP 서버가 원격 호스트에서 SMTP 서버에 연결하여 메일을 보낼 때 발생한 일에 대한 기록을 tcp_smtp_server.log 파일에 기록합니다. 이 로그 파일은 디스패처가 호스트 IP의 SMTP 서버로 보낼 때 작성됩니다.

  5. SMTP 서버가 tcp_intranet과 같은 채널 프로그램의 디스크에 있는 대기열 영역에 메일을 기록하고 Job Controller에 알립니다.

  6. Job Controller가 채널 프로그램에 연결합니다.

  7. 채널 프로그램이 메일을 전달합니다.

    채널마다 고유한 로그 파일이 있습니다. 그러나 이러한 로그에서는 일반적으로 채널의 시작 및 중지를 표시합니다. 추가 정보를 얻으려면 채널에 대한 디버그 수준을 활성화해야 합니다. 그러나 이로 인해서 시스템이 느려지고 진행 중인 문제가 더 모호해질 수 있으므로 실제 문제가 발생했을 경우에만 디버그 수준을 활성화해야 합니다.

    주 –

    효율성을 위해 채널이 기존 프로세스에 대해 이미 실행 중인 경우 시스템은 새 메일이 들어와도 새 채널 프로세스를 만들지 않습니다. 현재 실행 중인 프로세스에서 새 메일을 가져갑니다.

  8. 메일이 다른 호스트, 다른 TCP 연결 등의 다음 홉으로 전달됩니다. 이 정보는 connection.log 파일에 기록됩니다.

    SMTP 서버가 디스크의 대기열 영역에 메일을 기록하는 것과 동시에 메일을 담당하는 채널이 mail.log_current 또는 mail.log 파일에 레코드를 기록합니다. 이 레코드는 메일이 대기열에 포함된 날짜와 시간, 보낸 사람, 받는 사람 등의 정보를 보여 줍니다. 자세한 내용은 MTA 메일 로깅 예를 참조하십시오. 메일을 추적하는 데 가장 유용한 파일은 mail.log_current 파일입니다.

로깅 관리를 위한 도구

콘솔에서 configutil 명령을 사용하여 Messaging Server 로그 파일 작성 및 관리를 위한 정책을 사용자 정의할 수 있습니다.

메일 저장소 로그의 경우 콘솔을 사용하여 로그 설정을 지정하고 로그를 볼 수 있습니다. 지정하는 설정은 기록되는 이벤트 및 기록되는 이벤트의 수에 영향을 미칩니다. 로그 파일을 분석할 때 이러한 설정 및 기타 특성을 사용하여 기록되는 이벤트를 자세히 검색할 수 있습니다.

MTA는 별개의 로깅 기능을 사용하기 때문에 콘솔을 사용하여 로깅 서비스를 구성하거나 로그를 볼 수 없습니다. 대신 구성 파일에 정보를 지정하여 MTA 로깅을 구성할 수 있습니다.

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

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

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

MTA 메일 및 연결 로그 관리

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

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

자세한 내용은 MTA 로깅 활성화를 참조하십시오.

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

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

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

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

주 –

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

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

로그 항목에는 다음이 표시됩니다.

  1. 항목이 작성된 날짜와 시간(예: 19-Jan-1998 19:16:57.64)

  2. 소스 채널의 채널 이름(이 예의 경우 l)

  3. 대상 채널의 채널 이름(이 예의 경우 tcp_local)(SMTP 채널의 경우 LOG_CONNECTION이 활성화되어 있으면, 플러스 기호(+)는 SMTP 서버에 대한 인바운드를 나타내고 마이너스 기호(-)는 SMTP 클라이언트를 통한 아웃바운드를 나타냅니다.)

  4. 항목의 유형(이 예에서는 E). 표 21–2를 참조하십시오.

  5. 메일의 크기(이 예에서는 1). 기본적으로 KB로 표현되지만 MTA 옵션 파일에 BLOCK_SIZE 키워드를 사용하여 이 기본값을 변경할 수 있습니다.

  6. 봉투 From: 주소(이 예에서는 adam@sesta.com). 알림 메일과 같이 봉투 From: 주소가 비어 있는 메일의 경우에는 이 필드가 비어 있습니다.

  7. 봉투 To: 주소의 원래 형식(이 예에서는 marlowe@siroe.com)

  8. 봉투 To: 주소의 원래 형식(이 예에서는 marlowe@siroe.com)

  9. 전달 상태(SMTP 채널 전용)

다음 표에서는 로깅 항목 코드를 설명합니다.

표 21–2 로깅 항목 코드

항목 

설명 

B 

SMTP 서버로 보낸 잘못된 명령. 수신자 주소 필드에는 거부된 명령이 포함되고 진단 필드에는 SMTP 서버가 제공한 응답이 포함됩니다. MTA 채널 옵션 MAX_B_ENTRIES는 지정된 세션에 기록되는 잘못된 명령의 수를 제어합 니다. 기본값은 10입니다. 

BA 

트랜잭션 초기에 인증이 성공적으로 수행된 후의 잘못된 명령 

BS 

TLS가 성공적으로 시작된 후의 잘못된 명령 

BSA 

TLS 및 AUTH를 사용한 잘못된 명령 

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 

대기열에서 제외 시도에서 수신자 주소 거부(마스터 채널 프로그램에 의한 거부) 또는 실패/바운스 메일의 생성 

V 

트랜잭션이 비정상적으로 중지된 경우에 나타나는 경고 메시지입니다. 대기열에 포함된 수신자 주소마다 하나의 "V"가 기록됩니다. 

W 

메일이 아직 전달되지 않았지만 아직 대기열에서 시도 중에 있음을 원래 전송자에게 알려주기 위해 전송되는 경고 메일 

Z 

일부 수신자는 성공했지만 이 수신자는 일시적으로 성공하지 못했습니다. 모든 수신자의 원본 메일 파일이 대기열에서 제외되었으며 대신 이 수신자와 다른 성공하지 못한 수신자를 위한 새 메일 파일이 곧 대기열에 포함됩니다. 

SMTP 채널의 LOG_CONNECTION + 또는 - 항목 

C 

연결 끊김뒤이어 진단 필드가 표시됩니다. connection.log_current(하나의 로그 파일이 사용되는 경우에는 mail.log_current)에 작성됩니다. 연결이 끊긴 이유를 기록하는 데 사용됩니다. 특히, 연결이 끊긴 이유가 일부 세션이 연결 끊기 제한에 도달했기 때문인 경우 이 사실이 진단 필드에 표시됩니다. 

O 

연결 열림 

U 

SMTP 인증 성공 및 실패를 기록합니다. 형식은 다른 O 항목 및 C 항목의 경우와 같습니다. 특히, 응용 프로그램 필드와 전송 정보 필드가 동일한 순서로 표시됩니다. 사용자 이름이 알려져 있으면 사용자 이름 필드에 기록됩니다. LOG_CONNECTION MTA 옵션의 Bit 7(값 128)이 이를 제어합니다. 

X 

연결 거부됨 

Y 

연결이 설정되기 전에 연결 시도가 실패했음 

I 

ETRN 명령이 수신됨 

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


19-Jan-1998 13:13:27.10 HOSTA   2e2d.2.1 tcp_local   l
 E 1 service@siroe.com rfc822;adam@sesta.com
 adam 276 /imta/queue/l/ZZ01IWFY9ELGWM00094D.00
 <01IWFVYLGTS499EC9Y@siroe.com> inetmail
 siroe.com (siroe.com [192.160.253.66])

위에서 설명한 것 이외의 추가 필드는 다음과 같습니다.

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

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

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

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

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

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

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

MTA 로깅 활성화

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

Procedure특정 채널에서 MTA 로깅을 활성화하는 방법

단계

  1. imta.cnf 파일을 편집합니다.

    이 파일은 /opt/SUNWmsgsr/config 디렉토리에 있습니다.

  2. 특정 채널에 대한 로깅을 활성화하려면 logging 키워드를 채널 정의에 추가합니다. 예를 들면 다음과 같습니다.


    channel-name keyword1 keyword2 logging

    또한 로그 파일의 디렉토리 경로, 로그 수준 등의 여러 구성 매개 변수도 설정할 수도 있습니다. Message Store, Admin 및 Default 서비스 로그 관리를 참조하십시오.

Procedure모든 채널에서 MTA 로깅을 활성화하는 방법

단계

  1. imta.cnf 파일을 편집합니다.

    이 파일은 /opt/SUNWmsgsr/config 디렉토리에 있습니다.

  2. defaults 채널에 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

추가 MTA 로깅 옵션 지정

로깅이 활성화되면 기본 정보가 항상 제공될 뿐 아니라 MTA 옵션 파일에 다양한 LOG_* MTA 옵션을 구성하여 선택적 정보 필드가 추가로 포함되도록 할 수 있습니다. IMTA 조정 파일(msg_svr_base/config/imta_tailor)에서 IMTA_OPTION_FILE 옵션을 사용하여 지정한 파일에서 MTA 옵션 파일을 지정합니다. 기본적으로 이 파일은 msg_svr_base/config/option.dat입니다.

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

ProcedureMTA 로그를 syslog에 보내는 방법

단계

  1. MTA 옵션 파일을 편집합니다.

  2. LOG_MESSAGES_SYSLOG 옵션을 1로 설정합니다.

    값 0이 기본값이며 syslog(이벤트 로그) 로깅이 수행되지 않음을 나타냅니다.

Procedure로그 메일 항목을 연관시키는 방법

단계

  1. MTA 옵션 파일을 편집합니다.

  2. LOG_MESSAGE_ID 옵션을 1로 설정합니다.

    값 0이 기본값이며 메일 아이디가 mail.log 파일에 저장되지 않음을 나타냅니다.

Procedure메일 전달 재시도 횟수를 식별하는 방법

단계

  1. MTA 옵션 파일을 편집합니다.

  2. LOG_FILENAME 옵션을 1로 설정합니다.

    이 옵션을 사용하면 특정 메일 파일의 전달이 재시도된 횟수를 곧바로 쉽게 알 수 있 습니다. 또한 이 옵션을 사용하면 MTA가 여러 수신자를 대상으로 하는 메일을 디스크 상에서 개별 메일 파일 복사본으로 분할하거나 분할하지 않은 경우를 식별할 수 있습니다.

ProcedureTCP/IP 연결을 기록하는 방법

단계

  1. MTA 옵션 파일을 편집합니다.

  2. LOG_CONNECTION 옵션을 설정합니다.

    이 옵션을 사용하면 MTA는 메일 트래픽 뿐만 아니라 TCP/IP 연결을 기록합니다. 연결 로그 항목은 기본적으로 mail.log* 파일에 기록됩니다. 또는 연결 로그 항목을 connection.log* 파일에 기록할 수도 있습니다. 자세한 내용은 SEPARATE_CONNECTION_LOG 옵션을 참조하십시오.

Procedure항목을 connection.log 파일에 기록하는 방법

단계

  1. MTA 옵션 파일을 편집합니다.

  2. SEPARATE_CONNECTION_LOG 옵션을 1로 설정합니다.

    연결 로그 항목을 connection.log 파일에 대신 기록하도록 지정하려면 이 옵션을 사용합니다. 기본값 0을 사용하면 연결 로깅이 MTA 로그 파일에 저장됩니다.

Procedure프로세스 아이디로 로그 메시지를 연관시키는 방법

단계

  1. MTA 옵션 파일을 편집합니다.

  2. LOG_PROCESS 옵션을 설정합니다.

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

Procedure메일을 대기열에 포함시키는 프로세스에 연관된 사용자 아이디를 mail.log 파일에 저장 하는 방법

단계

  1. MTA 옵션 파일을 편집합니다.

  2. LOG_USERNAME 옵션을 설정합니다.

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

MTA 메일 로깅 예

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

주 –

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

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

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

MTA 로깅 예: 사용자가 보내는 메일 전송

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

예 21–1 MTA 로깅: 로컬 사용자가 보내는 메일 전송


19-Jan-1998 19:16:57.64 l            tcp_local    E 1         (1)
 adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com     (2)
 
 19-Jan-1998 19:17:01.16 tcp_local                  D 1        (3)
 adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com     (4)
 dns;thor.siroe.com
 (TCP|206.184.139.12|2788|192.160.253.66|25)                   (5)
 (THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])             (6)
 smtp;250 2.1.5 marlowe@siroe.com and options OK.              (7)

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

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

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

  4. 이것은 봉투 From: 주소, 원래 봉투 To: 주소 및 봉투 To: 지시합니다.

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

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

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

MTA 로깅 예: 옵션 로깅 필드 포함

이 예는 예 21–3과 비슷한 로깅 항목을 보여 주지만, LOG_MESSAGE_ID=1을 설정하여 파일 이름과 메일 아이디를 표시합니다. (1)과 (2)를 참조하십시오. 특히 메일 아이디를 사용하여 항목과 메일을 연관시킬 수 있습니다.

예 21–2 MTA 로깅 – 옵션 로깅 필드 포함


19-Jan-1998 19:16:57.64 l            tcp_local    E 1
  adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com
  /imta/queue/tcp_local/ZZ01ISKLSKLZLI90N15M.00
   <01ISKLSKC2QC90N15M@sesta.com>    (1)
                  
 19-Jan-1998 19:17:01.16 tcp_local                  D 1
  adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com
  /imta/queue/tcp_local/Z01ISKLSKLZLI90N15M.00
    <01ISKLSKC2QC90N15M@sesta.com>   (2)
  dns;thor.siroe.com (TCP|206.184.139.12|2788|192.160.253.66|25)
  (THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])
  smtp;250 2.1.5 marlowe@siroe.com and options OK.

MTA 로깅 예 – 목록으로 전송

이 예는 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: 주소는 각 수신자에 대해 test-list@sesta.com이라는 것에 주의합니다(현재 봉투의 To: 주소는 각각의 해당 주소임). 두 개의 별도 파일(l 채널에 대해 하나, tcp_local 채널에서 나가는 파일 하나)이 관련되어 있지만 메일 아이디는 동일하게 유지됩니다.

예 21–3 MTA 로깅 – 목록으로 전송


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.

MTA 로깅 – 존재하지 않는 도메인으로 전송

이 예는 존재하지 않는 도메인(여기에서는 very.bogus.comcom)으로의 전송 시도를 보여 줍니다. 즉, 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)의 대기열에 포함됩니다.

예 21–4 MTA 로깅 – 존재하지 않는 도메인으로 전송


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>

MTA 로깅 예 – 존재하지 않는 원격 사용자에게 전송

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

예 21–5 MTA 로깅 – 존재하지 않는 원격 사용자에게 전송 


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>

MTA 로깅 예 – 원격측의 메일 제출 시도 거부

이 예는 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에게 중계는 시도는 거부됩니다.

예 21–6 MTA 로깅 – 원격측의 메일 제출 시도 거부


28-May-1998 12:02:23 tcp_local            J 0               (1)
 harold@varrius.com rfc822; alan@very.bogus.com             (2)
 550 5.7.1 Relaying not permitted: alan@very.bogus.com      (3)

  1. 이 로그는 MTA가 원격측의 메일 제출 시도를 거부한 날짜와 시간을 보여 줍니다. 거부는 J 레코드에서 표시합니다. MTA 채널이 거부된 메일을 전송하려고 시도하는 경우는 예 21–4 및 예 21–5에서 볼 수 있는 것처럼 R 레코드에서 표시합니다.

    주 –

    로그에 기록된 마지막 J 레코드에는 지정된 세션에 대한 마지막 레코드라는 표시가 있습니다. 또한 현재 버전의 Messaging Server에서는 J 레코드 수에 제한이 없습니다.

  2. 시도된 봉투의 From: 및 To: 주소가 표시됩니다. 이 경우 원래 봉투의 To: 정보를 사용할 수 없으므로 해당 필드가 비어 있습니다.

  3. 해당 항목에는 MTA가 원격측(전송을 시도한 보낸 사람)에게 발행한 SMTP 오류 메시지가 포함됩니다.

MTA 로깅 예 – 복수 전달 시도

이 예는 첫 번째 시도에서 메일을 배달을 할 수 없어서 MTA가 메일 전송을 여러 번 시도한 경우의 로그 파일 항목입니다. 이 예에서는 옵션을 LOG_FILENAME=1 및 LOG_MESSAGE_ID=1로 설정한 것으로 가정합니다.

예 21–7 MTA 로깅 – 복수 전달 시도


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

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

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

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

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

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

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

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

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

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

MTA 로깅 – 변환 채널을 통해 라우팅된 받는 SMTP 메일

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

CONVERSIONS
  IN-CHAN=tcp_local;OUT-CHAN=l;CONVERT   Yes

이 예에서는 옵션을 LOG_FILENAME=1 및 LOG_MESSAGE_ID=1로 설정한 것으로 가정합니다.

예 21–8 MTA 로깅 – 변환 채널을 통해 라우팅된 받는 SMTP 메일


04-Feb-1998 00:06:26.72 tcp_local    conversion   E 9      (1)
  amy@siroe.edu rfc822;bert@sesta.com bert@sesta.com
  imta/queue/conversion/ZZ01IT5UAMZ4QW98518O.00
  <01IT5UALL14498518O@siroe.edu>
 
 04-Feb-1998 00:06:29.06 conversion   l            E 9     (2)
                   amy@siroe.edu rfc822;bert@sesta.com bert
  imta/queue/l/ZZ01IT5UAOXLDW98509E.00  <01IT5STUMUFO984Z8L@siroe.edu>
 
04-Feb-1998 00:06:29.31 conversion                D 9      (3)
 amy@siroe.edu rfc822;bert@sesta.com bert
 imta/queue/conversion/ZZ01IT5UAMZ4QW98518O.00
 <01IT5UALL14498518O@siroe.edu>
 
 04-Feb-1998 00:06:32.62 l                         D 9     (4)
  amy@siroe.edu rfc822;bert@siroe.com bert
  imta/queue/l/ZZ01IT5UAOXLDW98509E.00
  <01IT5STUMUFO984Z8L@siroe.edu>

  1. 외부 사용자 amy@siroe.edu가 보낸 메일은 l 채널 수신자 bert@sesta.com으로 주소 지정됩니다. 하지만 CONVERSIONS 매핑 항목 때문에 메일은 초기에 변환 채널의 대기열에 포함됩니다(l 채널로 직접 전송되지 않음).

  2. 변환 채널이 실행되고 메일을 l 채널 대기열에 포함시킵니다.

  3. 그런 다음에는 변환 채널이 메일을 대기열에서 제외할 수 있습니다(오래된 메일 파일 삭제).

  4. 그리고 마지막으로 l 채널이 메일을 대기열에서 제외(전달)합니다.

MTA 로깅 예: 아웃바운드 연결 로깅

이 예는 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 수신자는 다른 메일 파일에 저장됩니다.

예 21–9 MTA 로깅: 아웃바운드 연결 로깅


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

  1. 메일이 첫 번째 수신자의 대기열에

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

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

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

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

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

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

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

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

MTA 로깅 예: 인바운드 연결 로깅

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

예 21–10 MTA 로깅 – 인바운드 연결 로깅


19-Feb-1998 17:02:08.70 tcp_local    +            O          (1)
 TCP|206.184.139.12|25|192.160.253.66|1244 SMTP              (2)

19-Feb-1998 17:02:26.65 tcp_local    l             E 1
 service@siroe.com rfc822;adam@sesta.com adam
 THOR.SIROE.COM (THOR.SIROE.COM [192.160.253.66])            (3)

 19-Feb-1998 17:02:27.05 tcp_local    +             C        (4)
                   TCP|206.184.139.12|25|192.160.253.66|1244 SMTP
 
19-Feb-1998 17:02:31.73 l                          D 1
  service@siroe.com rfc822;adam@sesta.com adam

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

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

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

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

디스패처 디버깅 활성화

디스패처 오류 및 디버깅 출력(활성화된 경우)은 MTA 로그 디렉토리의 dispatcher.log 파일에 기록됩니다. 디스패처 구성 정보는 msg_svr_base/imta/ dispatcher.cnf 파일에 지정됩니다. 기본 구성 파일은 설치 시 작성되며 변경 없이 사용할 수 있습니다. 그러나 보안이나 성능상의 이유로 기본 구성 파일을 수정하려는 경우 dispatcher.cnf 파일을 편집하여 원하는 사항을 수정할 수 있습니다.

표 21–3 디스패처 디버깅 비트

비트 

 

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 거부 기록 

Procedure디스패처 오류 디버깅 출력을 활성화하는 방법

단계

  1. dispatcher.cnf 파일을 편집합니다.

  2. DEBUG 옵션을 -1로 설정합니다.

    또한 32비트 디버그 마스크를 16진수로 정의하는 논리 또는 환경 변수 IMTA_DISPATCHER_DEBUG(UNIX)를 FFFFFFFF 값으로 설정할 수 있습니다. 위의 표에는 각 비트의 의미가 설명되어 있습니다.

Procedure디스패처 매개 변수 설정 방법(Solaris)

디스패처 구성 파일에서 제공되는 디스패처 서비스는 다양한 시스템 매개 변수의 요구 사항에 영향을 미칩니다. 시스템의 힙 크기(datasize)는 디스패처의 스레드 스택을 사용하기에 충분해야 합니다.

단계

  1. 힙 크기(기본 datasize)를 표시하려면 다음 중 하나를 사용합니다.

    csh 명령


    # limit

    ksh 명령


    # ulimit -a

    Solaris 유틸리티


    # sysdef

  2. 각 디스패처 서비스에 대해 STACKSIZE*MAX_CONNS를 계산한 다음 각 서비스에 대해 계산된 값을 모두 더합니다. 시스템의 힙 크기는 이 숫자의 두 배 이상이 되어야 합니다.

Message Store, Admin 및 Default 서비스 로그 관리

이 절에서는 Message Store(POP, IMAP 및 HTTP), Admin 및 Default 서비스에 대한 로깅을 설명합니다. 표 21–1을 참조하십시오.

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

이 절에는 다음과 같은 하위 절이 포함됩니다.

서비스 로그 특징 이해

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

로깅 수준

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

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

표 21–4 저장소 및 관리 서비스의 로깅 수준

수준 

설명 

Critical 

최소의 로깅 세밀도입니다. 서버 문제 또는 중요한 조건이 발생(예: 서버가 메일함에 액세스할 수 없거나 서버를 실행하려면 라이브러리가 필요한 경우)할 때마다 이벤트가 로그에 기록됩니다. 

Error 

오류 조건(예: 클라이언트나 다른 서버에 대한 연결 시도가 실패한 경우)이 발생할 때마다 이벤트가 로그에 기록됩니다. 

Warning 

경고 조건이 발생할 때마다(예: 클라이언트가 보낸 통신을 서버가 인식할 수 없는 경우) 이벤트가 로그에 기록됩니다. 

Notice 

알림(일반적이지만 중요한 조건)이 발생할 때마다(예: 사용자 로그인 실패 또는 세션 종료시) 이벤트가 로그에 기록됩니다. 이는 기본 로그 수준입니다. 

Information 

수행되는 모든 중요 작업(예: 사용자가 성공적으로 로그온했거나 메일함을 만들거나 메일함 이름을 변경한 경우)에 대한 이벤트를 로그에 기록합니다. 

Debug 

가장 세밀한 로깅입니다. 디버깅 용도에만 적합합니다. 문제를 나타내기 위해 각 프로세스나 작업 내의 개별 단계에서 이벤트가 로그에 기록됩니다.  

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

주 –

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

기록되는 이벤트의 범주

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

표 21–5 로그 이벤트가 발생하는 범주

기능 

설명 

일반적인 문제 

이 프로토콜 또는 서비스에 관련된 구분되지 않은 작업입니다. 

LDAP 

LDAP 디렉토리 데이터베이스에 액세스하는 Messaging Server에 관련된 작업입니다. 

Network 

네트워크 연결에 관련된 작업(소켓 오류가 이 범주에 속함)입니다.  

Account 

사용자 계정에 관련된 작업(사용자 로그인이 이 범주에 속함)입니다. 

Protocol 

프로토콜별 명령에 관련된 프로토콜 수준 작업(POP, IMAP 또는 HTTP 기능에서 반환되는 오류가 이 범주에 속함)입니다. 

Stats 

서버 통계의 수집에 관련된 작업입니다. 

저장소 

메일 저장소 액세스에 관련된 낮은 수준의 작업(읽기/쓰기 오류가 이 범주에 속함)입니다. 

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

서비스 로그 파일 디렉토리

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

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

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

서비스 로그 파일 형식 이해

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

dateTime hostName processName[pid]: category logLevel: eventMessage

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

표 21–6 저장소 및 관리 로그 파일 구성 요소

구성 요소 

정의 

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)입니다(예 21–5 참조).

logLevel

이벤트가 표시되는 로깅 수준(예: Notice)입니다(예 21–4 참조).

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

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

서비스 로깅 옵션 정의 및 설정

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

유연한 로깅 구조

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

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

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

원하는 옵션 계획

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

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

디렉토리의 최대 로그 파일 수: 10

최대 로그 파일 크기: 2MB

모든 로그 파일에 허용되는 총 최대 크기: 20MB

허용되는 빈 디스크 최대 공간: 5MB

로그 롤오버 시간: 1일

만료 전 최대 수명: 7일

로깅 수준: Notice

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

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

로깅 옵션 이해

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

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

서비스 로그 검색 및 보기

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

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

검색 매개 변수

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

* 모든 문자 세트(예: *.com)

? 모든 단일 문자(예: 199?)

[nnn] nnn 집합에 속하는 모든 문자(예: [aeiou])

[^nnn] nnn 집합에 속하지 않는 모든 문자(예: [^aeiou] )

[n-m] n-m 범위의 모든 문자(예: [A-Z])

[^n-m] n-m 범위에 속하지 않는 모든 문자(예: [^0-9] )

\ 이스케이프 문자: *, ?, [ 또는 ] 앞에 입력하여 리터럴로 사용

주: 검색은 대소문자를 구분합니다.

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

서비스 로그 작업

이 절에서는 configutil 명령과 로그 검색 및 보기를 위한 콘솔을 사용하여 서비스 로그에 대한 작업을 수행하는 방법에 대해 설명합니다.

Procedure서비스 로그를 syslog에 전송하는 방법

단계

    configutil 명령을 syslogfacility 옵션과 함께 실행합니다.

    configutil -o logfile. service.syslogfacility -v value

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

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

Procedure콘솔을 사용하여 로깅 옵션을 설정하는 방법

단계

  1. 로그 파일 옵션을 설정할 Messaging Server를 엽니다.

  2. 구성 탭을 누르고 왼쪽 창에서 Log Files 폴더를 연 다음 서비스(IMAP, HTTP 또는 Admin 등)의 로그 파일을 선택합니다.

  3. “세부 정보 수준” 드롭다운 목록에서 로깅 수준을 선택합니다.

  4. “로그 파일에 대한 디렉토리 경로” 필드에서 로그 파일을 저장할 디렉토리의 이름을 입력합니다.

  5. “각 로그의 파일 크기” 필드에 최대 로그 파일 크기를 입력합니다.

  6. “다음 경우마다 새 로그 만들기” 필드에 로그 회전 일정 수를 입력합니다.

  7. “디렉토리당 로그 수” 필드와 “로그 최대 기간” 필드에 백업 일정에 맞는 최대 로그 파일 수와 최대 수명을 입력합니다.

  8. “총 로그 크기 초과” 필드에 원하는 총 저장소 제한을 입력합니다.

  9. “빈 디스크 공간 부족” 필드에 유지할 빈 디스크 공간의 최소 크기를 입력합니다.

HTTP 로깅 비활성화 방법

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

Procedure서버 로그 수준을 설정하는 방법

단계

    다음 configutil 명령을 실행합니다.

    configutil -o logfile.service.loglevel -v level

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

Procedure서버 로그 파일의 디렉토리 경로를 지정하는 방법

단계

    다음 configutil 명령을 실행합니다.


    configutil -o logfile.service.logdir -v dirpath

Procedure각 서비스 로그의 최대 파일 크기를 지정하는 방법

단계

    다음 configutil 명령을 실행합니다.


    configutil -o logfile.service.maxlogfilesize -v size

    여기서 size는 바이트 수를 지정합니다.

Procedure서비스 로그 회전 일정을 지정하는 방법

단계

    다음 configutil 명령을 실행합니다.


    configutil -o logfile.service.rollovertime -v number

    여기서 number는 초를 지정합니다.

Procedure디렉토리당 서비스 로그 파일의 최대 수를 지정하는 방법

단계

    다음 configutil 명령을 실행합니다.


    configutil -o logfile.service.maxlogfiles -v number

    여기서 number는 로그 파일의 최대 수를 지정합니다.

Procedure저장소 제한을 지정하는 방법

단계

    다음 configutil 명령을 실행합니다.


    configutil -o logfile.service.maxlogsize -v number

    여기서 number는 바이트 수를 지정합니다.

Procedure유지할 빈 디스크 공간의 최소 크기를 지정하는 방법

단계

    다음 configutil 명령을 실행합니다.


    configutil -o logfile.service.minfreediskspace -v number

    여기서 number는 바이트 수를 지정합니다.

로그 파일이 만료되는 시기를 지정하는 방법


configutil -o logfile.service.expirytime -v number

여기서 number는 초를 지정합니다.

Procedure검색 및 보기 결과를 지정하는 방법

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

단계

  1. 콘솔에서 검사할 로그 파일이 있는 Messaging Server를 엽니다.

  2. 다음 단계 중 하나를 수행하여 기록되는 해당 서비스에 대한 로그 파일 내용 탭을 표시합니다.

    • 작업 탭을 누른 다음 “서비스 로그 보기”를 누릅니다. 여기서 서비스는 기록되는 서비스(예: “IMAP 서비스” 또는 “관리” 등)의 이름입니다.

    • 구성 탭을 누른 다음 왼쪽 창에서 Log Files 폴더를 연 다음 서비스(예: IMAP 또는 Admin)의 로그 파일을 선택합니다. 그런 다음 오른쪽 창에서 내용 탭을 누릅니다.

  3. 기록된 해당 서비스의 내용 탭이 표시됩니다.

  4. 로그 파일 이름 필드에서 검사할 로그 파일을 선택합니다.

  5. 선택한 로그 보기 버튼을 눌러 로그 뷰어 창을 엽니다.

  6. 로그 뷰어 창에서 원하는 검색 매개 변수(앞의 검색 매개 변수 절에서 설명)를 지정합니다.

  7. 업데이트를 눌러 검색을 수행한 다음 그 결과를 로그 항목 필드에 표시합니다.

메시지 저장소 로깅에 메일 추적 사용

MTA가 메일을 추적하는 것과 비슷한 방법으로 메시지 저장소 로깅을 사용하여 메일 아이 디로 메일을 추적할 수 있습니다. 이 방식으로 메일을 추적하면 메일의 수명 주기의 중요 이벤트를 추적할 수 있습니다.

메시지 저장소 로그의 메일을 추적하려면 일반 로깅 구성 외에도 메일 추적을 구성해야 합니다. 기본적으로 메일 추적은 활성화되지 않습니다.

주 –

메일 추적에는 많은 양의 디스크 공간이 필요합니다. 디스크 공간이 충분하지 않을 경우 이 기능을 활성화하지 마십시오.

메시지 저장소 로깅에서는 다음 작업을 추적할 수 있습니다.

Procedure메일 추적을 활성화하는 방법

단계

    다음 configutil 명령을 실행합니다.


    configutil -o local.msgrace.active -v “yes”

    메일 추적 정보는 각 프로세스의 기본 로그에 기록됩니다. IMAP 가져오기는 imap 로그 파일에 표시됩니다. ims_master 추가는 ims_master 채널 로그 파일에 표시됩니다.

Procedure메일 추적을 단일 로그 파일로 리디렉션하는 방법

단계

    메일 추적 로깅을 단일 “msgtrace” 로그 파일로 리디렉션하려면 configutil 명령을 사용하여 로그 파일 매개 변수를 구성해야 합니다. 다른 로그 파일과 달리 msgtrace 로그 파일은 로컬로 구성됩니다. 예를 들면 다음과 같습니다.


    configutil -o "local.logfile.msgtrace.buffersize" -v "0"
configutil -o "local.logfile.msgtrace.expirytime" -v "604800"
configutil -o "local.logfile.msgtrace.flushinterval" -v "60"
configutil -o "local.logfile.msgtrace.logdir" -v "/opt/SUNWmsgsr/data/log"
configutil -o "local.logfile.msgtrace.loglevel" -v "Information"
configutil -o "local.logfile.msgtrace.logtype" -v "NscpLog"
configutil -o "local.logfile.msgtrace.maxlogfiles" -v "10"
configutil -o "local.logfile.msgtrace.maxlogfilesize" -v "2097152"
configutil -o "local.logfile.msgtrace.maxlogsize" -v "20971520"
configutil -o "local.logfile.msgtrace.minfreediskspace" -v "5242880"
configutil -o "local.logfile.msgtrace.rollovertime" -v "86400"

Procedure메일 추적 로깅을 구성 해제하는 방법

단계

    msgtrace 로그 파일을 구성 해제하려면 configutil 명령을 사용하여 해당 구성에 대한 모든 참조를 제거합니다. 예를 들면 다음과 같습니다.


    configutil -o "local.logfile.msgtrace.buffersize" -v ""
configutil -o "local.logfile.msgtrace.expirytime" -v ""
configutil -o "local.logfile.msgtrace.flushinterval" -v ""
configutil -o "local.logfile.msgtrace.logdir" -v ""
configutil -o "local.logfile.msgtrace.loglevel" -v ""
configutil -o "local.logfile.msgtrace.logtype" -v ""
configutil -o "local.logfile.msgtrace.maxlogfiles" -v ""
configutil -o "local.logfile.msgtrace.maxlogfilesize" -v ""
configutil -o "local.logfile.msgtrace.maxlogsize" -v ""
configutil -o "local.logfile.msgtrace.minfreediskspace" -v ""
configutil -o "local.logfile.msgtrace.rollovertime" -v ""

ProcedureLMTP 로깅을 구성하는 방법

단계

    LMTP를 사용하고 단일 “msgtrace” 로그 파일을 사용하지 않을 경우에는 마찬가지로 tcp_lmtp_server 로그 파일을 로컬로 구성해야 합니다. LMTP를 사용하지 않거나, 메일 추적을 사용하지 않거나, “msgtrace” 로그 파일에서 메일 추적을 사용할 경우에는 LMTP 메시지 저장소측 로그를 초기화할 필요가 없습니다. LMTP는 이미 MTA 정보를 별도로 기록합니다. 예를 들면 다음과 같습니다. 


    configutil -o "local.logfile.tcp_lmtp_server.buffersize" -v "0"
configutil -o "local.logfile.tcp_lmtp_server.expirytime" -v "604800"
configutil -o "local.logfile.tcp_lmtp_server.flushinterval" -v "60"
configutil -o "local.logfile.tcp_lmtp_server.logdir" -v \
   "/opt/SUNWmsgsr/data/log"
configutil -o "local.logfile.tcp_lmtp_server.loglevel" -v "Information"
configutil -o "local.logfile.tcp_lmtp_server.logtype" -v "NscpLog"
configutil -o "local.logfile.tcp_lmtp_server.maxlogfiles" -v "10"
configutil -o "local.logfile.tcp_lmtp_server.maxlogfilesize" -v "2097152"
configutil -o "local.logfile.tcp_lmtp_server.maxlogsize" -v "20971520"
configutil -o "local.logfile.tcp_lmtp_server.minfreediskspace" \
   -v "5242880"
configutil -o "local.logfile.tcp_lmtp_server.rollovertime" -v "86400"

메시지 저장소 로깅 예

메시지 저장소 로그 파일에 기록되는 정확한 필드 형식 및 필드 목록은 설정하는 로깅 옵션에 따라 다릅니다. 이 기능은 클라이언트 문제를 디버깅하는 데 유용합니다. 예를 들어, 사용자가 메일 액세스 클라이언트가 제대로 작동하지 않는다고 불평할 경우 이 기능을 사용하여 액세스 클라이언트와 Messaging Server 사이의 상호 작용을 추적할 수 있습니다. 원격 측정을 사용하여 사용자 IMAP/POP 세션 검사를 참조하십시오.

메일 저장소 로깅 예

메일 저장소 로그 파일에 기록되는 정확한 필드 형식 및 필드 목록은 설정하는 로깅 옵션에 따라 다릅니다. 이 절에서는 일반적인 로그 항목의 몇 가지 예를 보여 줍니다.

메시지 저장소 로깅 예: 잘못된 비밀 번호

사용자가 잘못된 비밀번호를 입력하면 “user not found” 메시지와 달리 “인증” 실패가 기록됩니다. 보안상의 이유 때문에 “user not found” 메시지가 클라이언트에게 전달되지만 기록되는 것은 실제 이유(잘못된 비밀번호)입니다.

예 21–11 메시지 저장소 로깅 – 잘못된 비밀번호


 [30/Aug/2004:16:53:05 -0700] vadar imapd[13027]: Account Notice: badlogin:
[192.18.126.64:40718] plaintext user1 authentication failure

메시지 저장소 로깅 – 비활성화된 계정

다음 예는 비활성화된 계정으로 인해 사용자가 로그인할 수 없는 이유를 보여 줍니다. 또한 비활성화된 계정이 “(inactive)” 또는 “(hold)”로 구분됩니다.

예 21–12 메시지 저장소 로깅 – 비활성화된 계정


[30/Aug/2004:16:53:31 -0700] vadar imapd[13027]: Account Notice: badlogin: 
[192.18.126.64:40720] plaintext user3 account disabled (hold)

메시지 저장소 로깅 예: 추가된 메일

다음 예는 메일이 폴더에 추가될 때마다 발생하는 추가 메시지를 보여 줍니다. 메시지 저장소 로그는 ims_master 및 lmtp 채널을 통해 메시지 저장소에 들어오는 모든 메일을 기록합니다. 사용자 아이디, 폴더, 메일 크기 및 메일 아이디의 “추가”가 기록됩니다.

예 21–13 메시지 저장소 로깅 – 추가


[31/Aug/2004:16:33:14 -0700] vadar ims_master[13822]: Store Information:append:
user1:user/user1:659:<Roam.SIMC.2.0.6.1093995286.11265.user1@vadar.siroe.com>

메시지 저장소 로깅 예: 클라이언트가 검색한 메일

클라이언트가 메일을 검색하면 메시지 저장소 로그는 “가져오기” 메시지를 기록합니다. 메시지 저장소 로그는 하나 이상의 본문 부분에 대한 클라이언트의 모든 가져오기를 기록합니다. 사용자 아이디, 폴더 및 메일 아이디의 “가져오기”가 기록됩니다.

예 21–14 메시지 저장소 로깅 – 클라이언트가 검색한 메일 


[31/Aug/2004:15:55:26 -0700] vadar imapd[13729]: Store Information:
fetch:user1:user/user1:<Roam.SIMC.2.0.6.1093051161.3655.user1@vad.siroe.com>

메시지 저장소 로깅 예: 폴더에서 제거된 메일

예 21–15 메시지 저장소 로깅 예: 폴더에서 제거된 메일

IMAP 또는 POP 메일이 폴더에서 제거되지만 시스템에서는 제거되지 않을 경우 메시지 저장소는 “정리” 메시지를 기록합니다. 이 메시지는 사용자가 정리하든 유틸리티가 정리하든 상관없이 기록됩니다. 폴더 및 메일 아이디의 “정리”가 기록됩니다.


31/Aug/2004:16:57:36 -0700] vadar imexpire[13923]: Store Information:
expunge:user/user1:<Roam.SIMC.2.0.6.1090458838.2929.user1@vadar.siroe.com>

메시지 저장소 로깅 예: 중복된 로그인 메시지

하나의 msgtrace 로그 파일에 대해 메일 추적을 구성할 경우 imap 및 pop 로그 파일에 표시되는 일반 “로그인” 메시지가 msgtrace 파일에서 중복됩니다. 일반 로그인 메시지는 다음과 같습니다.

예 21–16 메시지 저장소 로깅 – 로그인


[30/Aug/2004:16:53:13 -0700] vadar imapd[13027]: Account Information: login
[192.18.126.64:40718] user1 plaintext