DMARC/수정 이력

수정 이력

1개의 판이 있어요. 줄마다 펼쳐 바뀐 부분을 보거나, 두 판을 골라 비교할 수 있어요.

왼쪽 동그라미 = 이전 판, 오른쪽 = 이후 판
#574AI 조사: 게임 용어 문서GGWiki 자동 · · 현재 판+2,119자
1번째 줄 근처
추가: ## 개요
추가: DMARC(Domain-based Message Authentication, Reporting, and Conformance)는 이메일 도메인 소유자가 자신의 도메인을 이메일 스푸핑, 비즈니스 이메일 침해(BEC), 피싱, 이메일 사기 등 무단 사용으로부터 보호할 수 있게 하는 이메일 인증 프로토콜이다[1][2][3]. 수신 메일 서버는 발신 도메인의 DNS에 게시된 DMARC 레코드를 참조해 들어오는 메일이 인증을 통과했는지 검사하고, 정책에 따라 메일을 정상 전달·격리·거부한다[2][3]. DMARC는 기존의 SPF(Sender Policy Framework)와 DKIM(DomainKeys Identified Mail) 두 메커니즘을 확장하며, 단순히 SPF나 DKIM을 통과하는 것을 넘어 '연관성(Alignment)' 검사를 추가로 요구한다[2][3].
추가: ## 역사·유래
추가: DMARC 초안 명세는 2012년 1월 30일부터 관리되기 시작했다[3]. 2013년 10월 GNU Mailman 2.1.16이 DMARC p=reject 정책을 가진 도메인의 포스터를 처리하는 옵션을 추가하며 제한적 정책 도입에 따른 상호운용성 문제를 선제 대응했다[3]. 2014년 4월 야후(Yahoo)가 DMARC 정책을 p=reject로 변경하면서 여러 메일링 리스트에서 오작동이 발생했고, 며칠 뒤 AOL도 p=reject로 전환했다[3]. DMARC는 2015년 3월 12일 RFC 7489로 'Informational' 상태로 표준화되었으며[2], 2026년 5월 RFC 9989로 'Standards Track' 문서로 재정의되었다[3].
추가:
추가: ## 규제·논란·평가
추가: ### 메일링 리스트·포워딩과의 호환성 문제
추가: 메일링 리스트는 제목 접두사 추가, 푸터 삽입 등으로 원 작성자의 DKIM 서명을 깨뜨리는 주요 원인이다[3]. 이로 인해 정당한 메일이 DMARC 검사 실패로 처리될 수 있다. 주요 우회 방안[3]:
추가: - 메시지 수정 완전 중단: 표준 워크플로 유지, 대형 리스트 운영자 일부 채택. 단, 서명된 헤더 재정렬·수정 방지 위해 세심한 설정 필요.
추가: - From: 재작성(Rewriting): 가장 대중적·비침습적. 원 작성자 주소를 Reply-To:에 보존. `.INVALID` 접미사 추가, 임시 사용자 ID 할당, 불투명 ID 사용 등 다양한 방식 존재. 표시 이름에 작성자와 리스트 모두 표기 가능. 단, 작성자 정보 변경은 일반적인 공정성 원칙에 어긋나고 자동화 도구(첨부파일 작성자 귀속 등)를 깨뜨릴 수 있음.
추가: - 메시지 래핑(Wrapping): 래핑 지원 클라이언트에서 효과적.
추가: - 변경 없음: 일부 국가에서 법적 의무로 리스트 식별 정보 추가 요구, SPF 인증 상시 실패로 전체 인증 취약화 우려.
추가:
추가: ### Sender: 헤더 필드 미지원
추가: From: 필드 변경을 통한 DKIM 연관성 확보는 RFC 5322 3.6.2절(From:은 작성자 지정) 위반 소지가 있다[3]. `Sender:` 헤더로 '타인 대리 발송' 표시 가능하나, DMARC는 From 도메인 정책만 검사하고 Sender 도메인은 무시한다[3]. ADSP와 DMARC 모두 많은 사용자 에이전트가 Sender 필드를 수신자에게 표시하지 않는다는 비기술적 이유로 Sender 필드 사용을 배제한다[3].
추가:
추가: ### 포렌식 보고서의 프라이버시·보안 우려
추가: 포렌식 보고서에는 메일 본문·헤더 사본이 포함될 수 있어 민감 정보 유출 위험이 있다[3]. `fo` 태그로 보고 조건을 세밀히 제어하고, 수신 측에서 적절히 편집(redaction) 처리해야 한다.
추가:
추가: ### 단계적 도입의 실효성
추가: `p=none`으로 시작해 모니터링 후 점진 강화하는 권장 경로가 있으나, 최종 목표를 `p=reject`로 상정하는 명세의 가정이 모든 도메인에 적합하지 않을 수 있다[3]. 도메인 성격(순수 트랜잭션 메일 vs 사용자 참여 메일)에 따라 적정 정책 수준이 다를 수 있다.
추가:
추가: ## 표준 문서
추가: - RFC 7489 (2015-03-12, Informational) — 최초 표준화[2]
추가: - RFC 9989 (2026-05, Standards Track) — 최신 표준[3]
추가:
추가: 이 문서는 GGWiki AI가 공개 자료(아래 출처)를 조사해 새로 쓴 초안입니다. 틀린 내용은 편집하거나 이의 제기로 알려 주세요.

편집 요청

편집 요청이 없어요.