test

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

22장 MTA 문제 해결

이 장에서는 MTA(Message Transfer Agent) 문제 해결에 대한 일반 도구, 방법 및 절차에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

관련 항목인 모니터링 절차는 23 장, Messaging Server 모니터링에 설명되어 있습니다.

주 –

이 장을 읽기 전에 본 설명서의 5장부터 10장과 Sun Java System Messaging Server Administration Reference의 MTA 구성 및 명령줄 유틸리티에 대한 장을 검토하십시오.

문제 해결 개요

MTA 관련 문제 해결의 첫 단계 중 하나는 진단을 시작할 위치를 결정하는 것입니다. 문제에 따라 로그 파일에서 오류 메시지를 볼 수 있습니다. 다른 상황에서는 모든 표준 MTA 프로세스를 확인하고 MTA 구성을 검토하거나 개별 채널을 시작 및 중지할 수 있습니다. 사용 방법에 상관 없이 MTA 관련 문제 해결 시에는 다음 질문을 고려하십시오.

위 질문은 이 장의 다음 절에 설명되어 있습니다.

표준 MTA 문제 해결 절차

이 절에서는 MTA에 대한 표준 문제 해결 절차에 대해 간략하게 설명합니다. 문제가 오류 메시지를 생성하지 않거나 오류 메시지에서 충분한 진단 정보를 제공하지 않을 경우 또는 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에 표시됩니다.

표 22–1 MTA 로그 파일

파일 이름 

로그 파일 내용 

channel_master.log-uniqueid

channel에 대한 마스터 프로그램(주로 클라이언트)의 출력입니다.

channel_slave.log-uniqueid

channel에 대한 슬레이브 프로그램(주로 서버)의 출력입니다.

dispatcher.log-uniqueid

디스패처 디버깅입니다. 이 로그는 디스패처 DEBUG 옵션의 설정과 관계없이 만들어집니다. 하지만 자세한 디버깅 정보를 얻으려면 DEBUG 옵션을 0이 아닌 값으로 설정해야 합니다.

imta

ims-ms 채널 오류 메시지로 전달에 문제가 있는 경우 나타납니다.

job_controller.log-uniqueid

Job Controller 로깅입니다. 이 로그는 Job Controller DEBUG 옵션의 설정과 관계없이 만들어집니다. 하지만 자세한 디버깅 정보를 얻으려면 DEBUG 옵션을 0이 아닌 값으로 설정해야 합니다.

tcp_smtp_server.log-uniqueid

tcp_smtp_server에 대한 디버깅입니다. 이 로그에 있는 정보는 메일이 아닌 서버에만 해당됩니다.

return.log-uniqueid

주기적인 MTA 메일 바운서 작업에 대한 출력을 디버그하며 option.dat에 return_debug 옵션이 사용되는 경우 이 로그 파일이 만들어집니다.

주 –

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

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

채널 마스터 및 슬레이브 프로그램 디버깅에 대한 자세한 내용은 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를 참조하십시오.

개별 채널 시작 및 중지

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

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

단계

  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부. 매핑 테이블을 참조하십시오.

ORIG_SEND_ACCESS 

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

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

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 프로세스의 각 단계에서 메일 및 로그 파일을 저장할 수 있습니다. 이 파일은 나중에 메일 정지 지점 확인 방법에 사용됩니다.

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

단계

  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 서버를 다시 시작합니다.

Procedure메일 정지 지점 확인 방법

단계

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

일반 MTA 문제 및 솔루션

이 절에서는 MTA 구성 및 작업에 대한 일반 문제 및 솔루션을 나열합니다.

TLS 문제

SMTP 대화 중에 STARTTLS 명령은 다음 오류를 반환합니다.

454 4.7.1 TLS library initialization failure

pop/imap에 액세스에 대한 인증서를 설치 및 작동 중에 있다면 다음 사항을 확인하십시오.

보호를 변경하고 인증서를 설치한 후에는 다음을 실행해야 합니다.


stop-msg dispatcher 
start-msg dispatcher

다시 시작해도 좋지만 시스템을 완전히 종료하고 인증서를 설치한 다음 다시 시작하는 것이 좋습니다.

영향력이 없는 구성 파일 또는 MTA 데이터베이스에 대한 변경 사항

구성, 매핑, 전환, 보안, 옵션 또는 별칭 파일에 대한 변경이 적용되지 않는 경우 다음 단계를 수행했는지 확인합니다.

  1. 구성을 다시 컴파일합니다(imsimta cnbuild 실행).

  2. 적절한 프로세스(예: imsimta restart dispatcher)를 다시 시작합니다.

  3. 모든 클라이언트 연결을 다시 설정합니다.

MTA에서 보내는 메일은 전송하지만 받는 메일을 수신하지 않음

대부분의 MTA 채널은 받는 메일을 수신하는 슬레이브 또는 채널 프로그램에 의존합니다. MTA가 지원하는 일부 전송 프로토콜(TCP/IP 및 UUCP 등)의 경우 해당 표준 서버 대신 MTA 슬레이브 프로그램을 활성화해야 합니다. Messaging Server 설치의 일환으로 원시 sendmail SMTP 서버가 MTA SMTP 서버로 대체됩니다. 자세한 내용은 Sun Java Enterprise System 2005Q4 설치 설명서를 참조하십시오.

다중 스레드 SMTP 서버의 경우 디스패처에서 SMTP 서버의 시작을 제어합니다. 디스패처가 SMTP 서비스에 대해 1 이상의 MIN_PROCS 값을 사용하도록 구성된 경우, 적어도 하나 이상(가능한 경우 SMTP 서비스에 대한 MAX_PROCS 값에 따라 그 이상으로)의 SMTP 서버 프로세스가 항상 실행 중이어야 합니다. imsimta process 명령을 사용하여 SMTP 서버 프로세스의 존재 여부를 확인할 수 있습니다. 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 imsimta process를 참조하십시오.

디스패처(SMTP Server)가 시작되지 않음

디스패처가 시작되지 않는 경우에는 먼저 dispatcher.log-*에서 관련 오류 메시지를 확인합니다. 로그에서 /tmp/.SUNWmsgsr.dispatcher.socket 파일을 만들거나 액세스하는 문제를 표시하는 경우, /tmp 보호가 1777로 설정되어 있는지 확인합니다. 사용 권한에 다음과 같이 표시됩니다.


drwxrwxrwt 8 root sys 734 Sep 17 12:14 tmp/
.

또한 SUNWmsgsr.dispatcher.socket 파일의 ls -l을 수행하고 적합한 소유권을 확인하십시오. 예를 들어, root에서 만든 경우에는 inetmail에서 액세스할 수 없습니다.

SUNWmsgsr.dispatcher.file을 제거하지 말고 누락된 경우에는 만들지 마십시오. 디스패처에서 해당 파일을 만듭니다. 보호가 1777로 설정되지 않은 경우에는 디스패처가 소켓 파일을 만들고 액세스할 수 없기 때문에 시작 또는 다시 시작하지 않습니다. 또한 Messaging Server와 연관되지 않은 다른 문제들이 발생할 수 있습니다.

받는 SMTP 연결의 시간 초과

받는 SMTP 연결의 시간 초과는 흔히 시스템 자원 및 해당 할당과 연관되어 있습니다. 다음 기술을 사용하여 받는 SMTP 연결의 시간 초과 원인을 확인할 수 있습니다.

Procedure받는 SMTP 연결의 시간 초과 원인을 확인하는 방법

단계

  1. 허용된 동시에 받는 SMTP 연결 수를 확인합니다. 이는 SMTP 서비스에 대한 MAX_PROCS 및 MAX_CONNS 디스패처 설정이 제어하며 허용되는 동시 연결 수는 MAX_PROCS*MAX_CONNS입니다. 시스템 자원이 충분하고 이 수가 사용량에 비해 너무 적은 경우 수를 늘릴 수 있습니다.

  2. 다른 기술로는 TELNET 세션을 여는 것이 있습니다.

    다음 예에서는 사용자가 127.0.0.1 포트 25에 연결합니다. 연결되면 220 배너가 반환됩니다. 예를 들면 다음과 같습니다.


    telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ’^]’.
220 budgie.sesta.com --Server ESMTP (Sun Java System Messaging Server 6.1 
(built May  7 2001))

    사용자가 해당 포트에 연결되고 220 배너를 수신하지만 추가 명령(예: ehlo 및 mail from)이 응답을 부정하지 않는 경우, imsimta test -rewrite를 실행하여 구성이 올바른지 확인합니다.

  3. 220 배너의 응답 시간이 느리고 SMTP 서버에 pstack 명령이 실행 중인 경우 다음 iii_res* 함수가 표시됩니다(이 함수는 이름 확인 조회가 수행 중임을 나타냄).


    febe2c04 iii_res_send (fb7f4564, 28, fb7f4de0, 400, fb7f458c, fb7f4564) + 
42c febdfdcc iii_res_query (0, fb7f4564, c, fb7f4de0, 400, 7f) + 254

    그런 다음 호스트는 localhost/127.0.0.1과 같은 일반 쌍에서도 역방향 이름 확인 조회를 실행해야 할 수 있습니다. 이와 같은 성능 저하를 방지하려면 /etc/nsswitch.conf 파일에서 사용자 호스트 조회 순서를 다시 정렬해야 합니다. 그러기 위해서는 /etc/nsswitch.conf 파일에서 다음 행을 


    hosts: dns nis [NOTFOUND=return] files

    아래와 같이 변경합니다.


    hosts: files dns nis [NOTFOUND=return]

    /etc/nsswitch.conf 파일에서 이러한 변경 작업을 수행하면 여러 SMTP 서버가 불필요한 조회를 수행하는 대신 더 적은 수의 SMTP 서버에서 메일을 처리하므로 성능이 향상됩니다.

  4. 또한 slave_debug 키워드를 주로 tcp_local 및 tcp_intranet과 같은 TCP/IP 메일을 통해 받는 SMTP를 처리하는 채널에 입력할 수 있습니다. 그런 다음 최근의 tcp_local_slave.log-uniqueid 파일을 검토하여 시간 초과된 메일의 특성을 확인합니다. 예를 들어, 수신자가 많은 받는 메일이 시간 초과되는 경우 채널에 expandlimit 키워드를 사용하는 것이 좋습니다.

    시스템이 오버로드되고 지나치게 확장된 경우 시간 초과를 완전히 방지할 수는 없습니다.

메일이 대기열에서 제외되지 않음

TCP/IP 전달 중에 발생하는 오류는 보통 일시적이며 문제가 발생하면 일반적으로 MTA에서 메일을 보관하고 주기적으로 다시 보내려는 시도를 합니다. 다른 호스트 연결이 정상적으로 작동할 때 대규모 네트워크가 특정 호스트에서 주기적으로 중단되는 것은 정상입니다. 문제를 확인하려면 로그 파일에서 전달 시도와 관련된 오류를 검사합니다. "Fatal error from smtp_open"과 같은 오류 메시지가 표시될 수 있습니다. 이런 오류는 보편적이며 보통 일시적인 네트워크 문제와 연관되어 있습니다. TCP/IP 네트워크 문제를 디버그하려면 PING, TRACEROUTE 및 NSLOOKUP과 같은 유틸리티를 사용합니다.

다음 예는 메일이 xtel.co.uk에 전달 시 대기열에서 대기하는 이유를 확인하기 위해 사용자가 사용할 수 있는 단계를 보여 줍니다. 메일이 대기열에서 제외되지 않는 이유를 확인하려면 MTA가 TCP/IP에서 SMTP 메일 전달에 사용하는 단계를 다시 만들 수 있습니다.


% nslookup -query=mx xtel.co.uk (Step 1)
            
Server: LOCALHOST
Address: 127.0.0.1

Non-authoritative answer:
XTEL.CO.UK  preference = 10, mail exchanger = nsfnet-relay.ac.uk (Step 2)

% telnet nsfnet-relay.ac.uk 25 (Step 3)
Trying... [128.86.8.6]
telnet: Unable to connect to remote host: Connection refused

  1. NSLOOKUP 유틸리티를 사용하여 이 호스트에 어떤 MX 레코드가 있는지(있는 경우) 확인합니다. MX 레코드가 없으면 호스트에 직접 연결해야 합니다. MX 레코드가 있으면 지정된 MX 중계에 연결해야 합니다. 명시적으로 연결하지 않도록 구성된 경우를 제외하면 MTA는 우선적으로 MX 정보를 적용합니다. TCP/IP MX 레코드 지원을 참조하십시오.

  2. 이 예에서 DNS(도메인 이름 서비스)는 xtel.co.uk에 대해 지정된 MX 중계의 이름을 반환합니다. 이 호스트는 MTA가 실제로 연결할 호스트입니다. 둘 이상의 MX 중계가 나열된 경우 MTA는 각 MX 레코드를 기본값이 낮은 것부터 오름차순으로 연속해서 시도합니다.

  3. 원격 호스트에 연결된 경우 SMTP 서버 포트 25의 TELNET을 사용하여 인바운드 SMTP 연결을 허용하는지 확인합니다.

    주 –

    포트를 지정하지 않고 TELNET을 사용하는 경우에는 원격 호스트가 일반 TELNET 연결을 허용합니다. 하지만 위의 경우 원격 호스트가 SMTP 연결을 허용한다는 것을 의미하지는 않습니다. 많은 시스템이 일반 TELNET 연결은 허용하지만 SMTP 연결을 거부하며 또한 그 반대로 SMTP 연결을 허용하지만 TELNET 연결은 거부합니다. 따라서 항상 SMTP 포트에 대해 테스트를 수행해야 합니다.

    이전 예에서 원격 호스트는 SMTP 포트에 대한 연결을 거부합니다. 이는 MTA가 메일 전달에 실패하는 이유입니다. 원격 호스트의 잘못된 구성 또는 원격 호스트에서의 일부 자원 고갈로 인해 연결이 거부될 수 있습니다. 이런 경우 문제를 로컬에서 해결할 수 없습니다. 일반적으로 MTA가 메일을 계속해서 시도하도록 합니다.

DNS를 사용하지 않는 TCP/IP 네트워크에 Messaging Server가 실행 중인 경우에는 처음 두 단계를 건너뛸 수 있습니다. 대신 TELNET을 사용하여 해당 호스트에 직접 액세스할 수 있습니다. 호스트 이름은 MTA에서 사용하는 이름과 같아야 합니다. 호스트 이름을 확인하려면 MTA의 최근 시도에서 관련 로그 파일을 봅니다. 호스트 파일을 사용하는 경우에는 호스트 이름 정보가 올바른지 확인합니다. 호스트 이름 대신 DNS를 사용해야 합니다.

TCP/IP 호스트에 대한 연결을 테스트할 때 대화식 테스트 사용에 문제가 발생하지 않는 경우 문제는 MTA가 마지막 메일 전달을 시도할 때 간단히 해결되었을 수 있습니다. 메일이 대기열에서 제외되는지 확인하려면 적절한 채널에서 imsimta submit tcp_channel을 다시 실행합니다.

새 채널 만들기

원격 도메인이 정지되고 이 서버로 주소가 지정된 메일 양이 너무 커서 전달할 수 없는 메일이 보내는 채널 대기열을 채우는 경우가 있습니다. MTA는 이러한 메일을 주기적으로 다시 전달하려고 시도하며(재시도 빈도와 횟수는 backoff 키워드를 사용하여 구성 가능) 정상적인 상황에서는 어떤 작업도 수행할 필요가 없습니다. 그러나 대기열에 있는 메일 수가 너무 많으면 모든 채널 작업이 전달할 수 없는 메일의 백로그를 처리하기 때문에 다른 메일이 적시에 전달되지 못할 수 있습니다.

이 경우 이러한 메일을 자체 Job Controller 풀에서 실행되는 새 채널로 다시 라우팅할 수 있습니다. 이렇게 하면 처리를 위한 경합이 발생하지 않으며 다른 채널이 해당 메일을 전달할 수 있습니다. 이 절차에 대해서는 아래에서 설명합니다. siroe.com이라는 도메인을 사용한다고 가정합니다.

Procedure새 채널 만들기

단계

  1. tcp_siroe-daemon이라는 새 채널을 만들고 pool 키워드에 대한 새 값을 추가합니다.

    /msg_svr_base/config/imta.cnf의 채널 블록 섹션에 채널이 작성됩니다. 이 채널은 정기적인 보내는 tcp_* 채널에서 동일한 채널 키워드를 가져야 합니다. 일반적으로 이 채널은 모든 아웃바운드(인터넷) 트래픽을 처리하는 tcp_local입니다. siroe.com이 인터넷상에 있으므로 이 채널이 에뮬레이트됩니다. 새 채널은 다음과 같을 수 있습니다.

    tcp_siroe smtp nomx single_sys remotehost inner allowswitchchannel     \
dentnonenumeric subdirs 20 maxjobs 7 pool SMTP_SIROE maytlsserver      \
maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0      \    
tcp_siroe-daemon

    새 키워드-값 쌍의 풀인 SMTP_SIROE를 확인합니다. 이것은 이 채널로 보내는 메일이 SMTP_SIROE 풀의 컴퓨터 자원만 사용하도록 지정합니다. 또한 새 채널의 앞뒤에 빈 행이 필요하다는 것에 주의하십시오.

  2. imta.cnf 파일의 다시 쓰기 규칙 섹션에 두 개의 다시 쓰기 규칙을 추가하여 siroe.com을 대상으로 하는 전자 메일을 새 채널로 보냅니다.

    새 다시 쓰기 규칙은 다음과 같습니다.


    siroe.com     $U%$D@tcp_siroe-daemon
.siroe.com      $U%$H$D@tcp_siroe-daemon

    이러한 다시 쓰기 규칙은 siroe.com을 대상으로 하는 메일(host1.siroe.com 또는 hostA.host1.siroe.com과 같은 주소 포함)을 해당 공식 호스트 이름이 tcp_siroe-daemon인 새 채널로 보냅니다. $U%$D 및 $U%$H$D 규칙의 다시 쓰기 부분은 메일의 원래 주소를 유지합니다. $U는 원래 주소에서 아이디를 복사합니다. %는 아이디와 도메인 사이에 있는 구분자 @입니다. $H는 패턴에서 점 왼쪽에 있는 호스트/도메인 지정의 일치하지 않는 부분을 복사합니다. $D는 일치한 도메인 지정 부분을 복사합니다.

  3. SMTP_SIROE라는 새 Job Controller 풀을 정의합니다.

    /msg_svr_base/config/job_controller.cnf에 다음을 추가합니다.


    [POOL=SMTP_SIROE]
job_limit=10

    이렇게 하면 최대 10개의 작업을 동시에 실행할 수 있는 SMTP_SIROE라는 메일 자원 풀이 작성됩니다. 이 풀 정의와 다른 항목 사이에 빈 행이 있으면 제거합니다. 작업 및 풀에 대한 자세한 내용은 Job Controller를 참조하십시오.

  4. MTA를 다시 시작합니다.

    다음 명령을 실행합니다. imsimta refresh

    이 명령은 구성을 다시 컴파일하고 Job Controller와 디스패처를 다시 시작합니다.

    이 예에서는 인터넷 사용자가 siroe.com이라는 특정 원격 사이트로 다수의 전자 메일을 보냅니다. 어떤 이유로 siroe.com이 일시적으로 받는 SMTP 연결을 허용할 수 없어 전자 메일을 전달할 수 없게 됩니다. (이러한 상황이 자주 발생합니다.)

    siroe.com을 대상으로 하는 전자 메일이 들어오면 보내는 채널 대기열인 tcp_local에 전달할 수 없는 메일이 채워집니다. MTA는 이러한 메일을 주기적으로 다시 전달하려고 시도하며(재시도 빈도와 횟수는 backoff 키워드를 사용하여 구성 가능) 정상적인 상황에서는 어떤 작업도 수행할 필요가 없습니다.

    그러나 대기열에 있는 메일 수가 너무 많으면 모든 채널 작업이 siroe.com 메일의 백로그를 처리하기 때문에 다른 메일이 적시에 전달되지 못할 수 있습니다. 이 경우 siroe.com 메일을 자체 Job Controller 풀에서 실행되는 새 채널로 다시 라우팅할 수 있습니다( Job Controller 참조). 이렇게 하면 siroe.com 메일이 사용하는 처리 자원을 경합하지 않아도 다른 채널이 해당 메일을 전달할 수 있습니다. 새 채널을 만들어 이 문제를 해결하는 방법은 아래에서 설명합니다.

MTA 메일이 전달되지 않음

메일 전송 문제 외에도 메일 대기열에서 메일을 처리할 수 없도록 하는 두 가지 일반적인 문제가 있습니다.

  1. 대기열 캐시가 대기열 디렉토리의 메일과 동기화되지 않습니다. 전달 대기 중인 MTA 대기열 하위 디렉토리의 메일 파일은 메모리 내장 대기열 캐시에 놓입니다. 채널 프로그램이 실행되는 경우에는 이 대기열 캐시에 문의하여 해당 대기열에서 어떤 메일을 전달할지 결정합니다. 대기열에 메일 파일이 있지만 해당 대기열 캐시 항목이 없는 경우도 있습니다.

    1. 대기열 캐시에 특정 파일이 있는지 확인하려면 imsimta cache -view 유틸리티를 사용하고 파일이 대기열 캐시에 없는 경우 대기열 캐시를 동기화해야 합니다.

      대기열 캐시는 보통 4시간마다 동기화됩니다. 필요하면 imsimta cache -sync 명령을 사용하여 캐시를 수동으로 다시 동기화할 수 있습니다. 이 채널 프로그램은 일단 동기화되면 새 메일이 처리된 후에도 처리되지 않는 원본 메일을 처리합니다. 기본값(4시간)을 변경하려면 대기열 캐시의 동기화 빈도를 반영하는 timeperiod가 있는 sync_time=timeperiod를 추가하여 /msg_svr_base/config 디렉토리의 job_controller.cnf 파일을 수정합니다. timeperiod는 30분보다 커야 합니다. 다음 예에서는 sync_time=02:00을 job_controller.cnf의 전역 기본 섹션에 추가하여 동기화를 2시간으로 수정합니다.


      ! VERSION=5.0
!IMTA job controller configuration file
!
!Global defaults
tcp_port=27442
secret=N1Y9[HzQKW
slave_command=NULL
sync_time=02:00

      imsimta cache -sync를 실행한 후 imsimta submit channel을 실행하여 메일의 백로그를 모두 지웁니다. 메일의 백로그가 큰(1000 이상) 경우 채널을 모두 지우는 데 긴 시간이 필요할 수도 있다는 점에 유의해야 합니다.

      요약된 대기열 캐시 정보에 대해서는 imsimta qm -maint dir -database -total을 실행합니다.

    2. 대기열 캐시를 동기화한 후에도 메일이 전달되지 않으면 Job Controller를 다시 시작해야 합니다. 그러려면 imsimta restart job_controller 명령을 사용합니다.

      Job Controller를 다시 시작하면 디스크에서 메일 대기열의 메일 데이터 구조가 재구성됩니다.

      주의 – 주의 –

      Job Controller를 다시 시작하는 것은 최후의 수단으로 다른 방법을 모두 사용해 본 후에 수행되어야 합니다.

      Job Controller에 대한 자세한 내용은 Job Controller를 참조하십시오.

  2. 해당 처리 로그 파일을 만들 수 없기 때문에 채널 처리 프로그램을 실행할 수 없습니다. 액세스 권한, 디스크 공간 및 할당량을 확인하십시오.

메일 루핑

MTA가 메일 루핑을 감지하면 해당 메일은 .HELD 파일로 취급되어 보류됩니다. .HELD 메일 진단 및 정리를 참조하십시오. 특정 경우에는 MTA에서 감지할 수 없는 메일 루프가 발생할 수 있습니다.

첫 번째 단계로 메일 루핑의 원인을 확인합니다. 해당 채널에 대해 문제 메일 파일이 MTA 대기열 영역, 문제 메일과 연관된 MTA 메일 로그 항목(해당 채널에 대한 MTA 구성 파일에서 logging 채널 키워드를 활성화한 경우) 및 MTA 채널 디버그 로그 파일에 있는 동안 문제 메일 파일의 복사본을 검토해야 합니다. 문제 메일에 대한 보낸 사람 및 To: 주소와 받은 날짜헤더 행 및 메일 구조(메일 내용의 캡슐화 유형)를 확인하는 것은 발생할 수 있는 메일 루프 유형을 정확히 아는데 도움이 됩니다.

보다 일반적인 경우는 다음과 같습니다.

  1. 포스트마스터 주소가 손상되었습니다.

    MTA는 포스트마스터 주소로 전자 메일을 받도록 합니다. 포스트마스터로 보낸 메일이 루핑되는 경우에는 메일을 받을 수 있는 계정을 가르키는 적절한 포스트마스터 주소가 구성되어 있는지 확인합니다.

  2. Received: 헤더 행을 제거하면 MTA에서 메일 루프를 감지할 수 없습니다.

    정상적인 메일 루프 감지는 Received: 주석(괄호 안의 내용)을 제거합니다. Received: 헤더 행이 제거되면 (해당 시스템에서 명시적으로 또는 방화벽과 같은 다른 시스템에서) 메일 루프를 적절히 감지하는 것을 방해할 수 있습니다. 이 시나리오에서는 원하지 않는 헤더 행이 제거되지 않도록 합니다. 또한, 근본적인 메일 루핑 원인을 조사합니다. 가능한 원인으로는 시스템 이름 할당 문제, 해당 이름의 변형을 인식하지 못하게 구성된 시스템 문제, DNS 문제, 해당 시스템의 인증 주소 지정 정보 없음 또는 사용자 주소 전달 오류등이 있습니다.

  3. 다른 메시징 시스템이 알림 메일을 잘못 처리하면 알림 메일에 대한 응답으로 다시 캡슐화된 메일이 생성됩니다.

    인터넷 표준은 메일 루프를 방지하기 위해 알림 메일(전달되는 메일 또는 반송되는 메일에 대한 보고서)에 From: 주소가 공백인 봉투를 요구합니다. 하지만 일부 메시징 시스템은 이러한 알림 메일을 제대로 처리하지 않습니다. 알림 메일을 전달 또는 튕기는 경우 이 메시징 시스템은 새 From: 주소에서 추출된 SMS 대상 주소의 숫자가 아닌 모든 문자를 스트라이프하려면 이 옵션을 지시합니다. 이 봉투를 삽입하면 메일 루프가 발생할 수 있습니다. 해결책은 알림 메일을 제대로 처리하지 못하는 메시징 시스템을 수정하는 것입니다.

.HELD 메일 진단 및 정리

MTA에서 메일이 서버 또는 채널 사이에서 튕겨지는 것을 감지하면 전달이 중단되고 메일이 /msg_svr_base/data/queue/channel의 .HELD 접미어를 가진 파일에 저장됩니다. 일반적으로 각 서버 또는 채널은 메일 전달에 대한 책임이 다른 서버 또는 채널에 있다고 생각하기 때문에 메일 루프가 발생합니다.

예를 들어, 최종 사용자는 서로 다른 두 개의 메일 호스트에서 서로에게 메일을 전달하도록 옵션을 설정할 수 있습니다. 최종 사용자는 sesta.com 계정에서 varrius.com 계정으로 메일이 전달되도록 합니다. 그 후 최종 사용자가 이 설정을 사용 가능하게 한 사실을 잊고 varrius.com 계정에서 sesta.com 계정으로 메일이 전달되도록 설정합니다.

또한 MTA 구성 결함으로 인해 루프가 발생할 수 있습니다. 예를 들어, MTA 호스트 X는 mail.sesta.com에 대한 메일이 호스트 Y로 간다고 생각합니다. 하지만 호스트 Y는 mail.sesta.com에 대한 메일을 호스트 X가 처리해야 한다고 생각하기 때문에 메일을 호스트 X에게 반환합니다.

이런 경우 MTA는 메일을 무시하고 더 이상의 전달을 시도하지 않습니다. 이러한 문제가 발생하면 메일을 튕기는 서버나 채널을 알기 위해 메일의 헤더 행을 확인합니다. 필요에 따라 항목을 수정합니다.

또한 imsimta qm release를 실행하거나 다음 단계를 수행하여 .HELD 메일을 재시도할 수 있습니다.

  1. .HELD 확장자 이름을 00외의 두 자리 숫자로 바꿉니다(예: .HELD에서 .06으로).

    주 –

    .HELD 파일의 이름을 바꾸기 전에 메일이 루핑을 중단해야 합니다.

  2. imsimta cache -sync를 실행합니다. 이 명령을 실행하면 캐시가 업데이트됩니다.

  3. imsimta submit channel 또는 imsimta run channel을 실행합니다.

Received: 헤더 행이 축적되어 메일이 다시 .HELD로 표시될 수 있으므로 이 단계를 여러 번 수행해야 할 수도 있습니다.

받은 메일 인코딩

MTA에서 보낸 메일은 인코딩된 형식으로 수신됩니다. 예를 들면 다음과 같습니다.

Date: Wed, 04 Jul 2001 11:59:56 -0700 (PDT)
From: "Desdemona Vilalobos" <Desdemona@sesta.com> 
To: santosh@varrius.com
Subject: test message with 8bit data 
MIME-Version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

2=00So are the Bo=F6tes Void and the Coal Sack the same?=

이러한 메일은 MTA 디코더 명령인 imsimta decode를 통해 읽을 때 인코딩되지 않은 상태로 표시됩니다. 자세한 내용은 Sun Java System Messaging Server Administration Reference를 참조하십시오.

SMTP 프로토콜은 RFC 821에 설명된 것과 같이 ASCII 문자(7비트 문자 세트)의 전송만을 허용합니다. SMTP를 사용한 8비트 문자의 검토되지 않은 전송은 유효하지 않으며 일부 SMTP 서버에 다양한 문제를 일으키는 것으로 알려져 있습니다. 예를 들어, SMTP 서버는 연산 관련 루프로 이동할 수 있습니다. 메일이 계속해서 다시 보내집니다. 8비트 문자는 서버 충돌을 일으킬 수 있습니다. 결국 8비트 문자 세트는 8비트 데이터를 처리할 수 없는 브라우저 및 메일함을 복잡하게 만들 수 있습니다.

SMTP 클라이언트는 8비트 데이터를 포함하는 메일을 처리할 때 보낸 사람에게 전달할 수 없는 것으로 메일을 반환하거나, 메일을 코드화하거나, RFC 821을 직접 위반하여 메일 보내기와 같은 세 가지 옵션만을 가지고 있습니다. 하지만 MIME 및 SMTP 확장자의 발명으로 이제 ASCII 문자 세트를 사용하여 8비트 데이터 코드화에 사용할 수 있는 표준 인코딩 옵션이 있습니다.

이전 예에서 수신자는 TEXT/PLAIN의 MIME 내용 유형으로 인코딩된 메일을 받았으며, 원격 SMTP 서버(MTA SMTP 클라이언트가 메일을 전송한 서버)는 8비트 데이터의 전송을 지원하지 않았습니다. 하지만 원본 메일이 8비트 문자를 포함하고 있기 때문에 MTA가 메일을 인코딩해야 했습니다.

서버측 규칙(SSR)이 작동하지 않음

필터는 메일 메시지에 적용할 하나 이상의 조건부 작업으로 구성되어 있습니다. 필터는 서버에 저장 및 평가되므로 흔히 서버측 규칙(SSR)이라고 합니다.

이 절에서는 다음 SSR 관련 항목에 대해 설명합니다.

사용자 수준 필터 디버그를 참조하십시오.

사용자 SSR 규칙 테스트


# imsimta test -rewrite -debug -filter user@domain

출력에서는 다음 정보를 찾습니다.


mmc_open_url called to open ssrf:user@ims-ms
   URL with quotes stripped: ssrd: user@ims-ms
Determined to be a SSRD URL.
   Identifier: user@ims-ms-daemon
Filter successfully obtained.

일반 구문 문제

메일 보내기 버튼을 누른 후 응답이 느림

사용자가 메일을 보낼 때 지연이 발생하는 경우 메일 대기열 디스크가 충분히 크게 지정되지 않아 디스크 입력/출력이 줄었기 때문일 수 있습니다. 사용자가 전자 메일 클라이언트에서 보내기 버튼을 누를 때 MTA는 메일이 메일 대기열에 적용되어야만 메일 수신을 완전히 수락합니다. 메일 대기열 크기 지정에 대한 자세한 내용은 다음 설명서에서 확인할 수 있습니다.

받은 필드 또는 주소의 로컬 부분에 있는 별표

이제 MTA는 구성한 받은 필드뿐만 아니라 주소의 로컬 부분에서 8비트 문자(단순히 ASCII 문자가 아니라)를 검사하고 이 문자를 별표로 바꿉니다.

일반 오류 메시지

MTA가 시작되지 않으면 명령줄에 일반 오류 메시지가 표시됩니다. 이 절에서는 일반 오류 메시지를 설명하고 진단합니다.

주 –

고유한 사용자 MTA 구성을 진단하려면 imsimta test -rewrite -debug 유틸리티를 사용하여 사용자의 MTA 주소 다시 쓰기 및 채널 매핑 프로세스를 검사합니다. 이 유틸리티를 사용하여 메일을 실제로 보내지 않고도 해당 구성을 확인할 수 있습니다. MTA 구성 확인을 참조하십시오.

또한 MTA 하위 구성 요소는 이 장에서 설명하지 않은 다른 오류 메시지를 표시할 수도 있습니다. 명령줄 유틸리티 및 구성에 대한 장은 Sun Java System Messaging Server Administration Reference를 참조하고 각 하위 구성 요소에 대한 자세한 내용은 5장에서 10장을 참조하십시오. 이 절에서는 다음 오류 유형에 대해 설명합니다.

mm_init 오류

mm_init 오류는 일반적으로 MTA 구성 문제를 나타냅니다. imsimta test -rewrite 유틸리티를 실행하면 이러한 오류가 표시됩니다. imsimta cnbuild, 채널, 서버 또는 브라우저와 같은 다른 유틸리티에서도 이와 같은 오류를 반환합니다.

일반적으로 발생하는 mm_init 오류는 다음과 같습니다.

bad equivalence for alias. . .

별칭 파일 항목의 오른쪽의 서식 지정이 잘못되었습니다.

cannot open alias include file. . .

별칭 파일에 포함된 파일을 열 수 없습니다.

duplicate aliases found. . .

두 개의 별칭 파일 항목의 왼쪽이 동일합니다. 중복된 별칭을 찾아서 제거해야 합니다. 행 번호 XXX인 error line #XXX 오류 메시지를 찾습니다. 해당 행에서 중복된 별칭을 수정할 수 있습니다.

duplicate host in channel table. . .

이 오류 메시지는 MTA 구성에 공식 호스트 이름이 같은 두 개의 채널 정의가 있다는 것을 표시합니다.

사용자 구성 파일(imta.cnf)의 다시 쓰기 규칙(위쪽)에 추가로 생긴 빈 행으로 인해 MTA는 나머지 구성 파일을 채널 정의로 해석하게 됩니다. 파일의 맨 처음 행이 빈 행이 아니어야 합니다. 동일한 패턴(왼쪽)의 다시 쓰기 규칙이 많으므로 MTA는 이 규칙을 고유하지 않은 공식 호스트 이름을 가진 채널 정의로 해석합니다. 모든 중복된 공식 호스트 이름을 가진 채널 정의 및 파일의 위(다시 쓰기 규칙)쪽에 있는 잘못된 모든 빈 행에 대해 MTA 구성을 확인합니다.

duplicate mapping name found. . .

이 메시지는 두 개의 매핑 테이블이 같은 이름을 가지고 있다는 것을 나타내며 중복된 매핑 테이블 중 한 개는 제거되어야 합니다. 하지만 매핑 파일의 서식 지정 오류로 인해 MTA에서 무관한 것을 매핑 테이블 이름으로 잘못 해석할 수도 있습니다. 예를 들어, 매핑 테이블 항목을 적절하게 들여쓰지 않으면 MTA에서 항목의 왼쪽이 실질적인 매핑 테이블 이름인 것으로 잘못 생각할 수 있습니다. 일반 형식 매핑 테이블을 검사하고 매핑 테이블 이름을 확인합니다.

주 –

빈 행은 매핑 테이블 이름을 가진 모든 행의 앞뒤에 있어야 합니다. 하지만 어떤 빈 행도 매핑 테이블의 항목 간에 산재해 있으면 안 됩니다.

mapping name is too long. . .

이 오류는 매핑 테이블 이름이 너무 길어서 줄여야 함을 의미합니다. 매핑 파일의 서식 지정 오류로 인해 MTA에서 무관한 것을 매핑 테이블 이름으로 잘못 해석할 수도 있습니다. 예를 들어, 매핑 테이블 항목을 적절하게 들여쓰지 않으면 MTA에서 항목의 왼쪽이 실질적인 매핑 테이블 이름인 것으로 잘못 생각할 수 있습니다. 매핑 파일 및 매핑 테이블 이름을 확인합니다.

error initializing ch_ facility compiled character set version mismatch

이 메시지가 표시되면 imsimta chbuild 명령을 통해 컴파일된 문자 세트 테이블을 다시 컴파일하고 다시 설치해야 합니다. 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 imsimta chbuild를 참조하십시오.

error initializing ch_ facility no room in. . .

일반적으로 이 오류 메시지는 MTA 문자 세트 내부 테이블의 크기를 조정해야 한다는 것을 의미하며 다음 명령을 통해 컴파일된 문자 세트 테이블을 다시 만듭니다.


imsimta chbuild -noimage -maximum -option
imsimta chbuild

위와 같이 변경하기 전에는 아무것도 다시 컴파일하거나 다시 시작하지 않도록 합니다. imsimta chbuild에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 imsimta chbuild를 참조하십시오.

local host alias or proper name too long for system. . .

이 오류는 로컬 호스트 별칭 또는 해당 이름이 너무 길다는 것을 나타냅니다(채널 블록에서 두 번째 또는 후속 이름 중 하나의 오른쪽). 하지만 초기 MTA 구성 파일(예: 다시 쓰기 규칙의 추가적인 빈 행)의 일부 구문 오류로 인해 MTA에서 무관한 것을 채널 정의로 잘못 해석할 수도 있습니다. 구성 파일의 표시된 행을 확인하는 것 외에도 다른 구문 오류에 대해 위의 해당 행을 확인합니다. 특히 MTA에서 이 오류를 표시하는 행이 다시 쓰기 규칙으로 사용되는 경우 반드시 그 위의 추가적인 빈 행을 확인해야 합니다.

no equivalence addresses for alias. . .

별칭 파일에 있는 항목의 오른쪽(번역 값)이 없습니다.

no official host name for channel. . .

이 오류는 채널 정의 블록에 필수적인 두 번째 행(공식 호스트 이름 행)이 없다는 것을 나타냅니다. 채널 정의 블록에 대한 자세한 내용은 Sun Java System Messaging Server Administration Reference의 MTA 구성 및 명령줄 유틸리티 장 및 12 장, 채널 정의 구성을 참조하십시오. 각 채널 정의 블록 전후에는 빈 행이 필요하지만 채널 정의의 채널 이름과 공식 호스트 이름 행 사이에 빈 행이 있어서는 안 됩니다. 또한 빈 행은 MTA 구성 파일의 다시 쓰기 규칙 부분에 허용되지 않습니다.

공식 호스트 이름이 너무 긴 경우

채널(채널 정의 블록의 두 번째 행)의 공식 호스트 이름 길이는 128자의 8진수로 제한됩니다. 채널에 더 긴 공식 호스트 이름을 사용하려면 이를 자리 표시자 이름으로 줄인 다음 다시 쓰기 규칙을 사용하여 긴 이름을 짧은 공식 호스트 이름에 일치시킵니다. l(로컬) 채널 호스트 이름을 사용하면 이 시나리오를 볼 수 있습니다. 예를 들면 다음과 같습니다. 


Original l Channel:
!delivery channel to local /var/mail store
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
walleroo.pocofronitas.thisnameismuchtoolongandreallymakesnosensebutitisan
example.monkey.gorilla.orangutan.antidisestablismentarianism.newt.salaman
der.lizard.gecko.komododragon.com

Create Place Holder:
!delivery channel to local /var/mail store 
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
newt

Create Rewrite Rule:
newt.salamander.lizard.gecko.komododragon.com   $U%$D@newt

l(로컬) 채널을 사용하는 경우에는 REVERSE 매핑 테이블을 사용해야 합니다. 사용법 및 구문에 대한 자세한 내용은 Sun Java System Messaging Server Administration Reference의 MTA configuration 장을 참조하십시오.

초기 MTA 구성 파일의 특정 구문 오류(예: 다시 쓰기 규칙의 추가적인 빈 행)로 인해 MTA에서 무관한 것을 채널 정의로 잘못 해석할 수 있습니다. 이로 인해 의도된 다시 쓰기 규칙이 공식 호스트 이름으로 해석될 수 있습니다. 구성 파일의 표시된 행을 확인하는 것 외에도 다른 구문 오류에 대해 위의 해당 행을 확인합니다. 특히 MTA에서 이 오류를 표시하는 행이 다시 쓰기 규칙으로 사용되는 경우 반드시 그 위의 추가적인 빈 행을 확인해야 합니다.

컴파일된 구성 버전이 일치하지 않는 경우

imsimta cnbuild 유틸리티의 기능 중 하나는 신속하게 로드되는 이미지에 MTA 구성 정보를 컴파일하는 것입니다. 컴파일 형식은 엄격히 정의되며 MTA의 버전에 따라 상당한 차이가 있습니다. 사소한 변경 사항이 패치 릴리스의 일부로 발생할 수 있습니다.

이와 같은 변경 사항이 발생하면 호환되지 않는 형식을 감지할 수 있도록 내부 버전 필드도 변경됩니다. 호환되지 않는 형식이 감지되면 MTA 구성 요소가 위의 오류와 같이 정지합니다. 이 문제에 대한 해결책은 imsimta cnbuild 명령을 사용하여 새로 컴파일된 구성을 생성하는 것입니다.

또한 업데이트된 구성 정보를 얻을 수 있도록 imsimta restart 명령을 사용하여 모든 상주 MTA 서버 프로세스를 다시 시작하는 것도 좋은 방법입니다.

스왑 공간 오류

제대로 작동하게 하려면 사용자의 메시징 시스템에 충분한 스왑 공간을 구성하는 것이 중요합니다. 사용자의 구성에 따라 필수 스왑 공간 크기가 다릅니다. 일반적인 조정 권장 사항으로는 스왑 공간의 크기가 적어도 주 기억 장치 크기의 3배여야 합니다.

다음은 스왑 공간이 없음을 알리는 오류 메시지입니다.

jbc_channels: chan_execute [1]: fork failed: Not enough space

이 오류를 Job Controller 로그 파일에서 볼 수도 있습니다. 다른 스왑 공간 오류는 사용자 구성에 따라 다릅니다.

다음 명령을 사용하여 사용한 스왑 공간과 남은 스왑 공간 크기를 확인할 수 있습니다.

파일 열기 또는 오류 만들기

메일을 보내려면 MTA는 MTA 메일 대기열 디렉토리에서 구성 파일을 읽거나 메일 파일을 만듭니다. 구성 파일은 MTA 또는 MTA의 SKD에 대해 쓰여진 모든 프로그램으로 읽을 수 있어야 합니다. 설치하는 동안 적절한 사용 권한이 이 파일에 할당됩니다. 구성 파일을 만드는 MTA 유틸리티 및 절차도 사용 권한을 할당합니다. 시스템 관리자가 해당 파일을 보호하는 경우에는 다른 권한있는 사용자 또는 일부 사이트별 절차를 통해 MTA에서 구성 정보를 읽지 못할 수 있습니다. 이런 경우 “파일 열기” 오류 또는 예기치 않은 동작이 발생합니다. imsimta test -rewrite 유틸리티는 구성 파일 읽기에 문제가 발생하면 추가 정보를 보고합니다. Sun Java System Messaging Server 6 2005Q4 Administration Reference의 imsimta test를 참조하십시오.

MTA가 권한이 있는 계정에서는 작동하고 권한이 없는 계정에서는 작동하지 않는 것처럼 보이는 경우에는 MTA 테이블 디렉토리의 파일 사용 권한이 문제의 원인일 수 있습니다. 구성 파일 및 해당 디렉토리에서 사용 권한을 확인합니다. 중요 파일의 소유권 확인을 참조하십시오.

일반적으로 "파일 만들기" 오류는 MTA 메일 대기열 디렉토리에서 메일 파일을 만드는 중에 발생하는 문제를 나타냅니다. 파일 만들기 문제를 진단하려면 메일 대기열 디렉토리 확인을 참조하십시오.

유효하지 않은 호스트/도메인 오류

브라우저를 통해 주소가 MTA에 제공되는 경우 이 오류가 나타날 수 있습니다. 또는, 오류 반환 메일 메시지의 일부로 오류가 지연되고 반환될 수 있습니다. 두 경우 모두 이 오류 메시지는 MTA가 지정된 호스트에게 메일을 전달할 수 없다는 것을 나타냅니다. 지정된 호스트에게 메일을 보낼 수 없는 이유를 확인하려면 다음 문제 해결 절차를 수행해야 합니다.

SMTP 채널 오류, os_smtp_* 오류

다음 오류는 반드시 MTA 오류인 것은 아닙니다. os_smtp_open, os_smtp_read, 및 os_smtp_write 등 os_smtp_* 오류이러한 오류는 MTA가 네트워크 계층에서 발생한 문제를 보고할 때 생성됩니다. 예를 들어, os_smtp_open 오류는 원격측 네트워크 연결을 열 수 없다는 것을 의미합니다. MTA가 주소 지정 오류나 채널 구성 오류로 인해 잘못된 시스템에 연결되도록 구성되어 있을 수 있습니다. 일반적으로 os_smtp_* 오류는 DNS 또는 네트워크연결 문제로 인해 발생하며 특히, 이전에 작업 채널 또는 주소였다면 os_smtp_read 또는 os_smtp_write 오류는 보통 다른 쪽에서 연결을 중단하거나 네트워크 문제로 인해 연결이 중단되었다는 것을 나타냅니다.

네트워크 및 DNS 문제는 일시적인 경우가 많습니다. 따라서 가끔 발생하는 os_smtp_* 오류는 신경쓰지 않아도 됩니다. 하지만 이 오류가 지속적으로 나타난다는 것은 기본 네트워크 문제를 나타내는 것일 수 있습니다.

특정 os_smtp_* 오류에 대한 자세한 내용을 얻으려면 해당 채널에서 디버깅을 활성화합니다. 시도된 SMTP 대화의 세부 사항을 표시하는 디버그 채널 로그 파일을 조사합니다. 특히 SMTP 대화 중에 언제 네트워크 문제가 발생했는지 확인합니다. 그 시간으로 네트워크 또는 원격측 문제의 유형을 알 수도 있습니다. 경우에 따라 네트워크 수준 디버깅(예: TCP/IP 패킷 추적)을 수행하여 보내거나 받은 메일을 확인할 수 있습니다.