강화된 상태 코드는 완전한 사건 보고서가 아닌 구조화된 단서입니다. “5.7.1”은 조사 범위를 보안이나 정책으로 좁힐 수 있지만 정책 소유자, 영향을 받는 경로를 식별하거나 자체적으로 구성 변경을 수정할 수는 없습니다. 문제 해결 전반에 걸쳐 코드 옆에 완전한 진단을 유지하십시오.
세 가지 구성요소 모두 읽기
RFC 3463 클래스, 주제 및 세부 구성 요소로 향상된 상태 코드를 정의합니다. 클래스는 성공, 지속적인 일시적 실패 및 영구적 실패를 구별합니다. 주제 범주는 주소 지정, 사서함 상태, 라우팅, 보안 또는 정책과 같은 영역을 구분합니다. 세부 사항은 해당 주제 내의 조건을 좁힙니다. 일반적인 세 자리 SMTP 응답은 증거의 일부로 남아 있습니다. RFC 3463.
마지막 숫자를 전역 오류 식별자로 처리하지 마십시오. 의미는 완전한 강화 코드와 해당 등록 또는 공급자 문서에 따라 달라집니다. 수신 시스템은 향상된 코드 없이 유용한 산문을 반환할 수도 있습니다. 기본 클래스와 고급 클래스가 일관되지 않은 것으로 나타나면 로그를 자동으로 다시 작성하는 대신 정확한 바이트를 유지하고 공급자 동작을 조사하십시오.
배달 보고서와 별도의 SMTP 응답
대화 중에 SMTP 응답이 발생합니다. 배달 상태 알림은 나중에 결과를 보고할 수 있으며 여러 수신자를 설명할 수 있습니다. RFC 3464 최종 수신자, 작업, 상태, 원격 MTA 및 진단 코드를 포함한 필드를 정의합니다. 수신자별 블록을 독립적으로 읽습니다. 한 번의 실패로 인해 모든 수신자가 실패했음을 증명할 수는 없습니다. RFC 3464 섹션 2.
작업과 상태는 서로 다른 질문에 답합니다. 조치: 실패는 보고를 의미합니다. MTA 해당 수신자에 대한 시도를 중지했습니다. 상태: 4.2.2에서는 재시도가 소진된 후에도 일시적인 사서함 가득 참 원인을 계속 설명할 수 있습니다. 실패 및 4.xx 상태는 일관되지 않은 SMTP 응답이 아닌 DSN에서 유효합니다. 예를 들어 해당 필드가 포함된 만료된 항목은 용량이 반환된다는 이유만으로 자동으로 재개되지 않습니다. 교체를 승인하기 전에 실제 대기열을 확인하세요. 보다 RFC 3464 섹션 2.3.3.
사람이 읽을 수 있는 반송 제목은 분류에 유용하지만 결정적인 필드를 생략할 수 있습니다. 가능하면 기계가 읽을 수 있는 보고서를 얻거나 로그를 전송하십시오. 보고 서버를 원격 서버와 별도로 유지하고 보고서의 타임스탬프를 실패한 SMTP 명령의 타임스탬프와 구별하세요.
가상의 수신자 블록 읽기
전송 로그에 missing@example.test 에 대한 RCPT TO와 550 5.1.1이 기록되어 있다고 가정합니다. 예시적인 DSN 수신자 블록에는 최종 수신자: rfc822가 포함될 수 있습니다. missing@example.test , 작업: 실패, 상태: 5.1.1, 원격-MTA: dns; mx.example .test 및 진단 코드: smtp; 550 5.1.1 해당 사용자가 없습니다. 이는 실행된 트랜잭션이나 완전한 MIME 보고서가 아닌 고안된 필드 값입니다.
실패한 작업은 이 수신자에 대한 최종 결과이며 진단에서는 주소 지정을 가리킵니다. 주소를 사용할 수 없는 이유나 다른 수신자에게 무슨 일이 일어났는지는 밝혀지지 않습니다. 자체 블록과 신뢰할 수 있는 로그에서 답변을 얻으세요. 최종 수신자, 작업 및 상태는 수신자별 필수 필드입니다. 원격 MTA 및 진단 코드는 조건부이거나 선택 사항입니다. 그들의 부재는 거부 호스트 또는 오류 텍스트를 만들 수 있는 권한이 아닙니다.
익숙하지 않은 등록 내용에 대해서는 현재 IANA 강화 상태 등록 인용된 사양, 공급자의 현재 설명입니다. RFC 3463 이후의 모든 코드에 대한 전체 목록이 아닌 프레임워크를 제공합니다.
코드를 테스트 가능한 가설로 전환
주소 지정 코드의 경우 의도된 주소와 수신 시스템 동작을 확인합니다. 라우팅 코드의 경우 실패한 다음 홉 및 경로 구성을 검사합니다. 보안 또는 정책 코드의 경우 명명된 요구 사항과 해당 소유자를 식별합니다. 선호하는 DNS 변경으로 시작한 다음 모든 응답을 이에 대한 지원으로 해석하지 마십시오.
하나의 가설과 그것이 예측하는 증거, 그리고 가장 작은 승인된 테스트를 기록합니다. 수정된 메시지는 해당 경로 및 수신자 클래스에서 원본과 비교되어야 합니다. 모순된 결과를 원래의 설명으로 강요하기보다는 유용한 증거로 보존합니다. 에스컬레이션 패킷에는 타임스탬프, 정확한 응답, 영향을 받는 범위 및 이미 테스트된 변경 사항이 포함되어야 하며 메시지 내용과 개인 데이터는 최소화되어야 합니다. 코드 조회는 진단의 완료가 아닌 진단의 시작입니다.
유용한 에스컬레이션 패킷 구축
- ID: 메시지 및 대기열 식별자, 실패한 봉투 수신자 및 영향을 받는 범위를 유지합니다.
- 타임라인: 제출, 실패한 시도 및 보고서 도착을 별도로 기록합니다.
- 진단: 정확한 SMTP 응답, 명령 단계 및 수신자별 DSN 필드를 포함합니다.
- 소유권: 보고 시스템과 거부 시스템을 구분하고 각각에 대한 증거를 제시합니다.
- 다음 단계: 테스트 가능한 원인 하나, 승인된 가장 작은 수표 및 모순되는 증거를 기술합니다. 개인 데이터를 최소화하세요.