표준 MTA 문제 해결 절차

이 절에서는 MTA에 대한 표준 문제 해결 절차에 대해 간략하게 설명합니다. 문제가 오류 메시지를 생성하지 않거나 오류 메시지에서 충분한 진단 정보를 제공하지 않을 경우 또는 MTA의 일반 상태 확인, 테스트 및 표준 유지 관리를 수행할 경우에는 다음 절차를 따릅니다.

• MTA 구성 확인

• 메일 대기열 디렉토리 확인

• 중요 파일의 소유권 확인

• Job Controller 및 디스패처 실행 확인

• 로그 파일 확인

• 수동으로 채널 프로그램 실행

• 개별 채널 시작 및 중지

• MTA 문제 해결 예

MTA 구성 확인

imsimta test -rewrite 유틸리티를 사용하여 주소 구성을 테스트합니다. 이 유틸리티를 사용하여 실제로 메일을 보내지 않고도 MTA의 주소 재작성 및 채널 매핑을 테스트할 수 있습니다. 자세한 내용은Sun Java System Messaging Server 6 2005Q4 Administration Reference의 2 장, Message Transfer Agent Command-line Utilities 장을 참조하십시오.

일반적으로 유틸리티는 메일이 대기할 채널뿐 아니라 적용될 주소 재작성을 표시합니다. 단, MTA 구성에 구문 오류가 있는 경우 유틸리티는 오류 메시지를 발생합니다. 출력이 예상과 다를 경우에는 구성을 수정해야 할 수 있습니다.

메일 대기열 디렉토리 확인

일반적으로 msg_svr_base/data/queue/와 같은 MTA 메일 대기열 디렉토리에 메일이 있는지 확인합니다. imsimta qm과 같은 명령줄 유틸리티를 사용하여 MTA 메일 대기열 디렉토리 아래에 예상한 메일 파일이 있는지 확인합니다. 추가 정보imsimta qm에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 imsimta qm 및 imsimta qm counters를 참조하십시오.

imsimta test -rewrite의 출력이 올바르게 표시되면 메일이 실제로 MTA 메일 대기열 하위 디렉토리에 놓이는지 확인합니다. 확인 시에는 메일 로깅을 사용 가능하게 합니다(MTA 로깅에 대한 자세한 내용은 MTA 메일 및 연결 로그 관리 참조). 그런 다음 / msg_svr_base/log/ 디렉토리에서 mail.log_current 파일을 확인합니다. 메일이 MTA 메일 대기열 하위 디렉토리에 놓이는지 확인하기 위해 메일 아이디를 사용하여 특정 메일을 추적할 수 있습니다. 메일을 찾을 수 없는 경우에는 파일 디스크 공간 또는 디렉토리 사용 권한에 문제가 있을 수 있습니다.

중요 파일의 소유권 확인

Messaging Server를 설치 시에는 메일 서버 사용자 계정(기본값은 nobody)을 선택해야 합니다. 다음 디렉토리, 하위 디렉토리 및 파일은 이 계정에서 소유해야 합니다.

/msg_svr_base/data/queue/
/msg_svr_base/log
/tmp

예를 들어 다음 UNIX 시스템 명령은 이 디렉토리의 보호 및 소유권 확인에 사용될 수 있습니다.

ls -l -p -d /opt/SUNWmsgsr/data/queue
drwx------ 6 inetuser bin 512 Feb 7 09:32 /opt/SUNWmsgsr/data/queue

ls -l -p -d /opt/SUNWmsgsr/log/imta
drwx------ 2 inetuser bin 1536 Mar 10 09:00 /opt/SUNWmsgsr/log/imta

ls -l -p -d /opt/SUNWmsgsr/imta/tmp
drwx------ 2 inetuser bin 512 Feb 7 10:00 /opt/SUNWmsgsr/imta/tmp

다음과 같은 UNIX 시스템의 명령을 사용하여 MTA 계정이 /msg_svr_base/data/queue의 파일을 소유하는지 확인합니다.

ls -l -p -R /opt/SUNWmsgsr/data/queue

Job Controller 및 디스패처 실행 확인

MTA Job Controller는 대부분의 보내는(마스터) 채널 작업을 포함하여 MTA 프로세스 작업의 실행을 처리합니다.

MTA의 다중 스레드 SMTP 채널과 같은 일부 MTA 채널은 받는 메일을 처리하는 상주 서버 프로세스를 포함합니다. 이 서버는 채널에 대한 슬레이브(받는) 방향을 처리합니다. MTA 디스패처는 이러한 MTA 서버를 만듭니다. 디스패처 구성 옵션은 서버의 사용 가능성과 만들어진 서버의 수 및 각 서버가 처리할 수 있는 연결 수를 제어합니다.

Job Controller 및 디스패처가 있는지 확인하고 MTA 서버 및 실행 중인 처리 작업이 있는지 보려면 imsimta process 명령을 사용합니다. 유휴 상태에서 명령은 job_controller 및 dispatcher 프로세스를 수행해야 합니다. 예를 들면 다음과 같습니다.

# imsimta process
USER      PID S VSZ    RSS   STIME    TIME     COMMAND
inetuser 9567 S 18416 9368  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
inetuser 6573 S 18112 5720  Jul_13    0:00  /opt/SUNWmsgsr/lib/job_controller
inetuser 9568 S 18416 9432  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
inetuser 6574 S 17848 5328  Jul_13    0:00  /opt/SUNWmsgsr/lib/dispatcher

Job Controller가 없는 경우 /msg_svr_base/data/queue 디렉토리의 파일은 백업되고 메일이 전달되지 않습니다. 디스패처가 없으면 SMTP 연결을 수신할 수 없습니다.

imsimta process에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 imsimta process를 참조하십시오.

Job Controller 또는 디스패처가 모두 없는 경우에는 /msg_svr_base/data/log에서 dispatcher.log-* 또는 job_controller.log-* 파일을 검토해야 합니다.

로그 파일이 존재하지 않거나 오류가 표시되지 않는 경우에는 start-msg 명령을 사용하여 프로세스를 시작합니다. 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 start-msg를 참조하십시오.

시스템에서 실행해야 할 프로그램을 수행(exec())하기 전에 먼저 자식 프로세스를 포크(fork()) 처리하는 경우가 아닌 경우, imsimta process를 실행할 때 디스패처나 Job Controller의 여러 인스턴스가 표시되지 않습니다. 그러나 이러한 중복의 시간 프레임은 매우 작습니다.

로그 파일 확인

MTA 처리 작업이 제대로 실행되지만 메일이 메일 대기열 디렉토리에 남아 있는 경우 로그 파일에 무슨 문제가 있는지 확인할 수 있습니다. 모든 MTA 로그 파일은 /msg_svr_base/log 디렉토리에 만들어집니다. 다양한 MTA 처리 작업에 대한 로그 파일 이름 형식은 표 22–1에 표시됩니다.

각 로그 파일은 고유 아이디(uniqueid)를 가지도록 만들어져 동일한 채널에서 만든 이전 로그를 덮어쓰지 못하게 합니다. 특정 로그 파일을 찾기 위해 imsimta view 유틸리티를 사용할 수 있습니다. 또한 imsimta purge 명령을 사용하여 오래된 로그 파일을 제거할 수 있습니다. 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 imsimta purge를 참조하십시오.

channel_master.log-uniqueid 및 channel_slave.log- uniqueid 로그 파일은 다음 상황에서 만들어질 수 있습니다.

• 현재 구성에 오류가 있습니다.

• master_debug 또는 slave_debug 키워드가 imta.cnf 파일의 채널에 설정됩니다.

• mm_debug가 0이 아닌 값(mm_debug > 0)으로 option.dat 파일(/msg_svr_base/config/ 디렉토리)에 설정됩니다.

채널 마스터 및 슬레이브 프로그램 디버깅에 대한 자세한 내용은 Sun Java System Messaging Server Administration Reference를 참조하십시오.

수동으로 채널 프로그램 실행

MTA 전달 문제 진단 시에는 MTA 전달 작업을 수동으로 실행하는 것이 좋으며 특히 하나 이상의 채널에 대한 디버깅을 사용 가능하게 한 후에 유용합니다.

imsimta submit 명령은 MTA Job Controller에 채널을 실행할 것을 알립니다. 해당 채널에 대한 디버깅이 사용 가능한 경우에는 표 22–1에 표시된 대로 imsimta submit가 /msg_svr_base/log 디렉토리에 로그 파일을 만듭니다.

imsimta run 명령은 현재 출력이 사용자의 단말기로 전송되는 활성 프로세스 상태의 채널에 대한 아웃바운드 전달을 수행합니다. 이는 작업 전송 자체에 문제가 있다고 의심되는 경우 작업을 전송하는 것보다 편리할 수 있습니다.

채널을 수동으로 실행하려면 Job Controller가 실행 중이어야 합니다.

imsimta submit 및 imsimta run 명령에 대한 구문, 옵션, 매개 변수 및 그 예에 대한 정보는 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 Command Descriptions를 참조하십시오.

개별 채널 시작 및 중지

경우에 따라 개별 채널을 시작 및 중지하면 메일 대기열 문제의 진단 및 디버그가 더 쉬워질 수 있습니다. 메일 대기열을 중지하면 대기 메일을 검사하여 루프 또는 스팸 공격의 존재 여부를 확인할 수 있습니다.

특정 채널에 대한 아웃바운드 처리(대기열에서 제외) 중지 방법

단계

1. imsimta qm stop 명령을 사용하여 특정 채널을 중지합니다. 이렇게 하면 Job Controller를 중지하지 않아도 되며 해당 구성을 다시 컴파일하지 않아도 됩니다. 다음 예에서는 conversion 채널이 중지됩니다.

   imsimta qm stop conversion

2. 처리를 계속하려면 imsimta qm start 명령을 사용하여 채널을 다시 시작합니다. 다음 예에서는 conversion 채널이 시작됩니다.

   imsimta qm start conversion

   imsimta qm start 및 imsimta qm stop 명령에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 imsimta qm을 참조하십시오.

특정 도메인 또는 IP 주소에서 인바운드 처리(채널 대기열에 포함) 중지

클라이언트 호스트에게 임시 SMTP 오류를 반환하면서 특정 도메인 또는 IP 주소에 대한 인바운드 메일 처리를 중지하려면 다음 프로세스 중 하나를 실행할 수 있습니다. 이렇게 하면 메일이 사용자 시스템에 보존되지 않습니다. 1부. 매핑 테이블을 참조하십시오.

• 특정 호스트 또는 도메인 이름에 대한 인바운드 처리를 중지하려면 MTA 매핑 파일(보통 /msg_svr_base/config/mappings)의 ORIG_SEND_ACCESS 매핑 테이블에 다음 액세스 규칙을 추가합니다.

ORIG_SEND_ACCESS 

  *|*@sesta.com|*|*        $X4.2.1|$NHost$ blocked

이 프로세스를 사용하면 보내는 사람의 원격 MTA가 시스템에 메일을 보존하며 인바운드 처리를 다시 시작할 때까지 계속해서 주기적으로 메일을 재전송합니다.

• 특정 IP 주소에 대한 인바운드 처리를 중지하려면 MTA 매핑 파일(보통 /msg_svr_base/config/mappings)의 PORT_ACCESS 매핑 테이블에 다음 액세스 규칙을 추가합니다.

PORT_ACCESS

    TCP|*|25|IP_address_to_block|*    $N500$ can't$ connect$ now

도메인 또는 IP 주소에서 인바운드 처리를 다시 시작하려면 매핑 테이블에서 이 규칙을 제거하고 구성을 다시 컴파일해야 합니다. 추가로 각 매핑 테이블에 대한 고유 오류 메시지를 만들 수 있습니다. 이렇게 하면 어떤 매핑 테이블이 사용되는지 확인할 수 있습니다.

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가 아닌 경우 문제를 보고한 사용자가 해당 사이트에 문의해야 합니다.