줄 끝 문제는 바이트 수준 문제입니다. 메시지를 편집기에 복사하고 동일한 줄을 보고 아무것도 변경되지 않았다고 결론을 내리는 것은 신뢰할 수 없는 일입니다. DKIM 조사. 원본 표현을 보존하고 서명 전, 전송 중 또는 증거 수집 중에만 변환이 발생했는지 식별합니다.
예상되는 형태 확립
인터넷 메일은 CRLF 줄 구분 기호를 사용합니다. RFC 6376 §5.3 서명자는 서명하기 전에 로컬 베어 CR 또는 LF 규칙을 SMTP 표준 CRLF 시퀀스로 변환해야 합니다. 변환은 서명 알고리즘에 전달된 개인 복사본뿐만 아니라 전송된 메시지에도 적용되어야 합니다. 하나의 진술에 서명하고 다른 진술을 전송하면 확인 시 불일치가 발생합니다.
정규화 일반 텍스트 정규화보다 규칙이 더 좁습니다. 간단한 본문 정규화 후행 빈 줄을 무시하고 필요한 최종 CRLF를 제공합니다. 편안한 신체 정규화 또한 줄 끝 공백을 제거하고 줄 내의 공백이나 탭을 압축합니다. 일반적으로 의미 있는 줄 바꿈을 지우거나 래핑된 텍스트를 결합하지 않습니다. 헤더와 본문 알고리즘은 다를 수 있으므로 단일 모드를 가정하는 대신 c의 두 부분을 모두 읽으십시오.
증거를 먼저 보호하라
변환을 이해하는 방법을 사용하여 서명자와 수신자로부터 원시 메시지 파일을 수집합니다. 읽기 전용 원본과 해당 파일의 해시를 보관하세요. 작업 복사본에서 바이트 인식 도구를 사용하여 CRLF, 베어 LF 및 베어 CR 개수를 검사합니다. 텍스트 뷰어의 표시는 충분하지 않습니다. 많은 뷰어가 각 양식을 줄 바꿈으로 렌더링합니다.
샘플을 어떻게 얻었는지 물어보십시오. 아카이브, 셸 파이프라인 또는 소스 제어 설정은 전달 후 엔딩을 정규화할 수 있습니다. 내보낸 파일의 차이로 인해 SMTP 메시지 자체가 변경된 것은 아닙니다. 가능하다면 동일한 경계에서 독립적인 캡처를 비교하고 증거와 함께 내보내기 절차를 보관하십시오.
작은 제어 케이스를 사용하십시오
예시 입력: 몸체는 다음으로 구성됩니다. 알파, CRLF, 베타, 그리고 최종 CRLF. 끝에 빈 CRLF 전용 줄을 추가하면 표준 본문 알고리즘에 의해 정규화됩니다. 알파와 베타 사이의 줄 바꿈을 공백으로 바꾸면 내용이 변경되며 동일한 작업이 아닙니다. 알파 라인 끝에 공백을 추가하는 것은 단순 본문 정규화에서는 다르지만 완화된 본문 정규화에서는 정규화됩니다.
이 예에서는 규칙을 설명합니다. 완전한 서명을 확인하는 것을 대신할 수는 없습니다. 유효한 본문 해시 DKIM 확인의 한 부분일 뿐입니다. 헤더 선택, 공개 키 검색 및 암호화 서명도 성공해야 합니다.
책임있는 단계를 찾아서 수정하십시오.
서명자가 LF 전용 로컬 데이터를 수신하는 경우 서명하기 전에 직렬화 단계를 검사하십시오. 서명자 출력은 정확하지만 이후의 원시 캡처가 다른 경우 해당 홉의 변환 또는 재구축 동작을 조사하십시오. 내보낸 증거만 다른 경우 프로덕션 DNS 또는 키를 수정하는 대신 캡처 방법을 복구하십시오.
서명자와 전송된 메시지가 동일한 정규화된 표현을 사용하도록 좁은 범위의 변경을 수행합니다. 샘플을 통과시키기 위해 임의의 라인 변환을 허용하는 사용자 정의 검증기를 만들지 마십시오. 이러한 검증자는 더 이상 게시된 DKIM 규칙을 테스트하지 않습니다.
하나 이상의 메시지를 확인하세요.
변경 후에는 일반 텍스트, 빈 후행 줄, HTML 및 첨부 파일을 포함하는 작은 모음을 보내십시오. 선택한 표준화, 수집된 원시 파일 해시 및 신뢰할 수 있는 수신자의 확인 결과를 기록합니다. 예상되는 출력 표현을 회귀 고정물로 유지합니다. 유용한 해결 방법은 책임 있는 변환을 식별하고 새 메시지가 의도한 형식으로 수신자에게 도달함을 보여줍니다.
결론과 바이트 수를 별도로 유지
합성 신체의 경우 알파<CRLF>베타<CRLF>, 네트워크 형식 본문은 13옥텟입니다. 즉 문자 5개, 구분 기호 옥텟 2개, 문자 4개 및 최종 구분 옥텟 2개입니다. 동일한 가시 라인의 LF 전용 내보내기는 11옥텟입니다. 이러한 개수 차이는 전송된 메일이 손상되었다는 증거가 아니라 수집이나 일련번호를 조사해야 하는 이유입니다. 원본 파일과 수집 방법을 유지한 후 해당 경계에서 신뢰할 수 있는 캡처와 비교합니다. 대괄호로 묶인 CRLF 레이블은 리터럴 텍스트가 아닌 바이트를 나타냅니다.