Przed zaplanowaniem ponownej próby określ limit szybkości
Odroczenie Gmail nie jest diagnozą, dopóki zespół wysyłający nie uzyska pełnej odpowiedzi i etapu transakcji. Zachowaj podstawową odpowiedź SMTP , ulepszony kod stanu, tekst objaśniający, serwer odpowiadający, czas i identyfikator kolejki. Ustal, czy błąd wynika z dostarczenia do Gmail , z limitu przesyłania określonego przez dostawcę wysyłającego, czy z innego przeskoku. Podobnie wyglądające opóźnienia mogą należeć do różnych usług i wymagać różnych właścicieli.
Ten artykuł dotyczy dochodzenia w sprawie dostarczania na podstawie odpowiedzi, a aktualne wskazówki Google na temat nadawców stanowią dowód specyficzny dla dostawcy. Nie zastępuje ono dokumentacji dotyczącej limitów ruchu wychodzącego na koncie Google Workspace ani nie zapewnia jednego wspólnego limitu dla każdego produktu powiązanego z Gmailem. Przegląd źródeł miał miejsce 8 listopada 2026 r.; nie zaobserwowano rzeczywistego stanu przydziału, reputacji i zachowania kolejki.
Odróżnij tymczasową próbę od trwałej porażki
Odpowiedzi SMTP 4xx informują klienta, że żądana akcja nie została ukończona z powodu stanu tymczasowego. Odpowiedź 5xx trwale odrzuca próbę żądania w jej obecnej formie. Ulepszone kody stanu zapewniają więcej szczegółów, ale sama klasa nie identyfikuje problemu z uwierzytelnianiem ani problemu z szybkością wysyłania. Przeczytaj tekst i moment transakcji, w którym się pojawił. RFC 5321 , sekcja 4.2.1 I RFC 3463 , sekcja 2.
Nie zamieniaj stałego odbiorcy lub odrzucenia polisy w niekończącą się ponowną próbę ograniczenia szybkości. I odwrotnie, nie należy usuwać prawidłowej wiadomości umieszczonej w kolejce tylko dlatego, że jedna próba dostarczenia została odroczona. Dochodzenie powinno rozróżnić wynik ostatniej próby, bieżący stan kolejki i ostateczny wynik. To trzy różne rekordy, a ostatni z nich może być jeszcze nieznany.
Zastosuj wskazówki Google do pasującej odpowiedzi
Wytyczne Google dla nadawców określają wersję 4.7.28 jako typową odpowiedź związaną z limitem. W takim przypadku wytyczne zalecają przerwę trwającą co najmniej dziesięć minut, a następnie próbę pojedynczego połączenia; kolejna awaria wymaga kolejnych dziesięciu minut oczekiwania, a sukces pozwala na zwiększenie liczby połączeń pojedynczo. Jeśli diagnostyka nie rozróżnia DKIM, SPF lub limit adresów IP, Google zakłada, że dotyczy to wszystkich trzech. Jest to plan odzyskiwania dostosowany do odpowiedzi, a nie uniwersalny dziesięciominutowy licznik czasu dla każdego błędu SMTP . Wskazówki Google dla nadawców.
Te same wytyczne odróżniają limity związane z domeną od limitów współdzielonych adresów IP i zalecają stopniowe, monitorowane wysyłanie, a nie serie. Fakty te pomagają wybrać zakres, którego dotyczy problem. Nie zmieniaj tożsamości ani infrastruktury, aby ominąć limit. Gdy kilka strumieni współdzieli zasób, którego dotyczy problem, skoordynuj działania ich właścicieli, tak aby jeden strumień nie zużywał pojemności, którą inny czeka na przetestowanie.
Przypisz jednego właściciela kolejki
Aplikacja, usługa e-mail i agent transportowy mogą zawierać logikę ponawiania prób. Zidentyfikuj, który komponent aktualnie jest właścicielem wiadomości, zanim ktokolwiek naciśnie „wyślij ponownie”. Po pozytywnym zakończeniu odpowiedzi na dane wiadomości, odbierający serwer SMTP przejmuje odpowiedzialność za dostarczenie lub późniejszą obsługę błędów. Po tymczasowym negatywnym zakończeniu w tym momencie odpowiedzialność pozostaje po stronie klienta. Utrata połączenia przed ostateczną odpowiedzią może pozostawić wynik niepewny. RFC 5321 , sekcja 4.2.5.
Użyj istniejącego wpisu w kolejce, zamiast tworzyć nową kopię na poziomie aplikacji, gdy transport nadal jest właścicielem ponownych prób. Zapisz pierwotny czas umieszczenia w kolejce oraz każdą próbę, aby wielokrotne odraczanie nie maskowało wieku wiadomości. Jeśli wynik jest niepewny, przed utworzeniem zamiennika przejrzyj dzienniki serwera i identyfikatory wiadomości; pozornie nieudana wysyłka może w przeciwnym razie stać się zduplikowaną pocztą klienta.
Stwórz fikcyjną oś czasu bez udawania, że testujesz
Rozważmy fikcyjną kolejkę powiadomień. O godzinie 09:00 wiadomość umieszczona w kolejce otrzymuje tymczasową odpowiedź związaną z przydziałem. Operator rejestruje całą diagnostykę i wstrzymuje zakres wysyłania, którego to dotyczy. O godzinie 09:10 lub później proponowany plan umożliwia jedno kontrolowane połączenie zgodnie ze wskazówkami dostawcy. Jeśli ta próba również zostanie odroczona, kolejka zachowa własność, a następna próba będzie ponownie oczekiwana. Są to przykładowe czasy i gałęzie warunkowe, a nie przechwycone odpowiedzi Gmail .
Jeśli kontrolowana próba zakończy się pomyślnie, przed stopniowym przywróceniem współbieżności zapisz rzeczywistą odpowiedź dotyczącą zakończenia i dostępne dowody w dalszej części procesu. Jeśli zamiast tego spowoduje to trwały błąd odbiorcy, przestań traktować problem tego odbiorcy jako pierwotny tymczasowy limit. Trzymaj jego status oddzielnie od innych odbiorców w kolejce. Dobra oś czasu rejestruje, co zmieniło się pomiędzy próbami, a nie tylko liczbę kliknięć przez operatora „Ponów próbę”.
Pogodź odzyskanie dostawcy z polityką transportową
RFC 5321 opisuje opóźnione, konfigurowalne ponowne próby i pozwala na bardziej świadome strategie, gdy znana jest przyczyna. Ogólne wytyczne dotyczące ponawiania prób nie wymagają ponawiania prób w identyczny sposób w każdym miejscu docelowym, ani też minimalny 10-minutowy okres dostawcy nie powoduje usunięcia zasad kolejki nadawcy. Koordynuj autoryzowany harmonogram uwzględniający odpowiedzi z rzeczywistym oprogramowaniem pocztowym. Nie czyść kolejki, nie resetuj wieku wiadomości ani nie skracaj wygaśnięcia tylko po to, aby pulpit nawigacyjny wyglądał zdrowo. RFC 5321 , sekcja 4.5.4.1.
Eskalacja powinna obejmować najstarszą wiadomość, której dotyczy problem, liczbę odbiorców, których dotyczy problem, rozkład odpowiedzi, ostatnie zmiany w wysyłaniu oraz ostateczny termin operacyjny ustalony przez właściciela. Powiadomienie wrażliwe na czas może stać się bezużyteczne, choć z technicznego punktu widzenia możliwe jest jego ponowienie. Decyzja o anulowaniu lub zastąpieniu jest decyzją właściciela aplikacji, niezależną od normalnego zachowania agenta transportowego w zakresie ponawiania prób. Unikaj wysyłania zarówno przestarzałego oryginału, jak i zamiennika bez podjęcia decyzji.
Zamknąć tylko na podstawie zarejestrowanych dowodów
Malejąca długość kolejki może oznaczać pomyślną dostawę, wygaśnięcie, anulowanie lub usunięcie. Nie wystarczy udowodnić powrót do zdrowia. Porównaj wyniki na poziomie komunikatów i określony poziom błędów oraz zachowaj wszelkie nierozwiązane, trwałe awarie. Żaden test nie może obiecać rozmieszczenia skrzynek odbiorczych w przyszłości ani nieograniczonej liczby wiadomości.
Oś czasu kolejki i korygowanie specyficzne dla odpowiedzi z kontrolowanym wynikiem ponownej próby. Ten dokładny wymóg pozostaje otwarty. Oddzielne odwołanie do kodu SMTP firmy Google zwróciło podczas badania niedostępne przekierowanie, którego nie można powtórzyć; nie została ponowiona. Aktualne wytyczne dla nadawcy potwierdzają zalecenia zawarte w tym miejscu w wersji 4.7.28, ale nie zebrano żadnych wyników kolejki na żywo, pełnej diagnostyki klienta ani wyników kontrolowanej ponownej próby.