Martin.Wendel@udac.uu.se UDAC 94-09-09 Detta är en ansats till en lösning på de problem som finns vad gäller SMTP- baserad datorpost och formatinkompabilitet (teckenkodsproblem och strukturproblem mellan använda datorpostformat på SUNET). Problem och lösning Det huvudsakliga problemet är att (oftast) de svenska tecknen "å", "ä" och "ö" blir felaktigt visade på bildskärmen. Detta kan bero på två saker: 1. Avsändaren och mottagaren använder olika teckenkod (jfr Mac och PC). 2. Brevet har passerat en MTA (Mail Transfer Agent) som har förstört och/eller förändrat teckenkoden till någonting som inte passar mottagarens datorpostprogram. Det klassiska är en 8bitars tecken- kod som fått 8:e biten nollställd. Det finns flera alternativa lösningar på teckenkodsproblemet som man kan tänka sig. Nedan följer fyra lösningar. Kommentarer om vad de innebär följer längre ner. a. Avsändare och mottagare kommer överens om att en 8bitars teckenkod skall användas. b. Avsändare och mottagare kommer överens om att en 7bitars teckenkod skall användas. c. Avsändare och mottagare kommer överens om att använda sig av MIME. d. Avsändaren och mottagaren kommer överens med respektive lokala datorpostadministratör om vilken av (a), (b) eller (c) som kommer att användas. Den lokala datorpostadministratören installerar och konfigurerar konverteringsprogrammet Emil på den lokala post-servern. Avsändarens och mottagarens post-server kommunicerar sedan enligt något entydigt datorpostformat. Dagsläget är att samtliga lösningar redan existerar och används parallellt på SUNET. Detta gör ju naturligtvis att problemen kvarstår. Dessvärre så kan ovanstående också appliceras på problemet med olika kodningar av binära medskick. Samma läge gäller också där, att samtliga lösningar används parallellt. En av de tilltalande egenskaperna med (d) är att den kan användas parallellt med någon av (a), (b) eller (c) utan att för den skull ge upphov till någon förbistring i sig. Detta ger en viss frihet till de lokala administratörerna att välja mellan två alternativ. Val av lösning En lyckad lösning måste lösa både (1) och (2) med minsta möjliga arbete. Hänsyn måste tagas till att befintlig utrustning skall kunna användas utan alltför omfattande ingrepp. Nedan redovisas för- och nackdelar med de fyra lösningarna ovan. (a) Enhetlig 8bitars teckenkod. Fördelar: * Används i viss utsträckning idag på SUNET. * Klarar av att hantera ett tillfredställande antal av de vanligaste tecknen som används i skriven svenska. Löser (1). Nackdelar: * Ställer krav på 8bitars transparens i alla MTA:er, både i Sveriga och utomlands vilket gör det omöjligt att använda generellt eftersom denna transparens inte är uppnådd överallt. Bryter mot (2). * Ger upphov till "edv-syndromet" när 8bitars transparens inte uppnåtts. Bryter mot (2). * Bryter mot befintlig standard, rfc822. * Kommer i framtiden att brukas endast med ESMTP och MIME, enligt standard, och även då bli villkorsbaserad (konvertering kan bli nödvändig). * Ger ingen lösning av problemet med olika kodningsformat. Både BinHex och uuencode, två inkompatibla format, används vilket ger förbistring vad gäller val av kodning. (b) Enhetlig 7bitars teckenkod. Fördelar: * Används i stor utsträckning idag på SUNET. * Kan transporteras transparent genom de flesta MTA:er. Löser (2). * Fungerar med de svenska tecknen "å", "ä" och "ö". Löser (1). Nackdelar: * Det är ingen lösning för framtiden. Användare har tillgång till 8bitar och kräver 8bitars teckenkod. * Reducerar viktiga tecken som hakparenteser etc. från teckenkoden. * Lokal konvertering till 8bitars kod på mail-klient kan under vissa omständigheter förstöra medskick. Detta beror på att kodade medskick kan tolkas som baserade på svenska tecken när de i själva verket är baserade på US-ASCII. Problemet finns redan och måste lösas. * Ger ingen lösning av problemet med olika kodningsformat. Både BinHex och uuencode, två inkompatibla format, används vilket ger förbistring vad gäller val av kodning. (c) MIME. Fördelar: * MIME har redan börjat få fotfäste på SUNET. * Som det ser ut idag skulle ett nationellt genomförande av MIME komma tillrätta med teckenproblemen på SUNET och i kommunikationen mellan SUNET och de kommersiella IP-näten i Sverige (som får räknas som lika angelägen som kommunikationen mot utlandet). Löser (1). * MIME är en modern och internationell standard. * MIME deklarerar formatet på innehållet av brevet. Dvs svensk sjutbitars teckenkod kan entydigt skiljas från utländsk sjubitarskod. Detta ger möjlighet till en säker 7- till 8-bitars konvertering. * MIME löser problemet med kodade medskick genom att ha en definierad standard för kodningsformatet. * MIME är gjort för att vara transparent genom alla MTA:er. Löser (2). * Användningsområdet för MIME har börjat breddas att gälla mer än bara datorpost. Här kan nämnas gopher, news och www. Detta torde tyda på att livskraften hos MIME är trovärdig. * Kommersiella produkter har redan börjat understödja MIME och flera leverantörer aviserar framtida stöd för MIME. * Användarbasen ökar. Nackdelar: * Det råder fortfarande ovisshet vad gäller standardisering av vissa detaljer, dock är de viktigaste funktionerna färdigdefinierade. * MIME är till vissa delar inkompatibelt med de format på brev som används idag. Övergången måste organiseras så att den kan ske samtidigt. * MIME är till vissa delar ett tekniskt format som inte är avsett. eller lämpligt, att låta den enskilde användaren se. Det är oftast inte rekommendabelt att läsa MIME formatterade brev i en klient som inte klarar av att hantera MIME. * Användarbasen är ännu ganska liten inom landet (kräver ett stort ingrepp att få en gemensam övergång). * Användarbasen är ännu ganska liten utomlands (minoritet). (d) Emil. Fördelar: * Ger möjlighet att lokalt välja vilken av (a), (b) eller (c) som skall användas. Löser både (1) och (2) enligt lokala preferenser. * Ger möjlighet att tolka inkommande brev och anpassa dem till det lokala formatet oberoende av vilket format avsändaren använder. * Ger möjlighet till ett enhetligt uppträdande gentemot externa mottagare. Nackdelar: * Kan vara svårt att få Emil installerad på ett ganska stort antal maskiner och verkligen använt. Kräver portabel kod. * Kan vara svårt att få Emil konfigurerad rätt på dessa maskiner. Kräver enkel och "färdig" konfiguration. * Oönskad konvertering kan inträffa om användaren är omedveten om att konvertering används eller om informationen mellan användare och datorpostadministratör inte är tillfredsställande. Detta problem minskar om man lokalt väljer att använda sig av enhetligt brevformat. Detta är de viktigaste för- och nackdelarna med de fyra förslagen. Det är viktigt att det slutliga förslaget ger interoperabilitet både vad gäller svenska tecken och kodningsformat på medskick. Dessutom skall det vara enkelt att införa. * (b) vinner på enkelhet men förlorar på funktionalitet. (a) förlorar på funktionalitet och enkelhet. (c) vinner på funktionalitet men för- lorar på enkelhet. * Att låta (d), Emil, ensamt kompensera för det läge som råder nu är inte praktiskt möjligt. Det skulle kräva enorma konfigurationer med svåra koordinationsproblem. * Den lösning som återstår är då att kombinera (d) med någon av de andra lösningarna. Dvs att genomföra någon av de tre första förslagen generellt men att tillåta lokala variationer som då får kompenseras av Emil lokalt. * Emil kan inte kompensera (b) vad gäller funktionalitet eftersom begränsningen kvarstår med en 7bitars teckenkod. Emil kan inte heller kompensera (a) vad gäller enkelhet eftersom 8bitars transparens inte är uppfyllt. Däremot kan Emil underlätta (c) genom att tillåta ett lokalt val av (a) eller (b) istället. På sikt måste målsättningen ändå vara att genomföra (c) fullt ut, dvs att alla kör MIME. Under tiden bör istället en kombination av (c) och (d) införas. Detta betyder konkret att en generell övergång till MIME genom- förs. Lokalt har man då att välja på att antingen installera MIME- kompatibel programvara eller att behålla sin nuvarande programvara och istället låta Emil emulera MIME-kompatibilitet, dvs konvertera mellan MIME och det lokala formatet. Denna lösning ger möjlighet att begränsa arbetet med att installera MIME-kompatibel programvara genom att istället installera Emil. En installation av Emil kan ersätta ett större antal installationer av MIME- kompatibel programvara. Dessutom kommer konfigurationen av Emil att underlättas av att resten av SUNET kör, eller emulerar MIME. Framgångsrik lösning För att lyckas fullt ut och att uppnå full interoperabilitet måste flera åtgärder vidtagas. Åtgärderna måsta koordineras centralt och sanktioneras både centralt och lokalt. De lokala administratörerna och användarna måste få stöd genom tillhandahållande av information och programvara som krävs för genomförandet. Således måste ett åtgärdspaket skapas som innehåller flera delar: * En tillräckligt funktionell programvara, Emil version 2, utvecklas. - Den skall klara av att konvertera mellan de 5-10 vanligaste teckenkoderna (ISO 646-SE, ISO 8859-1, CP437, CP850, etc). Förslag: Kod som gör detta finns redan. - Den skall kunna ändra kodning av data mellan åtminstone Base64, BinHex, Quoted-Printable och Uuencode. Förslag: Kod som gör detta finns redan. - Den skall kunna konvertera header-informationen anpassat efter olika brevformat (till/från MIME etc). Detta gäller också 8bitars tecken i brevhuvudet. Förslag: Kod som gör detta finns (ej 8bitars brevhuvud), men mer generell och funktionell kod bör utvecklas. - Brevstruktur bör kunna konverteras. Detta gäller tex konvertering mellan AppleSingle/AppleDouble och BinHex eller konvertering till eller från nästlad Multipart-struktur i MIME. Förslag: Detta bör implementeras. - Viss användarstyrning måste tillåtas. Avsändaren bör kunna styra vilken typ av konvertering som skall utföras. Förslag: Tidigare på nordpost-maillistan har diskuterats att genomföra detta genom att ett nyckelord på Subject-raden anges. Detta bör implementeras. - Emil bör designas som ett fristående filter som kan användas till- sammans med en MTA. * Emil måste installeras på ett förmodligen ganska stort antal maskiner. - Informationen måste komma ut till de lokala administratörerna. Förslag: Sprid informationen på så många sätt som möjligt. Skapa en maillista och eventuellt news-grupp. Lägg upp informationen i gopher och WWW. - Koden skall vara portabel och anpassad till flera olika typer av system. Förslag: Någorlunda modern UNIX och sendmail eller annan MTA (smail?, PP?) som hanterar externa mailer-program. Det skall vara möjligt att använda sig av befintlig sendmail och att slippa kompilera en ny version. - Koden skall vara enkel att installera och konfigurationen skall vara överskådlig och enkel. Förslag: Frilägg Emil från sendmail och använd Emil som återkopplad back-end mailer. Förslag till filtermöjlighet i sendmail8 finns (Dan Oscarsson) och om det genomförs försvinner behovet av återkoppling i sendmail8. Frilägg Emil från TCL och lägg till intern interpretator istället. Skapa enkel tabellbaserad konfigurering. - Färdigkompilerade kopior måste tillhandahållas. Ett interaktivt installationsprogram bör tillhandahållas, för att underlätta för de som inte är vana att installera C-kod. Utförandet av detta program bör likna de terminalbaserade som används för kommersiella program- varor (detta kan eventuellt ersätta behovet av färdigkompilerade kopior genom att vara tillräckligt enkelt och generellt). - Emil skall vara konfigurerad att kunna hantera de vanligaste brev- formaten som används på SUNET idag. Den slutliga konfigurationen, att utföras av den lokala administratören, skall istället bestå i att koppla ihop lokala maskiner/användare med rätt brevformat i någon form av tabell. * De maskiner som inte kommer att få MIME installerat och som inte heller kommer att köra Emil lokalt, måste routa all utgående post vi någon lokal maskin som kör Emil. Inkommande post måste styras till maskinen som kör Emil via MX-records i nameservern. På detta sätt kommer maskinen som kör Emil att fungera som en gateway som konverterar till/från MIME. * Servrar som utför "conversion on demand" måste sättas upp. * Programvara (klienter) som understödjer MIME måste tillhandahållas till de vanligare systemen. - Frivara för Mac, DOS, WINDOWS, AMIGA, NeXT, VMS, VM/CMS och UNIX finns redan. Vissa kommersiella produkter finns också. Förslag: Kartläggning över befintliga programvaror bör genomföras. En sådan är redan bifogad i comp.mail.mime FAQ. * Information om åtgärderna sprids över Internet, dels för att meddela förändringen, dels för att genom att vara föregångare om möjligt påverka andra att göra samma sak. Slutsats Genomförandet av detta förslag skulle lösa de problem med svenska tecken som finns idag på SUNET. Samtidigt skulle den oundvikliga framtida över- gången till MIME bli avklarad på ett ordnat sätt. Eventuellt skulle ett sådant genomförande kunna påverka omvärlden att följa efter enligt liknande mönster. -- E-Mail: Martin.Wendel@UDAC.UU.SE Snail-Mail: UDAC Tel: 018 18 77 80 Box 174 Int: +46 18 18 77 80 S-751 04 Uppsala Fax: +46 18 51 66 00 Sweden