Egy e-mail útja

Modul 1: Hogyan működik az e-mail · Olvasási idő: 9 perc

Tanulási cél: E lecke után Ön lépésről lépésre le tudja írni, hogyan jut el egy levél a küldőtől a címzettig, és minden lépésnél meg tudja mondani, melyik program vagy szerver végzi el a munkát.

Kulcsfogalmak: levelezőprogram (MUA), küldőszerver (MSA, submission), levelezőszerver (MTA), MX-rekord, várakozási sor, kézbesítés (MDA), postafiók, lekérés (IMAP/POP3), boríték (envelope), fejlécek

A levél olyan, mint a postai levél, nem mint egy csetüzenet

Amikor csetüzenetet küld, az egyetlen szolgáltatón keresztül megy: a küldő és a fogadó alkalmazása ugyanazokkal a szerverekkel beszél. Az e-mail másképp működik. A küldő és a címzett lehet két különböző szolgáltatónál: az egyik egy tárhelyszolgáltatónál, a másik a Gmailnél, a harmadik a Microsoft 365-nél vagy a saját vállalati szerverén. Mégis megérkezik a levél. Ez azért sikerül, mert a világ összes levelezőszervere ugyanazokat a megállapodásokat követi.

Az e-mailt érdemes a hagyományos postai levélhez hasonlítani. Megírja a levelet (az üzenetet), borítékba teszi egy címmel (a boríték, angolul envelope), beviszi a postaládához (a küldőszerver), a postai szolgáltató megállapítja, hova tartozik a cím (az MX-lekérdezés), elszállítja a levelet a megfelelő elosztóközpontba (a fogadó levelezőszerver), amely a címzett postaládájába helyezi (a postafiók). A címzett onnan veszi ki, amikor neki megfelel.

Az állomások sorban

Tegyük fel, hogy Anna levelet küld a anna@example.com címről a jan@example.net címre. Ekkor a következő történik:

Kisebb szolgáltatóknál az MSA, az MTA és az MDA gyakran egy és ugyanazon program egyetlen szerveren. Nagy szolgáltatóknál ezek külön klaszterek. Az Ön számára ez nem sokat számít: ezek szerepek, nem fizikai dobozok.

Figyeljen az 1. és a 4. lépés közötti különbségre. Mindkettő SMTP-t használ, azaz a Simple Mail Transfer Protocol-t (RFC 5321). Az 1. lépésnél azonban bejelentkezik, és az 587-es vagy 465-ös portot használja; ezt nevezik submission-nek (RFC 6409). A 4. lépésnél két szerver beszél egymással a 25-ös porton, bejelentkezés nélkül: a fogadó szerver bárkitől elfogadja a saját domainjeinek szánt levelet. A lecke 1.4-ben látni fogja, miért van ez a megkülönböztetés.

A 3. lépés közelről: az MX-lekérdezés

A küldő szerver magától nem tudja, hol fogadja az e-maileket az example.net. Ezért megkérdezi a DNS-t:

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

A legalacsonyabb szám élvez elsőbbséget. A szerver először az mx1-et próbálja, és ha az nem válaszol, akkor az mx2-t. Ezután lekéri az adott név IP-címét (A- vagy AAAA-rekord), és kapcsolatot létesít.

Két különleges esettel is találkozhat a gyakorlatban:

• Nincs MX-rekord. Ekkor a küldő a domain saját A- vagy AAAA-rekordját próbálja (az úgynevezett "implicit MX" az RFC 5321 5.1. szakaszából). Ez egy régebbi időkből megmaradt megoldás, és nem megbízható; minden levelet fogadó domainnek rendelkeznie kellene MX-rekorddal.
• Null MX: 0 . Ez azt jelenti: "ez a domain soha nem fogad e-mailt" (RFC 7505). Az example.com domainnek van ilyen rekordja. A küldő ekkor azonnal feladja, és hibaüzenetet küld vissza, ahelyett hogy napokig próbálkozna.

Az MX-rekordok és a prioritások pontos működéséről a DNS-tanfolyam 4.1. leckéjében olvashat bővebben.

A várakozási sor: az e-mailnek szabad egy kicsit késnie

Egy levél nem mindig egy másodperc alatt érkezik meg. Ha a fogadó szerver nem válaszol, vagy azt mondja: "próbálja meg később" (egy 4-es számmal kezdődő kód), akkor a levél a küldőszerver várakozási sorában marad. A szerver később újra megpróbálja, egyre hosszabb időközökkel. Az RFC 5321 (4.5.4.1. szakasz) legalább 30 perc várakozást javasol a próbálkozások között, és azt, hogy csak 4-5 nap után adja fel a szerver a próbálkozást. Sok szerver már néhány óra után küld egy figyelmeztetést ("delayed", még nem kézbesítve), majd néhány nap után a végleges hibaüzenetet.

Ez az e-mail egyik erős tulajdonsága: ha egy levelezőszerver egy órán át nem elérhető, egyetlen levél sem vész el. Ez egyben az oka annak is, hogy egy levél néha csak órákkal később érkezik meg. A 6. modulban megtanulja, hogyan ismerhető fel egy ilyen késés.

Boríték és fejlécek: két cím

Akárcsak a postai levélnél, egy e-mailnek is kétféle címe van:

• A boríték (envelope). Ezek azok a címek, amelyeket a szerverek egymás között használnak az SMTP-párbeszéd során: MAIL FROM (a feladó a hibaüzenetek számára, amely később Return-Pathként jelenik meg) és RCPT TO (a címzett). A szerverek a boríték alapján kézbesítenek.
• A fejlécek (headers). Ez az, ami magában a levélben szerepel: From:, To:, Cc:, Subject:, Date:. A levelezőprogram ezeket jeleníti meg.

Ezek a legtöbbször megegyeznek, de nem mindig. Egy BCC-címzett szerepel a borítékban, de nem szerepel a fejlécekben; ezért nem látják őt a többiek. Egy hírlevélküldő szolgáltatás a saját címét állítja be boríték-feladóként, hogy a hibaüzenetek hozzá érkezzenek, miközben a From: mezőben az Ön címe szerepel. Egy csaló pedig azt írhatja a From: mezőbe, amit csak akar.

Miért fontos ez: az SPF a boríték-feladót ellenőrzi, a felhasználó viszont a From: mezőt látja. Ezért létezik a DMARC, amely összekapcsolja ezt a kettőt (4. modul).

Hol romolhat el valami

Ezzel az áttekintéssel minden probléma esetén megkérdezheti: melyik állomásnál csúszott el valami?

• A küldés nem sikerül (azonnali hibaüzenet a programban): az 1. vagy 2. lépés. Szinte mindig beállítási probléma: port, bejelentkezés, jelszó (2. modul).
• Bounce-üzenetet kap vissza: a 4. vagy 5. lépés. A fogadó szerver elutasította a levelet, vagy a cím nem létezik (6. modul).
• A levél megérkezik, de a spam mappába kerül: az 5. lépés. A címzett nem bízik a levélben (4. és 5. modul).
• A címzett semmit sem lát, és Ön sem kap hibaüzenetet: a levél esetleg még egy várakozási sorban van, vagy a címzettnél csendben kiszűrték. Ebben az esetben a küldőszerver naplói segítenek (6. modul).
• A domainjéhez sehova nem érkezik levél: a 3. lépés. Az MX-rekordok hibásak, például egy költözés után (8. modul).

A gyakorlatban: így néz ki egy tárhelycsomagnál

A WebOké tárhelycsomagjainál csomagonként egyetlen szerver látja el az összes szerepet: a levelezőprogram erre a szerverre kézbesíti a levelet (1. és 2. lépés), a szerver küldi ki azt (3. és 4. lépés), és ez fogadja a domainjének szánt leveleket (5. lépés). A DirectAdminben az E-mail követés funkcióval üzenetenként megnézheti, hogy a levél kézbesítve lett-e. Más szolgáltatóknál hasonlóan működik; ott az ilyen funkciót gyakran "üzenetkövetés" vagy "mail log" néven hívják.

Összefoglalás

• Egy levél a levelezőprogramtól (MUA) a küldőszerveren (MSA/MTA) keresztül jut el a fogadó szerverhez (MTA/MDA), onnan pedig a címzett levelezőprogramjához.
• A programból történő küldés SMTP-submission bejelentkezéssel (587/465); a szerverek egymás között a 25-ös porton beszélnek SMTP-t; a lekérés IMAP-pal vagy POP3-mal történik.
• A küldő szerver lekéri a kukac (@) utáni domain MX-rekordjait. A null MX (0 .) azt jelenti: ez a domain nem fogad e-mailt.
• Az a levél, amely nem kézbesíthető azonnal, a várakozási sorban marad, és napokig újra megpróbálják kézbesíteni.
• A boríték (Return-Path) és a fejlécek (From) két különböző feladót jelentenek. Az SPF az elsőt nézi, a felhasználó a másodikat.

Kvíz

Feladat

Z1.1 feladat: Az első levelezőszerver megkeresése. Keresse meg a gmail.com (vagy a saját domainje) MX-rekordjait. Töltse ki, melyik szervert próbálja meg elsőként a küldő, annak prioritási számával együtt, valamint adja meg az adott szerver egy IP-címét (IPv4 vagy IPv6). A program élőben lekérdezi ugyanezeket az adatokat, és ellenőrzi azokat.

Bővebben olvasva

Az ezekben a cikkekben leírt lépések a WebOké panelekre vonatkoznak; más szolgáltatóknál hasonlóan működik.

• Az e-mailek küldési folyamata / SMTP
• DirectAdmin útmutató 8.7: IMAP vagy POP3: mi a különbség?
• Ingyenes DNS-tanfolyam 4.1: MX-rekordok és prioritás
• RFC 5321 (SMTP), 5.1. szakasz (MX és implicit MX) és 4.5.4.1. szakasz (újrapróbálkozás); RFC 7505 (null MX)