test

Sun Java System Messaging Server 6.3 관리 설명서

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 참조)을 참조하십시오.