SMTP är en konversation, inte en enda skickaknapp. En klient öppnar en anslutning, identifierar sig, tillhandahåller ett kuvert, överför meddelandeinnehåll och läser serverns svar. Varje svar tillhör ett specifikt kommando och server. Att förstå den sekvensen gör det möjligt att förklara varför en mottagare misslyckades medan en annan accepterades och varför en initial framgång inte bevisar slutlig leverans.
Börja med anslutningen och hälsningen
Servern skickar en hälsning, vanligtvis börjar 220. Klienten använder EHLO att identifiera sig och begära förlängningsinformation; HELO tillhandahåller det äldre grundläggande hälsningsformuläret. Ett EHLO svar med flera rader använder fortsättningsrader före sin sista rad. Efter en lyckad STARTTLS handskakning kräver RFC 3207 att båda sidor förkastar SMTP kunskaper som lärts in innan TLS ; klienten bör skicka EHLO först för att upptäcka den skyddade sessionens möjligheter. Återanvänd inte den tidigare tilläggslistan.
Protokollsekvensen och svarsreglerna definieras av RFC 5321. Autentisering, TLS och inlämningspolicy är ytterligare problem, inte bevis på att den synliga Från-adressen automatiskt auktoriseras. Logga peer, tid och förhandlade funktioner utan att behålla lösenord eller återanvändbara autentiseringstokens.
Håll kuvertet åtskilt
MAIL FRÅN tillhandahåller den omvända vägen som används för transporthantering och fel. RCPT TO tillhandahåller en mottagare för den aktuella transaktionen. Inget av kommandona är den synliga Från- eller Till-rubriken i meddelandet. En transaktion kan innehålla flera RCPT-kommandon, och servern kan acceptera vissa samtidigt som den avvisar andra.
Betrakta denna syntetiska sekvens, inte ett fångat utbyte. MAIL FROM tar emot 250. RCPT TO för missing@receiver.test får 550 5.1.1, medan RCPT TO för accepted@receiver.test tar emot 250. Den accepterade mottagaren kan förbli kvalificerad för den efterföljande DATAöverföringen; den avvisade mottagaren har inte accepterats av den servern. Dessa fiktiva tilltal och svar beskriver inte en offentlig tjänst.
Överför meddelandet och läs det slutliga svaret
Efter att minst en mottagare har accepterats begär DATA innehållsöverföring. Ett 354-svar uppmanar klienten att skicka rubrikerna och brödtexten, som slutar med den önskade punktlinjen. Punkttransparens förhindrar att en innehållsrad som börjar med en punkt förväxlas med terminatorn. Till exempel sänds en innehållsrad som börjar .example med en extra inledande punkt som ..example; det mottagande SMTP lagret tar bort den tillagda punkten. En linje som endast består av den avslutande punkten har en annan roll.
Det avgörande meddelande-acceptanssvaret kommer efter innehållet, inte vid 354. I den syntetiska sekvensen, anta att servern returnerar 250 efter den avslutande punkten, med en serverlokal köidentifierare. En riktig accepterande SMTP server tar ansvar enligt beskrivningen av RFC 5321 , men acceptans är fortfarande inte en garanti för placering i inkorgen, läsning eller framgång vid ett senare nedströmshopp. Om anslutningen försvinner innan det slutliga svaret, kanske klienten inte vet om acceptans hände; ta hänsyn till eventuell dubblettleverans när du undersöker omförsök.
Tolka misslyckanden i sitt sammanhang
Ett 4xx-svar är en övergående negativ komplettering; ett 5xx-svar är en permanent negativ komplettering av begäran. Bevara hela svaret och eventuell förbättrad kod, eftersom en blottad 550 inte identifierar DMARC som orsak. Försök igen beror också på köpolicy och användbarheten av meddelandet. Att upprepa en ogiltig mottagare på obestämd tid reparerar den inte.
Om AUTH inte stöds eller avvisas, registrera det som ett separat kommandoresultat. Den beskriver inte i sig mottagarens giltighet, slutgiltig DATA-acceptans eller ett nedströms domänautentiseringsresultat. För en verklig undersökning, korrelera utskriften med avsändarköloggar, mottagarspårning och tillämplig policy och märk alla steg för vilka bevis saknas. Den här guidens exempel är hypotetiska; ingen inloggning, socket utbyte eller postleverans utfördes för dem.
Bygg en kommando- och resultatbok
- Anslutning: registrera den faktiska peeren, tiden och hälsningen.
- Funktioner: spara EHLO -resultat separat före och efter någon TLS förhandling.
- Kuvert: behåll MAIL FROM och varje RCPT TO-resultat separat.
- Innehåll: särskilj 354-inbjudan från det slutliga svaret efter den avslutande punkten.
- Osäkerhet: om det slutliga svaret saknas, markera acceptansen okänd och inspektera mottagarens/köbeviset innan du hävdar misslyckande.
- Stängning: registrera den slutliga meddelandedispositionen och olösta nedströmssteg, utan loggningsuppgifter.