보낸 사람이 두 명인 것으로 보이는 메시지에는 여러 가지 다른 내용이 포함될 수 있습니다. 하나는 여러 작성자가 포함된 보낸 사람 필드, 두 개의 별도 보낸 사람 필드 또는 다른 주소처럼 보이는 표시 이름입니다. 이는 구문 분석 및 보안 사례가 다릅니다. 메일 클라이언트의 발신자 회선 스크린샷으로는 이를 확실하게 구분할 수 없습니다.
원본 메시지 헤더를 유지하고 해당 구조부터 시작합니다. 통과 서명과 일치하는 주소를 자동으로 선택하지 마십시오. 이는 수신자와 수신자가 이해해야 하는 모호성을 숨길 수 있습니다.
필드 수와 주소 수를 구분하세요.
RFC 5322 사서함 목록이 있는 단일 보낸 사람 필드를 허용합니다. 목록에 사서함이 두 개 이상 포함된 경우 사서함이 하나 있는 보낸 사람 필드가 필요합니다. 메시지 형식 규칙은 여전히 하나의 보낸 사람 필드를 지정하므로 두 개의 개별 보낸 사람 필드는 하나의 유효한 다중 작성자 필드와 동일한 구성이 아닙니다.
발신자는 메시지 형식 모델에서 전송 에이전트를 식별합니다. From 도메인을 다음과 같이 대체하지 않습니다. DMARC의 작성자 도메인입니다. 회신, Return-Path 표시 이름도 다른 용도로 사용됩니다.
사용 ID 체인 연습 인증을 조사하기 전에 이러한 역할을 별도로 유지합니다.
DMARC 도메인 규칙을 명시적으로 적용
RFC 9989의 정상적인 처리에는 도메인에서 추출된 정확히 하나의 도메인이 필요합니다. 0개 이상의 도메인이 추출되면 해당 도메인의 일반적인 유효성 검사 프로세스가 종료됩니다. 사양에서는 수신기가 다중 도메인 사례에서 계속되도록 허용하고 보안 및 처리 관련 내용을 논의합니다.
진단 도구가 가장 편리한 작성자를 선택하고 무조건적인 성공을 보고하는 것은 허용되지 않습니다. 수신자가 여러 도메인을 평가하기로 선택한 경우 결과 절차와 적용 범위를 기록해야 합니다.
섹션 11.5에서는 각 도메인을 평가하고 실패한 검사 중에서 가장 강력한 정책을 적용하는 방법에 대해 설명합니다. 또한 과도한 수의 도메인을 처리하면 리소스 문제가 발생할 수 있다는 점도 주의해야 합니다. 모두 처리되지 않으면 평가가 불완전합니다. 이는 수신자 처리 고려사항이지 모든 제품이 해당 메일을 동일하게 수락하거나 표시한다는 약속은 아닙니다.
라벨이 지정된 기대치와 함께 통제된 사례 사용
아래 사례는 합성 헤더 조각입니다. 이는 실행된 테스트나 보고된 수신자 결과가 아니며 각각 제어된 테스트에서 올바르게 구성된 메시지의 나머지 부분이 필요합니다.
| 사례 | 예시 분야 | 기록할 평가 |
|---|---|---|
| 단일 저자 | 보낸 사람: author@example.com | 나머지 메시지 및 인증 확인이 적용되는 일반 단일 도메인 경로 |
| 한 분야의 여러 저자 | 보낸 사람: author@example.com , editor@example.net | 필요한 별도의 단일 사서함 보낸 사람 필드를 사용하면 유효한 다중 작성자 형식이 될 수 있습니다. 여러 발신 도메인에는 여전히 DMARC 예외 처리 분석이 필요합니다. |
| 복제 원본 필드 | example.com 의 From 필드와 example.net 의 From 필드 | 메시지 형식 결함; 원본 메시지를 평가한다고 주장하면서 눈에 보이지 않게 수정하지 마세요. |
| 주소와 유사한 표시 이름 | 실제 사서함 앞에 겉보기 주소가 포함된 텍스트 표시 | 실제 메일함 도메인을 구문 분석합니다. 디스플레이 위험을 별도로 평가 |
각 경우에 대해 원시 고정 장치와 파서 출력을 유지합니다. 필드 수를 계산하고, 추출된 사서함 값을 나열하고, 선택한 처리 경로로 연결되는 도메인 결과를 기록합니다. 두 개의 사서함이 동일한 도메인을 사용하는 경우 평가자가 다중 작성자 구성을 처리하는 방법에 메일 클라이언트의 표시가 응답한다고 가정하지 마십시오. 추출 결과를 유지하고 구현을 테스트합니다.
구문 분석된 신원과 연결된 인증 증거를 유지합니다.
안 SPF 또는 DKIM 한 도메인에 대한 패스는 필수 사항 없이는 표시된 다른 ID를 설명할 수 없습니다. 조정 분석. 모든 관련 DKIM d 값과 신뢰할 수 있는 수신자 결과를 보존합니다. 또한 구문 분석을 재현할 수 있도록 접기 및 주석을 포함하여 정확한 From 바이트를 유지합니다.
원본 서명을 확인하거나 수신 시스템에서 본 내용을 조사하기 전에 원본 From을 단일 작성자에게 다시 작성하지 마십시오. 다시 작성된 복사본은 별도의 테스트 사례로 유용할 수 있지만 다른 신원 질문이 있는 수정된 설비로 레이블이 지정됩니다.
거부된 시도는 전달된 헤더를 생성하지 않을 수 있습니다. 전달된 메시지를 만들어내는 대신 가능한 경우 SMTP 응답 및 수신 로그를 보존합니다. Authentication-Results 견본.
테스트 프레젠테이션 및 처리
보안 문제에는 수신자가 보는 내용이 포함됩니다. 한 구성 요소는 하나의 구성을 평가하는 반면 메일 클라이언트는 다른 명백한 작성자를 강조 표시할 수 있습니다. 승인된 테스트 환경에서 정확히 동일한 픽스처에 대해 파서 출력, 인증 결과, 처리 및 표시된 발신자 라인을 비교하십시오.
실제 관찰을 통해 소프트웨어 버전과 설정을 기록합니다. 한 고객의 행동을 보편적인 청구에 복사하지 마십시오. RFC 9989 다중 도메인 구성을 일반적인 DMARC 처리를 피할 수 있는 잠재적인 방법으로 식별하므로 "평가되지 않음"이라고 표시된 결과가 "안전함"으로 표시되어서는 안 됩니다.
실용적인 발신 구성은 일반적으로 일반 자동 메일에 대해 하나의 명확한 보낸 편지함을 사용하는 것이 좋습니다. 진정한 다중 작성자 기능이 필요한 경우 필수 보낸 사람 필드가 모든 다운스트림 인증 문제를 해결한다고 가정하기보다는 해당 형식을 처리할 시스템에서 지원되는 처리를 확인하세요.
원래 구문을 보존하고, 추출된 도메인 결정을 설명하고, 해당 결정을 실제 수신기 처리 및 프리젠테이션에 연결하면 조사가 완료됩니다. 단일 녹색 인증 답변을 작성하는 대신 예외적이거나 불완전한 처리를 눈에 띄게 유지하세요.