ugrás a tartalomhoz

Emailek felépítése – lépésről lépésre I.

Hodicska Gergely · 2005. Feb. 16. (Sze), 13.00
Emailek felépítése – lépésről lépésre I.
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.

Fontos látnunk, hogy egy dolog a szabvány és más dolog annak betartása. Sajnos sok olyan alkalmazás létezik, melyek nem teljesen kompatibilisek vele. Ezért előfordulhat, hogy mi hiába annak megfelelően járunk el, és a kapott eredmény teljesen konform azzal, az üzenetet fogadó felhasználónak mégsem jól jeleni meg. Ezért lehetőleg figyelnünk kell arra, hogy a szabványosság határain belül is, minél hibatűrőbb megoldást használjunk.

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.
 
Date: Sun,  6 Feb 2005 01:01:30 +0100
From: Hodicska Gergely <felho##kukac##felho.hu>
To: Hodicska Gergely <felho##kukac##felho.hu>
Subject: skizofren level

Ezt akkor most ki küldi kinek?
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:
telnet mail.axelero.hu 25
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:
 220 fe04.axelero.hu ESMTP Sendmail rulez @ Axelero Internet; Tue, 9 Nov 2004 13:57:12 GMT 
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.

->HELO felho.hu
<-250 fe04.axelero.hu Hello 218.45-182-adsl-pool.axelero.hu [81.182.45.218], pleased to meet you
->MAIL FROM: felho##kukac##felho.hu
<-250 2.1.0 felho##kukac##felho.hu... Sender ok
->RCPT TO: felho##kukac##felho.hu
<-250 2.1.5 felho##kukac##felho.hu... Recipient ok
->DATA
<-354 Enter mail, end with ″.″ on a line by itself
->Date: Sun,  6 Feb 2005 01:01:30 +0100
->From: Hodicska Gergely <felho##kukac##felho.hu>
->To: Hodicska Gergely <felho##kukac##felho.hu>
->Subject: skizofren level
->
->Ezt akkor most ki küldi kinek?
->.
<-250 2.0.0 iA9Jb8x6005803 Message accepted for delivery

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

Címlista felépítése

A címlista vesszővel elválasztott címzettek, vagy csoportok listája.
A címzettek általános alakja: nev <cim>. De megengedett az a forma is, hogy csak a cim szerepel kacsacsőrök nélkül. Sőt ha nincs nev, akkor ajánlottabb is ezt a formát alkalmazni, ugyanis némely levelező nem kezeli jól, ha a kacsacsőrös cim előtt nincs nev. Egy dolog lehet még érdekes, létezik egy USENET standard szerinti megadási forma is: cim (nev) , tehát a nevet megjegyzésként teszik a cím mögé. Elvileg ezeket a megjegyzéseket figyelmen kívül kell hagyjuk, de például ebben az esetben érdekes lehet, ha ezt a formát is értelmezni tudjuk.
A csoportok megadásának formája: csoprtnev: cimzett1, cimzett2;
  • 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.
 
1

RFC linkek

gerzson · 2005. Feb. 16. (Sze), 13.42
Nagyon jó és hasznos lenne, ha a felsorolt RFC-kre linkek mutatnának, így rögtön bele is tudnánk nézni! Kérlek, tegyétek ezt meg! Itt van néhány nagyobb gyűjtemény elérhetősége addig is:
2

Ki akarná elolvasni?

sajt · 2005. Feb. 16. (Sze), 13.46
Amikor itt van ez a hiper-szuper leírás :)
3

Done

Hodicska Gergely · 2005. Feb. 16. (Sze), 14.27
Szia!

Csak idő hiányában maradtak le (kis csúszásban voltam ;)).
Amugy 822-es RFC-t nem igazán érdemes átolvasni, mert azt szinte teljes egészében felváltotta a 2822-es.

Kicsit csodálkozom amúgy, hogy ezek az információk ennyire struktúrálatlanul vannak ott felhalmozva. Jo lenne néha, he lenne valami táblázat arról, hogy az egymással összefüggésben lévő RFC-k között mi a kapcsolat. Néha sokat kell bogarászni. Amugy pl. itt legalabb HTML formában találhatóak meg:
http://www.cse.ohio-state.edu/cs/Services/rfc/index.html

Ha lesz még egy kis időm, lehet, hogy a megfelelő részekre belinkelem az RFC megfelelő részeit.


Felho
4

Az nagyon jó lenne, ha egy k

gerzson · 2005. Feb. 16. (Sze), 16.26
Az nagyon jó lenne, ha konkrét részekhez is lenne RFC hivatkozás. Valahol már láttam a neten linkekkel teleaggatott RFC könyvtárakat, de azt a linket pont nem találtam meg. :(
5

Már régota keresek egy ilye

jf · 2005. Feb. 16. (Sze), 23.37
Már régota keresek egy ilyen leírást. Köszönöm, és várom a folytatást.
6

Levelezni kell

PAStheLoD · 2005. Feb. 17. (Cs), 13.06
Eddig is többnyire kézzel fabrikáltam a leveleimet, de általában majd csak el tudja olvasni valaki alapon, mert nem volt túl sok kedvem átrágni magam az RFC-ken ,de most itt a száraz tartalom kicsit felhigítva .. ráadásul magyarul :)) Köszönet és Grat!
7

Gratula

fmagnucz · 2005. Feb. 17. (Cs), 23.51
Ez egy nagyon kis szuper leírás. Nagy várakozással várom a folytatást.
Gratula a cikkhez.
8

Fejlécek...

Anonymous · 2005. Feb. 18. (P), 07.13
Hali!

Én eddig úgy tudtam, hogy a "From:" a küldő e-mail címe. A cikkben a fejlécek leírásánál "Címzettek"-ként szerepel...

# From: ez a másik kötelező fejléc, melyben címzettek listáját (csoportot nem) adhatunk meg.
# Sender: ha a From fejlécben több címzett is szerepel, akkor ennek megadása kötelező, és csak egy darab címzett tartalmazhat.


Üdv!
Fly
11

5 pont

Hodicska Gergely · 2005. Feb. 18. (P), 22.23
Bakker, pedig átolvastam. Koszi, hogy szóltál (mindig is tudtam, hogy a word helyesírás ellenőrzője nem tökéletes - főleg éjszaka).


Felho
12

miért nincs kint a szerző mail címe?

Anonymous · 2005. Feb. 19. (Szo), 22.31
Akkor ide írok két megjegyzést:
A cikk elején az első kiemelt szövegben:
mégsem jól jeleni meg
helyette:
mégsem jól jelenik meg


Content-Transfer-Encoding vastag betűs felsorolásnál a base64-et külön kéne venni ui., az kimondottan 6 bites kódolás. (2^6=64)
A sötét és távoli múltban magam is írtam base 64 algoritumst, csak onnan tudom.

A Return-Path szerepét kicsit jobban ki lehetett volna hagsúlyozni. Az általam üzemeltetett web szervereken pl. az smtp port közvetlenül nem elérhető belülről sem, s csak a php mail függvény használható levélküldésre. A php viszont suExec-cel fut; így az MTA rábiggyeszti minden php-ból küldött levélre a Return-Path -ba a usernev##kukac##servernev.et . Így a visszadobott levelek is jóhelyre mennek és ninics vita, hogy vajon ki küldözgeti ezrével a leveleket.

Szép cikk.
13

Nincs email cím

Hojtsy Gábor · 2005. Feb. 19. (Szo), 22.53
Nem az a célunk, hogy a szerző és az olvasók között személyes diskurzus alakuljon ki, hanem hogy a közösség profitáljon a jó ötletekből, javaslatokból. Tervezünk közvetlen kapcsolatfelvételi lehetőséget a szerzőkkel a jövőben különben.

A szakmai javaslatokat Felhő minden bizonnyal megfontolja majd, és reagál.
14

Megkésve, de ... ;-)

Hodicska Gergely · 2005. Feb. 25. (P), 15.51
Szia!

Ne haragudj, hogy csak most írok. Hétvégén nem voltam, hét eleje húzós volt, aztán már kicsit megfeledkeztem róla.

Content-Transfer-Encoding vastag betűs felsorolásnál a base64-et külön kéne venni ui., az kimondottan 6 bites kódolás. (2^6=64)

Olyan nincs, hogy 6 bites kódolás. Mindegyik esetben 8 bites "octet"-ek formájában van jelen az adat. Az már más dolog, hogy a különböző esetekben ez a reprezentáció mit is jelent. A 7 bit sem 7 bites "kódolást" jelent, hanem azt, hogy az adott adat csak az US-ASCII kódtáblában szereplő karaketereket tartalmaz.

A Return-Path szerepét kicsit jobban ki lehetett volna hagsúlyozni.

Sajnos valahol meg kellett húzni a határt, meg a következő részekre is kell tartogatni valamit ;-). Viszont szép az említett példa, köszönjük.

Jöhetnek egyéb hasznos, trükkös felhasználási lehetőségek is. Ne feledjétek, hogy a cikkek esetén mindig kimondatlan célunk egyfajta párbeszéd, együttgondolkodás gerjesztése.


Felhő
9

Grats

fly · 2005. Feb. 18. (P), 07.16
Jah, egyébként gratula, mert tényleg jó! :)
Kiváncsi vagyok az újabb részre!
10

Elméleti alapozás = remek!

Dualon · 2005. Feb. 18. (P), 12.18
Nagyon jónak tartom, hogy - már többedjére látom ezt weblaboros cikknél - némi "elméleti alapozásra" (ezúttal szintúgy "történelmi áttekintésre") is sor kerül, nem csak felcsermódra tapasztalati tényeket kapunk.
Kiváló a cikk, így tovább!
15

Javítás

presidento · 2005. Már. 11. (P), 11.57
A címlista felépítésénél nem csoportnév akart volna lenni?
,,A csoportok megadásának formája: csoprtnev: cimzett1, cimzett2;''

<fM />
FARKAS Máté
16

király...

Abdul · 2005. Ápr. 7. (Cs), 10.02
Hali

Ténlyeg frankó a cikk, és várom is a folytatást...
Ami már jöhetne... :-)

Esetleg amit hiányolok, egy-egy példa (apro) megjelenítse...
Mondjuk amikor a To; Cc; Bcc-t mutattad be, hogy emigyen lehet ezt elképzelni:
-=* és akkor itt lene a példa *=-
Aztán mindenki beépiti a maga kis nyelvkörnyezetébe..


A.
(Az élet olyan mint egy cigaretta.......mindig megszívjuk....)
17

multipart

Anonymous · 2005. Ápr. 12. (K), 14.49
Köszönöm én is, nagyon várom a folytatást, különösen a multipart használata, vagyis a html és txt tartalom egy levélben érdekelne.
Patics
18

folyt.köv.

wiktor · 2005. Aug. 21. (V), 23.03
Hol is van az a folytatás? :)