Reset hasła musi dotrzeć, zanim jego link straci ważność. Potwierdzenie musi opisywać właściwe zamówienie i nie pojawiać się ponownie po ponowieniu próby.
Te wymagania zaczynają się w Twojej aplikacji i obowiązują dalej, gdy usługa e-mail przyjmie wiadomość.
Co powinna zawierać wiadomość transakcyjna?
Przekaż odbiorcy informację lub akcję wymaganą przez zdarzenie, które wywołało e-mail. Potwierdzenie potwierdza zamówienie. Wiadomość resetująca umożliwia odzyskanie dostępu.
Użyj rozpoznawalnej nazwy nadawcy. Napisz temat identyfikujący zdarzenie. Kieruj odpowiedzi na adres monitorowany przez Twój zespół, jeśli przepływ wymaga wsparcia.
Dla przykładowego potwierdzenia zamówienia użyj tematu takiego jak Receipt for order 8472. Dołącz numer zamówienia, kupione produkty i kontakt do wsparcia. W przypadku wiadomości resetującej umieść akcję resetu na początku i podaj, kiedy wygasa.
Przetestuj treść zarówno w HTML, jak i w formacie tekstowym. Sprawdź, czy główna akcja pozostaje zrozumiała na wąskim ekranie i przy wyłączonych obrazach.
Oddzielaj promocje od niezbędnych wiadomości dotyczących konta. E-mail transakcyjny a marketingowy wyjaśnia, jak cel wiadomości wpływa na kontrolę odbiorców i zasady wysyłki.
Jak uwierzytelniać i rozdzielać nadawców?
Uwierzytelnij domenę wysyłkową przed ruchem produkcyjnym. Wymagania Gmaila wobec nadawców wymagają SPF lub DKIM dla wszystkich nadawców wysyłających na osobiste konta Gmail. Nadawcy przekraczający 5000 wiadomości dziennie potrzebują SPF, DKIM i DMARC.
Używaj osobnych tożsamości wysyłkowych dla poczty operacyjnej i marketingowej. Wytyczne Yahoo zalecają oddzielanie masowego marketingu od ruchu transakcyjnego po IP lub domenie podpisującej DKIM. Oba niosą sygnały reputacji, więc sam inny adres From nie rozdziela infrastruktury.
Zwiększaj wolumen wysyłki stopniowo. Wytyczne Google ostrzegają przed nagłymi skokami. Sprawdzaj odroczenia i odbicia podczas zwiększania, aby móc zmniejszyć tempo, gdy serwery odbierające nie radzą sobie z ruchem.
Lista kontrolna doręczalności obejmuje szerszy zakres prac nad uwierzytelnianiem i reputacją nadawcy.
Jak obsługiwać blokady i preferencje?
Sprawdź, dlaczego odbiorca jest zablokowany, zanim zdecydujesz, czy kolejne wysłanie jest uzasadnione. Rezygnacja z marketingu i niedoręczalny adres wymagają różnych działań.
Zasady kategorii Bird pozwalają na wysyłkę transakcyjną po rezygnacji wyłącznie z marketingu. Twarde odbicia, ręczne blokady i rezygnacja obejmująca wszystkie wiadomości blokują obie kategorie.
Kategoria transakcyjna nie znosi więc każdego ograniczenia wobec odbiorcy. Gdy Bird zgłasza recipient_suppressed, sprawdź rekord blokady i preferencje odbiorcy. Ponowne wysłanie tej samej wiadomości nie naprawi adresu ani nie zmieni tych zasad.
Jak powinny wygasać linki i kody resetujące?
Wymuszaj wygasanie w aplikacji, która waliduje link lub kod. Tekst w e-mailu nie może zapobiec przyjęciu wygasłego poświadczenia.
OWASP, społeczność bezpieczeństwa aplikacji, zaleca losowo generowane tokeny lub kody resetujące z odpowiednim okresem ważności. Zaleca również jednorazowe użycie. Unieważnij poświadczenie po pomyślnym użyciu, aby ta sama wiadomość nie mogła autoryzować kolejnego resetu.
Wybierz czas życia dla akcji na koncie i pokaż go w wiadomości. Uwzględnij czas oczekiwania w aplikacji i czas doręczenia. E-mail odebrany po wygaśnięciu potrzebuje możliwości zażądania nowego resetu.
Przed ponowieniem niewysłanego zadania resetu sprawdź, czy jego poświadczenie jest nadal ważne. Nie przedłużaj ważności poświadczenia tylko dlatego, że próba wysłania się nie powiodła. W przeciwnym razie ponowienia mogą utrzymywać poświadczenie jako użyteczne dłużej niż wybrany czas życia.
Dla adresów URL resetu OWASP zaleca HTTPS i zaufaną domenę docelową. Zaleca również ograniczanie liczby żądań resetu na konto, aby zapobiec zalewaniu skrzynki odbiorczej.
Jak ponowienia unikają duplikatów wysyłki?
Przechowuj trwały rekord zdarzenia biznesowego i jego operacji wysyłki. Powtórzone zdarzenie zamówienia powinno odnaleźć istniejące zadanie potwierdzenia zamiast tworzyć kolejne.
Użyj tego samego klucza idempotentności przy ponawianiu tego samego żądania API po niepewnej odpowiedzi. Kontrakt idempotentności Bird przechowuje zakończoną odpowiedź przez trzy godziny. Po tym oknie kolejne żądanie z tym samym kluczem może utworzyć kolejną wiadomość.
Ten limit sprawia, że własny rekord zdarzenia jest niezbędny przy starszych ponowieniach. Zapisz zwrócony identyfikator wiadomości przy zdarzeniu, zanim uznasz wysyłkę za zakończoną.
Odroczenie doręczenia to coś innego niż niepewna odpowiedź API. Bird automatycznie ponawia odroczone doręczenia. Tworzenie kolejnego wysłania dla każdego odroczenia może dodać duplikaty, gdy oryginał wciąż jest w toku.
Co monitorować i na co alertować?
Śledź każdą oczekiwaną wiadomość od momentu wysłania. Rejestruj wynik dla każdego odbiorcy. Mierz, czy użytkownik wykonuje zamierzoną akcję.
Zdarzenia doręczenia Bird rozróżniają akceptację, doręczenie, odroczenie, odbicie i odrzucenie. Doręczenie oznacza, że serwer odbierający przyjął wiadomość. Nie potwierdza umieszczenia w skrzynce odbiorczej ani odczytania.
Rejestruj czas zdarzenia biznesowego obok czasu wysłania i wyniku dla odbiorcy. W przypadku wiadomości resetujących porównuj czas, który upłynął, z pozostałym czasem życia poświadczenia. Mierz ukończone resety w swojej aplikacji. Zdarzenie śledzenia otwarcia nie dowodzi, że osoba przeczytała wiadomość.
Ustaw alerty wokół limitów operacyjnych przepływu:
- Niewysłane zadania zbliżają się do wygaśnięcia.
- Liczba błędów przekracza normalny zakres.
- Przetwarzanie webhooków zaczyna się opóźniać.
Przypisz właściciela, który może zareagować na każdy alert.
| Awaria | Dowody do zbadania | Właściciel i następna akcja |
|---|---|---|
| Brak wysyłki po zdarzeniu zamówienia | Zadanie aplikacji i rekord zdarzenia | Zespół aplikacji: odtwórz brakujące zadanie bez duplikowania istniejącej wysyłki |
| Zablokowany odbiorca | Powód odrzucenia, blokada i preferencje | Zespół wsparcia lub wysyłki: zbadaj blokadę przed kolejną próbą |
| Rosnące odroczenia doręczeń | Zdarzenia odbiorcy i wolumen wysyłki | Zespół wysyłki: sprawdź odpowiedzi serwerów odbierających i ogranicz skok ruchu |
| Wygasły reset przy dostarczeniu | Wygaśnięcie poświadczenia i znaczniki czasu zdarzeń | Zespół aplikacji: zbadaj opóźnienie i udostępnij ścieżkę ponownego żądania |
| Powtórzone dostarczenie webhooka | Identyfikator webhooka i rekord przetwarzania | Zespół aplikacji: pomiń pracę już wykonaną dla tego zdarzenia |
Weryfikuj sygnatury webhooków przed przyjęciem zdarzeń. Przewodnik po webhookach Bird używa webhook-id do deduplikacji, dzięki czemu ponowione powiadomienie nie powtarza pracy Twojej aplikacji.
Co sprawdzić przed wysyłką przez Bird?
Przetestuj przepływ od wysyłki, przez wynik dla odbiorcy, po odtwarzanie po awarii, zanim użyjesz go do wysyłki wiadomości dotyczących kont.
- Zweryfikuj domenę wysyłkową. Sprawdź, czy ruch operacyjny używa zamierzonej tożsamości i puli.
- Opublikuj szablon. Przetestuj szczegóły potwierdzenia lub akcję resetu z reprezentatywnymi parametrami.
- Ustaw
category: "transactional"dla treści operacyjnych. Zastosuj udokumentowane zasady blokad i preferencji. - Zachowaj rekord zdarzenia biznesowego i klucz idempotentności. Przechowuj identyfikator wiadomości zwrócony przez endpoint wysyłki.
- Przetestuj obsługę błędów za pomocą sandboxa pocztowego. Jego symulowane wyniki przechodzą przez normalne ścieżki zdarzeń i webhooków bez trafiania do prawdziwej skrzynki.
- Sprawdź oś czasu dla odbiorcy w logu e-mail. Potwierdź, że Twoja aplikacja obsługuje te same wyniki i kieruje alerty do ich właścicieli.