Jämförelser mellan mailprotokoll

Jämförelser mellan mailprotokoll Emil Helg & Christoffer Karlsson TDTS09 Datornät och internetprotokoll Linköpings universitet Linköping emihe386 chrka611

Omslagsbild: Källa: http://enolaserv.ro/contact.htm

Sammanfattning Med ett växande behov av att kunna sända information mellan både privatpersoner och mellan företag har email blivit en av grundstenarna i vårat informationssamhälle, i och med detta har det uppkommit en rad olika protokoll över hur mail ska sändas och mottas. Denna rapport kommer beskriva hur dem olika större mailprotokoll som existerar samverkar och fungerar, samt beskriva de olika styrkorna och svagheterna i dessa protokoll. Vi ska även ge egna tankar och funderingar över hur man skulle kunna effektivisera användningen av mail. Dem olika mailprotokollen som kommer beskrivas är följande: SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol), IMAP (Internet Message Access Protocol) och även en kortare beskrivning av HTTP (Hypertext Transfer Protocol). Alla dessa protokoll befinner sig i applikationslagret och använder sig av TCP (Transmission Control Protocol) för transport av information.

Innehållsförteckning 1. Inledning...1 1.1 Bakgrund...1 1.1 Syfte...1 1.2 Metod och källor...1 1.3 Avgränsningar...1 2. Beskrivning av protokollen...2 2.1 SMTP...2 2.2 POP3...5 2.3 IMAP...6 3. Skillnader mellan POP3 och IMAP...9 4. Diskussion och slutsatser...10 4.1 SMTP...10 4.2 POP3...10 4.3 IMAP...10 4.4 Egna tankar...11 Referenser...12

1. Inledning 1.1 Bakgrund Att skriva mail är något dem flesta människor ser som en självklarhet. Det används både för att sända personlig information och även för att sända information rörande företag. Detta har lett till att informationsflödet har ökat något markant sedan internet grundades. Medan möjligheten att kunna sända information mellan datorer fanns innan internet har internet sett till så att man nästan var som helst på jorden kan få fram ett meddelande till en eller flera kollegor eller vänner. En av fördelarna med mail över andra sätt att meddela sig exempelvis telefon eller videokonferenser är den att mail inte sker direkt utan efter att informationsflödet mellan personerna är asynkront dvs. behöver inte ske i serie, utan att det går att sända och ta emot information i olika takt utan att vara beroende av varandra. Detta leder till att man kan vara frånvarande i den stund ett mail kommer fram då man till skillnad från ett telefon inte måste svara och samtala med personen under den tidpunkt där man får sitt samtal. Man kan så att säga svara i den takt man själv känner är passande. Dock har just det att mail funnits så länge lett till att det har uppkommit en mängd olika protokoll över hur just mail kan sändas och tas emot. Den här rapporten kommer att beskriva hur dem större protokollen fungerar dvs SMTP, POP3, IMAP och HTTP som kommer skrivas på detta sätt då det är allmänna förkortningar. 1.2 Syfte Syftet med rapporten är att ge en djupare förståelse för hur dem större mailprotokollen fungerar, där vi även tar upp dem för- och nackdelar som existerar. Vi ska även försöka ge en beskrivning av hur man skulle kunna lösa detta, men även se om det går att skapa ett större mer omfattande protokoll som skulle kunna sköta det de nu existerande protokollen för. 1.2 Metod och källor Rapporten är en litteraturstudie av dem större mailprotokollen där större delen av informationen är tagen från dem olika RFC (Request for Comments) som existerar. Vi har även använt oss av ett program kallat Wireshark för att få en uppskattning av hur protokollen ser ut och fungerar i verkligheten, dock kommer denna information inte att finnas tillgänglig. RFC:er är dokument som beskriver hur olika typer av protokoll ska fungera och implementeras. Detta för att en standard ska kunna skapas och följas när man ska använda dessa protokoll. Dessa dokument publiceras av IETF (Internet Engineering Task Force) som arbetar med att ta fram internet standarder. 1 1

1.3 Avgränsningar Vad vi har gjort är att med rapporten försökt ta fram en rapport som är så teoretisk som möjligt. Dvs vi har beskrivit hur protokollen ska fungera i teorin, hur dem i verkligheten är implementerade är något som inte tas upp i denna rapport. Vad vi även gjort är att försökt beskriva protokollen på ett mer överskådligt sätt, då detta är en rapport avsedd mer som en introduktion i ämnet än en rapport på vilka vidare utveckling kan baseras. 2. Beskrivning av protokoll Här kommer vi beskriva hur dem olika protokollen är tänkta att fungera, samt vad dem har till uppgift. Vi kommer att börja med att ha en kortare beskrivning av protokollets backgrund, för att sedan följa upp detta med en beskrivning av protokollet. 2.1 SMTP SMTP som protokoll skrevs 1982 av Jonathan B. Postel (IETF, 1982) men har självklart ändrats sedan dess, då främst i olika typer av utökningar för att kunna anpassas allteftersom behoven uppståt dock har själva grundidéen med protokollet inte ändrats. SMTP som protokoll är väldigt simpelt och använder sig av olika typer av kommandon för att etablera, kommunicera och slutligen avsluta uppkopplingar mot olika mailservrar. Kommandona som SMTP använder är alltid verb och oftast spelar det ingen roll huruvida det är gemener eller versaler, dock finns det vissa servrar som endast tar emot versaler så detta är en standar. Dem svar som kommer från servern är alltid en tre-siffrig kombination. Exempel på kommandon: EHLO/HELO Detta kommando identifierar klienten för servern genom att skicka med domännamnet för klienten, om det finns någon. Om svaret från servern är 250 (OK) betyder detta att servern är redo för transaktion av information. EHLO är en nyare variant av HELO och frågar även efter vilka utökningar av SMTP som är implementerade på servern. Om inget svar fås från EHLO skickas ett HELO då alla mailservrar måste kunna ta emot detta kommando. MAIL Innehåller en så kallad Reverse-path, vilket är avsändarens mailadress. MAIL-kommandot inleder själva överföringen av information och får inte skickas först efter att ett EHLO/HELO skickats och fått svarskod 250. Det MAIL kommandot sedan ser till är att alla buffers (revers-path, forward-path och data) töms samt lägger till en ny reverse-path till buffern. 2 2

RCPT Innehåller en forward-path, det vill säga den innehåller information om var mailet ska skickas, och lägger till det i forward-path buffern. För varje mottagare skickas ett RCPT-kommando. DATA lägger till data i data-buffern, det vill säga själva meddelandet som mailet innehåller. När alla data är tillagd till buffern använder servern infon sparad i de tre bufferna för att skicka mailet vidare till mottagaren, sedan ska buffern tömmas. En server måste svara på detta kommando med antingen 250 eller med någon annan tre-siffrig kod.om svaret är 250 kommer då servern att vara den nya klienten som motsvarar för att meddelandet kommer fram. Servern lägger då också till en time stamp line som innehåller information om klienten som skickade meddelandet, hosten som tog emot det och vid vilken tidpunkt detta skedde. RSET Detta kommando tömmer alla buffers. En klient kan närsomhelst använda RSET för att återställa sändningen, och servern måste alltid svara med 250 på detta kommando. Att påpeka är att anslutningen mellan dem två klienterna inte stängs då endast QUIT-kommandor kan göra detta. VRFY Används för att få verifikation över att motagaren verkligen är en mailserver eller användare. Alla buffers förblir oförändrade vid detta kommando. En server kan även svara i olika tre-siffriga siffer kombinationer för att klienten ska veta vad som hänt med meddelandet. Dem tre siffrorna har olika funktioner, där den första siffran säger om svaret är bra,dåligt eller inte färdigt. Siffran i mitten talar om vad som blev fel, och den sista siffran specificerar detta ännu mer. Exempel första siffran är: 2. Kommandot utfördes korrekt, ett nytt kan skickas. 3. Kommandot godkändes, men mer info behövs. 4. Kommandot utfördes inte, försök igen 5. kommandot utfördes inte, försök inte igen, ändra kommandots utformning först Eftersom SMTP är ett mailprotokoll skulle man lätt kunna luras att protokollet tillåter klienter att sända och skicka mail. Detta är dock inte sant, då SMTP endast tillåter klienter att skicka mail. För att kunna hämta mail till en klient krävs ett annat protokoll. En av fördelarna med detta är den att SMTP är beskrivet på ett sådant sätt att den gör denna tillämpning i en närmast fulländning. 3 3

Men hur fungerar då SMTP? Jo SMTP fungerar genom att en klient ska skicka sitt mail, skickas det först till dennes mailserver. Vilken mailserver man har beror på vilken mailapplikation klienten använder. Anledningen till att man först skicka mailet till en mailserver är för att dessa alltid ska vara online, så att mottagaren även om denne inte är online kan ta emot det senare. En annan av fördelarna med just detta är att om mottagarens mailserver skulle vara offline kommer klientens mailserver att fortsätta skicka detta meddelande efter en stund tills det kommer fram eller så lång tid förflutit att meddelandet skickas tillbaka till avsändaren med ett meddelande att mailet inte kunde komma fram. Detta är dock tillräckligt ovanligt för att inte vara något problem. Från att avsändarens mailserver skickat mailet till mottagarens mailserver sparas det där tills mottagaren kan läsa det. Ofta är det så att det inte behövs något mellansteg från avsändarens mailserver till mottagarens mailserver. Det är dock möjligt för SMTP att ha ett mellanled (enligt RFC 5321). Det som händer då är att servern tar emot meddelandet och sedan agerar som en ny klient och skickar mailet vidare. Då antingen med SMTP och vid detta fall kallas då servern för en relay eller genom att sända mailet i något annat protokoll och då kallas servern gateway. För att genomföra själva skickandet av mailet gör klienten så att den börjar med att skicka kommandot EHLO/HELO till servern för att se om mailet kan skickas och för att identifiera klienten. Nästa kommando som skickas är MAIL som berättar vem som skickat mailet. Om servern nu kan ta emot mailet ska svaret 250 komma om inte detta sker ska ett annat svar komma. Nästa kommando ska vara RCPT som förklarar vem mailet ska till. Om denne mottagare kan ta emot detta skickas kod 250 tillbaka, annars avvisas just den mottagaren, detta upprepas tills alla mottagare har gåtts igenom. Om man har valt att skicka mailet till flera mottagare skickas informationen endast en gång. Sedan får alla mottagare hämta den där själva. Efter detta skickas själva informationen i mailet med DATA och servern ska nu svara med kod 250 om allt skett korrekt och informationen är mottagen. Kommunikationen som sänds innan själva informationen nått fram kalas handshake vilket ska se till så att flödet av information sker säkert. Efter att mailet har skickats sker en så kallad handoff, där servern avsäger sig ansvaret för meddelandet. SMTP är byggt på ett sådant sätt att när servern har svarat att meddelandet har skickats med kod 250 flyttas ansvaret att se till att mailet kommer fram, över till servern som mottagit mailet. Om servern inte kan ansvara för detta måste servern se till att meddelandet skickas tillbaka till avsändaren med ett notifikationsmeddelande om att mailet inte kunde skickas. När så meddelandet är skickat och handoff skett stängs anslutningen mellan servrarna ner om inte servern ska skicka fler meddelanden. 4 4

2.2 POP3 Eftersom SMTP inte kan användas för att användare ska kunna hämta mail var man tvungen att skapa ett protokoll som kunde göra detta. Där med skapades POP. Den första i POP-serien kallades enkelt nog endast POP, i och med utveckling har man allteftersom utökat denna serie tills vad som är standard just nu vilket är POP3. POP-serien är en väldigt simpel protokoll-serie med väldigt få finesser och metoder. Eftersom POP är så simpelt är det också ganska begränsat. En stor begränsning är att POP låter användaren koppla upp sig mot en server för att ladda ner mailet, efter att detta skett raderas mailet från servern. I andra mer avancerade protokoll raderas inte mailet utan man kan hämta det flera gånger från servern utan att det raderas. Servern startar POP-applikationen genom att starta en TCP anslutning på port 110, där den sedan väntar på att en klient ska koppla upp sig. När detta sker startar en TCP anslutning mellan servern och klienten. Servern börjar då med att skicka en hälsningsfras, och sedan börjar klienten att skicka kommandon som servern svarar på. Kommandon kan precis som i SMTP vara antingen gemener eller versaler i kommandona. Kommandot kan följas av olika typer av argument, både kommandot och argumentet skrivs i ASCII. Längden på kommandot är alltid 3 eller 4 tecken, medan argumenten kan vara upptill 40 tecken långt. Svaren består av en status och ett speciellt ord. Statusen kan vara antingen positiv eller negativ. För en positiv status skickas +OK, och för en negativ status skickas ERR (IETF, 1996). En anslutning i POP3 genomförs i olika steg. Det första steget kallas för AUTHORIZATION, denna startas direkt efter att den första hälsningsfrasen skickats till servern. I detta steg begär servern information om klienten, klienten måste då identifiera sig för servern med användarnamn och lösenord. Identifikationen kan ske på två olika sätt. Antingen med en kombination av USER och PASS kommandon, eller med APOP. I USER och PASS skickar klienten först kommandot USER följd av användarnamnet som argument. Om servern anser att användarnamnet är godkännd skickas OK tillbaka, och klienten kan nu använda PASS. PASS skickar med lösenordet som argument, och servern jämför sedan om det lösenordet hör ihop med användarnamnet tidigare sänt. Om detta lösenord inte hör ihop med användarnamnet får klienten försöka igen eller skicka kommandot QUIT. Om man istället skulle använda APOP skickas inte användarnamn och lösenord över direkt utan det krypteras för att man inte ska kunna se vad som användaren skrev in. Sedan skickas den kryppterade användarinformationen över till servern. Detta är mycket säkrare än att använda USER/PASS kommandon. 5 5

Om Authorization fasen lyckas låser servern användaren till maildropen, vilket gör att klienten får exklusiv tillgång till maildropen. Detta ser till så att ingen annan kan ändra eller ta bort dem mail som existerar för användaren under tiden han är inloggad. Efter detta sker TRANSACTION fasen i vilken klienten börjar skicka kommandon till servern. Några exempel på dessa kommandon är: RETR Ett kommando som ser till att mailen börjar skickas till klienten från servern. LIST Gör så att servern sorterar varje mail i en lista. DELE Får servern att radera dem meddelanden klienten markerat för radering. NOOP Servern ska skicka tillbaka ett positivt svar, bortsett från detta sker ingenting. RSET Får servern att återställa meddelandena, dvs dem mail som har markerats för radering avmarkeras. QUIT Stänger anslutningen mellan servern och klienten. Efter att dem kommandona som behövts skickas av klienten skickats kommer UPDATE fasen. I denna fas gör servern sig av med den information den fick i TRANSACTION fasen, dvs tar bort meddelanden som markerats för radering och stänger sedan ner anslutningen. En av dem större bristerna med POP3 är just det att mail alltid raderas från servern efter att dessa laddats ner. Detta gör att det finns inget sätt för en klient som loggar in på servern med samma användarnamn att kunna läsa/hämta samma information som hämtats tidigare. En av fördelarna med detta är dock att servrar inte behöver ett lika stort minne då informationen som sparas på servern snabbt försvinner från en vanlig användare. 2.3 IMAP Ett annat vanligt protokoll som används för att hämta mail från en mailserver är IMAP. IMAP som mailprotokoll är relativt avancerat då den har flera olika metoder och kommandon. När man använder sig av IMAP ladas inte all data från mailen ner, utan man laddar bara ner en liten del av mailet och sedan låter man användaren själv bestämma om den vill ladda ner mailet eller inte. En annan sak som IMAP gör är att den raderar inte själv mailen efter att dem lästs utan dem stannar alltså kvar på mailservern tills användaren själv vill radera dem. En av dem sakerna man kan göra med IMAP kommandona är att användaren har möjlighet att skapa egna mappar för att själv sortera sina mail. För att kunna göra detta implementerar IMAP ett system kallat UID (Unique Identifier). UID används för att ge varje mail som sparas för användaren ett unikt nummer, dvs inget mail kan ha samma UID-nummer som ett annat mail. Detta gör att varje nytt mail som sänds till användaren får ett högre UID-nummer än det föregående. Alla meddelanden får även ett sekvensnummer, som till skillnad från UID-nummret ändras beroende på om meddelanden tas bort. Exempelvis skulle en mailbox innehållande mail med sekvensnummren 1,2,3,4 där mail nummer 2 tas bort få sekvensnummren: 1,2,3 där den nya två:an är den föregående tre:an. 6 6

En annan fördel med just IMAP är att i och med att bara delar av mailet laddas ner, behöver inte stora filer såsom större bilder, ljud och film filer laddas ner för alla mail. Utan man laddar endast ner dessa när användaren specifikt ber om detta. Detta gör så att en användare med en lägre bandbredd kan läsa sin mail fort, trots att han har en stor bild-fil bifogad i ett av sina andra mail. En IMAP anslutning kan befinna sig i fyra olika steg. Dessa är Non Authenticated State, Authenticated State, Selected State och Logout State (IETF, 2003). När en anslutning till servern är upprättad hälsar mailservern för att verifiera uppkoplingen. Sedan kommer anslutningen in i Non Authenticated State. I detta steget måste klienten ge servern användarnamn och lösenord, innan kommandon kan användas. När servern fått uppgifterna går anslutningen in i Authenticated State, där klienten nu måste välja vilken mailbox som kommandona den skickar ska utföras på. När klienten valt mailbox går anslutningen in i Selected State, och nu kan man välja kommandon som påverkar mailen som existerar i just den mailboxen. När klienten vill, eller när något fel uppstår komman man till Logout State, vilket innebär att anlutningen stängs ner. Servern skickar ett hej-då -meddelande för att bekräfta detta. Bild 1 ger en bättre bild av hur detta sker. 7 7

+----------------------+ connection established +----------------------+ \/ +--------------------------------------+ server greeting +--------------------------------------+ (1) (2) (3) \/ +-----------------+ Not Authenticated +-----------------+ (7) (4) \/ \/ +----------------+ Authenticated <=++ +----------------+ (7) (5) (6) \/ +--------+ Selected ==++ +--------+ (7) \/ \/ \/ \/ +--------------------------------------+ Logout +--------------------------------------+ \/ +-------------------------------+ both sides close the connection +-------------------------------+ (1) connection without pre-authentication (OK greeting) (2) pre-authenticated connection (PREAUTH greeting) (3) rejected connection (BYE greeting) (4) successful LOGIN or AUTHENTICATE command (5) successful SELECT or EXAMINE command (6) CLOSE command, or failed SELECT or EXAMINE command (7) LOGOUT command, server shutdown, or connection closed Bild 1. En grafisk bild över hur IMAPs olika steg sker. 8 8

3. Skillnader mellan POP3 och IMAP Som vi lite tidigare beskrivit finns det större skillnader i hur POP3 och IMAP fungerar. Den största av dessa skillnader är att POP3 är ett väldigt simpelt protokoll med några få metoder och kommandon. IMAP däremot är ganska avancerat med en mängd metoder och kommandon. Dem skiljer sig även med att POP3 laddar ner all data från alla mail användaren har för att sedan radera dessa från mailservern, medan IMAP bara laddar ner en liten mängd data för att sedan låta användaren bestämma vad som ska laddas ner och inte. Den skiljer sig också på det att mailservern inte raderar alla mail efter att dessa laddats ner utan överlåter detta till användaren. En annan sak som skiljer dessa protokoll från varandra är den att IMAP ger användaren möjlighet att skapa mappar där användaren kan sortera sina mail, POP3 har inte en sådan funktion då användaren prompt laddar ner alla mail direkt och därefter får användaren sortera sina mail på sin klient. Det finns även en skillnad i hur protokollen sköter sina steg. Då man i IMAP får identifiera sig för att sedan gå igenom vilken mapp man vill söka efter sitt mail i. Där man sedan efter att ha gjort detta kan redigera sina mail för att slutligen kan bryta anslutningen. I POP3 däremot ska man först verifiera sig, sedan laddas alla mailen ner, och för att i sitt tredje och sista steg ta bort mailen och sedan stänga anslutningen. En annan sak som skiljer protokollen åt är den att med IMAP kan flera klienter vara uppkopplade med samma användarnamn till en mailserver, där dem kan läsa och redigera sina mail. Denna funktion existerar inte i POP3. Det går även i IMAP att kolla statusen på sina mail, dvs en klient kan kolla om mailet har blivit läst, fått ett svar eller blivit raderat. Även detta existerar inte i POP3. 9 9

4. Diskussion och slutsatser I denna del av rapporten ska vi ge belysa dem svagheter som existerar i dessa protokoll. Vi kommer även ge egna tankar om hur man skulle kunna lösa dessa protokoll problem som existerar bland mailprotokollen. 4.1 SMTP Det som är det största problemet just nu i SMTP är det att det är 7-bitar tecken. Detta har gjort att man inte har haft möjligt för ett flertal olika språk som inte existerar inom 7-bitar att kunna sändas, man har löst detta genom att koda om de tecken som inte finns tillgängliga bland dessa 7-bitar till en typ av hexadecimal form. Dessa omkodas sedan till dem tecken som den hexadecimala koden beskriver vid slutdestinationen. Det går även att omkoda dem olika tecknen till annan kod men idéen är densamma. Ett annat problem med just SMTP är den att det inte är byggt för att vara krypterad. Detta har gjort att det är något man har fått lägga till i efterhand. Detta sker i nuläget genom att kryptera sitt meddelande och sedan skicka det krypterade meddelandet i ett SMTP meddelande. 4.2 POP3 En av dem största bristerna med just POP3 är den att en klient inte kan komma åt sina meddelanden från mailservern efter det att han har laddat ner dem en gång innan. Detta är förstås också en av fördelarna med protokollet då mailservern inte behöver spara information redan läst över en längre tid. En annan av svagheterna med POP3 är den att man inte kan sortera sina mail i mailservern. Utan dem laddas alltid ner direkt trots att man har en dålig bandbredd. Dessa båda problem var tänkta att minska i storlek i och med POP4, dock har ingen ny information kommit om ett POP4. 4.3 IMAP En av dem saker som talar till IMAPs nackdel är den att i och med alla dess funktioner och metoder har protokollet blivit väldigt komplext. Bland annat så är funktionen som tillåter flera klienter att vara inne på samma användare väldigt komplex och ställer högra krav på servrar. Detta har lösts på olika sätt, ett av dessa är Maildir (Malidir, 1990). En annan av IMAPs nackdelar är den att den kan vara väldigt server krävande då en klient letar efter en viss mailbox. IMAP kräver också att en klient måste ha konstant åtkomst till servern för att kunna läsa och redigera sina mail. 10 10

4.4 Egna tankar Det vi kommit fram till med våran undersökning av dem olika mailprotokollen är att dem är mer genomtänkt än vi tidigare trott. Vi anser att man borde behålla SMTP som standard för att sända mail men att man ska fortsätta forska i hur man kan göra SMTP bättre. Vi anser även att IMAP borde få mer resurser tilldelade trots sin komplexitet. Då problemet med att det kan överbelasta mailservrar är ett problem som försvinner i och med tekniska landvinningar och flera servrar som kommer förbättra den kapacitet som mailservrarna kan ge för användare i en snabbare takt än vad mail användandet kommer öka. En annan möjlig lösning på detta skulle vara att skapa ett väldigt omfattande protokoll som kan ta hand om att både sända och ta emot mail. Vi skulle då föreslå att protokollet skulle försöka att vara så likt SMTP och IMAP i dessa funktioner, då dessa protokoll gör det lätt för användare att ta hand om sin mail. 11 11

Referenser IETF (1982) Simple Mail Transfer Protocol, RFC 821, Internet Engineering Task Force (IETF), 1982, Elektroniskt tillgänglig: <http://datatracker.ietf.org/doc/rfc821/> IETF (1996) Post Office Protocol Version 3 IETF (2003) Internet Engineering Task Force (IETF), 1996, Elektroniskt tillängäglig: <http://datatracker.ietf.org/doc/rfc1939/> Internet Message Access Protocol Version 4rev1 Internet Engineering Task Force (IETF), 2003, Elektroniskt tillgänglig: <http://datatracker.ietf.org/doc/rfc3501/> Malidir, 1990 Elektroniskt tillgänglig: <http://wiki.dovecot.org/mailboxformat/maildir> Senast ändrad: 2010-11-15, Skriven av: ppp121-45-248-9, 12 12