Portar, kryptering och inloggning

Modul 1: Hur e-post fungerar · Lästid: 10 minuter

Lärandemål: Efter den här lektionen kan du säga vad varje mailport används till, förklara skillnaden mellan STARTTLS och direkt TLS, och förklara ett certifikatmeddelande eller en nekad inloggning.

Nyckelbegrepp: port 25, 587, 465, 993, 995, 143, 110, STARTTLS, direkt TLS (implicit TLS, RFC 8314), certifikat, servernamn, SMTP-autentisering (SMTP AUTH), open relay, blockering av port 25, app-lösenord, OAuth

En port är en dörr

En server har en IP-adress, men många dörrar. Varje tjänst lyssnar på sin egen port, ett nummer. Din webbläsare knackar på port 443, ditt e-postprogram på port 993 för att läsa mejl och på 587 eller 465 för att skicka. Väljer du fel dörr svarar ingen, eller så svarar någon som talar ett annat språk. Det ger otydliga felmeddelanden som "kan inte ansluta" eller "servern svarar inte".

Mailportarna i en översikt:

Varför inte bara port 25 för att skicka?

Förr ställde man in port 25 i sitt e-postprogram. Det är förbi, av två anledningar.

För det första: på port 25 tar en mailserver emot mejl från alla, för sina egna domäner. Det sker ingen inloggning. En server som på port 25 även vidarebefordrar mejl från vem som helst till andra domäner kallas en open relay, och den missbrukas av spammare inom några timmar. Därför har det blivit en egen tjänst att skicka sin egen mejl till hela världen: submission på port 587 (och 465), där du alltid loggar in först.

För det andra: många internetleverantörer blockerar utgående trafik till port 25 från hemanslutningar. En smittad dator i ett vardagsrum kan då inte skicka skräppost direkt till mailservrar. Konsekvensen för dig: försöker du skicka via port 25 från ditt e-postprogram kan det fungera hemma men inte på kontoret, eller tvärtom.

Kom ihåg: e-postprogram skickar via 587 eller 465, med inloggning. Port 25 är för servrar sinsemellan.

STARTTLS eller direkt TLS?

Det finns två sätt att kryptera en mailanslutning.

Direkt TLS (implicit TLS): anslutningen är krypterad från första byten, precis som en webbplats med https. Det sker på 465, 993 och 995.

STARTTLS: anslutningen börjar okrypterad. Servern säger "jag kan kryptera", klienten svarar STARTTLS, och från den punkten är allt krypterat. Det sker på 587 (och på 25, 143 och 110).

För säkerheten spelar det liten roll, så länge ditt program kräver STARTTLS obligatoriskt. Risken med STARTTLS finns i början: någon som sitter mellan dig och servern kan ta bort erbjudandet "jag kan kryptera". Ett program som då i tysthet fortsätter okrypterat skickar ditt lösenord läsbart över linjen. Därför rekommenderar RFC 8314 (2018) direkt TLS (465, 993, 995) framför STARTTLS för e-postprogram. I praktiken fungerar både 587 med STARTTLS och 465 med SSL/TLS bra, om du ställer in kryptering i ditt program på "obligatoriskt" och inte på "om möjligt".

Ett vanligt misstag är fel kombination: port 587 med "SSL/TLS", eller port 465 med "STARTTLS". Programmet förväntar sig då något annat än vad servern gör, och anslutningen hänger sig eller misslyckas. Kom ihåg paren: 587 + STARTTLS och 465 + SSL/TLS. Program kallar ibland direkt TLS för "SSL", "SSL/TLS" eller "TLS"; STARTTLS kallas ibland också "TLS". Titta därför på porten.

Certifikatet och servernamnet

Vid varje krypterad anslutning visar servern ett certifikat som bevisar att den är den den säger sig vara. Ditt e-postprogram kontrollerar två saker: är certifikatet utfärdat av en betrodd part och fortfarande giltigt, och finns namnet du har angett som server i det?

Det sistnämnda går oftast fel. Anger du mail.example.com men certifikatet innehåller bara server12.hosting.example, får du ett meddelande som "Kan inte verifiera serverns identitet" eller "Målets principnamn är felaktigt". Själva anslutningen är då visserligen krypterad, men ditt program kan inte vara säkert på att det pratar med den riktiga servern.

Klicka inte bort ett sådant meddelande. Lösningen är ett servernamn som faktiskt finns i certifikatet (se lektion 2.1). På en delad server är det ofta servernamnet från din leverantör. En annan vanlig orsak: ett antivirusprogram som "skannar" krypterad mejl och sätter in sitt eget certifikat i mitten. I meddelandet står då skannerns namn vid "utfärdat av".

Inloggning vid utskick

På 587 och 465 måste du logga in innan servern skickar din mejl vidare. Det kallas SMTP-autentisering (SMTP AUTH). I ditt program heter alternativet "utgående server kräver autentisering", "inloggning krävs" eller "autentisering: vanligt lösenord". Oftast använder du samma användarnamn och lösenord som för IMAP.

Är autentisering avstängd, eller har användarnamnet för den utgående servern lämnats tomt, kan du läsa mejl men inte skicka. Servern svarar då med något som 530 5.7.0 Authentication required eller 554 5.7.1 Relay access denied. Det är den vanligaste orsaken till "ta emot fungerar, skicka inte".

En andra typ av nekande: 535 5.7.8 Authentication failed. Då stämmer inte kombinationen av användarnamn och lösenord. Observera: efter ett antal misslyckade försök blockerar många servrar IP-adressen som försöken kommer från, för att skydda mot lösenordsgissning. En gammal telefon med ett gammalt lösenord kan på så sätt blockera hela ditt kontor.

App-lösenord och OAuth

Hos stora leverantörer som Google och Microsoft fungerar det allt mer sällan att logga in med bara ditt vanliga lösenord i ett fristående e-postprogram. De använder OAuth: ditt program skickar dig till leverantörens inloggningssida, du loggar in där (eventuellt med tvåstegsverifiering), och programmet får en nyckel i stället för ditt lösenord. Program som inte klarar det får ibland ett app-lösenord: ett separat, långt lösenord som bara gäller för just det programmet och som du kan återkalla separat.

Vid en vanlig brevlåda hos ett webbhotell loggar du oftast in med brevlådans eget lösenord. Det gör ett starkt och unikt lösenord extra viktigt (lektion 3.4).

I praktiken: inställningarna för en brevlåda

Vid en brevlåda hos WebOké är inställningarna: IMAP 993 med SSL/TLS, POP3 995 med SSL/TLS, skicka 587 med STARTTLS eller 465 med SSL/TLS, autentisering på med din fullständiga e-postadress och brevlådans lösenord. Hos andra leverantörer fungerar det på liknande sätt: portarna är nästan överallt desamma, bara servernamnet skiljer sig. Vilket servernamn du ska välja ser du i lektion 2.1.

Sammanfattning

• E-postprogram skickar via 587 (STARTTLS) eller 465 (direkt TLS), alltid med inloggning. Port 25 är för servrar sinsemellan och blockeras ofta hemma.
• Att läsa sker via 993 (IMAP) eller 995 (POP3), båda med direkt TLS.
• Kombinera rätt: 587 + STARTTLS, 465 + SSL/TLS. Ställ in kryptering på obligatoriskt.
• Ett certifikatmeddelande betyder oftast: servernamnet du angav finns inte i certifikatet. Att klicka bort det är ingen lösning.
• "Läsa fungerar, skicka inte" är nästan alltid: autentisering för den utgående servern är avstängd eller tom.

Quiz

Uppgift

Uppgift Z1.4: Portar och certifikat för en mailserver. Ange det inkommande och det utgående servernamnet som du använder för din egen brevlåda (har du ingen egen brevlåda, använd då imap.gmail.com och smtp.gmail.com). Välj för port 993 (inkommande) och portarna 465 och 587 (utgående) vad du förväntar dig: direkt TLS, STARTTLS eller inte nåbar, och ange om du tror att namnet finns i certifikatet. Programmet ansluter själv till de tre portarna och ställer resultatet bredvid dina svar.

Läs mer

Stegen i dessa artiklar gäller för WebOkés kontrollpaneler; hos andra leverantörer fungerar det på liknande sätt.

• DirectAdmin-guide 8.1: Alla inställningar på ett ställe: servrar, portar och säkerhet
• DirectAdmin-guide 8.8: Skicka eller ta emot fungerar inte: så löser du det
• Certifikatfel vid hämtning av e-post
• Jag kan inte skicka e-post (att ta emot fungerar)
• RFC 8314 (direkt TLS för e-postprogram), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)