Porter, kryptering og innlogging

Modul 1: Hvordan e-post fungerer · Lesetid: 10 minutter

Læringsmål: Etter denne leksjonen kan du si hva hver mailport brukes til, forklare forskjellen mellom STARTTLS og direkte TLS, og forklare en sertifikatmelding eller en avvist innlogging.

Nøkkelbegreper: port 25, 587, 465, 993, 995, 143, 110, STARTTLS, direkte TLS (implicit TLS, RFC 8314), sertifikat, servernavn, SMTP-autentisering (SMTP AUTH), open relay, blokkering av port 25, app-passord, OAuth

En port er en dør

En server har én IP-adresse, men mange dører. Hver tjeneste lytter på sin egen port, et nummer. Nettleseren din banker på port 443, mailprogrammet ditt på port 993 for å lese mail og på 587 eller 465 for å sende. Velger du feil dør, svarer ingen, eller noen som snakker et annet språk. Det gir vage feilmeldinger som «kan ikke opprette tilkobling» eller «serveren svarer ikke».

Mailportene i oversikt:

Hvorfor ikke bare bruke port 25 for sending?

Før satte du opp port 25 i mailprogrammet ditt. Det er fortid, av to grunner.

For det første: på port 25 tar en mailserver imot mail fra alle, for sine egne domener. Det logges ikke inn. En server som på port 25 også videresender mail fra alle til andre domener, kalles en open relay, og den blir misbrukt av spammere i løpet av noen timer. Derfor er det å sende din egen mail ut i verden blitt en egen tjeneste: submission på port 587 (og 465), der du alltid logger inn først.

For det andre: mange internettleverandører blokkerer utgående trafikk til port 25 fra private tilkoblinger. En infisert datamaskin i en stue kan da ikke sende spam direkte til mailservere. Konsekvensen for deg: prøver du å sende via port 25 fra mailprogrammet ditt, kan det hende det ikke fungerer hjemme, men fungerer på kontoret, eller omvendt.

Husk: mailprogrammer sender via 587 eller 465, med innlogging. Port 25 er for servere seg imellom.

STARTTLS eller direkte TLS?

Det finnes to måter å kryptere en mailtilkobling på.

Direkte TLS (implicit TLS): tilkoblingen er kryptert fra første byte, akkurat som et nettsted med https. Det skjer på 465, 993 og 995.

STARTTLS: tilkoblingen begynner ukryptert. Serveren sier «jeg kan kryptere», klienten svarer STARTTLS, og fra det øyeblikket er alt kryptert. Det skjer på 587 (og på 25, 143 og 110).

For sikkerheten spiller det liten rolle hvilken du bruker, så lenge programmet ditt gjør STARTTLS obligatorisk. Risikoen med STARTTLS ligger i starten: noen som befinner seg mellom deg og serveren kan fjerne tilbudet «jeg kan kryptere». Et program som da stille fortsetter ukryptert, sender passordet ditt lesbart over linjen. Derfor anbefaler RFC 8314 (2018) at mailprogrammer bruker direkte TLS (465, 993, 995) fremfor STARTTLS. I praksis er både 587 med STARTTLS og 465 med SSL/TLS gode valg, forutsatt at du setter kryptering i programmet til «obligatorisk» og ikke til «hvis tilgjengelig».

En vanlig feil er feil kombinasjon: port 587 med «SSL/TLS», eller port 465 med «STARTTLS». Programmet forventer da noe annet enn det serveren gjør, og tilkoblingen henger seg opp eller mislykkes. Husk parene: 587 + STARTTLS og 465 + SSL/TLS. Programmer kaller direkte TLS noen ganger «SSL», «SSL/TLS» eller «TLS»; STARTTLS kalles noen ganger også «TLS». Se derfor på porten.

Sertifikatet og servernavnet

Ved hver kryptert tilkobling viser serveren et sertifikat, som beviser at den er den den sier den er. Mailprogrammet ditt kontrollerer to ting: er sertifikatet utstedt av en betrodd part og fortsatt gyldig, og står navnet du har fylt inn som server i det?

Det siste er det som oftest går galt. Fyller du inn mail.example.com, men sertifikatet inneholder bare server12.hosting.example, får du en melding som «Kan ikke bekrefte identiteten til serveren» eller «Prinsipalnavnet til målet er feil». Selve tilkoblingen er da kryptert, men programmet ditt kan ikke være sikkert på at det snakker med den ekte serveren.

Ikke klikk bort en slik melding. Løsningen er et servernavn som faktisk står i sertifikatet (se leksjon 2.1). På en delt server er det ofte navnet til selve serveren, som leverandøren din oppgir. En annen kjent årsak: en virusskanner som «skanner» kryptert mail og setter inn sitt eget sertifikat i prosessen. I meldingen står da skannerens navn under «utstedt av».

Innlogging ved sending

På 587 og 465 må du logge inn før serveren vil sende mailen din videre. Det kalles SMTP-autentisering (SMTP AUTH). I programmet ditt heter valget «utgående server krever autentisering», «pålogging kreves» eller «autentisering: vanlig passord». Som regel bruker du samme brukernavn og passord som for IMAP.

Er autentisering avslått, eller har brukernavnet for den utgående serveren blitt stående tomt, kan du lese mail, men ikke sende. Serveren svarer da med noe som 530 5.7.0 Authentication required eller 554 5.7.1 Relay access denied. Det er den vanligste årsaken til «mottak fungerer, sending ikke».

En annen type avvisning: 535 5.7.8 Authentication failed. Da stemmer ikke kombinasjonen av brukernavn og passord. Vær oppmerksom: etter en del mislykkede forsøk blokkerer mange servere IP-adressen forsøkene kommer fra, for å hindre passordgjetting. En gammel telefon med et gammelt passord kan dermed få hele kontoret blokkert.

App-passord og OAuth

Hos store leverandører som Google og Microsoft fungerer innlogging med bare det vanlige passordet ditt i et frittstående mailprogram stadig sjeldnere. De bruker OAuth: programmet sender deg til en innloggingsside hos leverandøren, du logger inn der (eventuelt med topptrinnsverifisering), og programmet får en nøkkel i stedet for passordet ditt. Programmer som ikke støtter dette, får noen ganger et app-passord: et eget, langt passord som bare gjelder for det ene programmet, og som du kan trekke tilbake separat.

Med en vanlig mailboks hos et hostingselskap logger du som regel inn med passordet til selve mailboksen. Det gjør et sterkt og unikt passord ekstra viktig (leksjon 3.4).

I praksis: innstillingene for en mailboks

For en mailboks hos WebOké er innstillingene: IMAP 993 med SSL/TLS, POP3 995 med SSL/TLS, sending 587 med STARTTLS eller 465 med SSL/TLS, autentisering på med din fullstendige e-postadresse og passordet til mailboksen. Hos andre leverandører fungerer det på samme måte: portene er nesten overalt de samme, bare servernavnet er forskjellig. Hvilket servernavn du skal velge, finner du i leksjon 2.1.

Oppsummering

• Mailprogrammer sender via 587 (STARTTLS) eller 465 (direkte TLS), alltid med innlogging. Port 25 er for servere seg imellom og blir ofte blokkert hjemme.
• Lesing skjer via 993 (IMAP) eller 995 (POP3), begge med direkte TLS.
• Kombiner riktig: 587 + STARTTLS, 465 + SSL/TLS. Sett kryptering til obligatorisk.
• En sertifikatmelding betyr som regel: servernavnet du fylte inn, står ikke i sertifikatet. Å klikke bort meldingen er ingen løsning.
• «Lesing fungerer, sending ikke» er nesten alltid: autentisering for den utgående serveren er avslått eller tom.

Quiz

Oppgave

Oppgave Z1.4: Porter og sertifikat for en mailserver. Fyll inn servernavnet for innkommende og utgående mail som du bruker for din egen mailboks (har du ingen egen mailboks, bruk imap.gmail.com og smtp.gmail.com). Velg for port 993 (innkommende) og portene 465 og 587 (utgående) det du forventer: direkte TLS, STARTTLS eller ikke tilgjengelig, og fyll inn om du tror navnet står i sertifikatet. Programmet kobler selv til de tre portene og setter resultatet ved siden av svarene dine.

Les mer

Trinnene i disse artiklene gjelder for panelene til WebOké; hos andre leverandører fungerer det på samme måte.

• DirectAdmin-veiledning 8.1: Alle innstillinger på én plass: servere, porter og sikkerhet
• DirectAdmin-veiledning 8.8: Sende eller motta e-post fungerer ikke: slik løser du det
• Feilmelding om sertifikat ved henting av e-post
• Jeg kan ikke sende e-post (mottak fungerer)
• RFC 8314 (direkte TLS for mailprogrammer), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)