test

Sun Java System Messaging Server 6.3 관리 설명서

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