[ 헤더 및 배송 오류 ]

반복 가능한 이메일 전달 사건 증거 팩 구축

다른 분석가가 재현할 수 있는 원본, 파생물, 타임라인 및 관찰된 내용에 대한 명시적 제한을 포함하여 사건 팩을 구축합니다.

EmailAuth 연구팀 제공 · 4분 읽기

[ 핵심사항 ]

  • 다른 분석가가 재현할 수 있는 원본, 파생물, 타임라인 및 관찰된 내용에 대한 명시적 제한을 포함하여 사건 팩을 구축합니다.
  • 모든 조사 결과에는 증거, 불확실성 및 다음 조치가 명시되어야 합니다. 일치하는 해시는 진실이 아닌 바이트 일관성을 설정합니다.
이 페이지에서

증거 팩을 사용하면 두 번째 분석가가 수집 작업을 반복하거나 어떤 파일이 신뢰할 수 있는지 추측하지 않고도 사건을 이해할 수 있어야 합니다. 독자의 질문과 실제 배송 경로를 중심으로 구성하세요. 스크린샷의 큰 ZIP은 출처가 명확하고 질문이 해결되지 않은 추적 가능한 작은 아티팩트 세트보다 유용성이 떨어집니다.

사건과 범위를 명시하세요.

예상되는 동작, 관찰된 증상, 영향을 받은 기간, 관련 발신자 및 수신자 범위, 비즈니스 영향 및 아직 답변되지 않은 질문 등 간단한 사례 요약으로 시작하세요. 개별 실패를 더 넓은 추세와 구별합니다. 증거가 공급자 테넌트, 로컬 테스트 또는 구성된 교육 사례에서 나온 것인지 기록합니다.

현재의 가설을 확립된 사실과 분리하세요. 예를 들어, "게이트웨이가 본문을 수정했을 수 있습니다"는 전후 바이트 또는 이에 상응하는 신뢰할 수 있는 증거가 이를 뒷받침할 때까지 가설입니다. 에이 DKIM 오류만으로는 수정 시스템을 식별할 수 없습니다. RFC 6376 자동 책임 귀속이 아닌 서명 확인을 설명합니다. RFC 6376 섹션 6.

원본을 보존하고 매니페스트 만들기

수정되지 않은 수신 메시지, 관련 발신자 로그, 수신자 진단 및 승인된 DNS 관찰을 제한된 원본 영역에 보관하십시오. 각 아티팩트에 대한 수집 방법, 수집기, 시간, 시간대 및 SHA-256 해시를 기록합니다. 자체 해시 및 변환 로그가 포함된 별도의 영역에 삭제된 파생 상품을 배치합니다. 해시는 매니페스트에 대해 바이트 일관성을 확인합니다. 기본 주장을 인증하지 않습니다.

DNS 증거의 경우 정확한 쿼리, 레코드 유형, 확인자, 응답 시간 및 반환된 데이터를 기록합니다. 오늘 기록의 스크린샷은 어제의 구성에 대한 역사적 증거가 아닙니다. 메시지의 경우 서명 확인이 필요할 때 원시 바이트를 유지하고 대체가 아닌 편의 보기로 사람이 읽을 수 있는 추출을 유지합니다.

수신자별 타임라인 구축

제출, 릴레이 수락, 수신자별 거부, 재시도, 최종 응답 및 알림을 개별 이벤트로 추적합니다. 모든 행에 소스 파일 이름이나 해시를 포함합니다. RFC 5321 SMTP 수락 및 재시도 컨텍스트를 설명합니다. RFC 3464 배달 상태 수신자 블록을 정의합니다. RFC 5321, RFC 3464.

정규화된 UTC 값과 함께 원래 타임스탬프를 유지합니다. 불확실한 클럭 오프셋과 누락된 이벤트를 표시합니다. 릴레이의 최종 250 응답에서 사서함 배치를 추론하거나 집계에서 특정 메시지 결과를 추론하지 마십시오. DMARC 세다. 각 진술이 관찰되었는지, 파생되었는지 또는 여전히 가설인지 명시적으로 라벨을 지정합니다.

재현 가능한 검사 및 제한 사항을 포함합니다.

명령 또는 스크립트, 도구 버전, 선택한 서명 또는 기록, 입력 해시, 예상 관찰 및 실제 출력을 제공합니다. 자격 증명이나 프로덕션 서명 비밀을 삽입하지 마세요. 주입된 공개 키를 사용한 로컬 테스트에서는 DNS 조회가 발생하지 않았다고 표시되어야 합니다. 합성 파서 예제는 공급자 평가로 가장해서는 안 됩니다.

검사를 완료하려면 실제 출력을 유지하고 누락되거나 변경된 아티팩트를 명시적으로 표시하세요. 제안된 점검에 대해서는 수행되지 않음이라는 라벨을 붙이고 필요한 액세스 또는 입력을 명시하십시오. 관찰로 제시된 예상 출력으로 빈 증거 팩을 채우지 마십시오.

다음 행동을 명확하게 하라

검증된 결과, 남은 간격, 제안된 좁은 수정 사항, 소유자 및 성공 조건으로 끝납니다. 증거 수집과 별도로 구성 변경 및 외부 공유에 대한 승인을 유지합니다. 승인된 수리 후에는 실패를 성공 스크린샷으로 대체하는 대신 새로 식별된 테스트를 추가하고 이전 증거를 보존하십시오.

또 다른 분석가는 팩의 세 가지 질문에 답할 수 있어야 합니다. 즉, 각 소스에 따라 무슨 일이 일어났는지, 독립적으로 확인할 수 있는 것은 무엇인지, 여전히 액세스 또는 판단이 필요한 것은 무엇인지 답할 수 있어야 합니다. 이는 이용 가능한 기록이 아직 원인을 입증할 수 없다는 정직한 결론일 때에도 완성 기준입니다.

가상의 해결되지 않은 배송 케이스 스케치

응용 프로그램 로그에 릴레이 수락이 기록되어 있지만 수신자가 메시지를 보고하지 않는다고 가정해 보겠습니다. 케이스 요약에는 인증 실패가 아니라 대상 전송이 해결되지 않았다고 표시되어야 합니다. 최소 제안 팩에는 승인된 원래 제출 또는 보관된 바이트, 릴레이의 대기열 식별자 및 타임스탬프, 수신자별 추적, 이후 DSN 및 수신자 측 관찰(사용 가능한 경우)이 포함됩니다.

사용할 수 없는 각 항목을 누락으로 표시하세요. 다음 소유자는 관련 릴레이 또는 수신자 추적에 액세스할 수 있는 사람입니다. 실제로 동의할 때까지 해당 사람을 할당되지 않은 상태로 둡니다. 적합한 성공 조건은 단순히 또 다른 성공적인 전송이 아니라 원래 수신자의 상관 관계 처리와 남은 격차에 대한 설명입니다.

이는 전달된 파일, 실행된 사건 조사 또는 실제 조직에서 수집, 공유 또는 보관을 승인한 주장이 아닌 가상의 팩 개요입니다.

팩을 다음 분석가에게 유용하게 만드세요.

  • 증상, 범위, 기간 및 해결되지 않은 질문부터 시작하세요.
  • 각 관찰을 원본 아티팩트 및 컬렉션 컨텍스트에 연결합니다.
  • 원본, 파생물, 가상 설명을 분리하세요.
  • 수행할 때만 재현 가능한 검사 입력과 실제 출력을 포함합니다.
  • 소유자나 승인을 고안하지 않고 다음 증거 요청과 성공 조건을 할당합니다.

[ 테이크아웃 ]

다른 분석가가 재현할 수 있는 원본, 파생물, 타임라인 및 관찰된 내용에 대한 명시적 제한을 포함하여 사건 팩을 구축합니다.

[ 역할별 ]

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

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

IT/메일 관리자

모든 결론을 추적 가능하게 만드세요

각 이벤트와 테스트에는 식별 가능한 소스가 필요합니다.

다음 단계

  1. 해시 및 인벤토리 아티팩트.
  2. 도구 버전과 명령을 유지합니다.
  3. 수신자 타임라인을 뚜렷하게 유지하세요.

CISO/SecOps

통제된 증거 처리 보존

재현성은 비밀을 노출하거나 액세스를 확장해서는 안 됩니다.

다음 단계

  1. 원본을 제한합니다.
  2. 외부 공유를 별도로 검토하세요.
  3. 가설과 승인을 명시적으로 유지하세요.

창립자 / 비기술자

조사를 실행 가능하게 만들기

팩은 영향과 다음 결정을 설명해야 합니다.

다음 단계

  1. 비즈니스 증상을 기술하세요.
  2. 해결되지 않은 질문을 할당합니다.
  3. 성공 조건을 추적합니다.

[ 자주 묻는 질문 ]

자주 묻는 질문

사건 팩의 시작 부분에는 무엇이 포함됩니까?

예상되는 동작, 실제 증상, 범위, 기간 및 해결되지 않은 질문입니다.

가설은 사실로 나타나야 하는가?

아니요. 라벨을 붙이고 테스트하는 데 필요한 증거를 확인하세요.

원본과 파생물을 별도로 보관하는 이유는 무엇입니까?

편집으로 인해 기술적 의미와 서명 유효성이 변경될 수 있으므로 계보는 명확하게 유지되어야 합니다.

일치하는 해시가 메시지가 진짜임을 증명합니까?

아니요. 이는 저작자나 진실이 아닌 기록된 바이트와의 일관성을 입증합니다.

오늘의 DNS 응답이 어제의 설정을 증명할 수 있습니까?

아니요. 역사적 구성에는 당시와 관련된 증거가 필요합니다.

수표를 재현할 수 있게 만드는 것은 무엇입니까?

식별된 입력, 도구 버전, 명령, 설정, 예상 결과 및 유지된 실제 출력.

개요에는 실제 사건이 기록되어 있나요?

아니요. 가상의 미해결 배송 사례입니다. 여기에는 수집된 파일, 실행된 확인 또는 할당된 실제 소유자가 포함되어 있지 않습니다.

조사는 언제 종료될 수 있나요?

조사 결과, 증거 제한, 소유권 및 확인된 수리 결과가 명확하게 기록되는 경우.

[ 출처 ]

출처

  1. RFC 6376 : DKIM 서명

    섹션 §3.4 · §3.6 · §5 · §6

  2. RFC 5321: SMTP

    섹션 §3.3 · §4.5.4 · §6.1

  3. RFC 3464 : 배달 상태 알림

    섹션 §2.2 · §2.3

  4. RFC 8601: Authentication-Results

    섹션 §1.2 · §7

  5. RFC 9990 : DMARC 집계 보고

    섹션 §3.1

[ 어휘 ]

어휘

사건 증거 팩
전달 조사를 위한 범위가 지정된 아티팩트, 출처, 테스트 및 결과 세트입니다.
무결성 감사
저장된 아티팩트 바이트와 기록된 지문을 비교합니다.
관찰 대 추론
직접적인 증거와 그로부터 도출된 결론의 차이.

기업 출처

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

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

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

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

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

기술 자료