begrip · mailprotocol SMTP

Wat is het mailprotocol SMTP en wat betekent het voor applicatiemail?

SMTP, of Simple Mail Transfer Protocol, is het gestandaardiseerde protocol dat mailsystemen gebruiken om uitgaande e-mail in te dienen, te relayen en over te dragen. Een applicatie geeft een afgewerkt bericht meestal aan een geauthenticeerde submission-service; mailservers gebruiken daarna SMTP-commando's en DNS-routering om het naar elke ontvanger te verplaatsen. SMTP-responses laten zien of een bepaalde hop een ontvanger heeft geaccepteerd of geweigerd, maar acceptatie is niet hetzelfde als inboxplaatsing. Applicaties hebben nog steeds duurzame wachtrijen, veilige retries, bericht-ID's, authenticatie en bounceverwerking nodig.

SMTP draagt mail over tussen verantwoordelijke systemen

SMTP is een store-and-forward-protocol voor mailoverdracht. Een client opent een sessie met een server, identificeert zich, geeft een envelope-afzender op, stelt een of meer envelope-ontvangers voor en verstuurt de berichtinhoud nadat de server heeft aangegeven die te willen ontvangen. De server kan sommige ontvangers accepteren en andere weigeren, dus de status hoort bij een ontvanger en een transactie, niet alleen bij het bericht als geheel. Zodra een server de verantwoordelijkheid accepteert, kan hij het bericht lokaal afleveren of doorsturen naar een ander systeem dat via DNS Mail Exchanger-records is geselecteerd. Door dit ontwerp per hop moet een applicatie de e-mailstatus niet terugbrengen tot één boolean 'verzonden'. De applicatie, de submission-service, de relay, de ontvangende server en het filtersysteem van de mailbox kennen elk een ander deel van de uitkomst. SMTP verplaatst het bericht tussen systemen, terwijl records op productniveau en provider-events die verplaatsing begrijpelijk maken voor gebruikers en beheerders.

Submission en relay zijn verschillende rollen in het protocol

RFC 6409 scheidt message submission van message relay. Submission is de eerste overdracht van een geautoriseerde gebruiker of applicatie aan een Message Submission Agent, normaal via poort 587. Relay is overdracht tussen Message Transfer Agents en gebruikt gewoonlijk poort 25. Submission-services kunnen authenticatie vereisen, berichtvelden valideren of aanvullen en afzenderbeleid afdwingen, omdat ze weten wie nieuwe mail introduceert. Openbare relayservers moeten samenwerken met andere domeinen en volgen andere vertrouwensregels. Applicatiecode moet daarom verbinden met het gedocumenteerde submission-endpoint van een provider of de HTTP-API gebruiken, en geen willekeurige verbindingen op poort 25 openen naar bestemmingsservers. Deze verdeling maakt ook de rol van credentials duidelijk: een SMTP-gebruikersnaam of -token geeft toestemming voor submission bij een bepaalde service; het geeft geen zeggenschap over het bestemmingsdomein. Houd submission-credentials server-side, beperk ze tot de verzendende workload als de provider dat ondersteunt, en roteer ze zonder ze in berichtinhoud of clientsoftware op te nemen.

De SMTP-envelope verschilt van de zichtbare berichtheaders

Een SMTP-transactie bevat een envelope met `MAIL FROM` en een of meer `RCPT TO`-commando's. De overgedragen inhoud volgt daarnaast het Internet Message Format uit RFC 5322, met velden zoals From, To, Date, Subject en Message-ID plus een body. MIME-standaarden breiden die inhoud uit voor HTML, alternatieve delen, bijlagen en niet-ASCII-data. De envelope-afzender is het adres dat voor transportfouten wordt gebruikt en kan verschillen van de zichtbare From-auteur. Envelope-ontvangers kunnen ook verschillen van de zichtbare To- en Cc-velden, zoals bij Bcc. Bouw deze structuren niet op door onbetrouwbare strings aan elkaar te plakken. Gebruik een onderhouden berichtbibliotheek, valideer adressen, blokkeer newline-injectie in headervelden en behoud een stabiele Message-ID. Bekijk bij troubleshooting beide lagen: een correct zichtbaar From-veld kan een niet-geautoriseerde envelope-identiteit niet herstellen, en een geldige envelope zorgt er niet voor dat misvormde MIME correct wordt weergegeven.

Lees de transactie als een state machine

Een eenvoudige Extended SMTP-sessie begint met een begroeting van de server, gevolgd door `EHLO`, zodat de server zijn extensies kan aankondigen. Voor submission kan de client over TLS en authenticatie onderhandelen. Een mailtransactie gebruikt daarna `MAIL FROM`, één `RCPT TO` per bestemming, `DATA`, het volledige bericht, afgesloten volgens de SMTP-framing, en `QUIT`. Zie het voorbeeld niet als reden om het wire-protocol zelf te implementeren; volwassen SMTP-bibliotheken gaan veiliger om met regeleinden, dot transparency, onderhandeling over capabilities, authenticatie en TLS-status. Instrumenteer de bibliotheek op het niveau van commandocategorie en responscode, zonder credentials of volledige berichtinhoud te loggen. Leg vast welke ontvanger in welke fase faalde en of de server na de berichtdata de verantwoordelijkheid had geaccepteerd. Die grens bepaalt of een retry gepast is, of een duplicaat mogelijk is en of de fout later via een delivery status notification wordt gemeld in plaats van via een directe respons.

Classificeer antwoordcodes voordat je besluit opnieuw te proberen

SMTP-antwoordklassen geven aan wat je moet doen. Een 2xx-respons betekent dat het commando succesvol is afgerond. Een 4xx-respons is een tijdelijke negatieve afronding, dus een afzender met een wachtrij kan het na een vertraging opnieuw proberen. Een 5xx-respons is een permanente negatieve afronding voor het geprobeerde commando en vraagt normaal om een correctie, suppressie of menselijk onderzoek in plaats van herhaalde retries. Enhanced status codes voegen een gestructureerde `X.Y.Z`-diagnose toe voor situaties rond adres, mailbox, systeem, routering, protocol, content of beveiliging en beleid. Bewaar zowel de numerieke code als de servertekst, want beide kunnen diagnostische waarde hebben, maar deel ruwe responses met ontvangergegevens niet breed. Pas bij tijdelijke fouten exponential backoff met jitter en een maximale levensduur in de wachtrij toe. Probeer nooit zo agressief opnieuw dat een tijdelijk probleem bij de bestemming verandert in misbruikend verkeer. Stop bij een permanente adresfout met automatische verzendingen naar die bestemming en werk de suppressiestatus bij. Herstel bij een beleids- of authenticatiefout eerst de identiteit, DNS, credentials of content voordat je het opnieuw probeert.

Gebruik versleutelde, geauthenticeerde submission

SMTP is begonnen als transportprotocol tussen netwerken met verschillende vertrouwensaannames, dus veilige submission hangt af van extensies en het deploymentbeleid. STARTTLS upgradet een SMTP-verbinding naar TLS, waarna de client de capabilities die vóór de handshake zijn geleerd moet vergeten en opnieuw `EHLO` moet sturen. RFC 8314 werkt de richtlijnen voor submission bij door toegang en submission in cleartext als verouderd te beschouwen en impliciete TLS voor submission te beschrijven. SMTP AUTH, gestandaardiseerd in RFC 4954, laat een submission-server een client authenticeren via aangekondigde mechanismen. Gebruik de actuele hostnaam, poort, TLS-modus en authenticatie-instructies van de provider in plaats van een combinatie te raden. Valideer het servercertificaat en val niet ongemerkt terug op cleartext als de workload beschermde submission vereist. Bewaar wachtwoorden of tokens in een secret manager, gebruik per omgeving aparte credentials en schakel verouderde authenticatiemechanismen uit. TLS beschermt één verbindingshop; het authenticeert de auteur van het bericht niet bij elke volgende ontvanger en vervangt de identiteitsalignment van SPF, DKIM en DMARC niet.

Analyseer een e-mailfout in je applicatie hop voor hop

Begin bij het duurzame record van uitgaande berichten in de applicatie: was het productevent geautoriseerd, en heeft slechts één job in de wachtrij het opgepakt? Bekijk daarna de submission: DNS-resolutie, TCP-verbinding, TLS-onderhandeling, certificaatvalidatie, authenticatie, autorisatie van de envelope-afzender, responses per ontvanger en de laatste DATA-respons. Als de submission-service het bericht heeft geaccepteerd, stop dan met het blind opnieuw afspelen van het request en volg het bericht-ID en de eventstream. Maak onderscheid tussen een status 'verwerkt door de provider' en acceptatie door de ontvangende server. Een latere bounce kan na de eerste acceptatie alsnog een permanente fout melden. Als de ontvangende server het bericht heeft geaccepteerd, onderzoek dan authenticatieresultaten, reputatie, ontvangersbeleid, content en de classificatie door de mailbox, in plaats van het een SMTP-transportfout te noemen. Controleer zowel de envelope- als de headeridentiteiten, en bewaar tijdstempels, responscodes, het aantal pogingen in de wachtrij en de identifiers van de provider. Gebruik voor tests ontvangers die je zelf beheert. Plak nooit SMTP-credentials uit productie of volledige klantberichten in tickets, prompts, terminalgeschiedenis of openbare diagnosetools.

Houd acceptatie, bezorging en inboxplaatsing uit elkaar

Protocolprecisie is belangrijk in productinterfaces. Acceptatie door de applicatie betekent dat het lokale systeem een request heeft vastgelegd. Acceptatie bij submission betekent dat de eerste mailservice de verantwoordelijkheid voor de verwerking heeft geaccepteerd. Bezorging bij de ontvangende server betekent dat de SMTP-server van de bestemming succes heeft teruggegeven voor de overdracht. Inboxplaatsing is een latere beslissing over beleid en classificatie binnen de ontvangende omgeving. Een bericht kan de ene status bereiken en bij de volgende falen of anders worden ingedeeld. SMTP levert direct bewijs over de huidige transactie en kan later delivery status notifications opleveren, maar laat niet zien in welke map het bericht bij de ontvanger uiteindelijk terechtkomt. Sla deze statussen apart op in plaats van elke 250-respons als bezorging in de inbox te labelen. Een provider-event met de SMTP-succesrespons van de bestemming kan een status 'afgeleverd bij de server' onderbouwen. Een bounce onderbouwt foutafhandeling of suppressie. Geen van beide onderbouwt een belofte over zichtbaarheid, lezen of engagement. Dit model houdt de status waarheidsgetrouw en voorkomt onveilige retries nadat de verantwoordelijkheid al is overgedragen.

Gebruik de gedocumenteerde API van SendHQ

Een applicatie kan SMTP spreken via een providerbibliotheek, of een HTTP-e-mail-API aanroepen waarvan de provider het internetmailtransport onder die interface afhandelt. SendHQ biedt een e-mail-API per workspace met controles voor geverifieerde domeinen, resources voor uitgaande en inkomende berichten, events, suppressies, inboxen en grenzen voor workspaceresources. De HTTP-API kan gestructureerde requests, identifiers en events naast directe SMTP-submission bieden. De API verandert het gedrag van de bestemmingsserver niet en stelt geen SMTP-acceptatie, inboxplaatsing of betrokkenheid van ontvangers vast.

Veelgestelde vragen

Waar staat SMTP voor?

SMTP staat voor Simple Mail Transfer Protocol. Het definieert hoe mailclients en -servers uitgaande berichten indienen en overdragen via commando's, antwoorden, envelopes, berichtdata en extensies voor functies zoals authenticatie en TLS.

Wordt SMTP gebruikt om e-mail uit een inbox te lezen?

Nee. SMTP is vooral bedoeld voor het indienen en overdragen van uitgaande mail. Toegang tot een inbox verloopt via andere interfaces, zoals IMAP, POP, een providerspecifieke mailbox-API of een e-mail-API voor applicaties die opgeslagen inkomende berichten beschikbaar stelt.

Wat is het verschil tussen poort 25, 587 en 465?

Poort 25 wordt gewoonlijk gebruikt voor relay tussen servers. Poort 587 is de standaardservice voor message submission en onderhandelt meestal over TLS. Poort 465 is geregistreerd voor submission via impliciete TLS. Volg het gedocumenteerde endpoint en de beveiligingsmodus van de provider in plaats van op de gok van poort te wisselen.

Bewijst een geslaagde SMTP-respons dat een e-mail in de inbox is beland?

Nee. Een geslaagd antwoord bewijst alleen dat de reagerende SMTP-server het betreffende commando of de verantwoordelijkheid voor het bericht heeft geaccepteerd. Het ontvangende systeem kan daarna nog beleid toepassen, een vertraagde fout genereren of geaccepteerde mail buiten de primaire inbox indelen.

Moet een applicatie elke 4xx-respons van SMTP opnieuw proberen?

Een 4xx-code geeft een tijdelijk negatief resultaat aan, maar retries moeten een duurzame wachtrij gebruiken, exponential backoff met jitter, een eindige levensduur en limieten op pogingen per ontvanger. Onderzoek herhaalde tijdelijke fouten in plaats van eindeloos opnieuw te proberen.

Is een HTTP-e-mail-API een vervanging voor SMTP?

In applicatiecode kan het SMTP vervangen, maar de provider gebruikt normaal gesproken nog steeds SMTP om met de mailsystemen van ontvangers te communiceren. Een API voegt boven de transportlaag gestructureerde authenticatie, payloads, afbakening van resources, identifiers en eventafhandeling toe.

Bronnen

Verder leren

Implementatiegids voor e-mail-API's voor productteamsOntwerp een veilige integratie met een e-mail-API met geverifieerde domeinen, verzending via een wachtrij, stabiele identifiers, gecontroleerde retries, bezorgevents, suppressie en isolatie van tenants.