MTA 문제 해결 예

이 절에서는 특정 MTA 문제를 단계적으로 해결하는 방법에 대해 설명합니다. 이 예에서 메일을 받는 사람은 전자 메일의 첨부 파일을 받지 못했습니다. 주: MIME 프로토콜 용어와 동일하게 이 절에서는 "첨부 파일"을 "메일 부분"이라고 합니다. 앞서 말한 문제 해결 기술은 메일 부분이 사라진 위치 및 이유를 확인하기 위해 사용됩니다( 표준 MTA 문제 해결 절차 참조). 다음 단계를 사용하면 MTA를 통해 메일이 거쳐간 경로를 확인할 수 있습니다. 또한 메일이 메일 대기열에 들어가기 전이나 후에 사라졌는지 여부를 확인할 수 있습니다. 이렇게 하려면 채널을 수동으로 중지 및 실행하여 관련 파일을 캡처해야 합니다.

채널을 통해 메일을 수동으로 실행하는 경우에는 Job Controller가 실행 중이어야 합니다.

메일 경로에서 채널 확인

메일 경로에 어떤 채널이 있는지 확인하면 master_debug 및 slave_debug 키워드를 해당 채널에 적용할 수 있습니다. 이 키워드는 채널의 마스터 및 슬레이브 로그 파일에서 디버깅 출력을 생성하고 마스터 및 슬레이브 디버깅 정보는 메일 부분이 사라진 지점을 확인하는 데 도움을 줍니다.

1. log_message_id=1을 /msg_svr_base/config. 디렉토리의 option.dat 파일에 추가합니다. 이 매개 변수와 함께 message ID: 헤더 행이 mail.log_current 파일에 표시됩니다.

2. imsimta cnbuild를 실행하여 구성을 다시 컴파일합니다.

3. imsimta restart dispatcher를 실행하여 SMTP 서버를 다시 시작합니다.

4. 최종 사용자가 메일 부분이 있는 메일을 재전송하도록 합니다.

5. 메일이 통과하는 채널을 결정합니다.

   채널을 확인할 수 있는 방법은 많지만 다음 방법을 사용하는 것이 좋습니다.

   1. UNIX 플랫폼의 경우 grep 명령을 사용하여 /msg_svr_base/log 디렉토리의 mail.log_current 파일에서 message ID: 헤더 행을 찾습니다.

   2. message ID: 헤더 행을 찾은 경우 대기열에 포함 및 대기열에서 제외 레코드를 찾아 메일 경로를 확인합니다. 로깅 입력 코드에 대한 자세한 내용은 MTA 로그 항목 형식 이해를 참조하십시오. 그 예는 다음 E 및 D 레코드를 참조하십시오.

      29-Aug-2001 10:39:46.44 tcp_local conversion E 2 ... 29-Aug-2001 10:39:46.44 conversion tcp_intranet E 2 ... 29-Aug-2001 10:39:46.44 tcp_intranet D 2 ...

왼쪽에 있는 채널이 소스 채널이고 오른쪽에 있는 채널이 대상 채널입니다. 이 예에서 E 및 D 레코드는 메일 경로가 tcp_local 채널에서 conversion 채널로 이동한 다음 최종적으로 tcp_intranet 채널로 이동했음을 나타냅니다.

수동으로 채널을 시작 및 중지하여 데이터 수집

이 절에서는 채널을 수동으로 시작 및 중지하는 방법에 대해 설명합니다. 자세한 내용은 개별 채널 시작 및 중지를 참조하십시오. 메일 경로에서 채널을 수동으로 시작 및 중지하면 MTA 프로세스의 각 단계에서 메일 및 로그 파일을 저장할 수 있습니다. 이 파일은 나중에 메일 정지 지점 확인 방법에 사용됩니다.

수동으로 채널을 시작 및 중지하는 방법

단계

1. 실질적인 디버깅 정보를 제공하려면 mm_debug=5를 /msg_svr_base/config 디렉토리의 option.dat 파일에 설정합니다.

2. slave_debug 및 master_debug 키워드를 /msg_svr_base/config 디렉토리에 있는 imta.cnf 파일의 해당 채널에 추가합니다.

   1. 메일 부분이 있는 메일을 보내는 원격 시스템에서 인바운드 채널(또는 초기 대화 중에 메일이 전환되는 모든 채널)에 slave_debug 키워드를 사용합니다. 이 예에서 slave_debug 키워드는 tcp_local 채널에 추가됩니다.

   2. 메일이 통과되고 메일 경로에서 채널 확인에서 확인된 다른 채널에 master_debug 키워드를 추가합니다. 이 예에서 master_debug 키워드는 conversion 및 tcp_intranet 채널에 추가됩니다.

   3. imsimta restart dispatcher 명령을 실행하여 SMTP 서버를 다시 시작합니다.

3. imsimta qm stop 및 imsimta qm start 명령을 사용하여 특정 채널을 수동으로 시작 및 중지합니다. 이 키워드 사용에 대한 자세한 내용은 개별 채널 시작 및 중지를 참조하십시오.

4. 메일 파일을 캡처하는 프로세스를 시작하려면 최종 사용자가 메일 부분이 있는 메일을 재전송하도록 합니다.

5. 메일이 채널에 입력될 때 imsimta qm stop 명령에 의해 중지된 경우에는 채널에서 메일이 중지됩니다. 자세한 내용은 단계 3을 참조하십시오.

   1. 메일 경로에서 다음 채널을 수동으로 실행하기 전에 메일 파일을 복사하고 이름을 바꿉니다. 다음 UNIX 플랫폼 예를 참조하십시오.

      # cp ZZ01K7LXW76T7O9TD0TB.00 ZZ01K7LXW76T7O9TD0TB.KEEP1

      일반적으로 메일 파일은 /msg_svr_base/data/queue/destination_channel/001과 유사한 디렉토리에 상주합니다. destination_channel은 메일이 다음으로 통과(tcp_intranet 등)하는 채널입니다. 하위 디렉토리(001, 002 등)를 destination_channel 디렉토리에 만들려면 채널에 subdirs 키워드를 추가합니다.

   2. 메일이 처리된 순서를 확인하려면 메일을 트랩 및 복사할 때마다 메일 확장자에 번호를 지정하는 것이 좋습니다.

6. 채널에서 메일 처리를 계속하고 메일 경로에서 다음 대상 채널로 대기열에 포함합니다. 이 작업을 수행하려면 imsimta qm start 명령을 사용합니다.

7. /msg_svr_base/log 디렉토리에 있는 해당 채널 로그 파일(예: tcp_intranet_master.log-*)을 복사하여 저장합니다. 추적하는 메일에 대한 데이터를 가진 해당 로그 파일을 선택합니다. 복사한 파일을 채널에 넣을 때 해당 메일의 타임스탬프 및 제목 헤더와 일치하도록 합니다. tcp_intranet_master.log-*의 예에서는 파일이 삭제되지 않도록 파일을 tcp_intranet_master.keep로 저장할 수 있습니다.

8. 메일이 해당 최종 대상에 도달할 때까지 단계 5 - 7을 반복합니다.

   단계 7에서 복사한 로그 파일은 단계 5에서 복사한 메일 파일과 상관 관계가 있어야 합니다. 예를 들어, 누락된 메일 부분 시나리오에서 모든 채널을 중지한 경우 conversion_master.log-* 및 tcp_intranet_master.log-* 파일을 저장합니다. 또한 소스 채널 로그 파일인 tcp_local_slave.log-*도 저장합니다. 추가로 다음과 같이 각 대상 채널로부터 해당 메일 파일의 복사본을 저장합니다. conversion 채널에서 ZZ01K7LXW76T7O9TD0TB.KEEP1 및 tcp_intranet 채널에서 ZZ01K7LXW76T7O9TD0TB.KEEP2 파일을 저장합니다.

9. 메일 및 로그 파일을 복사한 후 디버깅 옵션을 제거합니다.

   1. /msg_svr_base/config 디렉토리에 있는 imta.cnf 파일의 해당 채널에서 slave_debug 및 master_debug 키워드를 제거합니다.

   2. /msg_svr_base/config 디렉토리의 option.dat 파일에서 mm_debug=0을 재설정하고 log_message_id=1을 제거합니다.

   3. imsimta cnbuild를 사용하여 구성을 다시 컴파일합니다.

   4. imsimta restart dispatcher 명령을 실행하여 SMTP 서버를 다시 시작합니다.

메일 정지 지점 확인 방법

단계

1. 채널 프로그램 시작 및 중지가 완료되면 문제 해결에 사용할 수 있는 다음과 같은 파일을 가지게 됩니다.

   1. 각 채널 프로그램에서 메일 파일의 모든 복사본(예: ZZ01K7LXW76T7O9TD0TB.KEEP1)

   2. tcp_local_slave.log-* 파일

   3. 각 대상 채널에 대한 channel_master.log-* 파일 집합

   4. 메일 경로를 표시하는 mail.log_current 레코드 집합

      모든 파일은mail.log_current 레코드에서 message ID: 헤더 행과 일치하는 타임스탬프 및 메일 아이디 값을 가져야 합니다. 메일이 보낸 사람에게 다시 반송될 경우는 예외이며 반송된 메일은 원본 메일과는 다른 아이디 값을 가지게 됩니다.

2. tcp_local_slave.log-* 파일을 검사하여 메일이 메일 대기열에 들어갔을 때 메일 부분을 가지고 있었는지 확인합니다.

   SMTP 대화 상자 및 데이터를 확인하여 클라이언트 시스템에서 무엇을 보냈는지 봅니다.

   메일 부분이 tcp_local_slave.log-* 파일에 표시되지 않았다면 메일이 MTA에 놓이기 전에 문제가 발생한 것입니다. 그 결과 메일이 메일 부분 없이 대기열에 포함되었습니다. 이 경우 보낸 사람의 원격 SMTP 서버 또는 보낸 사람의 클라이언트 시스템에서 문제가 발생했을 수 있습니다.

3. 메일 파일의 복사본을 조사하여 메일 부분이 어디서 변경 또는 누락되었는지 확인합니다.

   메일 파일에서 메일 부분이 변경 또는 누락되었음이 표시되면 이전 채널의 로그 파일을 검사합니다. 예를 들어, tcp_intranet 채널에 놓이는 메일의 메일 부분이 변경 또는 누락된 경우 conversion_master.log-* 파일을 확인합니다.

4. 메일의 최종 대상을 확인합니다.

   tcp_local_slave.log 메일 파일(예: ZZ01K7LXW76T7O9TD0TB.KEEP1) 및 channel_master.log-* 파일에서 메일 부분이 변경되지 않은 것으로 확인되면 MTA는 메일을 변경하지 않았으며 메일 부분은 해당 최종 대상으로 가는 경로의 다음 단계에서 사라진 것입니다.

   최종 대상이 ims-ms 채널(메일 저장소)인 경우, 메일 부분이 전송 과정 도중이나 이후에 누락되는지를 확인하기 위해 메일을 서버에서 클라이언트 시스템으로 다운로드할 수 있습니다. 대상 채널이 tcp_* 채널인 경우에는 메일 경로의 MTA로 이동해야 합니다. 이 MTA를 Messaging Server MTA라고 가정하면 전체 문제 해결 프로세스를 반복해야 합니다( 메일 경로에서 채널 확인, 수동으로 채널을 시작 및 중지하여 데이터 수집 및 이 절 참조). 사용자가 관리하는 MTA가 아닌 경우 문제를 보고한 사용자가 해당 사이트에 문의해야 합니다.