test

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

일반 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 문자가 아니라)를 검사하고 이 문자를 별표로 바꿉니다.