레코드를 추가하기 전에 누락된 단계를 찾으세요.
경고 MTA-STS 정책 누락은 진단이 아니라 검색 결과를 설명합니다. 수신 도메인에 검색 기록이 부족하거나, 여러 경쟁 기록을 게시하거나, 잘못된 HTTPS 리소스를 제공하거나, 한 발신자가 검색할 수 없는 정책이 이미 있을 수 있습니다. 다른 만들기 TXT 레코드 이러한 케이스를 분리하기 전에 복구 가능한 문제를 더욱 악화시킬 수 있습니다. 정확한 도메인과 경고 뒤에 숨겨진 증거부터 시작하세요.
다큐멘터리 조사 계획입니다. DNS 조회, 고객 호스트로부터의 정책 다운로드, SMTP 연결 또는 공급자 변경이 수행되지 않았습니다. 아래의 사례는 허구입니다. 운영상의 결론을 내리려면 관련 인프라와 가능한 경우 보고 발신자의 정책 상태에서 타임스탬프가 표시된 관찰이 필요합니다.
정책 도메인 설정
example.com 사서함으로의 일반적인 배달의 경우 검색은 다음에서 시작됩니다. _mta-sts.example.com. 정책은 다음에서 가져옵니다. https://mta-sts.example.com/.well-known/mta-sts.txt. 하위 도메인의 사서함에는 해당 하위 도메인에 대한 검색이 필요합니다. 규정을 준수하는 발신자는 상위 정책으로 대체되어서는 안 됩니다. 관리적으로 구성된 스마트 호스트는 다른 정책 도메인 선택을 도입하므로 조사가 직접 전달에 관한 것인지 아니면 릴레이에 관한 것인지 기록하십시오. RFC 8461 섹션 3.1-3.4
타임스탬프, 쿼리 이름, 레코드 유형 및 전체 결과에 대해서는 경고 소유자에게 문의하세요. "누락"이라고 표시된 스크린샷은 존재하지 않는 이름, 사용 가능한 기록이 없는 성공적인 답변 또는 시간 초과를 구분할 수 없습니다. 나중에 승인될 때 권위 있는 관찰과 반복적인 관찰을 모두 유지합니다. DNS 네거티브 캐싱은 이전 부재를 보존할 수 있으므로 현재 제어판 디스플레이가 모든 확인자의 답변을 설명하지는 않습니다. RFC 2308
전체 검색 답변을 평가하세요.
발견 기록은 다음으로 시작됩니다. v=STSv1; 그리고 다음을 포함합니다 ID 정책 인스턴스를 식별합니다. 식별자는 변경을 나타냅니다. 정책을 포함하지 않거나 연대순 정렬을 적용하지 않습니다. 필수 버전 접두사가 없는 레코드가 삭제된 후에는 사용 가능한 레코드가 정확히 하나만 남아 있어야 합니다. 따라서 여러 개의 일치하는 TXT 레코드는 검색 실패의 원인이 될 수 있으며 세 번째 레코드를 추가할 이유는 아닙니다. RFC 8461 섹션 3.1
기록 경계를 보존합니다. 하나의 TXT 레코드 내에서 인용된 여러 문자열은 삽입된 공백 없이 연결됩니다. 여러 TXT 레코드는 별도의 레코드로 유지됩니다. 어떤 발견이라도 따라가세요 CNAME 연결하고 목표 답변을 유지합니다. RFC 8461 이러한 위임을 허용합니다. DNS 공급자의 편집 인터페이스는 이러한 사례를 유사하게 표시할 수 있으므로 쓰기를 제안하기 전에 실제 응답을 의도한 구성과 비교하십시오. RFC 8461 섹션 3.1
HTTPS 검색을 별도로 추적
유효한 검색 레코드는 고정된 HTTPS 정책 위치로 연결됩니다. 서비스는 정책 호스트에 유효한 신뢰할 수 있고 만료되지 않은 인증서를 제공해야 합니다. 유효한 가져오기에는 HTTP 200이 필요합니다. 리디렉션을 따라서는 안 됩니다. 따라서 자동으로 리디렉션을 따르는 브라우저는 손상된 엔드포인트를 정상으로 보이게 만들 수 있습니다. 최종적으로 표시되는 페이지뿐만 아니라 첫 번째 응답 상태와 원래 URL을 캡처하세요. RFC 8461 섹션 3.3
반환된 본문을 정책 텍스트로 검사합니다. 버전, 모드, 최대 기간 및 필수 MX 항목을 문법과 비교하여 확인하세요. 발신자는 텍스트/일반 미디어 유형을 확인해야 합니다. 상태 200으로 반환된 로그인 페이지 또는 브랜드 오류 문서는 사용 가능한 정책이 되지 않았습니다. 구문은 반복되는 MX 필드를 허용합니다. 중복된 싱글톤 필드는 다르게 처리되므로 자동으로 정규화하는 대신 원래 바이트를 유지합니다. RFC 8461 섹션 3.2
배송 확인과 검색을 별도로 유지
정책을 얻은 후에는 해당 MX 패턴을 실제 후보 호스트 이름과 비교하십시오. 허용되는 와일드카드는 임의의 수준이 아닌 가장 왼쪽의 하나의 레이블을 모두 포함합니다. 그런 다음 평가 STARTTLS 선택한 MX 호스트에 대한 수신 서버의 인증서. 이는 HTTPS 정책 서비스에서 인증서 유효성을 검사하는 것과는 다른 검사입니다. 성공적인 정책 다운로드는 메일 서버를 인증하지 않습니다. RFC 8461 섹션 4.1-4.2
또한 보낸 사람 캐시 상태도 기록합니다. 라이브 정책을 검색하거나 가져오는 데 실패하더라도 유효하고 만료되지 않은 캐시된 정책은 삭제되지 않습니다. 반대로, 사용 가능한 캐시 정책이 없고 HTTPS 가져오기에 실패한 발신자는 마치 도메인이 MTA-STS 구현하지 않은 것처럼 진행됩니다. 해당 설명은 MTA-STS 에만 적용됩니다. 다른 적용 가능한 운송 정책은 여전히 배송을 제한할 수 있습니다. RFC 8461 섹션 3.3
허구의 중복 기록 사례를 통해 작업
가상의 example.com 운영자가 호스팅 공급자를 변경한 후 "정책 누락" 경고를 보았다고 가정해 보겠습니다. 제안된 증거 패킷에는 두 개의 별도 검색 TXT 레코드가 포함되어 있습니다. id=old1 그리고 하나는 id=new2, 둘 다 유효한 버전 접두사로 시작됩니다. HTTPS 엔드포인트는 올바른 테스트 정책을 제공하는 것으로 가정됩니다. 이는 고안된 관찰이지 여기에 수집된 결과가 아닙니다.
검색 규칙에 따라 남아 있는 두 레코드는 사용 가능한 정책을 선택할 수 없도록 합니다. 그럴듯한 복구는 의도된 현재 레코드를 식별하고 더 이상 사용되지 않는 중복 항목의 제거를 검토하는 것이지 HTTPS 서비스를 다시 만드는 것은 아닙니다. 해당 제안에는 여전히 소유권과 변경 승인이 필요합니다. 후속 추적에서는 하나의 검색 레코드, 의도된 HTTPS 본문 및 MX 적용 범위를 확인합니다. 이전 보낸 사람 캐시는 정책 상태가 변경될 때까지 다른 동작을 생성할 수 있습니다.
제한된 출시 결정으로 마무리
조사를 통해 새로운 배포가 지원되는 경우 통제된 테스트부터 시행까지의 계획을 준비하세요. 백업을 포함하여 의도된 모든 MX 호스트를 식별하고 HTTPS 가용성을 설정하고 준비합니다. TLS-RPT 수집. 테스트 모드에서는 발신자가 배달을 차단하지 않고도 MTA-STS 검증 실패가 보고될 수 있습니다. 조용한 보고 사서함은 준비 상태에 대한 충분한 증거가 아닙니다. RFC 8461 섹션 5-6
정책 본문이 변경되면 검색 식별자와 DNS TTL 및 기존 캐시에 대한 계정을 변경하기 전에 HTTPS 본문을 게시하세요. 원본 추적, 제안된 차이점 및 롤백 소유자를 함께 유지합니다. 현재 RFC 8461 정오표는 별도로 확인되었습니다. 보고된 제안은 승인된 대체 제안으로 처리되지 않았습니다. 누락된 DNS-HTTPS-to-MX 추적 및 제어된 롤아웃 증거는 명시적인 릴리스 게이트로 남아 있습니다. RFC 8461 섹션 8.1 현재 정오표