[ 운송 보안 ]

TLS-RPT 보고 대상 및 보고서 전달

중복 전달을 보장하지 않고 승인된 mailto 또는 HTTPS 수집 경로, 보고 무결성, 타이밍 및 처리 책임을 정의합니다.

EmailAuth 연구팀 제공 · 8분 읽기

[ 핵심사항 ]

  • TLS-RPT 수집과 전송 적용은 별도의 종속성입니다.
  • 여러 루아 대상이 모든 끝점에서 복사본을 보장하지는 않습니다.
  • 수신, 무결성, 구문 분석 및 속성을 별도의 단계로 확인합니다.
이 페이지에서

[ 테이크아웃 ]

승인된 데이터 공유 및 관찰 가능한 전달-처리 단계를 갖춘 자체 서비스 계약으로 보고 대상을 처리합니다.

[ 역할별 ]

이것이 당신에게 의미하는 바

실용적인 다음 단계를 위해 역할을 선택하세요.

IT/메일 관리자

수집을 통한 보고서 추적

엔드포인트 승인은 성공적인 구문 분석과 동일하지 않습니다.

다음 단계

  1. 정확한 보고 기록과 지원되는 URI를 확인하세요.
  2. 수집을 통해 보고서 식별자를 보존합니다.
  3. 압축, 무결성, 속성을 별도로 확인하세요.

CISO/SecOps

신고 채널 승인 및 보호

보고서에는 운영 메타데이터와 신뢰할 수 없는 콘텐츠가 포함되어 있습니다.

다음 단계

  1. 제3자 수신자 및 보존을 승인합니다.
  2. 필수 SMTP 보고서 서명 확인을 유지합니다.
  3. 보고서 전송이 항상 암호화된다고 가정하지 마세요.

창립자 / 비기술자

컬렉션 책임 할당

대상을 게시한다고 해서 누군가가 실패에 대한 조치를 담당하게 되는 것은 아닙니다.

다음 단계

  1. 수집기와 사건 소유자의 이름을 지정합니다.
  2. 아카이브와 대시보드 관계를 정의합니다.
  3. 현실적인 참여와 기대 시기를 설정하세요.

[ 자주 묻는 질문 ]

자주 묻는 질문

TLS-RPT 레코드는 어디에 게시되나요?

정책 도메인 아래의 _smtp._tls 에서 버전 TLSRPTv1 및 rua 대상과 함께 TXT 사용합니다. 이는 MTA-STS 정책 파일과 별개입니다.

RFC 8460

RFC 8460 어떤 대상 체계를 지원합니까?

지원되는 구성표는 mailto 및 https입니다. HTTPS 보고서는 POST를 사용합니다. mailto 보고서는 지정된 사서함 배달 경로를 사용합니다.

RFC 8460

외부 대상에는 DMARC 스타일 인증 레코드가 필요합니까?

RFC 8460 DMARC 스타일 DNS 핸드셰이크를 정의하지 않습니다. 조직 승인 및 수집자별 온보딩을 별도로 확인합니다. 프로토콜 기록을 만들어내지 마세요.

RFC 8460

두 개의 루아 URI가 각각 모든 보고서를 수신합니까?

반드시 그런 것은 아닙니다. 리포터는 지원되는 여러 대상을 시도하거나 하나를 선택할 수 있습니다. 한 끝점에서 성공적으로 수락하면 전달이 만족될 수 있습니다.

RFC 8460

SMTP 보고서에는 어떤 무결성 검사가 적용됩니까?

l=. 없는 유효한 보고 도메인 DKIM 서명이 필요합니다. 키는 s=tlsrpt; 수신자는 해당 서비스 선언이 없는 보고를 무시할 수 있습니다.

RFC 8460

HTTPS 승인은 처리 성공을 증명합니까?

아니요. 성공적인 응답은 배달을 확인하고 수집기가 나중에 처리할 수 있습니다. 대기열, 파서 및 속성 결과를 별도로 추적합니다.

RFC 8460

일일 보고서가 보장되나요?

아니요. UTC일 전체 간격 및 배송 지연이 권장되지만 보고서는 선택 사항이며 보편적인 일일 수신 약속은 따르지 않습니다.

RFC 8460

두 개의 유효한 TLS-RPT 정책 레코드가 게시되면 어떻게 되나요?

리터럴 접두사 " v=TLSRPTv1; "로 시작하지 않는 TXT 리소스 레코드를 삭제한 후 발신자는 정확히 하나의 남은 레코드를 찾아야 합니다. 0개 이상을 찾으면 RFC 8460 에서는 TLS-RPT 구현되지 않았다고 가정하도록 요구합니다. 레코드 경계는 중요합니다. 하나의 TXT 레코드 내의 여러 문자열이 그 자체로 여러 정책 레코드를 의미하지는 않습니다.

RFC 8460 섹션 3

[ 출처 ]

출처

  1. RFC 8460

    섹션 §3. 보고 정책 · §4.1 보고 시간 프레임 · §4.3 결과 유형 · §5.2 압축 · §5.3 이메일 전송 · §5.4 HTTPS 전송 · §5.5 배달 재시도 · §5.6 메타데이터 차이 · §7. 보안 고려 사항

[ 어휘 ]

어휘

루아
TLS-RPT 정책에 게시된 보고 URI 목록입니다.

RFC 8460

신고접수
대상의 성공적인 수신 확인은 이후 처리와 구별됩니다.

RFC 8460

보고서 식별자
보고서를 식별하고 중복 제출을 감지하는 데 사용되는 메타데이터입니다.

RFC 8460

수집가 계약
목적지 소유권, 데이터 처리 및 증거 처리를 다루는 제안된 계약입니다.

기업 출처

최고의 금융 기관과 정부가 필요한 이유 이메일 보안 대시보드를 폐기했습니다.

기존 이메일 인증 플랫폼은 대시보드를 판매하고 엔지니어에게 작업을 요청합니다. 위험이 높은 환경에서 수동 감독은 시행 지연, 구성 드리프트 및 모니터링되지 않는 섀도우 도메인을 의미합니다.

EmailAuth 는 에이전트 이메일 출처 플랫폼입니다. 우리 대리인은 집행합니다 p=reject, 제3자 발신자를 정렬하고 도메인을 전체로 이동하세요. RFC 9989 인간 참여형 감사 기능을 갖춘 새로운 DMARC 표준을 준수합니다.

정부 대기업 1등급 금융기관

SaaS · 전용 테넌시 · Air-Gapped 온프레미스 · BYOK 암호화

기술 자료