질문과 수신자를 먼저 정의하세요.
공급업체는 서명 문제를 진단하기 위해 증거가 필요할 수 있습니다. 조정 불일치 또는 보고 불일치. 조직의 모든 도메인에 대한 모든 보고서가 필요한 경우는 거의 없습니다. 정확한 질문, 관련된 제품 및 계정, 대상 수신자 및 증거를 통해 어떤 결정을 내릴 수 있는지 설명하는 것부터 시작하십시오. 이는 "에 대한 요청을 방지합니다. DMARC 데이터”가 불필요하게 광범위하게 공개되는 것을 방지합니다.
수신자가 관련 서비스에 대한 승인된 지원 또는 엔지니어링 담당자인지 확인하십시오. 친숙한 표시 이름이나 전달된 요청만으로는 모든 첨부 파일을 해당 위치로 보내도록 설정하기에 충분하지 않습니다. 패키지 초안 작성은 패키지 전송 권한과 별개입니다. 이 문서에서는 준비에 대해서만 설명하며 이메일, 업로드 또는 외부 공유를 승인하지 않습니다.
영향을 받는 경로 및 간격에 범위를 연결하십시오. 자체 영수증 작업 흐름을 조사하는 공급업체는 단지 해당 관찰 내용이 동일한 집계 파일을 차지한다는 이유만으로 관련 없는 직원 메일, 마케팅 또는 기타 공급업체 트래픽을 수신해서는 안 됩니다.
보고서에서 알 수 있는 내용 이해
집계 보고서 발신자의 인프라 및 트래픽 측면을 밝힐 수 있는 기술적 관찰 및 정책 정보가 포함되어 있습니다. RFC 9990 수신자 및 보고서 데이터에 대한 개인 정보 보호 고려 사항을 논의합니다. 필드가 메시지 본문이 아닌 경우에도 공급업체의 작업에는 필요하지 않을 수 있습니다. 모든 집계 정보가 무해하다고 가정하기보다는 최소화를 필드별 결정으로 처리하십시오.
실패 보고서 아래에 별도의 잠재적으로 더 자세한 노출 표면이 있습니다. RFC 9991. "보고서"에 대한 일반 승인을 받아 집계 요약과 함께 묶지 마십시오. 보고서 유형, 내용 및 수신자 목적을 명시적으로 식별합니다. 진단 질문에 더 작은 요약이나 수정된 발췌문으로 답변할 수 있는 경우 완전한 원시 아티팩트보다 이를 선호합니다. RFC 9990 , 섹션 7.1 및 7.2; RFC 9991 , 섹션 7.1 및 7.2
수정 전 데이터 필드 맵 구축
필드 맵에는 각 후보 항목, 필요한 이유, 정확한 값이 필요한지 여부, 제안된 처리 방법 및 제거 결과가 나열되어야 합니다. 잠재적인 항목에는 관련 보낸 사람 도메인, 서명 도메인, 선택자, 봉투 도메인, 소스 주소, 보고 간격, 개수 및 평가 결과. 그 필요성은 질문에 달려 있습니다. 항상 전송되어야 하는 범용 번들은 없습니다.
정렬을 진단하거나 계정별 구성을 찾으려면 정확한 기술 ID가 필요할 수 있습니다. 해당 값을 승인된 범위 내에서 공유할 수 없는 경우 오해의 소지가 있는 값으로 대체하기보다는 진단 제한 사항을 설명하십시오. 다른 식별자는 관계를 유지하면서 제거하거나 지속적으로 가명화할 수 있습니다. 필요하고 승인된 경우에만 비공개 매핑을 유지하고 기본적으로 공급업체 패키지에 포함하지 마세요.
관련 없는 행과 도메인, 불필요한 수신자 주소, 메시지 내용, 내부 메모 및 비밀을 제거합니다. 지원 아티팩트에 비밀번호, API 키, 세션 토큰 또는 자격 증명을 포함하지 마십시오. 파일 이름, 메타데이터, 스크린샷, 숨겨진 스프레드시트 콘텐츠는 물론 표시되는 텍스트도 검토하세요. 수정된 단락은 첨부 파일이 최소화된다는 것을 보장하지 않습니다.
진단 관계 유지
유용한 증거 샘플은 원시 인증 결과와 정렬 간의 차이를 유지해야 합니다. DMARC 실패한 이유에 대한 질문이 있는 경우 모든 도메인을 동일한 자리 표시자로 바꾸면 공급업체가 이해해야 하는 관계가 지워질 수 있습니다. ID가 동일한지, 관련이 있는지, 다른지 여부를 유지하고 합성 대체 항목에 명확하게 라벨을 지정하여 쿼리할 실제 DNS 이름으로 착각하지 않도록 합니다.
보고 간격, 관련 결과 필드 및 범위 참고 사항을 함께 유지하십시오. 선택한 행만 공유하는 경우 샘플이 필터링되었음을 명시하고 선택 규칙을 식별합니다. 예제를 더 단순하게 보이도록 결과를 변경하지 말고 필터링된 수가 조직의 총 트래픽을 나타낸다는 것을 암시하지 마십시오. 필요한 경우 보유 필드와 함께 간결한 분석가 설명을 제공합니다. RFC 9989 , 섹션 4.4; RFC 9990 , 섹션 3.1
승인 및 보존 워크시트
수신자, 조직, 제품, 목적, 정확한 파일 또는 필드, 영향을 받는 도메인 또는 경로, 시간 간격, 민감도, 전송 방법 및 보존 결정에 대한 승인 기록을 준비합니다. 공급업체가 사례용으로만 자료를 보유할 수 있는지, 다른 목적으로 사용하거나 향후 공유할 수 있는지 확인하십시오. 일반적인 지원 관계가 관련 없는 재사용이나 광범위한 액세스를 승인한다고 가정하지 마십시오.
보존 결정은 공급업체 사본과 조직의 작업 사본을 모두 다루어야 합니다. 의도된 기간 또는 삭제 트리거를 기록하고, 그것이 중요한 경우 완료를 확인할 수 있는 사람을 기록하십시오. 이는 공급업체 계약이 이미 특정 조건을 제공한다는 주장이 아니라 제안된 거버넌스 프로세스입니다. 사용 가능한 조건이나 수신자 액세스 권한이 불분명한 경우 전송하기 전에 이를 해결하세요.
수락하려면 검토자가 최종 패키지를 승인된 현장 지도와 비교해야 합니다. 단순한 설명이 아닌 실제 첨부 파일에 관련 없는 행, 숨겨진 데이터 및 우발적인 비밀이 있는지 확인해야 합니다. 변경된 수신자, 확장된 데이터 세트 또는 새로운 목적은 동일한 공유의 무해한 연속으로 취급되기보다는 갱신된 검토를 촉발해야 합니다.
단일 서명 경로에 대한 가상 지원 패키지
정렬된 영수증을 조사하는 가상의 영수증 공급업체를 상상해 보십시오. DKIM 실패. 조직의 원시 집계 보고서에는 직원 메일 및 캠페인 관찰 내용도 포함됩니다. 이 예에서는 실제 보고서나 공급업체 요청에 액세스하지 않았습니다. 제안된 패키지에는 관련 수신 경로 행, 제한된 보고 간격, 관련 신원 관계 및 불확실한 사항에 대한 간단한 설명만 포함됩니다.
직원 및 캠페인 행은 공급업체의 질문에 답변하지 않으므로 제외됩니다. 공급업체에 정확한 서명 도메인이나 선택자가 필요한 경우 조직은 해당 수신자와 목적에 맞게 해당 값을 승인해야 합니다. 이를 모호하게 만드는 수정된 샘플은 여전히 개념적 논의에 유용할 수 있지만 실시간 DNS 진단에는 충분하지 않습니다.
최종 승인에는 사례별 보존 결정도 기록됩니다. 단지 초안이 완료되었다고 해서 패키지가 전송되는 것은 아닙니다. 공급자가 나중에 전체 메시지 샘플을 요청하는 경우 이는 특히 수신자나 메시지 본문을 소개하는 경우 다른 개인정보 보호 프로필을 사용하는 새 콘텐츠 요청입니다. 다음 단계는 자동 확장이 아닌 범위 지정 검토입니다.
증거 및 공개 상태
카탈로그에는 데이터 필드 맵과 명시적인 보존 결정이 포함된 승인된 최소 증거 샘플이 필요합니다. 이 글은 준비 방법과 가상의 패키지 디자인만을 제공합니다. 실제 샘플이 승인되지 않았고, 수신자가 확인되지 않았으며, 전송 또는 공급업체 삭제가 확인되지 않았습니다.
6개의 릴리스 게이트는 모두 열려 있습니다. 자격을 갖춘 검토자는 제안된 최소화가 수신자와 목적 제한을 존중하면서 진단 질문을 유지하는지 확인해야 합니다. 실제 공유 전에 실제 데이터 및 대상에 대해 필요한 승인을 얻으십시오. 안전하게 준비된 초안은 귀중한 진전이지만 공급업체가 무엇인가를 받거나 처리했다는 증거는 아닙니다.