Wiadomość może mieć ważny Podpis DKIM podczas gdy pola anulowania subskrypcji są niepodpisane. Jest to znacząca luka: odbiorca weryfikujący wiadomość niekoniecznie zweryfikował reklamowaną opcję rezygnacji. Sprawdź zasięg podpisu, nie tylko ogólny DKIM etykieta przejścia.
Znajdź podpis chroniący operację
RFC 8058 wymaga co najmniej jednego prawidłowego pokrycia podpisu DKIM List-Unsubscribe i List-Unsubscribe-Post . Obydwa pola muszą pojawić się w znaczniku h= tego prawidłowego podpisu. Brak wymaganego podpisu jest powodem, dla którego odbiorca nie oferuje możliwości rezygnacji jednym kliknięciem zgodnie ze specyfikacją. RFC 8058 sekcja 4.
Wiadomość może zawierać wiele podpisów. Nie łącz ważności jednego z pokryciem nagłówka drugiego i nazywaj tę parę wystarczającą. Zidentyfikuj pojedynczy ważny podpis obejmujący wymagane pola, a następnie zachowaj osobę podpisującą, selektor i wynik weryfikacji. Jest to niezależne od sprawdzania, do czego przyczynia się podpis DMARC wyrównanie.
Umieść nagłówki przed odpowiednim etapem podpisywania
Zamapuj potok konstruowania wiadomości: szablon aplikacji, przetwarzanie list, transformacje bramek, osoba podpisująca i ostateczna trasa wychodząca. Jeżeli serwis doda pola rezygnacji po podpisaniu, wcześniejszy podpis może zachować ważność bez ich zasłaniania. Rozwiązanie polega na umieszczeniu pól przed odpowiednim podpisem lub upewnieniu się, że późniejszy ważny podpis je zakryje.
Przeczytaj ostatni wyemitowany komunikat. RFC 6376 definiuje reguły wyboru listy h= i nagłówków, w tym sposób obsługi powtarzających się nazw pól. Wyszukiwanie ciągu znaków „list-unsubscribe” w dowolnym miejscu wiadomości nie jest testem zasięgu. Zduplikowane pola i przekształcenia wymagają dokładnej kontroli rzeczywistego wprowadzonego podpisu. RFC 6376 sekcje 3.5 i 5.4.
Rozróżnij zmiany podpisane i niepodpisane
Wyobraź sobie kontrolowaną wiadomość testową, której skądinąd prawidłowy podpis obejmuje oba pola rezygnacji z subskrypcji. Zmiana podpisanego URI na inną wartość powoduje zmianę podpisanych danych wejściowych; w ramach normalnej weryfikacji DKIM oryginalny podpis nie sprawdza już zmienionych danych wejściowych. Natomiast podpis pomijający oba pola może pozostać ważny po zmianie wartości bez znaku. To wyjaśnia, dlaczego przepustka ogólna nie może uwierzytelnić każdego pola.
Są to oczekiwania oparte na protokole, a nie wykonane urządzenie kryptograficzne. Rzeczywisty autoryzowany test mutacji wymaga dokładnych oryginalnych bajtów, wybranego podpisu i prawidłowego klucza weryfikacyjnego. Wstrzyknięty klucz testowy pokazuje jedynie relację kryptograficzną tego testu, a nie publiczne pochodzenie DNS lub historyczny wynik odbioru. Zachowaj oryginał i zmutuj oddzielną kopię.
Sprawdź całą podpisaną ścieżkę
Po naprawieniu zasięgu wyślij ponownie autoryzowaną wiadomość testową zamierzoną trasą i zweryfikuj ją po stronie odbiorcy. Przepisanie łącza, edycja bramy lub późniejszy procesor list może zmienić objęte pole. Jeśli to możliwe, zachowaj próbki przed transformacją i próbki końcowe, aby właściciel mógł zlokalizować pierwszy etap, w którym weryfikacja jest rozbieżna.
Unikaj rozwiązywania problemu, po prostu usuwając pola z h=. Może to ułatwić zachowanie podpisu, pozostawiając jednocześnie wymagania RFC 8058 niespełnione. Jeśli brama musi przekształcić akcję, skoordynuj ostateczną granicę podpisywania i upewnij się, że przekształcony identyfikator URI nadal jest mapowany na prawidłowego odbiorcę i listę.
Przeprowadź kontrolę działania
Pokrycie podpisu uwierzytelnia reklamowane pola; nie dowodzi, że punkt końcowy wykonuje żądane pomijanie. Użyj kontrolowanej subskrypcji, aby oddzielnie przetestować wykluczenie POST i dalszego wysyłania. I odwrotnie, działający punkt końcowy nie naprawia brakującego zasięgu podpisu.
Rekord zamknięcia powinien identyfikować ważny podpis obejmujący, dokładny komunikat końcowy, zakres punktu końcowego i zaobserwowany wynik tłumienia. Zachowaj wyświetlanie interfejsu użytkownika dostawcy jako osobną obserwację, a nie obiecaną konsekwencję prawidłowego podpisania.
Zachowaj zapis zamknięcia specyficzny dla podpisu
Zapisz końcową wiadomość, osobę podpisującą, selektor, dwa objęte pola i wynik weryfikacji dla tego konkretnego podpisu. Zapisz oddzielnie wyniki dotyczące punktu końcowego i tłumienia. Jeśli późniejsza brama zmutuje pola, napraw granicę podpisu zamiast usuwać wymagane pokrycie.