메일이 대기열에서 제외되지 않음 (Sun Java System Messaging Server 6 2005Q4 관리 설명서)

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

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

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

NSLOOKUP 유틸리티를 사용하여 이 호스트에 어떤 MX 레코드가 있는지(있는 경우) 확인합니다. MX 레코드가 없으면 호스트에 직접 연결해야 합니다. MX 레코드가 있으면 지정된 MX 중계에 연결해야 합니다. 명시적으로 연결하지 않도록 구성된 경우를 제외하면 MTA는 우선적으로 MX 정보를 적용합니다. TCP/IP MX 레코드 지원을 참조하십시오.
이 예에서 DNS(도메인 이름 서비스)는 xtel.co.uk에 대해 지정된 MX 중계의 이름을 반환합니다. 이 호스트는 MTA가 실제로 연결할 호스트입니다. 둘 이상의 MX 중계가 나열된 경우 MTA는 각 MX 레코드를 기본값이 낮은 것부터 오름차순으로 연속해서 시도합니다.
원격 호스트에 연결된 경우 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이라는 도메인을 사용한다고 가정합니다.

새 채널 만들기

단계

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 풀의 컴퓨터 자원만 사용하도록 지정합니다. 또한 새 채널의 앞뒤에 빈 행이 필요하다는 것에 주의하십시오.

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는 일치한 도메인 지정 부분을 복사합니다.

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

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

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 메일이 사용하는 처리 자원을 경합하지 않아도 다른 채널이 해당 메일을 전달할 수 있습니다. 새 채널을 만들어 이 문제를 해결하는 방법은 아래에서 설명합니다.