Oddziel protokół od uprawnień odbiorcy
BIMI kwalifikowalność nie jest ustalana poprzez znalezienie słowa DMARC w rekordzie DNS . Przed wyświetleniem logo operator musi określić obowiązującą politykę uwierzytelniania, czy faktyczna wiadomość przechodzi wymagane kontrole oraz czego aktualnie potrzebuje zamierzony odbiorca. Są to powiązane, ale odrębne pytania. Bieżąca specyfikacja protokołu i strona pomocy operacyjnej dostawcy mogą również różnić się terminologią lub czasem migracji, więc dowody wymagają dat i wyraźnego zakresu.
W artykule porównano zachowane źródła pierwotne. Strona konfiguracji Google została zaktualizowana 26 października; Strona BIMI Yahoo została pobrana bez równoważnej widocznej daty wersji. RFC 9989 dostarcza bieżący kontekst protokołu DMARC . Artykuł nie testuje dzierżawcy ani nie wnioskuje, że dostawca wdrożył każdy aspekt nowszej specyfikacji RFC. BIMI pozostaje pracą roboczą, a wyświetlacz odbiornika nie gwarantuje uniwersalnego protokołu.
Zapisz faktycznie opublikowane warunki Google
Strona konfiguracji BIMI Google mówi, że wiadomości muszą być uwierzytelniane przez DMARC i listy p=quarantine Lub p=reject, przy pct=100. Wymaga także a VMC Lub CMC ze względu na udokumentowany przepływ pracy oparty na certyfikatach i nie obsługuje samodzielnego wdrażania w Gmail wyłącznie w formacie SVG. Zapisz te stwierdzenia jako opublikowane przez Google wskazówki dotyczące kwalifikowalności, a nie pełną definicję DMARC lub dowód konkretnego wyniku wiadomości. Wymagania konfiguracyjne Google
Wymagania SVG i instrukcje dotyczące hostingu stanowią dodatkowe bramy. Odpowiednia polityka DMARC nie powoduje, że nieprawidłowy obraz jest odpowiedni, nie uzyskuje certyfikatu ani nie udostępnia publicznie PEM. I odwrotnie, ważny certyfikat nie naprawia wyrównanego uwierzytelnienia nadawcy, który uległ awarii. Użyj listy kontrolnej z oddzielnymi wierszami, aby zespół nie mógł przypadkowo oznaczyć całego projektu jako gotowego po wypełnieniu tylko wiersza zasad DNS.
Zamiast ukrywać rozbieżności, ujawnij je
RFC 9989 zastępuje wcześniejsze specyfikacje DMARC i usuwa znacznik pct. Jego dodatek wyjaśnia historyczny mechanizm procentowy i wprowadza znacznik testujący t z wartościami y i n. Jest to znacząca zmiana protokołu, podczas gdy zachowana strona Google BIMI nadal wyraźnie wspomina o pct=100. Obie obserwacje należy zachować, zamiast po cichu przepisywać którekolwiek źródło, aby wyglądały identycznie. RFC 9989 , dodatek A.6
Reakcją operacyjną jest potwierdzenie możliwości zastosowania bieżącego odbiorcy przed zmianą polityki produkcyjnej na podstawie tego niedopasowania. Nie twierdz, że Google ignoruje, wymaga transmisji lub wewnętrznie tłumaczy określony tag, chyba że aktualne dowody potwierdzają takie zachowanie. Nie traktuj t jako powszechnie sprawdzonego substytutu kwalifikowalności BIMI dla pct tylko dlatego, że RFC wyjaśnia ich historyczny związek. Wdrażanie dostawcy i dokumentacja dostawcy mogą zmieniać się według różnych harmonogramów.
Dlatego zapis dotyczący zastosowania źródła powinien zawierać wersję RFC, datę strony dostawcy, dokładny stan sporny i nierozwiązane pytanie. Poproś odpowiedzialnego recenzenta o rozwiązanie tego problemu na podstawie dowodów aktualnego dostawcy lub autoryzowanej obserwacji o odpowiednim zakresie. W tym artykule nie ma takiego potwierdzenia. Konflikt jest powodem bramki, a nie powodem do osłabienia egzekwowania prawa lub improwizowanego twierdzenia o zgodności.
Niezależnie porównaj warunki określone przez Yahoo
Własna strona BIMI Yahoo wymaga poddania się kwarantannie lub odrzucenia zasad DMARC , a Rekord BIMI wskazując ważny plik SVG, pocztę masową oraz wystarczającą reputację i zaangażowanie dla adresu wysyłającego. Mówi, że VMC nie są obecnie wymagane, chociaż dostarczony VMC informuje o ogólnej kwalifikowalności. Jej strona honoruje rekordy BIMI subdomeny, preferując konfigurację domeny organizacyjnej. Są to oświadczenia specyficzne dla Yahoo, a nie dowód na to, że Gmail korzysta z tego samego certyfikatu lub zasad wyświetlania. Wymagania Yahoo BIMI
Nie interpretuj braku warunku pct przez Yahoo na tej stronie jako dowodu na każde możliwe zachowanie w zakresie obsługi tagów. Zapisz, co faktycznie podaje źródło, a co pozostawia nieokreślone. Podobnie warunki związane z pocztą masową i reputacją oznaczają, że pojedyncza osobista wiadomość testowa może nie reprezentować udokumentowanej populacji wyświetlanej logo. Nie wymyślaj progu wysyłania liczb, jeśli recenzowane źródło go nie podaje.
Połącz politykę z rzeczywistym uwierzytelnianiem wiadomości
DMARC ocenia wyrównanie pomiędzy widoczną domeną From a przejściem SPF Lub DKIM tożsamość zgodnie z jej zasadami. Opublikowane preferencje dotyczące egzekwowania nie zmuszają każdego legalnego nadawcy do przejścia. Zrób inwentaryzację usług wysyłających i zidentyfikuj, które tożsamości uwierzytelniają, zanim zaproponujesz bardziej rygorystyczne traktowanie. Zmiany w zasadach mogą mieć wpływ na legalny przepływ pracy, dlatego ostateczny termin wydania logo nie może pomijać procesu gotowości i zatwierdzania zespołu pocztowego. Uwierzytelnianie i dopasowanie RFC 9989
Do późniejszej kontrolowanej obserwacji zachowaj faktycznie odebraną wiadomość i zaufane wyniki uwierzytelnienia. Nie akceptuj żądanego przejścia z dowolnego nagłówka bez zidentyfikowania systemu produkującego i granicy zaufania. Zachowaj odkrywanie zasad, uwierzytelnianie wiadomości i wyświetlanie logo jako osobne wyniki; wiadomość może przejść uwierzytelnienie bez spełnienia dodatkowych warunków wyświetlania odbiorcy. Granica zaufania RFC 8601
Oryginalny arkusz kwalifikacyjny odbiorcy
Utwórz po jednym wierszu na odbiorcę i strumień poczty. Poniższe proponowane pola zapobiegają ukrywaniu istotnych różnic przez ogólny status „Gotowy BIMI ”. W tym arkuszu nie oceniono żadnego rzeczywistego wdrożenia.
- Źródło: strona odbiorcy, data pobrania, widoczna data wersji i wersja referencyjna protokołu.
- Polityka domeny: dokładny obowiązujący rekord oraz wszelkie pytania dotyczące organizacji lub subdomeny.
- Niezgodność dokumentacji: kwestionowana etykieta lub stan, dowód i nierozwiązany właściciel zastosowania.
- Dowody wiadomości: widoczne od, uwierzytelnione tożsamości, wyrównanie i zaufane źródło wyników.
- Zasób: zatwierdzona wersja SVG, wymiary korpusu i ustalenia konstrukcyjne.
- Certyfikat: wymagana kategoria, status wydawcy i zależność od hostowanego PEM.
- Wyszukiwanie i wyświetlanie: publiczne dowody punktu końcowego, klient-odbiorca, czas obserwacji i limity.
- Decyzja: kwalifikuje się, nie kwalifikuje się lub jest nieznana dla tej transmisji, z pozostałymi warunkami.
Trzymaj decyzje dotyczące monitorowania i egzekwowania oddzielone od eksperymentów związanych z wyświetlaniem. Jeśli istniejącemu nadawcy nie uda się dopasować, rozwiąż problem z konfiguracją nadawcy i jego wpływem na działalność biznesową, zamiast wielokrotnie zmieniać plik logo. Jeśli uwierzytelnienie zakończy się pomyślnie, ale nie pojawi się żadne logo, sprawdź certyfikat, hosting, wsparcie i uznaniowe uprawnienia, nie deklarując, że DMARC jest uszkodzony wyłącznie z powodu brakującej grafiki.
Fikcyjny przykład: jedna lista kontrolna kryje w sobie dwóch odbiorców
Fikcyjny Silver Orchard przygotowuje listę kontrolną uruchomienia, która zawiera informację „Przepustka DMARC , certyfikat opcjonalny”. To sformułowanie łączy pozycję certyfikatu Yahoo z innym udokumentowanym przepływem pracy Gmail . Recenzent zauważa również, że starszy przewodnik wewnętrzny traktuje pct jako niezmienione wymaganie protokołu uniwersalnego, podczas gdy RFC 9989 go usunął, a bieżąca strona Google nadal podaje pct=100. Zespół ma dwa pytania dotyczące dokumentacji, a nie dowodów na to, że którykolwiek z odbiorników działa nieprawidłowo.
Proponowanym następnym krokiem jest podzielenie listy kontrolnej na wiersze odbiorników datowane na źródło i eskalacja pytania dotyczącego zastosowania tagów przed zmianą produkcyjnego DNS . Każdy strumień wymagałby rzeczywistych dowodów wiadomości oraz własnych kontroli zasobów i certyfikatów. Nie testowano żadnej wiadomości Silver Orchard, rekordu DNS ani odbiornika. Przykład ilustruje, jak ogólna lista kontrolna może ukryć nierozwiązane założenia.
Katalog wymaga specyficznej dla odbiorcy matrycy kwalifikacyjnej oraz dowodu uwierzytelnienia DNS , logo, certyfikatu i wiadomości. Ten manuskrypt dostarcza proponowaną matrycę i udokumentowane różnice, a nie dowody operacyjne. Oryginalne dowody, ludzkie MŚP, możliwość zastosowania źródła, trasy produkcji, dostępność wizualna i zezwolenie właściciela – wszystko to pozostaje otwarte. Nie sugeruje się żadnych zmian w zasadach, testów na żywo ani gwarancji kwalifikowalności.