국제화된 발신자는 메일 클라이언트, 원시 헤더, DNS 도구 및 인증 결과에서 다르게 보일 수 있습니다. 올바른 조사는 신원이 다르다고 결정하기 전에 이러한 표현을 설명합니다.
화면에 렌더링된 텍스트만 비교하지 마세요. 원시 헤더와 추출된 도메인을 유지하고 적용 가능한 국제화 규칙을 식별하며 정책 검색 및 ID 비교에 사용되는 DNS 형식을 기록합니다. 평가에 사용되는 변환은 서명된 메시지를 다시 작성하는 것과는 다른 작업입니다.
주소의 세 부분을 분리하세요.
표시 이름은 사람이 보는 레이블입니다. 사서함 로컬 부분은 @ 앞 부분입니다. 도메인은 @ 다음 부분입니다. 인증에는 서로 다른 규칙과 역할이 있습니다.
국제화된 이메일 표준을 통해 지원되는 시스템은 SMTPUTF8을 사용하여 UTF-8 헤더 콘텐츠와 메일함 이름을 전송할 수 있습니다. IDNA는 국제화된 도메인 라벨을 다룹니다. 유니코드 사서함 로컬 부분을 DNS 이름으로 변환하지 않습니다.
DMARC의 중앙 ID는 From에서 추출된 작성자 도메인입니다. 개인의 로컬 부분 철자를 변경해도 새로운 DMARC 생성되지 않습니다. 조정 모드이며, 도메인을 인증한다고 해서 표시 이름의 사람이나 의미가 인증되는 것은 아닙니다.
유니코드와 DNS 표현을 함께 유지하세요
IDNA는 유니코드 U-레이블을 ASCII A-레이블 표현과 구별합니다. 유효한 A-레이블은 xn-- 접두사로 인식할 수 있지만 접두사만으로는 임의의 문자열이 유효한 인코딩임을 증명할 수 없습니다. 직접 편집한 대체 대신 해당 IDNA 규칙의 구현을 사용하십시오.
RFC 9989 섹션 5.3.1에서는 추가 DMARC 처리를 위해 U-레이블 작성자 도메인을 A-레이블 형식으로 변환해야 합니다. 이는 시각적으로 다른 헤더와 DNS 이름이 동일한 도메인을 나타낼 수 있음을 의미합니다. 이는 관련되지 않은 두 이름의 비슷한 모양의 유니코드 문자가 동등하다는 의미는 아닙니다.
다음 예제는 합성 예제이며 예약된 .example 네임스페이스를 사용합니다. DNS 게시, 메시지 전달 또는 수신자 결과가 청구되지 않습니다.
- 항목: 유니코드 도메인이 있는 사서함에서; 예시 값: info@bü cher.example ; 목적: 원시 국제화 헤더 ID
- 항목: 해당 A-레이블 도메인; 예시 값: xn--bcher-kva.example ; 목적: 여기에 설명된 DMARC 처리를 위한 도메인 양식
- 항목: 직접 DMARC 조회 이름; 예시 값: _dmarc.xn--bcher-kva.example ; 목적: 해당 작성자 도메인에 대한 TXT 쿼리
- 항목: 동등한 ASCII 도메인 메일함 형식; 예시 값: info@xn--bcher-kva.example ; 목적: ASCII 형식의 동일한 도메인 표현
- 유효한 합격 DKIM 동일한 A-레이블 도메인을 사용하는 ID는 변환된 작성자 도메인과 비교할 수 있습니다. 동일하면 도메인 비교가 엄격한 정렬을 충족할 수 있습니다. 완전한 DMARC 통과에는 여전히 유효한 적용 가능한 정책과 통과 정렬 인증 경로가 필요합니다. 변환 자체는 인증이 아닙니다.
로컬 부분에 도메인 인코딩을 적용하지 마세요.
동일한 국제화 도메인에 유니코드 로컬 부분이 있는 가상의 사서함을 생각해 보십시오. 도메인은 A-레이블 표현을 가질 수 있지만 로컬 부분은 국제화된 이메일 처리에 의해 관리되는 사서함 식별자로 유지됩니다. 주소 전체에 퓨니코드를 적용하는 것은 잘못된 모델입니다.
메시지에서 요구하는 경우 실제 전송 경로에 대한 SMTPUTF8 지원을 확인하세요. ASCII A 레이블 형식으로 완전히 작성된 도메인 자체에는 SMTPUTF8이 필요하지 않습니다. 다른 주소나 헤더 내용은 여전히 그렇게 할 수 있습니다. UTF-8 원시 헤더 또는 ASCII가 아닌 사서함 로컬 부분에는 별도의 전송 및 파서 호환성 문제가 발생합니다.
이러한 결과를 별도로 유지하십시오. 국제화된 메시지를 전송할 수 없음, ID 구문 분석 실패, 정책 발견 실패 및 인증 실패는 서로 다른 단계입니다. DMARC 태그를 변경해도 모든 문제를 해결할 수는 없습니다.
조사 중에 서명된 콘텐츠 보존
원본 메시지 바이트와 관련 서명을 유지합니다. 비교를 위해 추출된 도메인을 변환할 때 도메인을 교체할 필요가 없습니다. 헤더에서 원본 메시지에서. 헤더를 다시 작성한 다음 수정된 사본을 확인하면 다른 서명 질문이 생성될 수 있습니다.
IDNA 및 이메일 구문 분석을 수행하는 라이브러리 또는 제품 버전, 지원되는 표준 및 변환 결과를 기록합니다. 통제된 수리는 별도의 테스트 픽스처로 보관하십시오. 해당 경로를 테스트하지 않고 모든 공급자, 게이트웨이 및 클라이언트가 동일한 국제화 워크플로우를 지원한다고 약속하지 마십시오.
DMARC 태그 이름과 정의된 값은 지정된 구문을 계속 따릅니다. v=DMARC1 번역하거나 유니코드 관련 정책 버전을 만들지 마세요. 국제화된 보고서 대상 또는 공급자 생성 설정의 경우 사서함 표시 지원이 모든 구성 필드에서 임의의 유니코드를 허용한다고 가정하는 대신 적용 가능한 URI, DNS 및 공급자 규칙을 따르십시오.
시각적인 가장과 정렬을 분리하세요.
표시 이름은 다른 기본 도메인을 나타내면서 친숙한 브랜드와 유사할 수 있습니다. IDNA 변환은 도메인 표현을 설명합니다. 이름이 적법하다거나 시각적으로 유사한 두 이름이 동일하다는 판단은 아닙니다.
의심스러운 메일을 검토할 때 실제 도메인과 해당 DNS 형식을 승인된 ID 등록부와 비교하세요. 표시 이름 및 유사 도메인 결과를 DMARC 결과와 함께 보관하되 별도로 보관하세요. 인증 대 권한 부여 가이드에서는 유효한 도메인 결과가 메시지 의도를 승인할 수 없는 이유를 설명합니다.
재현 가능한 신원 기록을 보관하세요
실제 조사를 위해 표시된 발신자, 원시 보낸 사람 필드, 추출된 유니코드 도메인, 검증된 A-레이블 변환, 정책 조회 이름, SPF DKIM 신원, 신뢰할 수 있는 수신자 결과 및 전송 증거. 결정을 재현하는 데 필요한 도메인 표현을 파괴하지 않고 개인 데이터를 수정합니다.
유용한 결과는 두 표현이 동일한 도메인에 매핑되거나 서로 다르다고 말하고 이것이 실제 평가에 어떤 영향을 미쳤는지를 보여줄 수 있습니다. 다른 검토자가 동일한 결론에 도달할 수 있도록 변환 및 원본 메시지를 보존하십시오.
인증을 발명하지 않고 변환을 기록합니다.
서면 사례 IDN-01은 From info@bü cher.example 및 해당 도메인 xn--bcher-kva.example 유지합니다. 메일 관리자는 해당 IDNA 라이브러리/버전을 기록하고 원시 메시지를 별도로 보존합니다. 이 경우 SPF , DKIM 확인, SMTPUTF8 협상 및 검색된 정책은 알려지지 않았습니다. 다음 단계는 두 도메인 표현이 동의하기 때문에 메시지를 인증된 것으로 표시하는 것이 아니라 이러한 관찰을 수집하는 것입니다. 메시지 또는 DNS 쿼리가 실행되지 않았습니다.