Zdefiniuj trasy powiadomień przed dotknięciem DNS
Dokumenty Zoho Forms DKIM w obszarze Konfiguracja > Panel sterowania > Ustawienia powiadomień > Konfiguracja DKIM . Po wstępnej weryfikacji domeny dodaj domenę, wybierz obsługiwany rozmiar klucza i uzyskaj wygenerowaną nazwę hosta oraz wartość, korzystając z opcji Wyświetl szczegóły. Opublikuj dane TXT i wybierz opcję Weryfikuj; udokumentowany status zmienia się z Oczekujący na Zweryfikowany. Formularze konfiguracji DKIM
Proponowany zakres zaczyna się od organizacji, edycji, regionu konta i formularzy, których powiadomienia wykorzystują domenę. Odróżnij wiadomości kierowane do administratorów wewnętrznych od wiadomości do respondentów. Pomyślne przesłanie i wygenerowane powiadomienie to zdarzenia aplikacyjne; żaden z nich nie określa, który transport lub tożsamość autora zostały użyte do dostarczenia wiadomości.
W tym artykule opisano wymagania konfiguracyjne i oryginalny plan akceptacji. Nie twierdzi, że przetestowano jakikolwiek formularz, najemcę, strefę DNS lub skrzynkę pocztową odbiorcy. Wymogi dotyczące dowodów z rachunku bieżącego i szerszego katalogu pozostają otwarte do czasu, gdy autoryzowany przegląd wdrożenia dostarczy brakujących uwag.
Uwzględnij niestandardowy SMTP i rezerwę w ekwipunku
W przewodniku dotyczącym Formularzy SMTP opisano Ustawienia > Ogólne > SMTP w kreatorze formularzy, włączanie niestandardowego SMTP i wybieranie istniejącego serwera. Jest napisane, że problemy z dostarczaniem SMTP mogą kierować pocztę przez serwer domyślny. Łączy także podpisanie ze zweryfikowaną domeną pasującą do domeny nadawcy. DKIM & SMTP
Rezerwa jest zatem granicą akceptacji materiału. Proponowany wykaz powinien zawierać zamierzony transport podstawowy, udokumentowaną możliwość powrotu i tożsamość oczekiwaną na każdej trasie. Nie zakładaj, że nominalny wybór SMTP w formularzu potwierdza ścieżkę używaną przez konkretne powiadomienie.
Zaplanuj wszelkie testy operacyjne w kontrolowanym, oddzielnie zatwierdzonym środowisku. Nie przerywaj celowo produkcyjnej usługi SMTP tylko po to, aby wywołać awarię, i nie przesyłaj prawdziwych danych respondentów dla wygody diagnostycznej. Plan bezpiecznego dowodu może rozpocząć się od przeglądu konfiguracji i istniejących autoryzowanych próbek, pozostawiając jednocześnie otwarte niezaobserwowane zachowanie awaryjne.
Traktuj wybór domeny i klucza jako konfigurację zarządzaną
Wygenerowany klucz należy do określonej konfiguracji domeny podpisującej. Zapisz jego dokładną nazwę wyszukiwania i wartość publiczną, wraz z kontem i żądaną zmianą. Podpis selektor i domena podpisująca określają, jakiego klucza potrzebuje weryfikator; zrzut ekranu z innej domeny nie zastępuje rzeczywistych danych konta.
Przejrzyj wybrane rozmiary kluczy pod kątem bieżących wymagań kryptograficznych organizacji i wsparcia dostawcy, zamiast traktować stary przykład jako uniwersalne zalecenie dotyczące bezpieczeństwa. Interfejs DNS , który w dziwny sposób wyświetla długą wartość TXT , nie uzasadnia jej obcięcia. Dane TXT mogą zawierać wiele ciągów znaków w jednym rekordzie, a aplikacje mogą interpretować te ciągi jako wymaganą pełną wartość.
Przed zastąpieniem istniejącego rekordu klucza zidentyfikuj inne formularze lub aktywne usługi, które mogą na nim polegać. Proponowany plan zmian powinien chronić zaplanowane powiadomienia i dokumentować decyzję o wycofaniu. Klucze prywatne i hasła SMTP nie powinny znajdować się w publicznym arkuszu konfiguracji ani w załączniku pomocy ogólnego przeznaczenia. RFC 6376 , sekcja 3.5; RFC 6376 , sekcja 3.6.2.2; RFC 1035 , sekcja 3.3.14
Mapuj pola edytora DNS na ostateczną nazwę wyszukiwania
Typowym ryzykiem związanym z konfiguracją jest mylenie względnej etykiety właściciela z w pełni kwalifikowaną nazwą domeny. Administrator powinien ustalić, jak rzeczywisty edytor DNS obsługuje sufiks strefy, a następnie porównać zamierzoną ostateczną nazwę wyszukiwania z opublikowanym wynikiem. Żadna pojedyncza zasada dotycząca usuwania lub zachowywania przyrostka nie ma zastosowania do każdego interfejsu.
W notacji pliku głównego DNS samodzielny @ oznacza bieżące pochodzenie. Nie jest to skrót oznaczający wszystkie subdomeny, a wizualne pole główne dostawcy nie powinno być interpretowane jako autoryzacja za pomocą symboli wieloznacznych. W przypadku DKIM zachowaj etykietę selektora, komponent _domainkey i zamierzoną domenę podpisującą jako jedną pełną nazwę.
Proponowany dowód akceptacji powinien zawierać dokładne imię i nazwisko oraz dane rekordu, a nie jedynie zielone powiadomienie o zapisaniu w edytorze. Jeśli dostawca nie może zweryfikować konfiguracji, porównaj zamierzonego właściciela, strefę i pełną wartość przed ponownym wygenerowaniem kluczy lub wprowadzeniem niepowiązanych SPF zmiany. RFC 1035 , sekcja 5.1; RFC 6376 , sekcja 3.5
Oceń uwierzytelnianie pod kątem rzeczywistej tożsamości powiadomienia
Forms dokumentuje także dokumenty korzystające z domeny domyślnej, gdy adres nadawcy nie ma domeny uwierzytelnionej. To sprawia, że faktyczny autor i tożsamość podpisującego są ważnymi dowodami, a nie szczegółami, które można wywnioskować z tytułu formularza lub logo organizacji. Notatki SMTP
Aby otrzymać powiadomienie od upoważnionego przedstawiciela, zapisz widoczne wyniki domeny „Od”, domeny podpisującej DKIM i selektora oraz wyniki zaufanego systemu odbierającego. Porównaj przekazywaną tożsamość z domeną autora w ramach obowiązującej DMARC wyrównanie tryb. Jeśli używana jest niestandardowa ścieżka SMTP , określ wymagania dotyczące uwierzytelniania odpowiedzialnego dostawcy, zamiast zakładać, że dane DNS wygenerowane przez Formularze konfigurują tę oddzielną usługę.
Nie myl podanego adresu odbiorcy z tożsamością autoryzowanego nadawcy. Respondent może podać adres e-mail, nie dając operatorowi formularza kontroli nad domeną tego adresu. Proponowany przegląd powinien zapewnić, że projekt powiadomienia nie będzie opierał się na nieuzasadnionych założeniach dotyczących własności domeny.
Przekazywanie uwierzytelnienia pozostaje węższe niż treść bezpiecznego formularza, umieszczenie w skrzynce odbiorczej czy dowód, że respondent widział potwierdzenie. Traktuj je jako osobne cele akceptacji. RFC 9989 , sekcja 4.4; RFC 7208 , sekcja 2.4
Arkusz akceptacji dla właścicieli formularzy
Użyj tego oryginalnego zaproponowanego arkusza do zajęć z powiadomieniami, zamiast zakładać, że jedno ustawienie formularza obejmuje każdą możliwą wiadomość.
- Zakres formularza: organizacja, identyfikator formularza, wydanie, region i odbiorcy powiadomień.
- Projekt nadawcy: zamierzona domena autora, miejsce docelowe odpowiedzi i zgoda firmy na zamianę domeny domyślnej.
- Transport podstawowy: wbudowany lub niestandardowy SMTP , odpowiedzialny właściciel usługi i odniesienie do istniejącej konfiguracji.
- Granica awaryjna: oczekiwana alternatywna ścieżka, dostępne dowody i wszelkie zachowania, które pozostają niezaobserwowane.
- Konfiguracja domeny: wygenerowana nazwa/wartość klucza, przegląd wybranego rozmiaru klucza i zatwierdzenie właściciela DNS .
- Weryfikacja: aktualny status produktu i sygnatura czasowa, niezależne od dowodu wysłania konkretnego powiadomienia.
- Przegląd wiadomości: zminimalizowane autoryzowane nagłówki, obserwowane domeny, zaufana weryfikacja i ocena dopasowania.
- Ochrona danych: treść syntetyczna lub zminimalizowana, ograniczony dostęp do dowodów i właściciel przechowywania.
- Wydanie: nierozwiązane kwestie produkcyjne, recenzent i plan ciągłości zaplanowanych powiadomień.
To artefakt planowania. Nie rejestruje żadnych rzeczywistych zgłoszeń, poświadczeń SMTP , zapytań DNS , testów awaryjnych ani zmian najemców.
Fikcyjna diagnoza: powiadomienie poszło drogą awaryjną
Fikcyjna organizacja szkoleniowa wybiera niestandardowy serwer SMTP do potwierdzeń rejestracji. Później otrzymuje próbkę z innym autorem lub podpisem niż oczekiwano. Administrator formularza proponuje zastąpienie rekordu Forms DKIM , ponieważ komunikat wygląda inaczej niż we wcześniejszym przykładzie.
Recenzent zamiast tego pyta, która ścieżka dostarczania wygenerowała próbkę i czy wystąpiła awaria. Proponowane badanie porównuje odniesienie do konfiguracji, czas komunikatu i zaobserwowane tożsamości przed dotknięciem działającego klawisza. Oddziela także powiadomienie administratora od potwierdzenia respondenta, ponieważ ich ustawienia i dowody nie muszą być identyczne.
Zespół pozostawia akceptację zastępczą otwartą do czasu uzyskania odpowiednich autoryzowanych dowodów. Nie zakłóca celowo dostaw produkcji ani nie eksportuje rzeczywistych danych rejestracyjnych w celu zademonstrowania teorii. Ten scenariusz jest fikcyjny i nie stanowi raportu o niepowodzeniu Zoho Forms ani wykonanym teście.