Porte, kryptering og login

Modul 1: Sådan virker e-mail · Læsetid: 10 minutter

Læringsmål: Efter denne lektion kan du for hver mailport sige hvad den bruges til, forklare forskellen mellem STARTTLS og direkte TLS, og forklare en certifikatadvarsel eller et afvist login.

Nøglebegreber: port 25, 587, 465, 993, 995, 143, 110, STARTTLS, direkte TLS (implicit TLS, RFC 8314), certifikat, servernavn, SMTP-autentificering (SMTP AUTH), open relay, blokering af port 25, app-adgangskode, OAuth

En port er en dør

En server har én IP-adresse, men mange døre. Hver tjeneste lytter på sin egen port, et nummer. Din webbrowser banker på port 443, dit mailprogram banker på port 993 for at læse mail og på 587 eller 465 for at sende. Vælger du den forkerte dør, svarer der enten ingen, eller nogen der taler et andet sprog. Det giver uklare fejlmeddelelser som "kan ikke oprette forbindelse" eller "serveren svarer ikke".

Mailportene i oversigt:

Hvorfor ikke bare bruge port 25 til afsendelse?

Tidligere satte man port 25 op i sit mailprogram. Det er fortid, af to grunde.

For det første: på port 25 tager en mailserver imod mail fra alle, til sine egne domæner. Der logges ikke ind. En server der på port 25 også videresender mail fra alle til andre domæner, kaldes en open relay, og den bliver misbrugt af spammere inden for få timer. Derfor er afsendelse af din egen mail til hele verden blevet en separat tjeneste: submission på port 587 (og 465), hvor du altid logger ind først.

For det andet: mange internetudbydere blokerer udgående trafik til port 25 fra privatforbindelser. En inficeret computer i en stue kan så ikke sende spam direkte til mailservere. Konsekvensen for dig: forsøger du at sende via port 25 fra dit mailprogram, kan det ske at det ikke virker hjemmefra, men gør det på kontoret, eller omvendt.

Husk: mailprogrammer sender via 587 eller 465, med login. Port 25 er til servere imellem.

STARTTLS eller direkte TLS?

Der er to måder at kryptere en mailforbindelse på.

Direkte TLS (implicit TLS): forbindelsen er krypteret fra den første byte, ligesom en hjemmeside med https. Det sker på 465, 993 og 995.

STARTTLS: forbindelsen starter ukrypteret. Serveren siger "jeg kan kryptere", klienten svarer STARTTLS, og fra det øjeblik er alt krypteret. Det sker på 587 (og på 25, 143 og 110).

For sikkerheden gør det ikke den store forskel, så længe dit program gør STARTTLS obligatorisk. Risikoen ved STARTTLS ligger i starten: nogen der sidder mellem dig og serveren, kan fjerne tilbuddet "jeg kan kryptere". Et program der så stille fortsætter ukrypteret, sender din adgangskode læsbart over linjen. Derfor anbefaler RFC 8314 (2018) direkte TLS (465, 993, 995) frem for STARTTLS til mailprogrammer. I praksis er 587 med STARTTLS og 465 med SSL/TLS begge gode, hvis du sætter krypteringen i dit program til "obligatorisk" og ikke til "hvis tilgængelig".

En hyppig fejl er den forkerte kombination: port 587 med "SSL/TLS", eller port 465 med "STARTTLS". Programmet forventer så noget andet end det serveren gør, og forbindelsen hænger eller mislykkes. Husk parrene: 587 + STARTTLS og 465 + SSL/TLS. Programmer kalder nogle gange direkte TLS for "SSL", "SSL/TLS" eller "TLS"; STARTTLS kaldes somme tider også "TLS". Kig derfor på portnummeret.

Certifikatet og servernavnet

Ved hver krypteret forbindelse viser serveren et certifikat, som beviser at den er den, den siger den er. Dit mailprogram kontrollerer to ting: er certifikatet udstedt af en betroet part og stadig gyldigt, og står det navn du har indtastet som server i det?

Det sidste går oftest galt. Indtaster du mail.example.com, men der kun står server12.hosting.example i certifikatet, får du en meddelelse som "Kan ikke verificere serverens identitet" eller "Målets principal-navn er forkert". Selve forbindelsen er godt nok krypteret, men dit program kan ikke være sikker på at det taler med den rigtige server.

Klik ikke sådan en meddelelse væk. Løsningen er at bruge et servernavn der faktisk står i certifikatet (se lektion 2.1). Ved en delt server er det ofte selve servernavnet, som din udbyder oplyser. En anden kendt årsag: en virusscanner der "scanner" krypteret mail og i den forbindelse sætter sit eget certifikat ind imellem. I meddelelsen vil scannerens navn så stå under "udstedt af".

Login ved afsendelse

På 587 og 465 skal du logge ind, før serveren vil sende din mail videre. Det kaldes SMTP-autentificering (SMTP AUTH). I dit program hedder indstillingen "udgående server kræver godkendelse", "login påkrævet" eller "autentificering: normal adgangskode". Som regel bruger du samme brugernavn og adgangskode som til IMAP.

Er autentificering slået fra, eller står brugernavnet til den udgående server tomt, kan du godt læse mail, men ikke sende. Serveren svarer så med noget i stil med 530 5.7.0 Authentication required eller 554 5.7.1 Relay access denied. Det er den hyppigste årsag til "modtagelse virker, afsendelse ikke".

En anden slags afvisning: 535 5.7.8 Authentication failed. Så passer kombinationen af brugernavn og adgangskode ikke. Bemærk: efter en række mislykkede forsøg blokerer mange servere det IP-adresse forsøgene kommer fra, for at undgå gætning af adgangskoder. En gammel telefon med en forældet adgangskode kan på den måde få hele dit kontor blokeret.

App-adgangskoder og OAuth

Hos store udbydere som Google og Microsoft virker login med kun din almindelige adgangskode i et separat mailprogram i stadig færre tilfælde. De bruger OAuth: dit program sender dig til en login-side hos udbyderen, du logger ind der (eventuelt med totrinsgodkendelse), og programmet får en nøgle i stedet for din adgangskode. Programmer der ikke kan dette, får nogle gange en app-adgangskode: en separat, lang adgangskode der kun gælder for netop det program, og som du kan tilbagekalde for sig.

Ved en almindelig mailboks hos et hostingfirma logger du som regel ind med selve mailboksens adgangskode. Det gør en stærk og unik adgangskode ekstra vigtig (lektion 3.4).

I praksis: indstillingerne for en mailboks

For en mailboks hos WebOké er indstillingerne: IMAP 993 med SSL/TLS, POP3 995 med SSL/TLS, afsendelse 587 med STARTTLS eller 465 med SSL/TLS, godkendelse slået til med din fulde e-mailadresse og mailboksens adgangskode. Hos andre udbydere fungerer det på lignende vis: portene er næsten de samme overalt, det er kun servernavnet der er forskelligt. Hvilket servernavn du skal vælge, kan du se i lektion 2.1.

Opsummering

• Mailprogrammer sender via 587 (STARTTLS) eller 465 (direkte TLS), altid med login. Port 25 er til servere imellem og bliver ofte blokeret hjemmefra.
• Læsning sker via 993 (IMAP) eller 995 (POP3), begge med direkte TLS.
• Kombiner rigtigt: 587 + STARTTLS, 465 + SSL/TLS. Sæt kryptering til obligatorisk.
• En certifikatadvarsel betyder som regel: det servernavn du indtastede, står ikke i certifikatet. At klikke den væk er ingen løsning.
• "Læsning virker, afsendelse ikke" skyldes næsten altid: godkendelse for den udgående server er slået fra eller står tom.

Quiz

Opgave

Opgave Z1.4: Porte og certifikat for en mailserver. Indtast det indgående og udgående servernavn du bruger til din egen mailboks (har du ikke en egen mailboks, så brug imap.gmail.com og smtp.gmail.com). Vælg for port 993 (indgående) og portene 465 og 587 (udgående) det du forventer: direkte TLS, STARTTLS eller ikke tilgængelig, og angiv om du tror navnet står i certifikatet. Programmet opretter selv forbindelse til de tre porte og sætter resultatet op mod dine svar.

Læs mere

Trinene i disse artikler gælder for WebOkés kontrolpaneler; hos andre udbydere fungerer det på lignende vis.

• DirectAdmin vejledning 8.1: Alle indstillinger samlet: servere, porte og sikkerhed
• DirectAdmin vejledning 8.8: Afsendelse eller modtagelse virker ikke: sådan løser du det
• Fejlmeddelelse om certifikat ved hentning af mail
• Jeg kan ikke sende e-mails (modtagelse fungerer fint)
• RFC 8314 (direkte TLS til mailprogrammer), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)