begrip · smtp-poort

Welke SMTP-poort gebruikt een applicatie voor e-mail?

De meeste applicaties moeten het submission-endpoint en de poort gebruiken die door hun e-mailprovider worden gedocumenteerd. Poort 587 is de standaardpoort voor berichtsubmission en begint doorgaans in plaintext SMTP vóór een STARTTLS-upgrade. Poort 465 is berichtsubmission met impliciete TLS, zodat de TLS-handshake onmiddellijk begint. Poort 25 is voornamelijk voor SMTP-relay van server naar server, niet voor reguliere geauthenticeerde applicatiesubmission. Een werkende configuratie moet vier zaken samen laten overeenkomen: hostnaam, poort, TLS-modus en authenticatiemethode.

Een SMTP-poort bepaalt een protocolrol en een verbindingsmodus

Een poortnummer is niet zomaar een uitwisselbare deur naar dezelfde dienst. Het helpt bepalen welke SMTP-rol de server biedt en hoe de verbinding begint. Message submission is de eerste overdracht van een applicatie of user agent aan een submission-dienst. Relay is de overdracht van mail tussen mailservers. Standaarden scheiden die taken, omdat submission authenticatie, afzenderautorisatie en controles op berichtbeleid kan vereisen die niet op dezelfde manier gelden voor publieke mailrelay. De poort kan ook aangeven of de client met SMTP-commando's begint en later via STARTTLS upgradet, of meteen met een TLS-handshake start. Behandel de hostnaam, poort, TLS-modus en authenticatie-instructies van de provider als één configuratiegeheel. Een poort overnemen van een ongerelateerde provider, of na een fout alleen de poort wijzigen, kan een netwerkprobleem veranderen in een TLS- of authenticatiefout zonder de oorspronkelijke oorzaak op te lossen.

Poort 25 is vooral voor relay tussen mailservers

Poort 25 is de gebruikelijke SMTP-relaypoort wanneer de ene Message Transfer Agent mail overdraagt aan een andere. RFC 6409 houdt relay op poort 25 en verplaatst de submission van nieuwe berichten naar poort 587. Een applicatie moet er dus niet van uitgaan dat directe verbindingen met mailservers van ontvangers op poort 25 de normale manier zijn om productmail te versturen. Directe relay vereist wachtrijen, DNS-routering, bounceafhandeling, maatregelen tegen misbruik, reputatiebeheer en retrygedrag volgens de standaarden. Netwerken en hostingproviders kunnen uitgaand verkeer op poort 25 ook beperken. AWS documenteert bijvoorbeeld dat e-mailverkeer van Amazon EC2 op poort 25 standaard wordt afgeknepen. Poort 25 kan nog steeds een gedocumenteerde optie zijn bij een provider of binnen gecontroleerde infrastructuur, maar beschikbaarheid maakt het niet de voorkeurskeuze voor submission. Gebruik hem alleen als de verantwoordelijke dienst dat endpoint, die beveiligingsmodus en dat operationele model expliciet documenteert.

Poort 587 is de standaardpoort voor message submission

RFC 6409 reserveert poort 587 voor message submission en beschrijft een submission-dienst die ongeautoriseerde mail kan weigeren, authenticatie kan vereisen en beleid kan afdwingen voordat een nieuw bericht wordt geaccepteerd. Een gangbare sessie op poort 587 begint als SMTP, biedt na `EHLO` de STARTTLS-extensie aan, upgradet de verbinding naar TLS, herhaalt `EHLO`, authenticeert en dient daarna het bericht in. Het woord gangbaar is belangrijk: de exacte authenticatiemechanismen en eisen komen uit de actuele documentatie van de provider en de mogelijkheden van de server. Een veilige client hoort de verwachte TLS-upgrade te vereisen en het servercertificaat te valideren, in plaats van na een mislukte onderhandeling in cleartext door te gaan. Verwar een onversleutelde begroeting aan het begin van het protocol niet met een onbeschermde geauthenticeerde sessie; STARTTLS is ontworpen om die verbinding te upgraden voordat credentials en berichtdata worden verzonden. Poort 587 identificeert de submission-dienst, terwijl het daadwerkelijk afdwingen van TLS afhangt van correct clientbeleid.

Poort 465 gebruikt impliciete TLS voor submission

Poort 465 is geregistreerd voor message submission via impliciete TLS. Bij impliciete TLS voert de client de TLS-handshake uit zodra de TCP-verbinding opengaat en verstuurt hij SMTP-commando's alleen binnen het beschermde kanaal. Dat verschilt van poort 587 met STARTTLS, waarbij de client eerst een SMTP-begroeting ontvangt en daarna om de upgrade vraagt. RFC 8314 raadt impliciete TLS aan voor submission en beschrijft ook een overgangsfase waarin providers en clients zowel poort 465 met impliciete TLS als poort 587 met STARTTLS kunnen ondersteunen. De RFC merkt op dat correct geïmplementeerde clients en servers met beide modi in wezen gelijkwaardige beveiliging kunnen bieden als TLS verplicht is. De praktische regel is dus niet om één poort universeel juist te verklaren. Gebruik exact het endpoint en de modus die de provider ondersteunt. STARTTLS configureren tegen een listener met impliciete TLS, of impliciete TLS tegen een STARTTLS-listener, mislukt meestal al vóór de authenticatie.

Alternatieve poorten van providers zijn expliciete afspraken

Sommige providers bieden alternatieve poorten om netwerkbeperkingen te omzeilen, maar die nummers zijn geen universele SMTP-standaarden voor elke dienst. Amazon SES documenteert momenteel STARTTLS op de poorten 25, 587 en 2587, en TLS Wrapper, hun term voor impliciete TLS, op de poorten 465 en 2465. SES vereist versleutelde verbindingen en publiceert SMTP-endpoints per regio. Dit laat zien waarom je een poort uit de documentatie van de gekozen provider moet halen en niet uit een generieke lijst. Poort 2587 betekent niet overal STARTTLS, en poort 2465 wijst niet op een dienst met impliciete TLS op willekeurige hosts. Alternatieve poorten omzeilen ook geen afzenderverificatie, scope van credentials, quota of providerbeleid. Leg de bron-URL en de verificatiedatum vast bij de productieconfiguratie, zodat een operator een bewuste providerinstelling kan onderscheiden van een onverklaard magisch getal dat jaren geleden in een omgevingsvariabele is gekopieerd.

Configureer hostnaam, poort, TLS en authenticatie samen

Een robuuste SMTP-configuratie is een bundel: de hostnaam van de provider, poort, modus voor transportbeveiliging, beleid voor certificaatvalidatie, authenticatiemechanisme, gebruikersnaam, geheim, verbindingstimeout en verzendidentiteit. De hostnaam is belangrijk omdat het TLS-certificaat ertegen wordt gevalideerd en omdat providers verschillende regionale endpoints kunnen aanbieden. Poort en TLS-modus moeten overeenkomen. Authenticatie hoort pas plaats te vinden als het bedoelde beschermde kanaal bestaat, en secrets horen in een secretmanager, niet in broncode, browserbundels, logs of diagnostische uitvoer. Scheid credentials en configuratie per omgeving, zodat een lokale test niet per ongeluk via productie verstuurt. Stel eindige timeouts in voor verbindingen en commando's, maar laat een duurzame wachtrij in de applicatie de retries van berichten regelen. Een library-optie met de naam `secure` kan in de ene SDK impliciete TLS betekenen en in een andere alleen STARTTLS vereisen, dus controleer de definitie in de library en test het daadwerkelijk onderhandelde gedrag in plaats van op de optienaam te vertrouwen.

Test de verbinding laag voor laag zonder secrets bloot te geven

Begin met DNS-resolutie en TCP-bereikbaarheid vanuit hetzelfde runtimenetwerk als de applicatie. Een timeout vóór de verbinding wijst op routering, een firewall, het uitgaande beleid van de provider, een verkeerde hostnaam of een gesloten poort. Test daarna de verwachte TLS-modus. Bij impliciete TLS hoort een TLS-client een certificaat en vervolgens een SMTP-begroeting te ontvangen. Bij STARTTLS hoort een SMTP-bewuste client de begroeting te ontvangen, `EHLO` te sturen, STARTTLS aangeboden te zien, om de upgrade te vragen, het certificaat te valideren en na TLS opnieuw `EHLO` te sturen. RFC 3207 vereist dat client en server kennis die vóór de handshake is verkregen weggooien; daarom is de tweede `EHLO` belangrijk. Test pas daarna de authenticatie met een gecontroleerd account. Maak gebruikersnamen, tokens, ontvangeradressen, volledige servertranscripten en berichtinhoud onleesbaar voordat je logs deelt. Een connectiviteitstest heeft geen productieverzending of echt klantadres nodig.

Classificeer fouten op de fase die daadwerkelijk misging

Een geweigerde verbinding betekent dat de TCP-bestemming de verbinding actief heeft afgewezen; een timeout betekent dat er binnen de limiet geen bruikbare respons is gekomen. Een fout in de TLS-handshake wijst op een verkeerde modus, een certificaatprobleem, protocolincompatibiliteit, onderschepping of een verkeerd endpoint. Een authenticatiefout treedt later op en moet worden onderzocht als configuratieprobleem met credentials, mechanisme, account of autorisatie, niet worden opgelost door willekeurig van poort te wisselen. SMTP-antwoordcodes tijdens `MAIL FROM`, `RCPT TO` of `DATA` beschrijven nog latere beslissingen over beleid en berichten. Bewaar de fase, het tijdstip, het endpoint, het aantal pogingen, het numerieke antwoord en een respons die op privacy is gefilterd. Een 4xx-SMTP-antwoord is normaal gesproken tijdelijk en een 5xx-antwoord normaal gesproken permanent voor dat commando, maar retries moeten begrensd zijn en rekening houden met ontvangers. Als de provider de berichtdata heeft geaccepteerd, dien dan niet blind een duplicaat in omdat een later applicatierequest een timeout kreeg; reconcilieer met de provider-ID en de eventgeschiedenis.

Een werkende poort is geen bezorging of inboxplaatsing

Een geslaagde TCP-verbinding bewijst alleen dat een listener antwoordde. Een geslaagde TLS-handshake bewijst een beschermde verbinding met het geauthenticeerde endpoint als de certificaatvalidatie slaagt. Authenticatie bewijst dat de server de aangeboden clientidentiteit voor die sessie heeft geaccepteerd. Een SMTP-`250`-respons na de berichtdata betekent dat de antwoordende server volgens het protocol de verantwoordelijkheid heeft overgenomen, niet dat iemand het bericht heeft ontvangen of gelezen. Een latere relay kan nog steeds mislukken, en een ontvangend systeem kan mail accepteren en tegelijk buiten de primaire inbox indelen. Houd deze statussen gescheiden in applicatierecords en monitoring. Netwerkbeschikbaarheid, TLS-onderhandeling, authenticatie, acceptatie door de provider, acceptatie door de bestemmingsserver, bounces, klachten en betrokkenheid zijn verschillende waarnemingen. Deze scheiding voorkomt dat een poorttest ten onrechte als bezorgtest wordt gerapporteerd en dat een geaccepteerd bericht opnieuw wordt verstuurd alleen omdat inboxplaatsing niet te bewijzen is.

Kies bewust tussen SMTP-submission en een e-mail-API

Gebruik SMTP-submission wanneer een systeem al over een volwassen SMTP-client beschikt, wanneer een vereist platform SMTP als ondersteunde integratie aanbiedt of wanneer controls op protocolniveau specifiek nodig zijn. Een HTTPS-e-mail-API kan een betere applicatiegrens zijn wanneer gestructureerde requests, tokens met beperkte scope, idempotentie, batchresources en machineleesbare eventrecords bij de workload passen. De provider kan downstream nog steeds SMTP gebruiken om mailsystemen van ontvangers te bereiken, dus een API schaft mailtransport niet af. Deze verplaatst de verantwoordelijkheid voor poort, TLS, authenticatie en retries bij de overdracht aan de provider uit de SMTP-configuratie van de applicatie.

Veelgestelde vragen

Moet mijn applicatie SMTP-poort 587 of 465 gebruiken?

Gebruik de poort en TLS-modus die je provider documenteert. Poort 587 gebruikt normaal gesproken STARTTLS, poort 465 impliciete TLS. Beide kunnen submission beschermen als ze correct geïmplementeerd en verplicht zijn; de clientconfiguratie moet overeenkomen met de listener van de server.

Waarom is SMTP-poort 25 geblokkeerd of krijg ik een timeout?

Een hostingplatform, internetprovider, firewall of bestemmingsbeleid kan poort 25 beperken, omdat die voor relay tussen mailservers wordt gebruikt en vaak wordt misbruikt. Controleer het netwerkbeleid en gebruik het gedocumenteerde submission-endpoint van de provider, in plaats van een beperking te omzeilen met een willekeurige poort.

Kan ik van poort 587 naar 465 overstappen zonder iets anders te wijzigen?

Meestal niet. Poort 587 begint doorgaans met SMTP en schakelt via STARTTLS over op TLS, terwijl poort 465 direct met een TLS-handshake begint. Wijzig de poort en de TLS-modus van de client samen, volgens de documentatie van de provider en de library.

Is poort 587 standaard versleuteld?

De poort identificeert message submission, maar versleuteling hangt nog steeds af van de STARTTLS-onderhandeling en het clientbeleid. Configureer de client zo dat hij een geslaagde upgrade vereist, het certificaat valideert en weigert credentials of berichtdata te versturen als beschermde submission niet tot stand komt.

Wat betekent SMTP connection refused?

Het betekent dat de TCP-bestemming de verbinding vóór de SMTP-onderhandeling heeft geweigerd. Veelvoorkomende oorzaken zijn een verkeerde host of poort, een dienst die niet luistert, een weigering door een firewall of een provider-endpoint dat vanaf dat netwerk niet bereikbaar is.

Bewijst een geslaagde test van de SMTP-poort dat e-mail wordt afgeleverd?

Nee. Het bewijst alleen de fasen die de test daadwerkelijk heeft doorlopen, zoals TCP of TLS. Authenticatie, acceptatie van het bericht, acceptatie door de bestemmingsserver, bounceafhandeling, indeling in de mailbox en betrokkenheid van de ontvanger vereisen apart bewijs en moeten apart worden gerapporteerd.

Bronnen

Verder leren

Het SMTP-mailprotocol: hoe applicatiemail zich verplaatstLeer hoe SMTP-submission, relay, envelopes, responscodes, TLS, retries en berichtinhoud een e-mailworkflow in je applicatie vormgeven.Een SMTP-relayservice beoordelenBeoordeel SMTP-relayservices op beveiliging van submission, authenticatie, wachtrijen, retrygedrag, limieten, bezorgevents, suppressie, isolatie en geschiktheid voor migratie.Een e-mail-API implementeren: gids voor productteamsOntwerp een veilige e-mail-API-integratie met geverifieerde domeinen, verzending via een wachtrij, stabiele identifiers, gecontroleerde retries, bezorgevents, suppressie en tenantisolatie.Een deliverability-dienst voor e-mail beoordelenBeoordeel deliverability-diensten op scope, bewijs, authenticatie, feedbackloops, suppressies, privacy, overdraagbaarheid en operationele fit.