Odróżnij pocztę w chmurze Coremail od samodzielnie zbudowanego systemu
Oficjalny artykuł Coremaila „如何设置企业邮箱的SPF” odróżnia pocztę w chmurze od systemów samodzielnie zbudowanych. W przypadku poczty w chmurze opisuje dodanie DNS Rekord TXT i podaje przykład za pomocą include:spf.icoremail.net. Kieruje samodzielnie zbudowane wdrożenia do różnych wskazówek, zamiast przedstawiać usługę chmury jako uniwersalną autoryzację. W tym artykule omówiono udokumentowaną trasę SPF poczty w chmurze i powiązaną z nią dyskusję dotyczącą pomocy administratora publicznego DMARC. Nie ustala DKIM udostępnianie, wartości wygenerowane przez aktualnego najemcę lub uniwersalną konfigurację dla wszystkich edycji Coremail. Instrukcje Coremail SPF
Zanim zaproponujesz zmianę, potwierdź faktycznie subskrybowaną usługę. Firma może korzystać z oprogramowania Coremail, obsługując własną infrastrukturę wychodzącą, lub może korzystać z usługi w chmurze dostawcy. Ustalenia te nakładają różne wymogi dowodowe na serwery upoważnione do wysyłania. Zapisz nazwę usługi, odpowiedzialnego operatora, zamierzoną domenę koperty i aktualnie obsługiwane instrukcje. Na zachowanych stronach nie podano daty publikacji każdej instrukcji, dlatego należy sprawdzić aktualne zastosowanie, a nie wyciągać wnioski z roku praw autorskich do witryny.
To jest dokumentacyjny plan konfiguracji. Nie skontrolowano żadnej skrzynki pocztowej, domeny ani serwera, nie wykonano żadnego zapytania DNS , zmiany dzierżawcy ani wiadomości testowej. Pierwotny wymóg katalogu dotyczący faktycznego wdrożenia i weryfikacji pozostaje otwarty. Węższy zakres oparty na źródle jest celowo widoczny, aby czytelnik nie pomylił przewodnika po publikacji SPF z ukończoną akceptacją SPF , DKIM i DMARC .
Użyj przykładu SPF w chmurze jako danych wejściowych o określonym zakresie
Artykuł dotyczący poczty w chmurze kieruje operatora do interfejsu administracyjnego DNS domeny i do utworzenia rekordu TXT . Jego ilustracyjne ustawienia wykorzystują notację hosta domeny głównej, domyślną linię rozdzielczości i dziesięciominutowy TTL. Są to przykładowe opcje prezentacji, a nie dowód, że każdy edytor DNS akceptuje te same dane wejściowe lub że rekord konkretnego klienta powinien zastąpić istniejące dane. Potwierdź w pełni wykwalifikowanego właściciela i rzeczywistą semantykę pola dostawcy DNS . Instrukcje Coremail SPF
Przed zastosowaniem autoryzacji dostawcy należy uzyskać istniejącą zatwierdzoną politykę w ramach autoryzowanego procesu i inwentaryzować inne legalne usługi wysyłania. Jeżeli poczta personelu, powiadomienia na stronie internetowej i aplikacja mają tę samą tożsamość, należy je przeglądać łącznie. Krótki przykład usługi w chmurze nie jest bezpiecznym zamiennikiem istniejących zasad dotyczących wielu nadawców. Zachowaj niepowiązane rekordy TXT u właściciela, upewniając się, że obowiązuje tylko jedna obowiązująca zasada SPF . RFC 7208 , sekcje 3.1–3.3
Mechanizm dołączania ocenia politykę SPF innej domeny w ramach reguł protokołu; nie jest to ogólne stwierdzenie, że jakakolwiek wiadomość wspominająca o Coremailu jest uzasadniona. Przejrzyj ścieżkę zależności i oszacowany limit terminu zapytania DNS. Buforowanie nie zmienia dziesięciookresowego limitu oceny w większy limit, a liczenie tylko widocznych uwzględnień najwyższego poziomu może spowodować pominięcie pracy zagnieżdżonej. Zachowaj nierozwiązane zależności jako jawne elementy przeglądu, zamiast spłaszczać je w zgadywane adresy. RFC 7208 , sekcje 4.6.4 i 5.2
Sprawdź tożsamość faktycznie ocenianą przez SPF
SPF ma zastosowanie do odpowiedniego SMTP POCZTA OD tożsamość lub HELO w odpowiednich przypadkach. Domena w widocznym adresie Od może być inna. To rozróżnienie ma znaczenie, gdy trasa w chmurze korzysta z tożsamości koperty zarządzanej przez dostawcę lub gdy aplikacja zmienia prezentację nadawcy bez zmiany rzeczywistej ścieżki przesyłania. Zapisz te tożsamości osobno, zamiast traktować pole Od redaktora jako wynik SPF . RFC 7208 , sekcje 2.3–2.4
Ostateczny mechanizm polityki daje wynik oceny SPF ; nie gwarantuje, że każdy odbiorca odrzuci, podda kwarantannie lub dostarczy wiadomość w określony sposób. Obsługa odbiornika i inne elementy sterujące pozostają istotne. Awaria może pomóc w zdiagnozowaniu nieautoryzowanej trasy, ale nie stanowi pełnego wniosku po zdarzeniu. Wynik pozytywny potwierdza jedynie odpowiednią ocenę autoryzacyjną, a nie prawdziwość treści wiadomości czy bezpieczeństwo żądania płatności. RFC 7208 , sekcja 8 RFC 9989 , sekcja 2.4
Oddziel wymagania wstępne DMARC dostawcy od semantyki protokołu
Publiczna pomoc administratora Coremail zaleca skonfigurowanie określonej chmury Rekord SPF przed ustawieniem proponowanego Rekord DMARC. Zachowaj to jako warunek wstępny konfiguracji podany przez dostawcę dla udokumentowanej trasy. To nie to samo, co reguła protokołu mówiąca, że DMARC musi zawsze przejść zarówno SPF jak i DKIM . DMARC może wykorzystać kwalifikujący się wyrównany wynik pozytywny z dowolnego mechanizmu. Pomoc administratora Coremail, „Jak ustawić rekord DMARC ?” RFC 9989 , sekcja 4.4
Strona pomocy zawiera przykład zasad monitorowania z miejscami docelowymi raportowania obsługiwanymi przez Coremail. Nie kopiuj tych odbiorców jako automatycznego upoważnienia do udostępniania danych z raportu organizacji. Właściciel domeny musi zdecydować, kto otrzymuje raporty, jaki rodzaj usług ma zastosowanie i czy wybrane miejsce docelowe jest odpowiednie. Podobnie przykład monitorowania nie upoważnia do osłabiania istniejącej polityki kwarantanny lub odrzucania. Trzymaj decyzję dotyczącą zasad organizacji oddzielnie od ciągu ilustracyjnego dostawcy.
Tekst pomocy zawiera ogólne stwierdzenia na temat phishing zapobieganie i dostarczanie raportów. W tym przewodniku nie traktuje się ich jako gwarancji. Uwierzytelnianie jest ograniczone tożsamością domeny i wyrównanie; Dostępność raportowania i zachowanie odbiorcy nie są potwierdzane poprzez publikację rekord. Zalecana metoda akceptacji rejestruje rzeczywiste dowody, gdy tylko staną się dostępne, i nie interpretuje milczenia jako dowodu, że żadna poczta nie została wysłana ani że nie doszło do nadużycia. RFC 9989 , sekcje 2.4 i 5.3
Pozostaw implementację DKIM nierozwiązaną do czasu wsparcia
Zachowane instrukcje SPF w chmurze i dyskusja administratorów nie zapewniają pełnego przepływu pracy włączania DKIM , selektor reguła alokacji lub klucz publiczny specyficzny dla konta. Nie generuj dowolnej pary kluczy ani nie publikuj odgadniętego selektora, aby szersza lista kontrolna uwierzytelniania wyglądała na kompletną. System wysyłający musi faktycznie podpisać się odpowiednim materiałem prywatnym, a odbiorca musi zlokalizować odpowiedni publiczny rekord weryfikacyjny, korzystając z selektora i domeny podpisu. RFC 6376 , sekcje 3.5 i 3.6.2.2
Przydziel otwarte zadanie DKIM odpowiedzialnemu administratorowi serwisu i uzyskaj odpowiednie oficjalne instrukcje przed zaplanowaniem wdrożenia. Zapisz, czy wymaganie dotyczy poczty w chmurze, samodzielnego wdrożenia, czy innej ścieżki produktu. Ustawienie przychodzącej weryfikacji DKIM nie jest dowodem na włączenie podpisywania wychodzącego. Dopóki nie zostanie ustalona rzeczywista trasa i obsługiwane elementy sterujące, bramka implementacji DKIM artykułu pozostaje otwarta, a nie jest po cichu zadowalana poprzez wyjaśnienie protokołu.
Fikcyjna diagnoza: przykład chmury zastosowany do niewłaściwej trasy
Rozważmy fikcyjną organizację Lantern Manufacturing z samodzielnie obsługiwaną platformą pocztową i oddzielnie zakontraktowaną usługą w chmurze. Administrator znajduje przykład SPF w chmurze i proponuje zastąpienie nim aktualnej polityki organizacji. Inny kolega zakłada, że opublikowany rekord DMARC również spowoduje utworzenie podpisu DKIM . Żadne założenie nie jest zaobserwowanym zdarzeniem ani wynikiem testu; jest to fikcyjne ćwiczenie przeglądowe.
W proponowanym przeglądzie w pierwszej kolejności dokonano klasyfikacji tras nadania. Zachowuje zatwierdzone autoryzacje trasy obsługiwanej samodzielnie i potwierdza, czy uwzględnienie w chmurze ma znaczenie dla jakichkolwiek komunikatów objętych zakresem. Następnie rozdziela publikację SPF , politykę DMARC i włączenie DKIM na różne elementy robocze. Żaden rekord nie jest uznawany za kompletny tylko dlatego, że przypomina przykład. Właściciel wymaga odpowiednich dowodów dla każdej trasy i pozostawia nierozwiązaną nieznaną konfigurację DKIM .
Pusty arkusz akceptacji poczty w chmurze
- Rzeczywisty produkt, model wdrożenia i potwierdzenie obecnego dostawcy: ____.
- Właściciel firmy, administrator poczty i autorytatywny operator DNS : ____.
- Trasa wysłania w zakresie, MAIL Z domeny i widoczna Z domeny: ____.
- Istniejąca polityka SPF , zachowani legalni nadawcy i proponowana autoryzacja w chmurze: ____.
- Zamierzona pełna konwencja wprowadzania właściciela DNS i edytora: ____.
- Oceniony przegląd zależności SPF i nierozwiązane błędy: ____.
- Warunek wstępny DMARC dostawcy i decyzja dotycząca polityki organizacyjnej: ____.
- Zatwierdzeni odbiorcy raportów i obowiązujące ustalenia dotyczące usług: ____.
- Informacje o implementacji DKIM są nadal wymagane: ____.
- Autoryzowane obserwacje DNS , wyniki odebranych wiadomości i osoba zatwierdzająca wydanie: ____.
Wszystkie pola są puste. Oryginalne dowody, przegląd przeprowadzony przez człowieka/MŚP, zastosowanie źródła, trasy produkcji, przegląd wizualny/dostępności i zezwolenie właściciela pozostają otwarte. Ta wersja robocza nie wymaga aktywnej konfiguracji, pomyślnego wyniku wiadomości ani gwarantowanej dostawy.