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

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 로깅 항목 코드

항목 

설명 

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

BA 

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

BS 

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

BSA 

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

대기열에서 제외 성공 

DA 

SASL(인증)을 사용한 대기열에서 제외 성공 

DS 

TLS(보안)를 사용한 대기열에서 제외 성공 

DSA 

TLS 및 SASL(보안 및 인증)을 사용한 대기열에서 제외 성공 

대기열에 포함 

EA 

SASL(인증)을 사용한 대기열에 포함 성공 

ES 

TLS(보안)를 사용한 대기열에 포함 성공 

ESA 

TLS 및 SASL(보안 및 인증)을 사용한 대기열에 포함 성공 

대기열에 포함 시도 거부(슬레이브 채널 프로그램에 의한 거부) 

수신자 메일 거부됨. 보낸 사람이 NOTIFY=NEVER DSN 플래그 설정을 요청하거나 메일이 시간 초과하거나 메일을 수동으로 반환하는 경우(예: imsimta qm “delete” 명령은 각 수신자에 대해 항상 “K” 레코드를 생성하고 qm “return” 명령은 “R” 레코드 대신 “K” 레코드 생성). 보낸 사람의 요청에 따라 보낸 사람에게 알림을 보내지 않았음을 나타냅니다.

rejection/time-out과 동일한 종류이지만 실패한 메일에 대한 새 알림 메일(원래의 보낸 사람에게 보냄)이 생성되는 “R” 레코드와 비교될 수 있습니다. 

대기열에서 제외 일시적으로 실패 

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

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

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

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

SMTP 채널의 LOG_CONNECTION + 또는 - 항목 

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

연결 열림 

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

연결 거부됨 

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

ETRN 명령이 수신됨 

MTA 옵션 파일에서 LOG_CONNECTION, LOG_FILENAME, LOG_MESSAGE_ID, LOG_NOTARY, LOG_PROCESSLOG_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 ReferenceOption 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_PROCESSLOG_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=1LOG_CONNECTION=1을 활성화하여 여러 수신자에게 전송하는 예를 보여 줍니다. 여기서 사용자 adam@sesta.com은 MTA 메일 목록 test-list@sesta.com으로 전송하였고 이 메일 목록은 bob@sesta.com, carol@varrius.comdavid@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=1LOG_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=1LOG_MESSAGE_ID=1이고 채널 옵션 설정이 LOG_BANNER=1LOG_TRANSPORTINFO=1인 것으로 가정합니다. (1)에 있는 거부 항목 (R)에 주의하십시오. 하지만 예 21–4의 거부 항목과는 대조적으로 여기에 있는 거부 항목은 원격 시스템으로 연결되었음을 보여주고 원격 SMTP 서버, (2) 및 (3)에 의해 발생한 SMTP 오류 코드를 보여줍니다. (2)에 있는 정보가 포함된 이유는 채널 옵션이 LOG_BANNER=1LOG_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=1LOG_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=1LOG_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=1LOG_FILENAME=1이라고 가정합니다. 이 예는 사용자 adam@sesta.com이 세 명의 수신자(bobby@hosta.sesta.com, carl@hosta.sesta.comdave@hostb.sesta.com)에게 같은 메일을 보내는 경우를 보여 줍니다(각 메일 사본의 메일 아이디는 동일함). 이 예에서는 일반적으로 채널이 그러하듯이 single_sys 채널 키워드로 표시된 tcp_local 채널로 메일이 나가는 것으로 가정합니다. 따라서 (1), (2), (3)에서 볼 수 있듯이 각 수신자 집합에 대해 별도의 메일 파일이 디스크에 별도의 호스트 이름으로 생성됩니다. 여기서 bobby@hosta.sesta.comcarl@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.comhostb.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진수 값 

사용 

 

x 00001 

기본 서비스 디스패처 주 모듈 디버깅 

x 00002 

추가 서비스 디스패처 주 모듈 디버깅 

x 00004 

서비스 디스패처 구성 파일 로깅 

x 00008 

기본 서비스 디스패처 기타 디버깅 

x 00010 

16 

기본 서비스 디버깅 

x 00020 

32 

추가 서비스 디버깅 

x 00040 

64 

프로세스 관련 서비스 디버깅 

x 00080 

128 

사용되지 않습니다. 

x 00100 

256 

기본 서비스 디스패처 및 프로세스 통신 디버깅 

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를 계산한 다음 각 서비스에 대해 계산된 값을 모두 더합니다. 시스템의 힙 크기는 이 숫자의 두 배 이상이 되어야 합니다.