Welke SMTP-poort moet ik gebruiken?

Vier poorten komen telkens naar voren wanneer een applicatie mail moet versturen: 25, 465, 587 en 2525. Twee daarvan zijn submission-standaarden, 587 en 465, en het meest herhaalde advies over 465 is verouderd sinds 2018. Poort 25 is helemaal niet bedoeld voor submission, en 2525 is een conventie zonder standaard.

Het korte antwoord: gebruik 587 met STARTTLS. Gebruik 465 als je client liever direct een TLS-verbinding opent. Gebruik 2525 als iets op je netwerk 587 blokkeert. Gebruik 25 niet om mail vanuit een applicatie te versturen.

Wat doet elke poort precies?

De poorten verschillen op twee assen: of ze bedoeld zijn voor submission of relay, en wanneer in de verbinding de versleuteling begint.

• 25 is de relay-poort. Zo draagt de ene mailserver een bericht over aan de andere. Hij dateert van voor geauthenticeerde submission en veronderstelt geen van beide.
• 587 is de submission-poort, daarvoor gedefinieerd door RFC 6409. De verbinding begint in plaintext en wordt opgewaardeerd naar TLS met het STARTTLS-commando voordat credentials worden verstuurd.
• 465 is de impliciete-TLS-submission-poort. De TLS-handshake vindt eerst plaats en het volledige SMTP-dialoog loopt erbinnen, dus er wordt nooit iets onversleuteld verstuurd. Libraries noemen dit meestal "SSL/TLS" of "SMTPS".
• 2525 heeft helemaal geen standaard die hem aan SMTP toewijst. Providers bieden hem aan als alternatief voor 587 voor netwerken die de standaardpoort blokkeren.

Het verschil tussen 465 en 587 gaat over wanneer TLS begint, niet over hoe sterk het is. Op 465 is de verbinding versleuteld vanaf de eerste byte. Op 587 wordt de verbinding een round trip later versleuteld, en een correct geconfigureerde server weigert AUTH tot dat is gebeurd.

Is poort 465 deprecated?

Nee, en dit is het allermeest voorkomende verouderde SMTP-advies.

De historie is oprecht verwarrend. Poort 465 werd in het begin toegewezen voor SMTP over TLS, daarna ingetrokken ten gunste van de STARTTLS-aanpak op 587, en daar komt het "465 is deprecated"-advies vandaan. Dat advies was een tijd lang correct. Vervolgens adviseerde RFC 8314, gepubliceerd in januari 2018, impliciete TLS voor mailsubmission en herstelde 465 als de poort daarvoor, onder de servicenaam submissions.

Een pagina die je vertelt dat 465 verouderd is, beschrijft dus de situatie van vóór 2018. Zowel 465 als 587 zijn actueel. Kies de poort die je client het schoonst ondersteunt, en geef de voorkeur aan 465 als je liever niet afhankelijk bent van een plaintext-naar-TLS-upgrade.

Waarom is poort 25 geblokkeerd, en hoe controleer ik dat?

Uitgaande poort 25 wordt geblokkeerd door veel consumenten-ISP's en door cloud- en hostingproviders, omdat een ongeauthenticeerde relay-poort op een gecompromitteerde machine de manier is waarop bulkspam wordt verstuurd. Of de blokkade kan worden opgeheven hangt af van wie hem heeft ingesteld. Een consumenten-ISP heft hem over het algemeen niet op voor een thuisaansluiting, terwijl cloudproviders variëren: sommige accepteren een opheffingsverzoek, en minstens één biedt helemaal geen uitzondering. Controleer het beleid dat je eigen provider publiceert in plaats van het een of het ander aan te nemen.

Je kunt een blokkade bevestigen door een verbinding te openen naar een bekende mailserver op poort 25 en te kijken of je een 220-begroeting of een timeout krijgt. Een handmatige sessie is de duidelijkste manier om het te zien, en een SMTP-verbinding controleren met een telnetsessie loopt er een door.

Als poort 25 geblokkeerd is, is dat niet het probleem dat je moet oplossen. Een applicatie hoort sowieso op 587 of 465 te submitten.

Wat is het verschil tussen submission en relaying?

Submission is een mailclient of applicatie die een nieuw bericht aanbiedt aan een server waarmee hij zich heeft geauthenticeerd. Relaying is een server die een bestaand bericht doorstuurt richting zijn bestemming.

Het verschil bepaalt welke poort en welke regels van toepassing zijn. Submission vereist authenticatie, laat de server het bericht onderweg corrigeren en ondertekenen, en vindt plaats op 587 of 465. Relaying gebeurt op 25, tussen servers, en dat is wat de spam- en reputatiesystemen van de ontvangende kant beoordelen.

Een applicatie die zelf mail verstuurt doet altijd submission. Als je iets configureert en naar poort 25 grijpt, beschrijft de configuratie de verkeerde helft van het systeem.

Welke poorten accepteert Bird?

Drie, en poort 25 zit er bewust niet bij:

Op 587 en 2525 wordt AUTH geweigerd totdat STARTTLS is uitgevoerd, dus credentials gaan op geen van de drie onversleuteld over de lijn. Poort 25 wordt niet aangeboden voor submission.

De host hangt af van de regio van je key, het prefix in de key zelf: een bk_eu1_...-key verstuurt via eu1.smtp.bird.com, een bk_us1_...-key via us1.smtp.bird.com. Authenticatie gebruikt je normale API-key in plaats van een apart SMTP-credential: de gebruikersnaam is de letterlijke string bird en het wachtwoord is de key.

Mail verstuurd over SMTP wordt exact hetzelfde behandeld als mail verzonden via de e-mail-API, met dezelfde domeinverificatie, DKIM-ondertekening, suppressieafhandeling, tracking en events. E-mail versturen over SMTP bevat de volledige verbindingsreferentie, twee geannoteerde sessies, één op 465 en één gedeeld door 587 en 2525, en de per-key-standaarden die een verzending vormgeven.

Hoe vind ik welke poort mijn client gebruikt?

Waar je moet kijken hangt af van de software, en het patroon is consistent:

• Applicatieframeworks plaatsen het in de mailconfiguratie, meestal naast de host, als een port- of MAIL_PORT-instelling.
• Contentmanagementsystemen tonen het op de instellingenpagina van een SMTP-plugin naast een versleutelingsdropdown. Die dropdown is de instelling die mensen fout instellen: "SSL/TLS" betekent 465 en "STARTTLS" betekent 587 of 2525, en een mismatch tussen de twee levert een verbinding op die hangt of wordt geweigerd in plaats van een bruikbare foutmelding.
• Apparaten zoals printers en scanners hebben het onder een notificatie- of scan-naar-e-mailscherm.

Als mail faalt en je vermoedt de poort, test dan de verbinding direct voordat je applicatiecode aanpast. Een handmatige sessie vertelt je of de poort bereikbaar is, of TLS wordt onderhandeld en of authenticatie wordt geaccepteerd, waarmee je een netwerkblokkade van een credentialprobleem onderscheidt.