test

Sun Java System Messaging Server 6.3 관리 설명서

26.3 일반 MTA 문제 및 솔루션

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

26.3.1 TLS 문제

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

454 4.7.1 TLS library initialization failure

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

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


stop-msg dispatcher 
start-msg dispatcher

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

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

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

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

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

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

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

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

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

26.3.4 디스패처(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와 연관되지 않은 다른 문제들이 발생할 수 있습니다.

26.3.5 받는 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 키워드를 사용하는 것이 좋습니다.

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

26.3.6 메시지가 대기열에서 제외되지 않음

TCP/IP 전달 중에 발생하는 오류는 보통 일시적이며 문제가 발생하면 일반적으로 MTA에서 메시지를 보관하고 주기적으로 다시 보내려는 시도를 합니다. 다른 호스트 연결이 정상적으로 작동할 때 대규모 네트워크가 특정 호스트에서 주기적으로 중단되는 것은 정상입니다. 문제를 확인하려면 로그 파일에서 전달 시도와 관련된 오류를 검사합니다. "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 정보를 적용합니다. 12.4.3.5 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을 다시 실행합니다.

26.3.6.1 새 채널 만들기

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

이 경우 이러한 메시지를 자체 작업 제어기 풀에서 실행되는 새 채널로 다시 라우팅할 수 있습니다. 이렇게 하면 처리를 위한 경합이 발생하지 않으며 다른 채널이 해당 메시지를 전달할 수 있습니다. 이 절차에 대해서는 아래에서 설명합니다. 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라는 새 작업 제어기 풀을 정의합니다.

    /msg-svr-base/config/job_controller.cnf에 다음을 추가합니다.


    [POOL=SMTP_SIROE]
job_limit=10

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

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

    다음 명령을 실행합니다. imsimta cnbuild;imsimta restart

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

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

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

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

26.3.7 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. 대기열 캐시를 동기화한 후에도 메시지가 전달되지 않으면 작업 제어기를 다시 시작해야 합니다. 그러려면 imsimta restart job_controller 명령을 사용합니다.

      작업 제어기를 다시 시작하면 디스크에서 메시지 대기열의 메시지 데이터 구조가 재구성됩니다.

      주의 – 주의 –

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

      작업 제어기에 대한 자세한 내용은 8.7 작업 제어기를 참조하십시오.

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

26.3.8 메시지 루핑

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

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

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

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

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

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

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

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

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

26.3.8.1 .HELD 메시지 진단 및 정리

MTA에서 메시지 배달과 관련하여 심각한 문제를 발견한 경우, 그 메시지는 /msg-svr-base/data/queue/ channel에서 .HELD 접미어가 붙은 파일에 저장됩니다. 예를 들면 다음과 같습니다.


% ls 
ZZ0HXZ00G0EBRBCP.HELD
ZZ0HY200C0O6LGHU.HELD
ZZ0HYA006LP66O3H.HELD
ZZ0HZ7003EOQSE37.HELD

.HELD 파일이 생성되는 대표적인 이유 세 가지는 다음과 같습니다.

루핑에 의한 Messages .HELD

서버 또는 채널 사이에 바운스되는 메시지를 루핑한다고 합니다. 일반적으로 각 서버 또는 채널은 메시지 전달에 대한 책임이 다른 서버 또는 채널에 있다고 생각하기 때문에 메시지 루프가 발생합니다. 루핑 메시지는 보통 많은 수의 *Received: 헤더 행을 포함하고 있습니다. Received: 헤더 행은 메시지 루프의 정확한 경로를 나타냅니다. 그러한 헤더 행에 나타나는 호스트 이름과 수신자 주소 정보(예: for recipient 절이나 (ORCPT recipient) 주석)를 자세히 확인합니다. 메시지 루프가 생기는 원인 중 하나는 사용자의 실수입니다.

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

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

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

메시지 루프의 또 다른 대표적인 원인은 MTA가 자신의 이름 중 하나로 인식하지 않는(인식하도록 구성되지 않은) 네트워크 이름을 사용하여 MTA 호스트로 주소 지정된 메시지를 수신하는 것입니다. 이 문제를 해결하려면 MTA가 자신의 이름으로 인식하는 이름 목록에 추가 이름을 추가합니다. 메시지가 루핑 중이라고 MTA가 판단하는 임계값은 구성 가능합니다. MAX_*RECEIVED_LINES option.dat 옵션(Sun Java System Messaging Server 6.3 Administration Reference의 Option File Format and Available Options)을 참조하십시오. 또한 MTA는 선택적으로 구성 가능합니다. 임계값 초과로 인해 메시지가 강제로 .HELD 상태가 될 때마다 syslog 알림을 생성하려면 HELD_SNDOPR 전역 MTA 옵션을 참조하십시오. Received count exceeded; message held.라는 syslog 메시지가 존재하면 그러한 상황임을 알 수 있습니다.

Sun Java System Messaging Server 6.3 Administration Reference의 release를 실행하거나 다음 단계를 수행하여 .HELD 메시지를 다시 보낼 수 있습니다.

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

    주 –

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

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

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

Received: 헤더 행이 누적되기 때문에 메시지가 다시 .HELD로 표시될 가능성이 있으므로 이 단계를 여러 번 수행해야 할 수 있습니다. 문제가 여전히 계속되는 경우 앞에서 설명한 것처럼 동일한 채널 아래 *.HELD 파일이 다시 만들어집니다. 문제가 해결되었다면 메시지는 대기열에서 삭제되고 배달됩니다.

배달 시도 없이 메시지가 삭제될 수 있게 하려면 Sun Java System Messaging Server 6.3 Administration Reference의 clean을 참조하십시오.

사용자 또는 도메인 hold 상태에 의한 Messages .HELD

사용자 또는 도메인의 hold 상태로 인한 Messages .HELD 및 그러한 이유로 생겨난 messages .HELD는 보관 채널의 대기열 영역에 저장됩니다. 즉, 보관 채널의 대기열 영역에 있는 .HELD 메시지 파일은 사용자나 도메인 상태에 의한 .HELD로 간주할 수 있습니다.

의심스러운 특성에 의한 Messages .HELD

의심스러운 특성 때문에 생긴 Messages .HELD는 그 특성을 나타냅니다. 사이트에서 의심스러운 것으로 규정한 모든 것이 이 특성에 해당될 수 있습니다. MTA 관리자는 이러한 구성 선택 사항과 작업을 알고 있어야 합니다. 그러나 이 MTA의 유일한 관리자 또는 원래 관리자가 아닌 경우 , holdlimit 채널 키워드 사용이 구성되었는지( 12.5.9 여러 주소 확장), MTA 매핑 파일의 주소 기반 *_ACCESS 매핑 테이블에서 $H를 사용하는지 또는 시스템 시브(Sieve) 파일(시스템 수준 imta.filter 파일 또는 sourcefilter나 destinationfilter 채널 키워드를 사용하여 구성, 명명된 채널 수준 시브(Sieve) 필터, 12.12.4 메일함 필터 파일 위치 지정 참조)에서 hold 작업을 사용하는지 MTA 구성에서 확인합니다. 그리고 최근에 수동 명령줄 메시지 보관을 수행했는지(예: imsimta qm clean 명령을 통해) 동료 MTA 관리자에게 문의합니다. 또한 시스템 시브(Sieve) 필터에서 또는 사용자 개인 시브(Sieve) 필터에서의 시브(Sieve) 필터 hold 작업 적용이 선택적으로 기록될 수 있습니다. 자세한 내용은 LOG_FILTER 전역 MTA 옵션(Sun Java System Messaging Server 6.3 Administration Reference의 Option File Format and Available Options 참조)을 참조하십시오.

26.3.9 받은 메시지가 인코딩됨

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가 메시지를 인코딩해야 했습니다.

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

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

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

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

26.3.10.1 사용자 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.

26.3.10.2 일반 구문 문제

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

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

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

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