SMTP is een gesprek, geen enkele verzendknop. Een client opent een verbinding, identificeert zichzelf, levert een envelop aan, verzendt berichtinhoud en leest de reacties van de server. Elk antwoord behoort tot een specifieke opdracht en server. Als u die volgorde begrijpt, kunt u verklaren waarom de ene ontvanger faalde terwijl de andere werd geaccepteerd, en waarom een aanvankelijk succes geen definitieve levering betekent.
Begin met de verbinding en begroeting
De server verzendt een begroeting, meestal beginnend met 220. De client gebruikt EHLO om zichzelf te identificeren en extensie-informatie op te vragen; HELO biedt het oudere basisbegroetingsformulier. Een EHLO -antwoord met meerdere regels gebruikt vervolgregels vóór de laatste regel. Na een succesvolle STARTTLS handdruk vereist RFC 3207 dat beide partijen SMTP kennis die vóór TLS is geleerd, negeren; de client moet eerst EHLO sturen om de mogelijkheden van de beveiligde sessie te ontdekken. Gebruik de eerdere extensielijst niet opnieuw.
De protocolvolgorde en antwoordregels worden gedefinieerd door RFC 5321. Authenticatie, TLS en indieningsbeleid zijn aanvullende zorgen, geen bewijs dat het zichtbare Van-adres automatisch wordt geautoriseerd. Registreer de peer-, tijd- en onderhandelde functies zonder wachtwoorden of herbruikbare authenticatietokens te bewaren.
Houd de envelop apart
MAIL VAN levert het omgekeerde pad dat wordt gebruikt voor transportafhandeling en -storingen. RCPT TO levert een ontvanger voor de huidige transactie. Geen van beide opdrachten is de zichtbare kop Van of Naar in het bericht. Een transactie kan verschillende RCPT-opdrachten bevatten, en de server kan sommige accepteren en andere weigeren.
Beschouw deze synthetische reeks, niet een vastgelegde uitwisseling. MAIL FROM ontvangt 250. RCPT TO voor missing@receiver.test ontvangt 550 5.1.1, terwijl RCPT TO voor accepted@receiver.test 250 ontvangt. De geaccepteerde ontvanger kan in aanmerking blijven komen voor de daaropvolgende GEGEVENSoverdracht; de afgewezen ontvanger is niet geaccepteerd door die server. Deze fictieve adressen en antwoorden beschrijven geen openbare dienst.
Breng het bericht over en lees het definitieve antwoord
Nadat ten minste één ontvanger is geaccepteerd, vraagt DATA om inhoudsoverdracht. Een 354-antwoord nodigt de client uit om de koptekst en de hoofdtekst te verzenden, eindigend met de vereiste stippellijn. Punttransparantie voorkomt dat een inhoudsregel die met een punt begint, wordt aangezien voor de terminator. Een inhoudsregel die begint met .example wordt bijvoorbeeld verzonden met een extra voorlooppunt als ..example; de ontvangende SMTP laag verwijdert die toegevoegde punt. Een lijn die alleen uit het eindpunt bestaat, heeft een andere rol.
Het beslissende berichtacceptatieantwoord komt na de inhoud, en niet op 354. Stel dat in de synthetische reeks de server 250 retourneert na de afsluitende punt, met een server-lokale wachtrij-ID. Een echte accepterende SMTP server neemt de verantwoordelijkheid op zich zoals beschreven door RFC 5321 , maar acceptatie is nog steeds geen garantie voor plaatsing in de inbox, lezen of succes bij een latere downstream-hop. Als de verbinding vóór het definitieve antwoord verdwijnt, weet de klant mogelijk niet of acceptatie heeft plaatsgevonden; Houd rekening met mogelijke dubbele bezorging bij het onderzoeken van nieuwe pogingen.
Interpreteer mislukkingen in hun context
Een 4xx-antwoord is een voorbijgaande negatieve voltooiing; een 5xx-antwoord is een permanente negatieve voltooiing van het verzoek. Bewaar het volledige antwoord en eventuele verbeterde code, want een kale 550 identificeert zich niet DMARC als oorzaak. Het gedrag bij opnieuw proberen is ook afhankelijk van het wachtrijbeleid en het nut van het bericht. Door een ongeldige ontvanger voor onbepaalde tijd te herhalen, wordt deze niet hersteld.
Als AUTH niet wordt ondersteund of afgewezen, registreer dat dan als een afzonderlijk opdrachtresultaat. Het beschrijft op zichzelf niet de geldigheid van de ontvanger, de definitieve DATA-acceptatie of een downstream-domeinauthenticatieresultaat. Voor een echt onderzoek correleert u het transcript met de wachtrijlogboeken van de afzender, de tracering van de ontvanger en het toepasselijke beleid, en labelt u elke fase waarvoor bewijs ontbreekt. De voorbeelden in deze handleiding zijn hypothetisch; er werd voor hen geen login, socketuitwisseling of e-mailbezorging uitgevoerd.
Bouw een opdracht- en uitkomstgrootboek
- Verbinding: registreer de daadwerkelijke peer, tijd en begroeting.
- Mogelijkheden: bewaar EHLO resultaten afzonderlijk voor en na elke TLS onderhandeling.
- Envelop: bewaar MAIL FROM en elk RCPT TO-resultaat afzonderlijk.
- Inhoud: onderscheid de 354-uitnodiging van het definitieve antwoord na de afsluitende punt.
- Onzekerheid: als het definitieve antwoord ontbreekt, markeer dan de acceptatie als onbekend en inspecteer het bewijs van de ontvanger/wachtrij voordat u een mislukking claimt.
- Sluiting: registreer de definitieve berichtvolgorde en onopgeloste downstream-fasen, zonder inloggegevens.