루핑에 의한 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을 참조하십시오.