요약

  • RFC 9991은 DMARC 실패 보고서가 실패한 한 통의 메일 또는 유사한 원인으로 실패한 메일 묶음을 어떻게 기술하는지 규정한다. 집계 보고서보다 일반적으로 더 신속하며, 더 민감한 원본 자료를 포함할 수도 있다.
  • 도메인 소유자가 공개하는ruf와fo는 공개 요청이지 데이터 수집 명령이 아니다. 메일 수신 측은 여전히 자체 정책, 실패 조건, 프라이버시 판단과 보안 역량에 따라 보고서를 보낼지 여부를 결정한다.
  • Daniel Kade는 목적을 한정한 실패 공개 영수증을 사용해 선택, 삭제·축약, 그룹화, 속도 제한, 전송, 접근 및 삭제 결정을 기록하되 본문, 주소, 자격 증명 또는 악성 페이로드는 저장하지 않을 것을 제안한다.

의심스러운 헤더 한 줄에서 시작된 두 번째 유출

운영 담당자가 갑자기 늘어난 DKIM 정렬 실패를 조사하는 상황을 상상해 보자. 집계 데이터는 특정 출처에 문제가 발생했다는 사실만 알려줄 뿐, 서명 설정 오류인지, 중간 전송 경로의 재작성인지, 사칭 발송인지, 검증 시점의 일시적 이상인지 판단할 수 없다. 원본 헤더의 짧은 조각이면 몇 분 만에 답을 얻을 수 있을 것이다.

그러나 이 헤더 조각은 동시에 수신자, 로컬 서버, 전송 경로, 메일링 리스트 구성원 또는 발신 도메인에 공개된 적 없는 관계까지 노출할 수 있다. 보고서에 메일 전문이 첨부되면 유출 면은 계약, 일정, 제품 계획, 비밀번호, 추적 링크와 악성 첨부파일까지 확장된다. 조사에 필요한 증거와 경계를 넘어서는 안 되는 데이터는 서로 다른 두 파일이 아니라 같은 바이트 묶음이다.

따라서 첫 번째 인증 실패가 두 번째 정보 유출의 자동적 근거가 될 수는 없다. RFC 9991의 중요한 거버넌스 경계는 바로 형식 표준화 때문에 수신 측의 판단을 폐지하지 않았다는 점에 있다. 표준은 요청, 보고서, 처리가 상호 운용 가능하게 만들 뿐, 사적 통신에 대한 지배권까지 도메인 소유자에게 넘기지 않는다.

요청, 생성, 사용은 하나의 권한 부여 행위가 아니다

RFC 9991은 2026년 5월에 발표된 표준 트랙 규격이다. 새로운 DMARC 핵심 규격, 집계 보고서 규격과 함께 RFC 7489의 관련 사항을 대체하고, 이전의 인증 실패 보고 규칙을 갱신한다.

도메인 소유자는 DMARC 정책 레코드에ruf목적지를 기재하고fo로 어떤 실패 조건에 관심이 있는지 표시한다. 이것은 "받고 싶다"는 뜻이지 "반드시 전달해야 한다"는 뜻이 아니다. 메일 수신 조직은 여전히 실제 실패, 요청 옵션, 자체 정책과 적용 의무에 따라 어떤 보고서를 보낼지 결정하며, 하나도 보내지 않을 수도 있다.

이 연쇄에는 적어도 세 개의 자율적 결정이 포함된다. 도메인 소유자는 요청 여부와 요청의 방향을 결정하고, 수신 측은 공개 여부와 축약 수준을 결정하며, 보고서 소비자는 누가 열람할 수 있는지, 어떻게 분석하는지, 얼마나 보존하는지, 이전할지 여부를 결정한다. 앞 단계의 성공은 앞 단계의 조건만 충족할 뿐, 뒤 단계를 대신해 서명할 수 없다.

실패 보고서는 한 통의 메일을 대상으로 할 수도 있고, 유사한 원인의 사건을 하나로 묶을 수도 있으며, 거의 실시간으로 도착한다. 속도는 복구 시간을 줄여 주지만, 프라이버시 재검토, 목적지 확인, 악성 콘텐츠 격리에 걸리는 시간도 압축한다. 훌륭한 자동화는 이 결정들의 경계를 유지해야 하며, 모든 녹색 불을 하나의 "허용"으로 묶어서는 안 된다.

세부 정보가 늘어나면 증거의 성격도 달라진다

악용 보고 형식은 사람이 읽을 수 있는 설명, 기계 판독 가능한 피드백 필드, 원본 메시지 자료를 서로 다른 MIME 부분에 배치한다. RFC 9991은 DMARC에 구체적인 의미를 추가하는데, 여기에는Identity-Alignment, DKIM 관련 세부 정보, SPF의 DNS 정보, 인증 실패 유형이 포함된다.

Identity-Alignment의 의미는 매우 좁다. 정렬된 신원을 인증하지 못한 메커니즘을 나열하며, 시도한 메커니즘이 모두 성공했다면none으로 기재할 수 있다. 서명이 왜 실패했는지 설명하지 않고, 표면상의 발신자가 실제로 메일을 보냈다는 증명도 아니며, 콘텐츠의 악성 여부를 판단하지도 않고, 수신 측의 이후 처리나 공개의 정당성을 입증하지도 않는다.

원본 헤더나 본문은 파생 필드로는 답할 수 없는 질문에 답할 수 있지만, 진단 목적을 넘어서는 사실도 함께 끌어온다. 보고서에 복제되는 순간, 원래 메일 시스템 안에만 존재하던 정보는 새로운 보관자, 새로운 접근 권한 체계와 새로운 보존 시계를 갖게 된다. "포렌식"이라는 목적 설명이 모든 자료를 무제한 데이터 카테고리로 만들지는 못한다.

외부 목적지가 받아들일 의사가 있다는 것이 전체 콘텐츠를 받을 권리와 동일하지는 않다

정책 레코드는 보고서를 조직 도메인 밖으로 보낼 수 있다. RFC 9991은 집계 보고서의 외부 목적지 승인 절차를 계승한다. 목적지는 DNS를 통해 요청 도메인을 대신해 보고서를 받겠다는 의사를 표시해야 한다. 이 검사는 도메인 소유자가 모르는 제3자에게 대량의 보고서를 일방적으로 향하게 하는 것을 막는다.

이것은 필요하지만 입증 범위가 제한적이다. 모든 보고서가 정확하다는 증명도, 모든 필드가 필요하다는 증명도, 소비자에게 법적 또는 계약적 근거가 있다는 증명도 없으며, 데이터가 계속 전달되지 않는다는 보장도 없다. 규격은 또한 조직 내부로 보이는 목적지 자체가 보고서를 외부로 보낼 수 있다고 명시적으로 경고한다. 공개 주소를 읽는다고 최종 도착지를 확인할 수는 없다.

따라서 시스템은 두 가지 질문을 각각 답해야 한다. 이 주소가 보고서 목적지로서 자격이 있는가? 그리고 이번 구체적 공개가 비례에 맞는가? 두 질문을 합치면 "어떤 보고서를 받을 의사가 있다"가 "생성 측이 우연히 보유한 모든 콘텐츠를 받을 권리가 있다"로 잘못 기재된다.

최소화는 보고서를 쓸모없게 만드는 것이 아니다

RFC 9991은 요청의 목적과 기간을 제한하고, 보고서 URI를 엄격히 통제하며, 본문과 헤더를 축약하고, 안전한 전송을 채택할 것을 권고한다. 동시에 많은 대형 서비스 제공업체가 실제 프라이버시 비용 때문에 실패 보고를 제한하거나 중단했다는 점도 인정한다.

축약은 삭제와 같지 않다. RFC 6590은 일관되고 충돌에 강한 변환 방법을 기술해, 소비자가 원본 값을 보지 않고도 두 개의 가려진 문자열이 본래 동일했는지 판단할 수 있게 한다. 이는 보고서 간 그룹화 능력과 연관 가능성을 유지한다. 같은 키와 변환이 오랫동안 여러 목적으로 사용되면 익명 표식이 점차 안정적인 관계 색인이 된다.

책임 있는 구현은 변환 버전과 적용 범위를 기록하고, 목적별로 키를 격리하거나 교체하며, 원본 값과 축약 값이 같은 광범위한 로그에 들어가지 않도록 해야 한다. 조사 자체에 사건 간 연관이 필요 없다면 장기 안정 표식을 기본 생성해서는 안 된다. 때로 최소 충분 공개는 실패 카테고리이고, 때로는 일회성 케이스 번호이며, 때로는 보고서를 보내지 않는 것이다.

최소화는 구체적인 진단 질문을 기준으로 검수되어야 한다. 축약이 부족하면 사적 통신이 불필요하게 조직 경계를 넘고, 지나치게 많으면 보고서가 문제 해결에 도움이 되지 않으면서도 여전히 수신, 파싱, 저장 위험을 만든다. 영원히 옳은 필드 목록은 존재하지 않는다. 검증 가능한 목적과 선택만이 존재한다.

속도 제한은 "보고서 없음"을 다의어로 만든다

실패 보고서 자체가 무기화될 수 있다. 공격자가 피해 도메인을 사칭한 메일을 대량 발송하면, 참여 수신 측이 보고서 트래픽을 피해자 또는 그 수탁자에게 보내도록 유도할 수 있다. 이 때문에 RFC 9991은 생성 측의 속도 제한을 요구하고, 유사 사건의 병합 또는 한도 초과 보고서의 폐기를 허용한다. 목표는 각 메일을 정확히 세는 것이 아니라 서로 다른 실패 조건을 드러내는 것이다.

이는 소비자가 실패 보고서 흐름을 완전한 사건 장부로 취급할 수 없다는 뜻이기도 하다. 침묵은 조건에 맞는 실패가 없다는 뜻일 수도 있고, 수신 측이 참여하지 않거나, 프라이버시 정책이 공개를 막거나, 보고서가 그룹화되었거나, 속도 제한이 작동했거나, 전송이 실패했거나, 진단 기간이 만료되었다는 뜻일 수도 있다. 갑작스러운 증가는 새로운 장애일 수도 있고, 정책 변경이거나 인위적으로 만든 홍수일 수도 있다.

소비자는 수량을 해석하기 전에 생성 측이 선언한 그룹화 및 속도 제한 배경을 알아야 한다. 생성 측은 폐기된 사유의 로컬 요약을 보존해야 하며, 폐기 행위를 설명하겠다고 또 하나의 민감한 메일별 기록 체계를 만들어서는 안 된다. 제한된 시간 창과 사유별로 개수를 기록하는 것만으로도 충분한 경우가 많다.

보고서 역시 신뢰할 수 없는 입력이다

실패 보고서는 스팸, 피싱 콘텐츠, 악성코드, 기만 링크와 첨부파일을 재현할 수 있다. 규격은 처리 환경을 격리, 샌드박스화, 분할하고 훈련을 받고 권한을 부여받은 인원만 접근하도록 권고한다. 소비자가 보고서를 일반 메일함, 티켓 미리보기 또는 전역 검색에 넣으면 본래 조사하려던 사건을 오히려 확대할 수 있다.

보고서 흐름 자체가 DMARC를 통과하고 정렬되게 하면 전송 신원을 예상 발신 도메인에 묶을 수 있지만, 포함된 콘텐츠가 자동으로 안전해지지는 않으며, 기계 필드의 모든 판단을 입증하지도 않고, 모든 분석자에게 원본 메일 열람 권한을 부여하지도 않는다. 신원 인증, 콘텐츠 보안, 데이터 자격과 운영 접근은 네 가지 서로 다른 통제다.

가장 가치 있는 자동화는 거부의 형태로 나타나는 경우가 많다. 활성 콘텐츠 제거, 지원되지 않는 MIME 구조 거부, 첨부파일 격리, 압축 해제와 파싱 자원 제한, 보고서의 범용 검색 차단이 그것이다. 파싱 성공은 통제된 보관의 출발점이지 공개 결정의 종착점이 아니다.

목적을 한정한 실패 공개 영수증

나는 공개 정책과 예외 발생 시마다 이를 위해 컴팩트한 영수증을 생성할 것을 제안한다. 이는 거버넌스 제안이지 IETF 규격에 새 요구사항을 추가하는 것이 아니다.

영수증은 먼저 DMARC 정책 도메인, DNS 조회 시각과 결과, 요청된ruf목적지와fo조건, 외부 승인 결과, 수신 측 정책 버전, 용도와 만료일을 기록한다. 이어서 실패 카테고리, 단건 또는 그룹 속성을 표시하고, 선택된 데이터 카테고리만 나열한다. 예컨대 파생된 인증 필드, 제한된 추적 헤더, 축약된 주소 표식 또는 한정된 메시지 조각 등이며, 데이터 자체를 복제하지는 않는다.

영수증은 또한 축약 알고리즘 버전, 연관 범위, 그룹화 규칙, 속도 제한 결과, 안전 전송 결과와 생성 오류를 보존해야 한다. 소비 측에서는 역할, 접근 경계, 격리 결과, 보존 기간, 삭제 또는 대체 사건을 책임질 수 있는 결정에 묶어야 한다.

영수증이 절대 그림자 메일함이 되어서는 안 된다. 본문, 주소 로컬 부분, 수신자 주소, 자격 증명, 클릭 가능한 악성 링크와 첨부파일은 모두 영수증 밖에 두어야 한다. 콘텐츠 지문도 위험과 용도가 실제로 필요할 때만 사용하며, 명확한 범위와 만료 시각이 있어야 한다.

그러면 나중에 누군가 "왜 이 바이트들이 이 경계를 넘었는가"라고 물었을 때, 답이 단순히 "DNS가 요청했기 때문"이 아니게 된다. 검증 가능한 로컬 결정 연쇄가 답이 될 것이다.

출처

  1. Lu Heng: 데이터 주권의 기술적 현실과 실제적 현실
  2. Lu Heng: BTW Media가 존재하는 이유
  3. Lu Heng: 정책의 거울
  4. IANA: 메일 악용 보고 형식 파라미터
  5. RFC 9991 정보 페이지
  6. RFC 5322: 인터넷 메시지 형식
  7. RFC 5965: 확장 가능한 메일 피드백 보고 형식
  8. RFC 6590: 메일 악용 보고의 민감 데이터 축약
  9. RFC 6591: ARF를 이용한 인증 실패 보고
  10. RFC 6650: 메일 피드백 보고서의 생성과 사용
  11. RFC 7489: DMARC
  12. RFC 9989: DMARC
  13. RFC 9990: DMARC 집계 보고서
  14. RFC 9991: DMARC 실패 보고서