Weblabor

Webes alkalmazások készítése során gyakran előforduló feladat, hogy elektronikus leveleket készítsünk és küldjünk ki. Ilyenkor nem esünk kétségbe, mert remek eszközök állnak rendelkezésünkre ennek megvalósítására (pl. PHPMailer, PEAR::Mail_Mime), de ettől függetlenül nem árt tisztában lennünk azzal, hogy hogyan is épül fel egy email. Ezúttal erről lesz szó, a cikk elolvasása után akár kézzel is képesek leszünk összeállítani és elküldeni akár egy csatolmányokkal rendelkező levelet.

RFC-k

Az emailek felépítését különböző RFC-k (Request for Comments) definiálják. Az RFC dokumentumok az IETF (Internet Engineering Task Force) által kibocsátott tervezetek, javaslatok és szabványok, mely szervezet felelős az Internet működésének felügyelésére ill. az azon használt standard protokollok és formátumok kidolgozásáért, koordinálásáért. Minden egyes RFC rendelkezik egy számmal. Számunkra a legfontosabbak:

• a 822-es az alap email specifikáció, melynek korszerűsített verziója a 2822. Egy ezen dokumentumnak megfelelő levél azonban csak 7 bites US-ASCII karakterekből álló, egyszerű szöveget tartalmazó üzenet továbbítására képes.
  
• Ezt a korlátot oldja fel a MIME (Multipurpose Internet Mail Extensions) specifikáció, melyet a 2045, 2046, 2047, 2048 és a 2049 RFC-k definiálnak, és mely lehetővé teszi számunkra:
  - 7 bites US-ASCII karakterektől eltérő karakterkódolású
  - különböző (bővíthető) nem karakteres tartalmú
  – több részből álló
  – 7 bites US-ASCII karakterektől eltérő karaktereket tartalmazó fejlécekkel bíró üzenetek továbbítást.
  
• Ezeken kívül még számos ebben a témában fontos RFC létezik, például van amelyik a levelek tikosítását, digitális aláírását teszi lehetővé, vagy pl. fontos üzenet fejléceket definiál, de van aminek elolvasása csak azért fontos, hogy a többi RFC-ben használt formalizmust, jelölésrendszert illetve szóhasználatot képesek legyünk megérteni.
  

Üzenetek felépítése

Minden levél sorokból áll, melyek végét egy CRLF szekvencia jelzi, mely a 13-as kódú kocsivissza illetve a 10-es kódú soremelés karakterekből áll. Ezek két csoportban helyezkednek el: fejlécek és az üzenet törzs, melyeket egy üres sor választ el egymástól.

A sorok maximális hossza 998 (+CRLF) karakter. Ennek oka, hogy az emailek generálását, továbbítását és feldolgozását végző eszközök között rengeteg olyan van, ami csak ezt a hosszt támogatja (az SMTP (Simple Mail Transfer Protocol) protokollnak megfelelően). A sorok ajánlott hossza azonban 78 (+CRLF) karakter.


Fejléc felépítése: FejlecNev:FejLecTorzsCRLF. A fejléc törzs csak nyomtatható US-ASCII karaktereket tartalmazhat, ezek a 33-126 közötti kódúak. Kivételt képez a ’:’. A fejléceket lehetőségünk van több sorba tördelni (″folding″): ehhez az első sort követő sorokat szóköz vagy tabulátor karakterrel kell kezdenünk. Feldolgozáskor ezek eltávolításra kell kerüljenek (″unfolding″). A fejlécben megjegyzés is szerepelhet ’()’ jelek között. A megjegyzésben lévő speciális karaktereket (’(’, ’)’, ’\’) meg kell védenünk egy ’\’ jellel. A ’:’ előtt nem szerepelhet szóköz, de a 822-es RFC szerint még lehetett, ezért ha email feldolgozót készítünk, inkább engedjük meg. A ’:’ után nem kötelező.

Az üzenet törzse tetszőleges karaktereket tartalmazhat, illetve itt is érvényes, amit a sorok hosszáról a teljes üzenettel kapcsolatban elmondtunk. Ezenkívül egyetlen megszorítás van még, hogy a CR és LF karakterek csak együtt és CRLF szekvenciaként szerepelhetnek.

Egy teszt üzenet

Ennyi bevezetés után következzen egy Hello World jelegű példa levél. Ebben négy fejléc szerepel: az üzenet dátuma, feladója, címzettje és tárgya, valamint az üzenet szövege.

Üzenet elküldése

Levél küldésre PHP alatt a legegyszerűbb mód a mail parancs használata. Most nézzük, hogy hogy is tudnánk a levelünket közvetlenül egy SMTP szerverhez kapcsolódva elküldeni. Ehhez szükségünk lesz egy parancssorra illetve például a telnet programra. Gépeljük be a következő parancsot:A legtöbb SMTP szerver nem engedélyezi tetszőleges IP címről email küldését, ezért tudjuk meg saját Internet szolgáltatónk SMTP szerverének címét. Általában ez a 25-ös porton fut. A szerver válasza valami hasonló lesz:Illetve egy konzolt kapunk, melyben parancsokat adhatunk az SMTP szervernek. Például a következő párbeszéd folyhat le. A -> jelzi az általunk begépel sorokat, míg a <- a szerver válaszait.


Először is beköszönünk, mire udvarias választ kapunk :-). Ezt követően jelezzük, hogy szeretnénk egy levelet küldeni, majd megadjuk a címzettet is. Ha eddig minden jól ment (a szerver 250-es kóddal válaszolt), akkor ezután kiadjuk a DATA parancsot, majd jöhet a fentebb összeállított üzenet. Az adatok végét egy 1 darab pontot tartalmazó sorral jelezzük. Emiatt figyelnünk kell arra, hogy ha van a levélnek olyan sora, melyben csak egy darab pont van, akkor azt meg kell védeni, melynek módja, hogy két pontot írunk helyette.

Ezzel a módszerrel tetszőleges emailt el tudunk küldeni, csak előtte a levelet megfelelően fel kell építeni. És ezt a kommunikációt akár programból is el tudjuk játszani socket kezelő függvények segítségével.

Üzenet fejlécek

Összesen két kötelező fejléc van: a Date és a From. A Date azt a dátumot kell tartalmazza, amikor a feladó kezdeményezte a levél küldését és az bekerült az üzenetküldési listába, nem pedig amikor ténylegesen elküldésre kerül. A fejléc tartalmának formátuma szabvány szerint definiált, a PHP date függvénye szerencsére támogatja ezt, és az ″r″ formázó használatával az ennek megfelelő formában kapjuk vissza dátumunkat.

Feladót azonosító fejlécek

• From: ez a másik kötelező fejléc, melyben a küldők listáját (csoportot nem) adhatunk meg.
  
• Sender: ha a From fejlécben több cím is szerepel, akkor ennek megadása kötelező, és csak egy darab címet tartalmazhat.
  
• Reply-To: ebben a fejlécben jelzi a feladó, hogy a válasz email milyen cím(ek)re menjen. Itt egy címlistát adhatunk meg.

Címzett fejlécek

Háromféle fejlécet használhatunk a címzett(ek) kijelölésére: To, Cc, Bcc. Mindhárom esetén címlistát adhatunk meg. A To fejléc tartalmazza az üzenet elsődleges címzettjét. A Cc (carbon copy - indigómásolat) fejlécbe kerülnek azok, akik másolatot kapnak az üzenetről, tehát az nem nekik szól, de tudniuk kell róla. A Bcc (blind carbon copy - titkos indigómásolat) azokat a címzetteket tartalmazza, akik nem jelenhetnek meg a többi címzett számára.

Levelet azonosító fejlécek

Ezek közül három igazán fontos van számunkra.

• Message-ID: ez azonosítja az adott levelet, ezért minden a levél esetén egyedülálló kell legyen. Ha ugyanazt az üzenetet többször elküldjük, akkor különböző kell legyen ez a fejléc az egyes üzenetek esetén.
  
• In-Reply-To és References: Ezeknek a fejléceknek akkor van jelentőségük, ha válaszolunk egy levélre. Azt az információt hordozzák, hogy melyik levélre is válaszoltunk, akár több lépcsőn keresztül is. Elvileg az In-Reply-To célja, hogy azt a levelet azonosítsa, amelyre a válasz történt, míg a References-é a szál megőrzése, de ezek használata implementáció függő, az RFC csak ajánlást tartalmaz.
  

Nyomkövetéssel kapcsolatos fejlécek

Ezek a fejlécek a levél kézbesítésének menete során kapnak szerepet.

• Return-Path: elsődleges célja egy olyan címzett kijelölése, ahová értesítést lehet küldeni a sikertelen kézbesítésről, vagy egyéb a küldés során fellépő hibákról. Ez nem feltétlenül kell megegyezzen a levél küldőjével.
  
• Received: amikor egy levelet elküldünk valakinek, akkor az nem közvetlenül a mi számítógépünktől jut el a címzettéig, hanem ez a folyamat általában több lépcsőből áll. Például a mi gépünktől először az SMTP szervert futtató számítógéphez kerül, majd onnan (akár sok köztes lépcsőfokon keresztül) a címzett által használt mail szerverig, majd csak onnan az ő számítógépére. Minden egyes ilyen lépcsőfok egy ilyen Received fejlécet ragaszt a levélhez, így ezek segítségével nyomon követhetjük a kézbesítés folyamatát. Rendkívül hasznosak lehetnek például SPAM emailek kiszűrésére is.

Subject

Ki ne hagyjuk :-). Ebben a fejlécben adhatjuk meg a levél tárgyát.

MIME specifikáció

A 2822-es RFC által definiált 7bites korlát komoly akadály volt az emailek használhatósága szempontjából. Ezt a problémát szüntette meg a MIME specifikáció. Ráadásul elég ötletes módon, ugyanis a megoldás kompatibilis a 2822-es RFC-ben definiáltakkal. A megoldás lényege, hogy néhány új fejlécet definiál, melyek segítségével lehetőségünk van összetett üzenetek összeállítására tetszőleges karakterkészlet használatával.

Vegyük is szépen sorra ezeket, de még előtte szeretném kiemelni, hogy egy MIME email esetén már nem csak egy levél törzs van, hanem az üzenet több részből állhat, mindegyik rendelkezik saját fejlécekkel, mely leírja az adott tartalmat, illetve ezek tetszőleges mélységben egymásba ágyazhatóak fastruktúra szerűen.

MIME-Version fejléc

Ezen fejléc használatával jelezhetjük az email feldolgozó alkalmazásunk számára, hogy MIME üzenettel van dolga. Bár a szabvány kompatibilis az 2822-es RFC-vel, de egy MIME értő alkalmazás bizonyos esetekben másképp dolgozhat fel egy emailt, mint egy azt nem értő kliens, ezért fontos, hogy jelezzük, hogy az üzenetünk ezen specifikációnak megfelelően született. Jelenleg csak ebben a formában szerepelhet: MIME-Version: 1.0
De a jövőben előfordulhat, hogy ez is további kiegészítéseket vezetnek majd be.

Content-Type fejléc

Nyugodtan kijelenthetjük, hogy a specifikáció lelke. Ezen fejléc használatával írhatjuk le, hogy az üzenet adott része milyen adatokat is tartalmaz. Minden fejléc tartalmaz egy típust, egy altípust perjellel elválasztva, illetve esetleges paramétereket pontos vesszővel elválasztva. Például a
Content-Type: text/html; charset=″iso-8859-2″
fejléccel jelezzük, hogy az adott rész egy HTML dokumentum, melynek a LATIN2 karakterkódolást használja.

A szabvány 7 úgynevezett top-level típust definiál, de lehetőséget biztosít újabbak regisztrálására is. Ezek:

• text: alapvetően szöveges tartalmak küldésére használatos. A charset paraméter határozza meg, hogy a szöveg milyen kódolással készült. A különböző altípusok jelzik pedig, hogy a kliens program mit kezdjen az adott tartalommal. Például lehet plain (sima szöveg), HTML, RichText vagy bármi egyéb. A nem ismert altípusú tartalmakat plain textként kell kezelni.
  
• image: ezzel jelezhetjük, hogy az adott tartalom egy kép. Nem ismert altípus esetén ″application/octet-stream″-ként kell kezelni.
  
• audio: ugyanaz mint az előző, csak hang fájlok esetére.
  
• video: ugyanaz mint az előző, csak videó fájlok esetére
  
• application: olyan adatok esetén használatos, melyek nem férnek be az előző csoportok valamelyikébe, ráadásul melyeket kifejezetten egy adott programmal való feldolgozásra szánunk. Például így jelölhetünk meg Excel, Word dokumentumokat. Az octet-stream altípust használhatjuk, ha nincs más megfelelő, vagy jelezni szeretnénk, hogy az adott tartalom bináris adat.
  
• multipart: ez az egyik úgynevezett összetett típus. Használatával lehetőségünk van jelezni, hogy az adott üzenet rész több, elkülönülő részből áll, melyek egymástól egy határoló karaktersorozattal vannak elválasztva, és melyet a típus boundary paraméterében határozunk meg. A fontosabb altípusok:
  - mixed: az egyes részek egymástól teljesen függetlenek. Például egy lével szövege és egy hozzá csatolt dokumentum.
  - alternative: az egyes részek ugyanazt a tartalmat hordozzák, csak más formában, és általában definiált közöttük egyfajta rangsor (pl. HTML ″erősebb″ mint a sima szöveg). Ilyenkor a feldolgozó program feladata, hogy a számára még értelmezhető részek közül a megfelelőt ″jelenítse″ meg. Például általánosan bevett szokás, hogy a HTML levelekben elhelyezik ugyanazt a tartalmat szöveges formában is, így HTML-t megjeleníteni nem képes klienssel is olvasható marad az üzenet. Vagy például egy hangfájl mellé elhelyezhetjük annak szöveges tartalmát.
  - related: akkor használatos, ha hivatkozni szeretnénk az egyes részek között. Például elhelyezhetünk ″inline″ képeket a levélben, majd a HTML kódban ezekre hivatkozni tudunk. Külső hivatkozások esetén ugye a képek letöltése általában nem engedélyezett, de ezen módszer használatával levelünk szépen megjelenik ilyenkor is.
  
• message: ez a másik összetett típus, alkalmazásával teljes leveleket helyezhetünk el egy üzenet részben. Ez történik, ha például csatolva továbbítunk egy levelet. Ezenkívül van még pár trükköz alkalmazási lehetősége. Elérhetjük például, hogy egy adott (nagy méretű) csatolmányt több levélként tudjunk elküldeni, vagy pl. egy ugyancsak nagyméretű csatolmány ne kerüljön elküldésre, csak ha a felhasználó a levél fogadása után ezt külön kéri, stb..
  
• Ezenkívül a szabvány lehetővé teszi a rendszer bővítését. Erről a 2048-as RFC-ben olvashatunk bővebben (nem egy krimi ;)).
  
• És még ezentúl lehetőségünk van nem szabványos fejlécek bevezetésére. Ezek neve X- karakterekkel kell kezdődjön. Ezek közül néhány manapság már de facto szabványnak számít, tehát körültekintően válasszunk nevet, ha ilyesmit szeretnénk használni.

Content-Transfer-Encoding fejléc

Ebben a fejlécben adhatjuk meg, hogy az adott tartalom milyen formában van kódolva. Mivel az 2822-es RFC szerint csak 7 bites US-ASCII karakterek továbbíthatóak (ráadásul még a sorhossz limitünk is van), ezért valamilyen módon biztosítanunk kell, hogy az ezeknek a feltételeknek nem megfelelő tartalmakat is át tudjuk passzírozni a rendszeren.
A fejléc tartalma a következők valamelyike lehet jelenleg:

• 7bit: csak 7 bites karaktereket tartalmaz.
  
• 8bit: 8 bites karaktereket is tartalmaz.
  
• binary: bináris adatot tartalmaz.
  
• quoted-printable, base64: a MIME által bevezetett transzformációk, melyek segítségével nem 7bit tartalmakat tudunk 7bites tartalommá konvertálni.

Jelenleg a 8 bites és bináris tartalmak szállítására nincs standard forma, ezért használatukkal kockáztatjuk, hogy az üzenet nem jut el eredeti formájában a címzetthez.

quoted printable

A 7 bites karaktereket békén hagyja, a 8 bites karaktereket pedig lecseréli egy egyenlőség jelre, melyet a karakter kódja követ egy kétszámjegyű hexadecimális szám formájában. A kódolás egyik előnye, hogy a 7 bites karaktereket békén hagyja, ezért a szöveg kódolás után is viszonylag olvasható marad, ha eredetileg kevés nem ilyen karaktert tartalmazott, plusz ilyen esetben a kódolt szöveg mérete sem nagyon haladja meg az eredeti méretet. Ellenkező esetben viszont lényegesen nőhet a méret, és az olvashatóság előnye is elvész. Ráadásul ennek fontossága ma már lényegesen csökkent, ugyanis szinte minden levelező program MIME kompatibilis.

base64

Az eredeti tartalom 3 egymást követő byte-ját összefogjuk, majd az így kapott 24 bitet 4 darab 6 bites részre osztjuk. Minden így kapott szám egy 64 elemet tartalmazó táblázat egy elemének mutatója lesz, és az üzenetben a helyére ezen karakter kerül. Ezek a karakterek úgy vannak összeválogatva, hogy mindegyik kódtáblában szerepeljenek, és a bármilyen mail szállítmányozó rendszeren képesek legyenek gond nélkül áthaladni. Ezen kódolás alkalmazásával a kódolt méret az eredeti 4/3-a lesz, tehát egy 33%-os növekedéssel kell számolnunk. A kapott szöveget úgy kell tördelni, hogy a sorok maximális hossza 76 legyen.

Content-ID fejléc

Használatával az adott részhez egy azonosítót tudunk rendelni, és például ezzel tudunk rá hivatkozni az üzenet más részeiből. A multipart/related típusú üzeneteknél lesz jelentősége.

Content-Description fejléc

Használatával az adott részhez egy leíró jellegű szöveget rendelhetünk hozzá, például egy kép esetén hasznos lehet a kép leírását elhelyezni egy ilyen fejlécben.


A következő részben részletesebben szó lesz MIME üzenetek szintén szigorúan csak ″kézzel″ történő összeállítására. Részletesebben szólunk majd az egyes kódolásokról, azok helyes megvalósításáról, illetve több példát is nézünk összetett üzenetek összeállítására.