Elektronisk post Andreas Söderlund Institutionen för informationsbehandling Åbo Akademi, Åbo, Finland E-post: andsoder(snabela)abo.fi Webbplats: http://www.sci.fi/~andreas/ Abstrakt Denna uppsats ger en ingående beskrivning av systemet med elektronisk post, förkortat e- post, d.v.s. möjligheten för olika användare vid olika datorer i olika delar av världen att kommunicera med varandra med hjälp av digitala brev, som skrivs och läses på dator och överförs elektroniskt. Det som mest kommer att beröras är den form av elektronisk post vi är vana vid att använda på Internet. Uppsatsen beskriver de grundläggande protokollen och standarderna för att skicka och ta emot e-post, ss. Simple Mail Transfer Protocol, Post Office Protocol och Internet Message Access Protocol. Även system för att bifoga filer, framför allt MIMEstandarden, gås igenom. I korthet förklaras hur posten hittar fram över nätet och vilka teckenkodningar som företrädesvis används. Vanliga program som implementerar något eller flera av ovanstående protokoll presenteras och diskuteras också. Därtill tas praktiska aspekter på e-post upp: hur säker e-posten är och hur den kan göras säkrare, hur virus sprids per e-post och missbruk av e-post i form av spam. Klassificering Klassificering enligt ACM Computing Classification System: C.2.2 Network Protocols---Applications (SMTP, FTP, etc.) H.4.3 Communications Applications---Electronic mail Klassificering enligt ACM Special Interest Groups: Data Communication SIGCOMM Applied Computing SIGAPP
1. Inledning Elektronisk post är en så nyttig och allmän företeelse att många betraktar den som en självklarhet utan att desto mera fundera på hur den fungerar. Senast då man hamnar i en situation där systemet inte fungerar riktigt som man vill, reflekterar man ändå troligen över den bakomliggande tekniken, som först kan tyckas väldigt enkel att realisera. Det ligger dock en hel del kunskap och arbete bakom ett fullständigt elektroniskt postsystem som det dominerande e-postsystemet på Internet. För många är e-post den nyttigaste delen av Internet. E-posten är praktisk eftersom den gör det lätt och billigt att förmedla information till andra. Det krävs väldigt lite skolning för att lära sig hantera e-post. I och med att e-posten i grunden bygger på överföring av ren text, klarar man sig också med relativt enkel utrustning. Därtill, och antagligen som en följd av ovanstående, är användningen av e-post mycket utbredd, vilket gör att det går att kommunicera med en stor del av befolkningen med hjälp av e-post. 2. Historik E-posten är definitivt inte något nytt påhitt; tvärtom är den den äldsta allmänt använda Internettjänsten, och är t.o.m. äldre än Internet. Före e-posten förekom det från mitten av 1960-talet datorsystem där användare vid olika terminaler hade möjlighet att sända meddelanden till användare vid andra terminaler, om de kände till de andra terminalernas identiteter [AEH93]. Någon möjlighet att adressera specifika användare fanns dock inte ännu vid denna tidpunkt, och kommunikationen var avsedd för mycket korta meddelanden. Senare började dataservicebyråer som sålde datoranvändningstid på distans erbjuda elektronisk post som en kommersiell tjänst. De som köpte dessa tjänster var stora företag. Utvecklingen gick mot att företagen utvecklade interna system för elektronisk post, som kunde anslutas till leverantörer av meddelandetjänster, och på så sätt nå varandra. Dagens verkliga e-post föddes på ARPANET i USA på 1970-talet. ARPA står för Advanced Research Projects Agency, och ARPANET var föregångaren till Internet. E-posten blev snabbt den populäraste tjänsten på ARPANET och tog upp över 75 procent av nätverkskapaciteten, trots att ARPANET främst tänkts för att överföra program och filer samt komma åt andra datorer. Det var i stor utsträckning e-posten som gjorde att ARPANET fick fortsätta och utvecklas till dagens Internet [Jon01]. Under 1980-talet utvecklades olika
inkompatibla system för e-post. Att den standard som används på Internet idag kom att bli dominerande kan bero på det populära serverprogrammet Sendmail, som använder denna standard, och på att den är enkel och smidig att använda. I takt med att Internet under de senaste tio åren har blivit tillgängligt för gemene man, har också e-posten blivit var mans kommunikationskanal. 3. Standardisering För att e-posten ska kunna skickas och mottas av den brokiga skara användare, program och datorer som är kopplade till nätet, måste det finnas standarder för hur kommunikationen ska fungera. Dessa standarder beskriver protokoll och regler, som program som hanterar e-post ska implementera för att de olika programmen ska förstå varandra. Jacob Palme definierar ett protokoll på följande sätt [Pal89]: "Med begreppet protokoll menas en standard för hur två olika system kan kommunicera med varandra via ett nät. Ett protokoll utmärker sig för att det innehåller konversationsregler, som föreskriver när det ena systemet sänder vad i vilket format, hur det andra systemet svarar och i vilket format o.s.v." E-poststandarderna finns tillgängliga på Internet i form av RFC-dokument, på samma sätt som de övriga allmänna Internetstandarderna. RFC står för Request For Comments (begäran om kommentarer). Namnet förklaras av att RFC:erna först läggs ut som föreslagna standarder för att senare, möjligtvis i förändrad form, kanske få officiell standardstatus. RFC:erna har från början tillkommit på relativt inofficiellt sätt, med utgångspunkt i fungerande programkod man lyckats producera. En bra plats att gå till för att läsa RFC:er är http://www.rfc-editor.org/. Det e-postsystem som beskrivs i RFC:erna är inte det enda existerande, men det är idag det helt dominerande systemet på Internet. 4. E-postmeddelandens struktur Vi börjar med att titta på hur enkla e-postmeddelanden är uppbyggda. De består av två delar: huvudet och kroppen. Huvudet kan också, som resultat av jämförelse med papperspost, liknas vid ett kuvert. I huvudet finns rubrikerna och i kroppen det egentliga meddelandet. Rubrikerna skrivs av e-postprogrammet som skickar meddelandet och av servrarna som förmedlar meddelandet. Vissa rubrikers innehåll har dock angetts av användaren. Den RFC som
definierar hur e-postmeddelanden byggs upp är RFC 822 (Standard for the Format of ARPA Internet Text Messages) [Cro82], från augusti 1982. Det finns en nyare RFC för detta, RFC 2822 [Res01], men den har ännu inte officiell standardstatus. Enligt standarden måste varje e- postmeddelande åtminstone ha rubrikerna From (från), To (till) och Date (datum). Vanligen går det dock bra att skicka e-postmeddelanden som saknar någon av dessa rubriker. From- och To-adresserna har formatet användarnamn@domän, t.ex. anvandar@abo.fi. För att e- postprogrammen ska förstå datumet, ska det anges i ett visst format, med engelsk text. Formatet förklaras bäst med ett exempel: Wed, 12 Oct 2003 17:00 +0200, där Wed står för Wednesday, onsdag, och Oct för October. +0200 anger enligt vilken tidszon tiden och datumet är angivna. Tidszonen anges som tidsskillnaden mellan ifrågavarande tidszon och Greenwich standardtid. Utöver dessa rubriker finns många andra rubriker, bl.a. Subject (ämne), Reply-To (svar till), Cc (Carbon copy, kopia), Bcc (Blind carbon copy, hemlig kopia), X-Mailer (vilket program som skickat meddelandet) och Received, som anger vilken dator meddelandet kommer från och vilka e-postservrar det har passerat under sin färd över nätet. Samtliga rubriker har formatet Rubriknamn: Värde, t.ex. To: mottagare@abo.fi. De flesta rubrikerna är som synes självförklarande. Det finns oftast flera Received-rubriker, och för att få veta vilken väg meddelandet har tagit över nätet, läser man dem i ordningen nedifrån och upp. Flera e-postprogram använder egna rubriker, som inte behöver vara meningsfulla för mottagare som läser meddelanden i ett annat e-postprogram. Efter rubrikerna, som med undantag av Subject alltså egentligen inte är några rubriker i ordets egentliga bemärkelse, följer en tom rad och därefter själva meddelandet som avsändaren har skrivit. Enligt RFC 822 består e-postmeddelanden enbart av text, skriven med teckenuppsättningen 7-bit ASCII. Därtill får raderna i meddelandet inte vara längre än 1000 tecken. ASCII står för American Standard Code for Information Interchange. Ordet American är värt att lägga märke till, för denna teckenuppsättning omfattar inte å, ä, ö eller andra ickeengelska bokstäver. För att säkerställa att skandinaviska tecken överförs korrekt, och för att kunna skicka även annat än ren text per e-post, har MIME-standarden utvecklats. MIME beskrivs i kapitel åtta. 5. Allmänt om programvara för e-post Man brukar indela den programvara som behövs för att kunna använda e-post i tre grupper. Den första gruppen är e-postprogram som betjänar den enskilda användaren, d.v.s. låter användaren skriva och läsa samt skicka och ta emot brev. På engelska brukar dessa program
kallas för MUA, som står för Mail User Agent. Vi kan kalla dem klientprogram. Exempel på klientprogram är Eudora, Pine och Netscape Mail. Den andra gruppen är serverprogram som skickar och tar emot e-post. Dessa kallas allmänt MTA (Mail Transport Agent). I denna uppsats kallas de sändservrar. På detta område är programmet Sendmail det mest använda. Slutligen består den tredje gruppen av serverprogram som lagrar inkommande e-post och låter användaren hämta den. Den engelska benämningen är MDA (Mail Delivery Agent) och jag använder här benämningen åtkomstserver. 6. Transport av e-post 6.1 Simple Mail Transfer Protocol Simple Mail Transfer Protocol förkortas SMTP och betyder enkelt postöverföringsprotokoll. Det är detta protokoll som definierar hur det går till att skicka e-post på Internet och det är alltså med hjälp av detta protokoll som klientprogram kommunicerar med sändservrar. Den standardiserade versionen av SMTP beskrivs i RFC 821 [Pos82], daterad augusti 1982. Liksom av RFC 822 finns det en nyare RFC som ännu inte är officiell standard, i detta fall RFC 2821. Liksom många andra Internet- och e-postprotokoll bygger SMTP på att klienten skickar kommandon och data till servern och servern svarar. Kommunikationen sker här i form av ren text, så processen är, som namnet säger, enkel att implementera och använda. Här följer ett exempel på en SMTP-session, d.v.s. hur det kan gå till när ett e-postmeddelande skickas. Den text som klienten skickar till servern anges här med fetstil. 220 ra.abo.fi ESMTP Sendmail 8.12.5/8.12.5; Tue, 28 Oct 2003 19:37:30 +0200 (EET) HELO datornamn 250 ra.abo.fi Hello anvandar@aton.abo.fi [130.232.213.6], pleased to meet you MAIL FROM:<avsandare@abo.fi> 250 2.1.0 <avsandare@abo.fi>... Sender ok RCPT TO:<mottagare@abo.fi> 250 2.1.5 <mottagare@abo.fi>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself From: Avsändarens namn <avsandare@abo.fi> To: Mottagarens namn <mottagare@abo.fi> Date: Tue, 28 Oct 2003 19:40:00 +0200 Detta är ett e-postmeddelande.. 250 2.0.0 h9shbu0v020434 Message accepted for delivery
QUIT 221 2.0.0 ra.abo.fi closing connection Notera att raderna som börjar med From, To och Date inte är SMTP-kommandon, utan meddelanderubriker som utgör meddelandets huvud! Här följer förklaringar av de viktigaste SMTP-kommandona: HELO Folkligt uttryckt kan man säga att klienten hälsar på servern, ty HELO är en förkortning av hello. Man kan också säga att klienten identifierar sig för servern. Som argument är det meningen att klienten ska ange sitt datornamn, men det går att ange vad som helst, och servern tar ändå reda på klientens datornamn själv. MAIL Det här kommandot påbörjar själva överföringen och tar som parameter avsändaradressen i standardformatet <användarnamn@domän>. Mottagaren kommer dock inte att se den adress som angivits här, förutsatt att en From-rubrik anges i meddelandet. I så fall är det nämligen den som visas i mottagarens e-postprogram. RCPT Här anges mottagarens e-postadress i standardformatet <användarnamn@domän>. Det är det här kommandots parameter som anger vart e-postmeddelandet skickas, men det är innehållet i To-rubriken i meddelandet som mottagaren ser som mottagaradress. DATA Detta betyder att klienten vill börja överföra själva e-postmeddelandet. Allt som klienten skickar efter det här tolkas som meddelandetext och inte som kommandon till servern. För att visa att meddelandet tar slut, skickar klienten en punkt på en tom rad. RSET Om något går på tok och klienten vill börja om från början, skickar den detta kommando, som står för reset. QUIT Klienten talar om att den är klar med kommunikationen för denna gång och att servern sålunda får koppla ned förbindelsen. Om klienten ska skicka flera brev, avbryter man inte sessionen mellan breven, utan ger på nytt kommandot MAIL FROM efter att det föregående brevet är klart. Kommandot QUIT anges först efter att alla breven är skickade. Det finns flera kommandon än ovanstående, framför allt i den utökade standarden ESMTP. Man klarar sig dock med ovanstående kommandon, och det kan finnas SMTP-servrar som ännu inte stöder ESMTP. Man kan dock kontrollera om ESMTP stöds genom att ge kommandot EHLO istället för HELO. Om servern känner till kommandot EHLO, stöder den ESMTP.
SMTP används inte bara vid kommunikationen mellan klienter och sändservrar, utan också vid kommunikationen mellan olika sändservrar. Olika sändservrar måste kunna kommunicera med varandra eftersom ett e-postmeddelande oftast passerar flera än en sändserver på sin väg över Internet. I det enkla typfallet sker SMTP-kommunikation först mellan avsändarens klientprogram och avsändarens Internetleverantörs SMTP-server och sedan mellan avsändarens Internetleverantörs SMTP-server och mottagarens Internetleverantörs SMTP-server. Det är värt att lägga märke till att alla serverns svar i exemplet ovan börjar med ett nummer. Numren är det enda väsentliga ur teknisk synvinkel; texten efter dem finns bara där för att underlätta för mänskor. Detta kommer sig givetvis av att det är mycket enklare att behandla tresiffriga nummerkoder än långa textsträngar i datorprogram. Serverns viktigaste responskoder är följande: 220 Jag är redo att skicka e-post. Identifiera dig! 221 Det är okej för mig att avsluta sessionen. 250 OK. Allt är som det ska tills vidare. 354 Börja överföra själva e-postmeddelandet! 550 Mottagaren eller mottagardatorn existerar inte. Vad mottagaren beträffar kan det här svaret endast ges av mottagarorganisationens SMTP-server, och kommer som respons på kommandot RCPT TO då ingen användare med den mottagaradress som angetts existerar i denna organisation, d.v.s. avsändaren har försökt skicka e-post till en adress som inte finns. Om mottagardatorn inte existerar, upptäcks det redan hos avsändarens SMTP-server. Avsändaren kommer i de flesta fall att uppmärksammas på felet i en felrapport som skickas till avsändarens e-postadress. Om man bara ska använda färdiga e-postprogram, och inte själv ha något med implementeringen att göra, behöver man självfallet inte känna till SMTP-protokollets kommandon, svarskoder etc. Detsamma gäller för de övriga protokollen som beskrivs i denna uppsats. 6.2 Hur e-posten hittar fram över Internet För att datorer i ett nätverk ska kunna hitta varandra krävs någon form av adresseringsprotokoll, och för att de ska kunna kommunicera med varandra dessutom någon form av transportprotokoll. På Internet är dessa IP (Internet Protocol) och TCP (Transmission
Control Protocol). Dessa bildar tillsammans med några andra protokoll TCP/IP, som är grunden för hur Internet fungerar. Enligt IP har varje dator på Internet en IP-adress i form av fyra nummer mellan 0 och 255, åtskilda av punkter, t.ex. 130.232.213.6. Dessutom har datorn oftast ett namn, t.ex. aton.abo.fi. För att översätta mellan IP-adress och datornamn används ett system som heter DNS (Domain Name System, domännamnssystem). Som beskrivits i föregående avsnitt, förmedlas posten från avsändaren till mottagaren av och mellan SMTP-servrar, eller endast en SMTP-server om avsändarens och mottagarens post hanteras av samma SMTP-server, vilket ofta är fallet om avsändaren och mottagaren tillhör samma organisation. SMTP används alltså både för att skicka post och för att ta emot post; i det senare fallet dock endast då servern, inte användaren, tar emot ny post. Då någon (ett klientprogram eller en SMTP-server) levererar ett brev till en SMTP-server, kontrollerar den sistnämnda vart brevet ska skickas. Om den inte är den mottagande servern för adressen som brevet ska till, skickar den det vidare till den server som är mottagaren. Vilken server brevet ska levereras till tas reda på med hjälp av DNS. DNSservrar står inte endast till tjänst med adressöversättningar, utan håller även reda på vilken SMTP-server som hanterar inkommande e-post för en viss domän. I det enklaste fallet bygger e-postadresseringen på att adressdelen efter @:et anger vilken dator mottagarens elektroniska postlåda finns på, men så är oftast inte fallet. Exempelvis existerar det ingen dator som heter abo.fi, trots att det bevisligen existerar tusentals fungerande adresser i formatet anvandar@abo.fi. Då en SMTP-server ska skicka iväg ett brev, konsulterar den DNS-servern om vart brev till ifrågavarande domän ska skickas. Denna information kan manuellt kontrolleras med Unix-kommandot host i formatet 'host t MX domän.fi', där domän.fi ska ersättas med namnet på den domän man är intresserad av. DNS-servern returnerar en lista bestående av namnet på åtminstone en dator som ska kunna ta emot post till ifrågavarande domän. Datornamnen är ordnade i prioritetsordning så att posten i första hand ska skickas till den dator som har det lägsta prioritetsnumret. Här följer ett exempel, där det som användaren skrivit är markerat med fetstil: [17:20] tuxedo ~ >host -t MX abo.fi abo.fi mail is handled by 10 ra.abo.fi. Post till någon@abo.fi ska alltså skickas till SMTP-servern med namnet ra.abo.fi. SMTP-servrarna är emellertid inte de enda datorer som vidarebefordrar ett e- postmeddelande över Internet, trots att det bara är de som lägger till Received-rubriker överst i meddelandet. Då data skickas över nätet, uppdelas de i datapaket, som skickas oberoende av
varandra som förbindelselös kommunikation, vilket betyder att avsändaren och mottagaren inte etablerar någon fast kommunikationskanal för kommunikationen, utan avsändaren skickar iväg paketen åt rätt håll och förväntar sig att de småningom hittar fram. Datapaketen lotsas åt rätt håll av nätväxlar (routers) beroende på uppgjorda ruttabeller (routing tables) och trafikmängder på olika håll i nätet. Olika delar av ett och samma e-postmeddelande kan faktiskt nå samma destination längs olika vägar, d.v.s. via olika datorer. En detaljerad beskrivning av Internetkommunikation på den här nivån hör dock inte till den här uppsatsen, utan kan läsas i t.ex. [PeDa00] eller [Com00]. 7. Protokoll för åtkomst till e-post I Internets barndom bestod nätet av datorer som var anslutna till nätet mer eller mindre hela tiden. Att leverera e-post till mottagarens dator var därför inget problem [Jon01]. Sedermera har det blivit vanligt att ansluta PC:r i hemmen till Internet via modem och telefonlinjer. Då dessa datorer oftast inte är uppkopplade på nätet, måste inkommande e-post tas emot av en server som alltid är uppkopplad på nätet. Därefter bör posten smidigt kunna hämtas till den lokala datorn. Detta gav upphov till protokollet POP (Post Office Protocol). För sitt ändamål fungerar POP bra. Det har emellertid igen uppstått nya krav på e-poståtkomst. I dagens läge rör sig användarna ofta mellan olika datorer, och vill ha tillgång till sin e-post oavsett var de befinner sig. E-posten måste sålunda ligga på servern, men samtidigt önskar man behandla den med den lokala datorns program. Att bredbandsuppkopplingar hela tiden blir vanligare gör att det inte längre behöver vara viktigt att minimera PC:ns uppkopplingstid. Mot bakgrund av dessa faktorer har protokollet IMAP (Internet Message Access Protocol) utvecklats. 7.1 Post Office Protocol Post Office Protocol betyder postkontorsprotokoll och definieras i RFC 1939. Det är det vanligaste åtkomstserversystemet. POP bygger på att användarens klientprogram, när användaren så önskar, tar kontakt till en POP-server och då hämtar de brev som eventuellt finns i användarens elektroniska postlåda på servern. Vanligen raderar man automatiskt breven från servern när hämtningen utförts. Om man använder e-post över ett vanligt modem och en vanlig telefonlinje, eller har relativt lite utrymme på servern till förfogande för sin elektroniska post, är POP det bästa poståtkomstsystemet. Liksom SMTP fungerar POP genom
att klienten och servern skickar kommandon respektive svar i form av ren text åt varandra. Här är ett exempel på hur det kan gå till. Det som klienten skickar till servern är markerat med fetstil. +OK POP3 Ready <29366.1067450457@kotilo> USER mottagar +OK PASS losenord +OK opened mailbox for mottagar LIST +OK 1 547 2 1932. RETR 2 +OK X-UIDL: 0dfca887a5e24d92c2db73284bb26a21.1066935241.2898 Return-Path: <avsandar@abo.fi> Received: from fe02.mail.jippii.net (fe02.mail.jippii.net [195.197.172.101]) by kotilo.saunalahti.fi (Postfix) with ESMTP id 766E763308 for <mottagar@kotilo.saunalahti.fi>; Thu, 23 Oct 2003 18:30:56 +0300 (EEST) (Jag skriver inte ut hela e-postmeddelandet här, eftersom det skulle ta för mycket plats.). RETR 3 -ERR No such message DELE 2 +OK Message 2 marked QUIT +OK Kommandona i exemplet ovan är självförklarande bara man vet vad det är som pågår. Med USER (användare) och PASS (lösenord) loggar klienten in och rätt postlåda öppnas. LIST (lista) ger en förteckning med meddelandenummer och meddelandestorlek för meddelandena i postlådan. Med kommandot RETR (retrieve, hämta) hämtar klienten ett visst meddelande från servern. Efter att det hämtats kan det markeras för radering med kommandot DELE (delete, radera) och kommer i så fall att raderas när sessionen avslutas med kommandot QUIT (avsluta). POP-servern använder inte nummerkoder som svar, men dess svar börjar alltid med +OK om den ifrågavarande operationen lyckades, och med ERR om den misslyckades. Då svaret består av mer än en rad, avslutas det med en rad med en ensam punkt för att man ska veta att hela svaret har kommit.
7.2 Internet Message Access Protocol Även detta protokoll, vars namn betyder åtkomstprotokoll för Internetmeddelanden, är logiskt nog ett protokoll för åtkomstservrar. Det beskrivs i RFC 2060 och några andra RFC:er som ytterligare specificerar vissa detaljer. Medan POP går ut på att man är uppkopplad mot servern bara då meddelandena överförs, och sedan läser och lagrar meddelandena på sin egen dator, är idén med IMAP att meddelandena lagras på servern och sålunda är åtkomliga från olika datorer. Då användaren loggar in på servern, överförs först normalt bara en lista över meddelandena i postlådan. Själva breven överförs först när användaren väljer att öppna dem. Även om grundtanken är att breven finns på servern, kan användaren givetvis även med IMAP spara breven på sin lokala hårddisk. Även IMAP bygger på utväxling av textsträngar mellan servern och klienten, men IMAP är betydligt mera komplext än SMTP och POP. Komplexiteten kommer sig av att IMAP inte är ett protokoll endast för att skicka e- postmeddelanden åt något håll, utan även för diverse manipulerings- och hanteringsfunktioner. Bland annat låter IMAP användaren lagra sin e-post i flera olika mappar på servern och söka bland meddelandena med hjälp av sökfunktioner. IMAP-servern har helt enkelt en del av den funktionalitet som man väntar sig att klientprogrammet ska ha när man använder POP. Här följer ett exempel på en kort och enkel IMAP-session, där klienten bara hämtar post. Det som klienten skickar är markerat med fetstil. * OK emperor Cyrus IMAP4 v2.0.15-aau4 server ready a001 LOGIN anvandar losenord a001 OK User logged in a002 SELECT INBOX * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] * 38 EXISTS (bortklippt text) a002 OK [READ-WRITE] Completed a003 FETCH 12 FULL * 12 FETCH (FLAGS (\Answered \Seen) INTERNALDATE "23-Oct-2003 18:19:35 +0300" RFC822.SIZE 1711 ENVELOPE ("Thu, 23 Oct 2003 18:24:23 +0300 (EET DST)" "Seminarieuppsats" (("=?ISO-8859-1?Q?Andreas_S=F6derlund?=" NIL "andreas" "sci.fi")) (bortklippt text) a004 OK Completed a004 FETCH 12 BODY[TEXT] * 12 FETCH (BODY[TEXT] {338} Jag skriver en seminarieuppsats. Detta är innehållet i meddelande nummer 12 i inboxen. ) a005 OK Completed
a006 LOGOUT * BYE LOGOUT received a006 OK Completed Klienten börjar varje kommando med en godtycklig, men entydig alfanumerisk identifierare och servern inleder den sista raden i svaret på ifrågavarande kommando med samma identifierare. Detta behövs för att klienten ska veta vilket kommando ett svar hör till eftersom IMAP-protokollet tillåter klienten att skicka ett nytt kommando innan svaret på det föregående har erhållits. 8. Bilagor och avancerad meddelandestruktur Från början var e-posten tänkt enbart som ett system för att distribuera ren engelsk text. Då detta naturligtvis inte är tillräckligt, har olika påbyggnadssystem utvecklats. Det viktigaste är MIME. 8.1 Teckenuppsättningar Det finns olika system för att representera text i datorer. Eftersom datorer internt lagrar data i binär form, bygger alla textrepresentationer på att varje tecken får en nummerkod. Hur stora teckenuppsättningar som kan representeras beror på hur många bitar, d.v.s. hur stort minnesutrymme, man använder för att representera varje tecken. Tyvärr finns det ingen enhetlig standard som alla följer för hur många bitar som ska användas för att representera ett tecken, ej heller för vilket tecken som ska motsvaras av vilken nummerkod. Olika tillverkare av operativsystem, program och datorer har valt att gå olika vägar, vilket kan leda till problem då olika datorer ska kommunicera, t.ex. då e-post skriven i ett visst operativsystem ska läsas av en mottagare som använder ett annat operativsystem och däremellan kanske passera en server som använder ett tredje operativsystem. Den äldsta och enklaste allmänt använda teckenuppsättningen är ASCII, som nämnts i kapitel fyra. ASCII bygger på att sju bitar används för att representera varje tecken, vilket gör att man kan representera 2 7 = 128 olika tecken. Det kanske låter som tillräckligt många med tanke på att vårt alfabet har 29 bokstäver, men dels ska det finnas utrymme för såväl versaler, gemener och siffror som kontroll- och specialtecken, dels bör man kunna skriva på olika språk med olika språks specialtecken om man ska kunna kommunicera med mänskor som inte kan svenska. Man har försökt lösa problemet med olika språks
specialtecken genom att göra lokala versioner där man bytt ut vissa ovanligare tecken i den ursprungliga US-ASCII till nationella tecken, t.ex. finns en svensk variant av ASCII där { är utbytt mot ä, } mot å och mot ö. Sådana lösningar är emellertid inte tillfredsställande; det enda rätta är att representera varje tecken med åtminstone åtta bitar, så att man kan representera 2 8 = 256 olika tecken. Trots att man inte kan lita på att alla följer standarder, finns det de facto en allmän standard för åttabitstext. Eftersom inte heller 256 tecken är tillräckligt många för att kunna skriva alla vanliga språk som finns, är standarden egentligen en familj av standarder. Den heter ISO 8859, där ISO står för International Standards Organization. Den vanligaste av ISO 8859-standarderna är ISO 8859-1, även kallad Latin 1, som omfattar språken i huvuddelen av västvärlden, däribland svenska. ISO 8859 är kompatibel med ASCII såtillvida att de 128 första tecknen är identiska i båda standarderna. ISO 8859 kan m.a.o. ses som en utökning av ASCII. Det finns också en standard för 16 bitars representation av text. Den heter Unicode, men används just inte i e-post. Unicode och ISO 8859-1 är dock identiska vad de första 256 tecknen beträffar, så Unicode kan ses som en utökning av ISO 8859-1. Eftersom RFC 822 specificerar att e-postmeddelanden ska bestå av endast ren ASCII-text och eftersom man därför inte kan vara säker på att alla servrar meddelandet ska passera klarar av att hantera åttabitstext, kan man koda om meddelandet så att det under transporten endast består av ASCII-text. Då mottagaren läser brevet, skapar mottagarens e- postprogram en avkodad version av det, och visar den för användaren, så att mottagaren ser brevet som det är tänkt att se ut. Alternativt kan den mottagande SMTP-servern automatiskt avkoda brevet. Dylik omkodning kan också behövas om avsändarens och mottagarens operativsystem eller e-postprogram använder olika teckentabeller. 8.2 Bifogade filer Trots att e-posten är ett medium för text, har de flesta använt sig av möjligheten att bifoga filer i diverse format, ss. bilder, ljud och videoklipp, med e-postmeddelanden. Hur går det här ihop? Eftersom e-postsystemet endast hanterar text, kodar avsändarens e-postprogram bilagorna till text som läggs in i själva meddelandet. Då meddelandet läses av mottagaren, avkodar mottagarens e-postprogram meddelandet så att bilagorna igen blir skilda filer av den typ de var från början. Exaktare uttryckt är det som sker vid kodningen att filinnehållet kodas om till endast vanliga ASCII-tecken. Det överlägset vanligaste systemet är att använda MIME
och kodningen Base64, vilket förklaras närmare i följande avsnitt. Ett annat system, som var det vanligaste innan MIME introducerades, är UUencoding, som dock ofta inte fungerade så automatiskt som ovan beskrivits. Ytterligare ett system är BinHex, som var det vanligaste i Macintosh-kretsar före MIME. I dagens läge finns knappast någon anledning att använda något annat än MIME, såvida man inte kommunicerar med någon som använder gamla, ovanliga program, som inte stöder MIME, men väl något av de andra två systemen. Det kan också lyckas att skicka en bilaga i binärt format precis som den är, utan att koda om den på något sätt, men det finns inga garantier för att den inte kommer att bli korrupt på vägen. 8.3 MIME MIME står för Multipurpose Internet Mail Extensions (universella tillägg för Internetpost) och är inte enbart en e-poststandard, trots att den utvecklats i detta syfte, utan helt enkelt en standard för att ange och koda innehåll. Den beskrivs i RFC 2045 2049. MIME-standarden består av tre delar: några extra e-postrubriker, en uppsättning benämningar för att ange innehållstyper och kodningssystem för att koda icke-ascii-data i ASCII-format. MIME (eller något annat påbyggnadssystem) behövs så fort något annat än ren text i formatet 7-bit ASCII ska skickas per e-post. Vi tittar först på hur MIME används för att skicka svensk text, och därefter på hur det används för att skicka bifogade filer per e-post. Ett e-postmeddelande som är i MIME-format ska åtminstone ha rubrikerna MIME-Version, Content-Type (innehållstyp) och Content-Transfer-Encoding (innehållsöverföringskodning). Användningen av versaler eller gemener i MIME-rubriker är godtycklig. Rubriken MIME-Version har alltid värdet 1.0, så den kan tyckas överflödig, men används för att visa att meddelandet är i MIME-format. Content-Type har normalt värdet text/plain; charset=iso-8859-1. Detta betyder att e-postmeddelandets innehåll är av huvudtypen text, texten är av undertypen vanlig och skriven med teckenuppsättningen ISO- 8859-1. Med den här rubriken talar vi alltså om hur texten i meddelandet ska tolkas. Såhär långt är det inga problem, men innehållsöverföringskodningen är lite mera komplicerad. De värden man oftast ger Content-Transfer-Encoding är 8bit eller Quoted-printable. 8bit innebär att man inte alls kodar texten på något sätt, utan skickar den precis som den är, inklusive å, ä, ö och andra tecken som inte ingår i 7-bit ASCII. Man lovar dock att det inte förekommer rader som är mer än 1000 tecken långa. Det här är det vanligaste systemet åtminstone i Finland. Trots att standarderna ännu inte kräver att e-postservrar ska kunna hantera åttabitsdata, kan man vara så gott som säker på att det fungerar åtminstone i
Västeuropa. Att i dagens läge ha en e-postserver som inte klarar av åttabitsdata är en försyndelse. Dessutom vet man att mottagaren inte kommer att ha några problem med att läsa meddelandet om man har skickat det som 8bit, förutsatt att servrarna på vägen har klarat av att hantera åttabitsdata. Om man däremot kodar meddelandet på något sätt, t.ex. med Quotedprintable, kan mottagaren få problem med att läsa det om hans/hennes e-postprogram inte stöder ifrågavarande kodning. Quoted-printable förkortas QP och innebär att de tecken i meddelandet som inte ingår i teckentabellen 7-bit ASCII kodas om till koder bestående av tre tecken som ingår i 7- bit ASCII. De tecken i meddelandet som så att säga är säkra, alltså ingår i 7-bit ASCII, får däremot vara precis som de är. Det här betyder att man garderar sig mot primitiva servrar som inte kan hantera åttabitsdata utan att man förvränger meddelandet alltför mycket. I praktiken går omkodningen till så att varje icke-ascii-tecken ersätts med ett likhetstecken följt av tecknets hexadecimala värde i ISO 8859-1-tabellen. Den h=e4r meningen =E4r allts=e5 kodad med QP. När man ska använda MIME för att bifoga filer, som kan vara binära, med e- post, utökas komplexiteten. Det fungerar så att e-postmeddelandet består av olika delar: en del för varje innehållselement, t.ex. en del för texten i brevet och en del för en bifogad bild. Varje dels början och slut i meddelandet markeras av en viss identifieringssträng. Samma identifieringssträng används för alla delar, så den anger endast att någon del börjar eller slutar där strängen finns. Rubriken MIME-Version: 1.0 kvarstår som förut i brevhuvudet, men rubriken Content-Type i brevhuvudet får nu ett annorlunda innehåll, eftersom det inte längre är endast text som skickas. Den kan t.ex. se ut så här: Content-Type: MULTIPART/MIXED; BOUNDARY="403593-14284-1068643714=:1108". Multipart/mixed betyder att meddelandet består av flera delar, som är oberoende av varandra. Boundary anger identifieringssträngen, som anger var delarna börjar och slutar. Den kan se ut på många olika sätt, men det som är viktigt är att samma sträng inte finns någonstans i själva data i meddelandet, alltså varken i texten eller i någon bilaga. Där meddelandets sista del slutar, används samma identifieringssträng förlängd med -- (två minustecken). Rubriken Content- Transfer-Encoding faller bort från brevhuvudet, eftersom de olika delarna kan använda olika innehållsöverföringskodningar. För att varje dels innehåll ska kunna bestämmas, måste varje del ha några egna MIME-rubriker efter den inledande identifieringssträngen. För textdelar räcker det med Content-Type och Content-Transfer-Encoding, och de har samma värden som de har i
meddelanden som endast består av text, vilket har beskrivits ovan. För bilagedelar ska ytterligare åtminstone rubriken Content-disposition anges. Den har formatet Content- Disposition: attachment; filename="enbild.gif". Efter filename står naturligtvis den bifogade filens namn, d.v.s. det namn filen har haft hos avsändaren. Som standard kommer filen även att sparas under detta namn hos mottagaren. Den här rubriken anger utöver filens namn att den ifrågavarande delen är en bilaga och därför ska behandlas som en skild fil hos mottagaren, och inte visas i själva meddelandet. Content-Type beskriver precis som vanligt innehållstypen, så dess värde varierar beroende på vad bilagan är för en fil. Det kan vara t.ex. image/jpeg eller något annat liknande. De vanligaste MIME-typerna anges nedan. Det finns dock en massa typer, framför allt undertyper, och nya kommer till då och då. Huvudtyp Undertyp Innehåll Text plain Vanlig text. html HTML-formaterad text. HTML kan användas för att variera textfärg m.m. i e-postmeddelanden, men stöds inte av alla e- postprogram. Image gif En bild i GIF-formatet. jpeg En bild i JPEG-formatet. Application msword Ett dokument i MS Word-format, godtycklig version. octet-stream Binära data i något okänt format, t.ex. en programfil. Video mpeg En videofilm i MPEG-formatet. Multipart mixed Ett meddelande som innehåller flera oberoende delar i olika format. Denna MIME-typ används för meddelanden med bilagor. alternative Ett meddelande som innehåller olika representationer av samma data, t.ex. ett meddelande med både text- och HTMLversion. För att koda binära filer används oftast kodningen Base64. Det vanligaste värdet på rubriken Content-Transfer-Encoding för en bifogad binärfil är alltså Base64. Man skulle också kunna använda Quoted-printable, men eftersom en mycket stor del av tecknen i en binärfil måste kodas om, skulle datastorleken växa enormt, eftersom QP använder tre tecken för att representera varje tecken som ska kodas om. Base64 går ut på att åttabitarstecknen grupperas tre och tre, varefter de 24 bitarna i varje tregrupp kodas om till fyra sexbitarstecken. Namnet
Base64 kommer av att man med sex bitar kan representera 2 6 = 64 olika tecken. Base64- kodade data består av högst 76 tecken långa teckenrader, som är helt obegripliga för en mänska ty de saknar helt likheter med originalet, också ifall den kodade filen ursprungligen har varit en textfil. Här följer sammanfattningsvis en lista över MIMEs innehållsöverföringskodningar (värden för Content-Transfer-Encoding): 7bit 8bit Binary Quotedprintable Base64 Text i teckenuppsättningen 7-bit ASCII, som inte är kodad på något sätt. Radlängden är dock högst 1000 tecken. Åttabitstext som inte är kodad på något sätt. Radlängden är dock högst 1000 tecken. Åttabitsdata, som inte har kodats på något sätt. Raderna kan vara hur långa som helst. Detta innehållsöverföringssystem är ovanligt, eftersom det inte är säkert att det fungerar. Data, oftast ursprungligen text, som är kodade enligt QP-systemet. Innehållet är alltså nu endast ASCII-text utan långa rader, men ska avkodas för mottagaren. Data, oftast ursprungligen binära data, som är kodade enligt Base64-systemet. Innehållet är alltså nu endast text (en delmängd av ASCII), men ska avkodas för mottagaren. Slutligen följer här ett förkortat exempel på ett e-postmeddelande som använder MIME. Vi ser att meddelandets text är skriven med teckenuppsättningen ISO-8859-1 och överförd som 8bit. Därtill har meddelandet en bilaga, som är ett Worddokument som är kodat enligt Base64-standarden. Date: Wed, 12 Nov 2003 15:28:34 +0200 (FLE, normaltid) From: Avsändaren <avsandar@abo.fi> To: Mottagaren <mottagar@sci.fi> Subject: Meddelande med bilaga MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="403593-14284-1068643714=:1108" --403593-14284-1068643714=:1108 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Detta är ett meddelande med ett Worddokument som bilaga. --403593-14284-1068643714=:1108 Content-Type: APPLICATION/msword; name="universitetsuppsats.doc"
Content-Transfer-Encoding: BASE64 Content-Disposition: attachment; filename="universitetsuppsats.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAA AA... en massa oförståelig Base64-text... //////////////////////////////////////////////////////////////////////////////////////////////////////////////8= --403593-14284-1068643714=:1108-- 9. Program som hanterar e-post Det är visserligen intressant och nyttigt att känna till allt som nämnts i kapitel 4, 6, 7 och 8, men om man skulle vara tvungen att hålla reda på allt det här och göra det för hand varje gång man ska skicka e-post, skulle få mänskor klara av att använda e-post och ännu färre skulle göra det eftersom det skulle vara så jobbigt. Därför finns det en uppsjö av olika e-postprogram (klientprogram) som tar hand om de underliggande detaljerna och låter användaren fokusera på innehållet i breven. Dessutom måste det givetvis finnas serverprogram som upprätthåller distributionssystemet. Det absolut vanligaste SMTP-serverprogrammet är Sendmail, som kan köras i alla allmänt använda Linux- och UNIX-versioner. Det har varit populärt i många år och är mycket komplext och kan därför vara invecklat att konfigurera. Ett SMTPserverprogram som används på många Windows-servrar är Microsoft Exchange Server. Vi kommer här att fokusera på klientprogram. Även om det finns många olika e-postprogram, som alla är bra på sitt sätt, finns det ett antal gemensamma funktioner som man förväntar sig att ett e-postprogram ska ha. Naturligtvis ska det gå att skicka post med SMTP-protokollet. Därtill bör det gå att hämta post på det eller de sätt man ska använda för att komma åt sin post. Det här innebär oftast POP eller IMAP, men kan även innebära att breven läses direkt ur en fil. Programmet måste också ha funktioner för att arkivera mottagna och skickade brev i någon vettig struktur och söka åtminstone i och helst även bland breven. Även om e-postadresser är lättare att komma ihåg än telefonnummer, är det ganska nödvändigt med en adressbok. För att kommunikationen ska löpa smidigt, är det dessutom ett krav att programmet hanterar MIME. Önskvärda funktioner är att programmet ska hantera både POP och IMAP, stöda filtrering, så att man kan radera skräppost automatiskt, kunna hantera flera olika e-postkonton samtidigt, automatiskt kunna lägga till en användardefinierad signatur i slutet av utgående meddelanden och vara gratis.
Pine är ett bra e-postprogram som finns både för Linux/Unix och Windows. Det är egentligen ett Unix-program, vilket syns i användargränssnittet, men när man har fått konfigureringen anpassad efter sina behov, är det smidigt och enkelt att använda. Pine är helt textbaserat, så det kan köras på en annan dator än den man sitter vid över t.ex. Telnet eller SSH. Eudora är ett mycket kompetent e-postprogram, men om man vill ha alla funktioner måste man betala för det. Det finns dock i en reklamfinansierad version med nästan alla funktioner och i en version som är helt gratis, men ändå är bra. Eudora Light, gratisversionen av Eudora, var förr ett mycket populärt e-postprogram bland Windowsanvändare. Webbläsarpaketet Netscape, som finns till många operativsystem, inkluderar ett mycket funktionellt e-postprogram, som finns på svenska och klarar flera e-postkonton. Det har utmärkt stöd för IMAP och givetvis även för POP. Andra bra e-postprogram är Microsoft Outlook Express, Microsoft Outlook, Pegasus Mail och Becky Internet Mail. 10. Andra e-postsystem Det finns och har funnits även andra system för elektronisk post än det system som är det vanliga på Internet och som är huvudtemat för denna uppsats. Nätverksoperativsystem, som framför allt används på företags lokala nätverk, har sina egna elektroniska postsystem för att skicka meddelanden mellan användarna. Dessa system kan skilja sig från det som används på Internet t.ex. genom att meddelandena omedelbart visas för mottagaren, att avsändaren automatiskt kan få bekräftelse på att mottagaren har läst brevet eller att adresseringen helt sker på basen av datornamn istället för personnamn. X.400 är en e-poststandard, som i slutet av 1980-talet verkade kunna bli den dominerande standarden för e-post i världen [Pal89]. Relationen mellan X.400 och Internets e-postsystem liknar relationen mellan OSI-nätverksmodellen och Internets arkitektur. Den sistnämnda kom till under relativt informella former, med utgångspunkt i fungerande programkod, medan OSI-modellen kom till under åratal av teoretiskt standardiseringsarbete. X.400 har dock fått större användning än OSI-nätverksmodellen, ty flera stora företag gick in för X.400. Den är en klart mera komplex e-poststandard än Internets dito, vilket tydligt framgår redan då man jämför adressformaten. En X.400-adress består av många olika element och kan t.ex. se ut på följande sätt: G=Karl S=Svensson ORG=KONCERNEN ORG- UNIT=MARKNAD PRMD=KONCERNNATET ADMD=400Net C=SE. G anger förnamn, S efternamn, ORG organisationsnamn, ORG-UNIT organisationsenhetsnamn, PRMD privat domännamn, ADMD administrativt domännamn och C landsbeteckning. X.400 har dessutom
officiella standarder för många funktioner som bara finns i vissa program eller inte alls finns i Internets e-postsystem. Sådana är möjligheten att säkerställa vem som sänt ett meddelande, skydd mot förvanskning, skydd mot obehörig läsning, bekräftelse och bevis på att mottagaren har erhållit ett meddelande och möjlighet att ange kategori, t.ex. brådskande eller privat, för ett meddelande. X.400:s säkerhetsfunktioner är dock definierade som frivilliga, vilket betyder att alla implementeringar inte behöver ha alla funktioner. 11. Säkerhet och missbruk 11.1 Säkerhet Hur säker är e-posten? Svaret är att e-posten i grunden inte på något sätt är säker, varken i fråga om säker eller oavlyssnad leverans. Meningen är att SMTP alltid antingen ska leverera posten till mottagaren eller returnera ett felmeddelande till avsändaren. Om mottagardatorn inte kan nås för tillfället, ska överföringen försöka upprepas under lång tid i jämförelse med andra nätverksprotokoll. Ett dygn är en vanlig försökstid för leverans av e-post, men även längre tider förekommer. I praktiken kan man dock inte vara helt säker på att ett meddelande man sänt har nått mottagaren därför att man inte har erhållit något felmeddelande. Ju flera datorer meddelandet ska passera, desto större är risken för att det kommer bort på vägen. För att det ska komma bort, måste dock något fel inträffa. Det finns metoder för att få automatisk bekräftelse på att meddelandet har gått fram, men de är inte alls säkra. ESMTP-standarden innehåller en möjlighet för användaren att få bekräftelse på att meddelandet levererats till den sista SMTP-servern, men dels innebär detta inte att mottagaren verkligen har fått brevet, och dels måste alla inblandade servrar stöda ESMTP för att det ska fungera. För att lösa problemet med att få bekräftelse på att mottagaren faktiskt har fått och öppnat brevet, har många e-postprogram, t.ex. Pegasus Mail, system för läskvitton, d.v.s. att mottagarens e-postprogram automatiskt, dock ibland med användarens lov, då mottagaren öppnar eller stänger brevet skickar ett e-postmeddelande till avsändaren med bekräftelse på att meddelandet har lästs av mottagaren. Det här fungerar dock endast om avsändarens och mottagarens e-postprograms system för läskvitton är kompatibla, vilket nästan alltid i praktiken innebär att de måste använda samma e-postprogram. Praktiskt går det till så att en extra rubrik, t.ex. X-Confirm-Reading-To: avsandar@adress.fi, sätts in i