[ Leverans och avsändarregler ]

Plötsligt ökar volymen och leverantören stryper

Diagnostisera en volymrelaterad avmattning genom att separera applikationskvoter, SMTP uppskjutningar och permanenta fel innan du ändrar sändningshastigheter.

Av EmailAuth forskningsteam · 3 min läsning

[Nyckelpunkter]

  • Identifiera det första försenade steget och vilket system som avgav svaret.
  • Räkna unika jobb separat från försök och klassificera tillfälliga kontra permanenta misslyckanden.
  • Minska trycket utan att skapa dubbla transaktioner eller undvika restriktioner.
På den här sidan

En kö som växer under en kampanj kan ha flera orsaker. Applikationen kan producera post snabbare än dess leverantör accepterar det, leverantören kan bromsa utgående leverans, eller ett mottagande system kan skjuta upp särskilda destinationer. Genom att anropa alla tre " Gmail throttling" döljs platsen för flaskhalsen.

Leta upp det första försenade steget

Referenser: RFC 5321 §4.2.1, RFC 5321 §4.5.4.1.

Fånga tidsstämplar för jobbskapande, leverantörsinlämning, leverantörsacceptans och varje leveransförsök. Bevara hela svarstexten och systemet som avgav den. Ett framgångsrikt applikations-API-svar är inte samma händelse som den sista mottagande servern som accepterar ett meddelande. Om leverantören inte exponerar en scen, markera den som otillgänglig istället för att sluta sig till en exakt tidsstämpel.

SMTP skiljer tillfälliga negativa svar från permanenta negativa svar. Ett temporärt svar är inte en riktning att försöka igen kontinuerligt med full hastighet; det sändande systemet behöver en kö och en lämplig återförsökspolicy. Ett permanent misslyckande ska inte behandlas som en oändlig tillfällig eftersläpning. RFC 5321 avsnitt 4 och 4.5.4.

Inspektera den ändrade arbetsbelastningen

Jämför destinationsmix, unika meddelanden och försök. En kampanj som skickar många försök kan öka antalet försök utan att representera ytterligare mottagare. Separera marknadsföringsjobb från latenskänsliga transaktionsmeddelanden och kontrollera om de konkurrerar om samma samtidighets- eller prisbudget.

Google rekommenderar att du undviker skurar och ökar trafiken gradvis medan du övervakar svaren. Tillämpa nuvarande Gmail vägledning till dess angivna omfattning snarare än att översätta den till en universell gräns för säkra meddelanden per sekund. Inget offentligt nummer i denna artikel kan intyga en avsändares kapacitet. Gmail riktlinjer för avsändare.

Arbeta kön aritmetik

Referenser: RFC 5321 §4.2.1.

Den lokala syntetiska modellen börjar med en tom kö. Nya jobb kommer till 120 meddelanden per minut medan den antagna servicehastigheten är 80 per minut i tio minuter. Eftersläpningen växer med 40 per minut till 400 meddelanden. Om ankomster sedan pausas och samma servicetakt fortsätter, är den idealiserade dräneringstiden fem minuter.

Detta är köaritmetik, inte en uppmätt leverantörsgräns eller en förutsägelse av återhämtning i realtid. Det utesluter medvetet omförsök, utgång och ändrade servicepriser. Dessa utelämnanden förklarar varför en riktig kö kan ta längre tid. Bevara antagandena vid sidan av beräkningen så att ett kapacitetsark inte blir ett löfte på servicenivå som inte stöds.

Den bibehållna deterministiska respons-tillståndsmodellen, körs offline för denna granskning, behåller en försöksreskontra. Klockan 09:00 UTC får ett skriptjobb "451 4.7.0 Tillfällig hastighetsgräns; försök igen senare." Dess tillstånd blir väntande på nytt försök, den påverkade strömmen markeras för reducerat tryck och ett kontrollerat lokalt försök klockan 09:30 får "250 2.0.0 Accepted." Ett annat jobb tar emot "550 5.1.1 Ingen sådan mottagare" kl. 09:00 och går in i permanent misslyckande utan något nytt försök; nästa åtgärd är godkänd mottagarverifiering. Dessa kompletta svar är uppfunna lokala testingångar. Trettio minuter är inställningen för denna armatur igen, inte en universell leverantörsinstruktion. Koden härleder tillståndsövergångar från svarsklasser och förbjuder ett oplanerat andra försök.

Minska trycket utan att förlora korrekthet

Referenser: RFC 5321 §4.5.4.1.

Pausa eller minska den påverkade icke-nödvändiga strömmen genom den godkända schemaläggaren. Låt den ansvariga kön försöka igen tillfälliga fel med hjälp av dess policy. Undvik att skapa en andra kö som skickar om samma transaktion eftersom en instrumentpanel är försenad. Använd stabila transaktionsidentifierare för att stämma av osäkra inlämningsresultat.

För brådskande meddelanden, följ den godkända kontinuitetsvägen endast efter verifiering av autentisering och dubblettförhindrande. Rotera inte infrastruktur för att undvika en leverantörsbegränsning. Eskalera med tidsstämplar, svarstext, destinationsomfång, ruttidentifierare och bevis på korrigeringsändringen.

Återuppta expansionen när eftersläpningen och åldersfördelningen stabiliseras under en definierad legitim arbetsbelastning. Fortsätt att kontrollera de äldsta meddelandena: en låg genomsnittlig fördröjning kan dölja en liten grupp av allvarligt försenade återställningar eller kvitton.

[ Takeaway ]

Minska trycket utan att skapa dubbla transaktioner eller undvika restriktioner.

[Efter roll]

Vad detta betyder för dig

Välj din roll för praktiska nästa steg.

IT / Mail Admin

Hitta fördröjningssystemet

En kö kan stanna innan den når mottagaren.

Nästa steg

  1. Behåll scenens tidsstämplar.
  2. Separera försök från transaktioner.
  3. Inspektera åldern för det äldsta meddelandet.

CISO / SecOps

Bevara säker återhämtning

Trycket får inte orsaka förbikopplingar eller dubbletter av känslig post.

Nästa steg

  1. Granska reservauktorisering.
  2. Kräv idempotent inlämning.
  3. Behåll bevis för incidentrespons.

Grundare / Icke-teknisk

Skydda tidskänsliga resor

Kampanjkapacitet kan förbruka resurser som kunderna behöver.

Nästa steg

  1. Identifiera kritiska strömmar.
  2. Auktorisera icke väsentliga tempoändringar.
  3. Granska olöst kundpåverkan.

[ Vanliga frågor ]

Vanliga frågor

Är ett ansökningskvotfel ett mottagareavslag?

Inte nödvändigtvis. Identifiera vilket system som avgav det.

Är omförsök nya mottagarmeddelanden?

Nej. Räkna unika transaktioner separat från leveransförsök.

Betyder ett tillfälligt SMTP svar att adressen är ogiltig?

Nej. Det identifierar ett tillfälligt fel; granska hela svaret.

RFC 5321 §4.2.1

Bör permanenta misslyckanden prövas på obestämd tid?

Nej. Klassificera dem med det faktiska svaret och den policy som stöds.

RFC 5321 §4.2.1

Vad skapar exemplets eftersläpning på 400 meddelanden?

Tio minuter med ankomster som överstiger service med 40 meddelanden per minut.

Är tömningstiden på fem minuter garanterad?

Nej. Det förutsätter inga nyanlända och en konstant servicetakt.

Varför kontrollera äldsta meddelandets ålder?

Ett genomsnitt kan dölja en liten kraftigt försenad population.

Kan en ny IP användas för att undvika strypning?

Behandla inte rotation av infrastruktur som ett botemedel mot en olöst leverantörsbegränsning.

[ Källor ]

Källor

  1. RFC 5321

    Avsnitt §4.2.1 · §4.5.4.1

  2. Gmail riktlinjer för avsändare

    Avsnitt Öka sändningsvolymen långsamt för att undvika leveransproblem

[ Ordlista ]

Ordlista

Köålder
Förfluten tid sedan ett meddelande kom in i den aktuella kön.
Uppskov
Ett tillfälligt negativt SMTP svar som kräver senare hantering enligt avsändarens policy för försök igen.
Servicepris
Den modellerade eller observerade hastigheten med vilken köarbete fullbordar ett definierat stadium.

Företagets härkomst

Varför toppfinansiella institutioner och regeringar avvecklat sina instrumentpaneler för e-postsäkerhet.

Traditionella plattformar för e-postautentisering säljer dig en instrumentpanel och ber dina ingenjörer att göra jobbet. I miljöer med hög insats innebär manuell övervakning försenad tillämpning, konfigurationsdrift och oövervakade skuggdomäner.

EmailAuth är den agentiska e-postplattformen. Våra agenter verkställer p=reject, håll avsändare från tredje part i linje och flytta dina domäner till fulla RFC 9989 överensstämmelse, den nya DMARC standarden, med auditerbarhet för människor i slingan.

regeringar Stora företag Tier-1 finansiella institutioner

SaaS · Dedikerad hyresavtal · Air-gapped on-prem · BYOK-kryptering

Kunskapsbas