Ett studs som kommer efter att någon redan har skickat illa om ett meddelande är lätt att felläsa. Det kan beskriva det ursprungliga försöket, ersättningen eller en försenad nedströmshändelse. Fastställ identiteten och tidslinjen för varje inlämning innan du vidtar ytterligare åtgärder. Det senaste meddelandet i inkorgen är inte nödvändigtvis bevis på det senaste meddelandet.
Skilj en varning från ett terminalfel
Ett meddelande om leveransstatus kan rapportera försenat snarare än misslyckat. RFC 3464 definierar dessa som olika åtgärdsvärden. En försenad rapport innebär att rapporteringssystemet skulle fortsätta leveransförsöken när rapporten genererades. konsultera dess statusfält och köbevis istället för att behandla varningen som en annullering. Will-Retry-Until, när den levereras, ger en angiven horisont för ett nytt försök, inte bevis på att leveransen redan har slutförts. RFC 3464 avsnitt 2.3.
Åtgärd: misslyckades betyder rapporteringen MTA övergivna försök för den mottagaren. Det kan åtfölja en övergående 4.xx-status, som beskriver orsaken snarare än ett löfte om ett nytt försök. En misslyckad rapport är terminal för den rapporterade leveransåtgärden, men den kan endast gälla en mottagare och ett försök. Bevara mottagarblocket, ursprunglig inlämningstid, rapporteringssystem och diagnostik. En senare korrigerad inlämning har sin egen livscykel även när dess ämne och innehåll ser identiska ut med det första meddelandet.
Bygg tidslinjen från köbevis
Skapa en rad per försök eller meddelande: inlämningstid, köidentifierare, kuvertmottagare, meddelande-ID, acceptera eller avvisa hopp, svarsklass och aktuell disposition. Inkludera de ursprungliga leveransförsöken samt manuella återinlämningar. Använd inte ankomsttiden för aviseringen som en ersättning för den sista försökstiden som beskrivs i rapporten.
För en rutt med flera hopp kan ett utgående relä acceptera meddelandet och fortsätta arbeta efter att applikationen har markerat att det har skickats. Fråga vilket system som för närvarande äger kön. En applikations återsändningsknapp kan skapa en ny inlämning istället för att instruera den befintliga reläkön att försöka tidigare. Den skillnaden avgör risken för dubbla leveranser och dubbla affärsbearbetningar.
Följ en hypotetisk tidslinje med två köer
Vid 09:00, anta att ett originalbidrag hamnar i kön Q-original. Klockan 09:10 får en mottagare ett tillfälligt kapacitetsavslag och ligger kvar i väntan. Klockan 09:20 trycker en användare på skicka igen, vilket skapar Q-ersättning. Klockan 09:30 återgår kapaciteten och båda köerna når senare slutgiltig DATA-acceptans. Dessa uppfunna tider förklarar beställning, inte ett standardkompatibelt återförsöksintervall eller ett leverantörsschema.
Ersättningen annullerade inte originalet, så två godkända leveranshändelser är möjliga. En fördröjningsvarning om Q-original som anländer efter 09:30 kan beskriva dess tidigare tillstånd, inte det nuvarande tillståndet för Q-ersättning. Använd mottagare, köidentifierare, försökstider och aktuella loggar för att upprätta den relationen. Liknande ämnen eller meddelande-ID enbart bevisar det inte.
Inga transaktioner utfördes för detta exempel. I en verklig incident, särskilj varje accepterat hopp från bekräftad postlådeleverans och fråga applikationsägaren om dubbletter av meddelanden kan utlösa dubbla affärsåtgärder. Bevara båda posterna istället för att skriva om originalet som en framgångsrik ersättning.
Bestäm om en annan inlämning är motiverad
Kontrollera först det aktuella läget för originalet och ersättningsförsöken. Om endera fortfarande är i kö eller dess slutliga svar är osäkert, ökar en annan återsändning tvetydigheten. En timeout efter meddelandedata kan göra avsändaren osäker på om mottagaren accepterade meddelandet, en risk som uppmärksammas i SMTP :s timeout- och tillförlitlighetsdiskussion. RFC 5321 avsnitt 4.5.3.2 och 6.1.
Om ett original förblir väntande, använd endast tjänstens stödda kökontroller med lämplig behörighet. Ta inte bort företagspost i kö bara för att städa händelsen och anta inte att en avbokning lyckades förrän systemet bekräftar det. För tidskänsligt transaktionsinnehåll, samordna med applikationsägaren så att upprepad meddelandeleverans inte upprepar en oåterkallelig affärsåtgärd.
Stäng varje försök separat
Registrera om varje inlämning misslyckades, löpte ut, förblev väntande, avbröts genom en auktoriserad åtgärd eller accepterades vid relevant hopp. Koppla den sena aviseringen till försöket som den faktiskt beskriver. Om korrelationen förblir osäker, säg det istället för att förklara att den senaste sändningen misslyckades.
Kommunicera det praktiska resultatet till avsändaren: om den tilltänkta mottagaren fått informationen och om någon dubblettåtgärd behöver uppmärksammas. Håll SMTP acceptans, postlådeleverans och företagsslutförande distinkt. En korrekt tidslinje är mer användbar än en annan overifierad återsändning.
Bestäm dig innan en ny sändning
- Ursprungligt väntande: bekräfta köägarskap och stödda kontroller för nästa försök.
- Ersättning väntar: undersök det separat; dess existens upphäver inte originalet.
- Acceptans osäker: stämma av mottagandet av bevis innan du lägger till ytterligare en kopia.
- Slutligt misslyckande: fastställa vilken mottagare och inlämning den tillhör.
- Stängning: registrera varje inlämning och bekräfta om någon dubblerad affärsåtgärd behöver åtgärdas.