Problem z zakończeniem linii jest problemem na poziomie bajtu. Skopiowanie wiadomości do edytora, zobaczenie tych samych linijek i stwierdzenie, że nic się nie zmieniło, nie jest wiarygodne DKIM dochodzenie. Zachowaj oryginalne przedstawienie i określ, czy konwersja nastąpiła przed podpisaniem, w trakcie transportu, czy dopiero podczas gromadzenia dowodów.
Ustal oczekiwaną formę
Poczta internetowa używa separatorów wierszy CRLF. RFC 6376 §5.3 wymaga, aby podpisujący przed podpisaniem przekonwertował lokalne, gołe konwencje CR lub LF na sekwencję CRLF w standardzie SMTP. Konwersja powinna dotyczyć przesyłanej wiadomości, a nie tylko prywatnej kopii przekazywanej algorytmowi podpisującemu. Podpisanie jednego oświadczenia i przesłanie drugiego powoduje brak zgody podczas weryfikacji.
Kanonizacja ma węższe zasady niż ogólna normalizacja tekstu. Prosta kanonizacja ciała ignoruje końcowe puste linie i dostarcza wymagany końcowy CRLF. Zrelaksowana kanonizacja ciała usuwa również spacje na końcu linii i kompresuje spacje lub tabulatory w linii. Zwykle nie usuwa znaczących podziałów wierszy ani nie łączy zawiniętego tekstu. Algorytmy nagłówka i treści mogą się różnić, więc przeczytaj obie części c, zamiast zakładać pojedynczy tryb.
Najpierw chroń dowody
Zbieraj nieprzetworzone pliki wiadomości od osoby podpisującej i odbiorcy, korzystając z metod, których przekształcenia rozumiesz. Zachowaj oryginały i skróty tych plików tylko do odczytu. W kopii roboczej sprawdź liczbę CRLF, nagich LF i nagich CR za pomocą narzędzia rozpoznającego bajty. Widok przeglądarki tekstu nie jest wystarczający: wiele przeglądarek renderuje każdy formularz jako podział wiersza.
Zapytaj, w jaki sposób uzyskano próbkę. Archiwum, potok powłoki lub ustawienia kontroli źródła mogą normalizować zakończenia po dostarczeniu. Różnica w wyeksportowanych plikach nie oznacza, że sama wiadomość SMTP uległa zmianie. Jeśli to możliwe, porównaj niezależne połowy na tej samej granicy i zachowaj procedurę wywozu wraz z dowodami.
Użyj małej kontrolowanej skrzynki
Przykładowe dane wejściowe: ciało składa się z alfa, CRLF, betai końcowy CRLF. Dodanie na końcu pustej linii zawierającej tylko CRLF jest normalizowane przez standardowe algorytmy treści. Zastąpienie podziału wiersza między alfa i beta spacją zmienia treść i nie jest tą samą operacją. Dodawanie spacji na końcu linii alfa różni się w przypadku prostej kanonizacji treści, ale jest normalizowane przez zrelaksowaną kanonizację treści.
Te przykłady wyjaśniają zasady; nie zastępują weryfikacji pełnego podpisu. Ważne skrót ciała to tylko jeden z elementów weryfikacji DKIM . Wybór nagłówka, odzyskanie klucza publicznego i podpis kryptograficzny również muszą się powieść.
Znajdź i popraw odpowiedzialny etap
Jeśli osoba podpisująca otrzyma dane lokalne tylko w formacie LF, przed podpisaniem sprawdź etap serializacji. Jeśli dane wyjściowe osoby podpisującej są prawidłowe, ale późniejsze nieprzetworzone przechwycenie jest inne, sprawdź zachowanie konwersji lub przebudowy tego przeskoku. Jeśli tylko wyeksportowane dowody różnią się, napraw metodę przechwytywania, zamiast modyfikować produkcyjne DNS lub klucze.
Wprowadź zmianę o wąskim zakresie, która zapewni, że osoba podpisująca i przesyłana wiadomość będą używać tej samej znormalizowanej reprezentacji. Nie wymyślaj niestandardowego weryfikatora, który akceptuje dowolne przekształcenia linii, aby próbka przeszła pomyślnie. Taki weryfikator nie testowałby już opublikowanych zasad DKIM .
Sprawdź więcej niż jedną wiadomość
Po zmianie wyślij mały pakiet zawierający zwykły tekst, puste linie końcowe, kod HTML i załączniki. Zapisz wybraną kanonizację, zebrane skróty nieprzetworzonego pliku i wynik weryfikacji zaufanego odbiorcy. Zachowaj oczekiwaną reprezentację wyjściową jako element regresji. Przydatna rozdzielczość identyfikuje odpowiedzialną konwersję i pokazuje, że nowe komunikaty docierają do odbiorcy w zamierzonej formie.
Trzymaj liczbę bajtów oddzielnie od wniosków
Do syntetycznego ciała alfa<CRLF>beta<CRLF>, treść w formie sieci składa się z 13 oktetów: pięć liter, dwa oktety separatora, cztery litery i dwa końcowe oktety separatora. Eksport tych samych widocznych linii w formacie LF ma długość 11 oktetów. Ta różnica w liczbie jest powodem do zbadania odbioru lub serializacji, a nie dowodu, że przesłana poczta została uszkodzona. Zachowaj oryginalne pliki i metody gromadzenia, a następnie porównaj z zaufanym przechwytywaniem na odpowiedniej granicy. Ujęta w nawiasy etykieta CRLF reprezentuje bajty, a nie tekst dosłowny.