Vegyünk egyetlen üzenetet. Egy kitalált bolt, a Bright Parcel, éppen most kapott egy látogatót, aki a quietfox42@veylax.com címmel regisztrált, és a rendszere megnyomja a Küldés megfelelőjét egy megerősítő e-mailen. Kicsivel később az üzenet a látogató képernyőjén van, egy nappal utána pedig sehol sem létezik már a postaláda-szolgáltatásnál. Ez a cikk végigköveti az egész útját.
Szóval hogyan működik a temp mail? A szokásos internetes levelezési gépezetet használja egy csavarral: a fogadó oldal a domainjein bármilyen felhasználónévre elfogad levelet, és csak rövid ideig tartja meg. A feladó szervere megkeresi a domain MX-rekordját a DNS-ben, SMTP-n keresztül a 25-ös porton csatlakozik a megadott géphez, és kézbesíti az üzenetet. A temp mail rendszer ezután feldolgozza, megjeleníti egy postaládában, és ütemezetten törli. A VookMailen a domainek MX-rekordjai egy levélkézbesítő szolgáltatóra mutatnak, amely fogadja az SMTP-munkamenetet, és minden üzenetet HTTPS-en továbbít a VookMailnek.
1. szakasz: Elhagyja a feladót
A Bright Parcel alkalmazása összeállítja az üzenetet. Az üzenet strukturált szöveg, amelyet az Internet Message Format (RFC 5322) szerint raknak össze: fejlécek, például From, To és Subject, aztán egy üres sor, aztán a törzs. Az alkalmazás általában nem közvetlenül kézbesíti. Átadja egy kimenő levelezési szolgáltatásnak, vagy hitelesített SMTP-kapcsolaton a 587-es porton (illetve a 465-ösön, amelynél a TLS az elejétől él), vagy a küldő cég webes API-ján keresztül.
Az első késés már itt előfordulhat. Sok alkalmazás a kimenő leveleket feladatsorba teszi, és kötegekben dolgozza fel, főleg a marketingplatformok. Így az a pillanat, amikor egy weboldal azt mondja, „nézd meg az e-mailedet”, jócskán előbb lehet, mint az, amikor a levél tényleg elhagyja a rendszert. A példánkban tegyük fel, hogy a sor húsz másodpercet vesz igénybe. A címzett oldalára még semmi nem jutott el, és egyetlen temp mail szolgáltatás sem látja, nem gyorsíthatja.
2. szakasz: Kiderítjük, hová viszi a veylax.com a leveleit
A kimenő szerver elolvassa a @ utáni részt, esetünkben a veylax.com-ot, és lekérdezi a DNS-től a domain MX-rekordjait. Az MX (mail exchanger) rekord megnevez egy szervert, amely a domain leveleit fogadja. Zónafájl-jelöléssel így nézhetnek ki egy domain rekordjai. A nevek szemléltetésre kitaláltak:
example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.
A 3600 a TTL (time to live), vagyis az a másodpercszám, ameddig egy névfeloldó gyorsítótárazhatja a választ. A 10 és a 20 a prioritás: a küldők a legkisebb számmal próbálkoznak először, és ha az nem érhető el, a magasabbra térnek át. A gazdagépnévnek saját A (IPv4) vagy AAAA (IPv6) rekordja kell, hogy legyen. Az MX-rekordnak gazdagépnévre kell mutatnia, nem közvetlenül IP-címre vagy CNAME-aliasra.
Ezt a keresést te magad is lefuttathatod bármelyik domainre:
| Rendszer | Parancs |
|---|---|
| Windows parancssor | nslookup -type=mx example.com |
| Windows PowerShell | Resolve-DnsName example.com -Type MX |
| macOS és Linux | dig MX example.com +short |
A visszaélés elleni rendszerek ugyanezt a keresést használják arra, hogy kiszúrják az ismert eldobható infrastruktúrára irányító domaineket. Ez az egyik oka annak, hogy egyes weboldalak akkor is felismerik a temp mail domaineket, ha maga a domain új.
Két szélsőséges eset a DNS-ben
Az a domain, amelynek nincs MX-rekordja, nem automatikusan elérhetetlen. Az RFC 5321, az SMTP szabványa, tartalékot határoz meg: a küldő a domain saját A vagy AAAA rekordját feltételezett levelezőgépnek tekintheti. Az a domain, amely egyáltalán nem akar levelet, ezt jelezheti null MX-szel (RFC 7505), ami egy 0 prioritású MX-rekord, amelynek gazdagépe egyetlen pont. A temp mail domainek természetesen normál MX-rekordokat tesznek közzé, hiszen a fogadás a céljuk.
A gyorsítótárazás is akadályozhat, amikor egy szolgáltatás új domaint vesz fel. Azok a névfeloldók, amelyek nemrég „nincs ilyen rekord” választ kaptak, megtarthatják azt, amíg le nem jár a negatív gyorsítótár ideje, amelyet a domain SOA-rekordja szabályoz (RFC 2308). Egy vadonatúj domain ezért eltarthat egy ideig, mire minden küldőtől megbízhatóan fogad.
3. szakasz: A két szerver beszélgetése
A Bright Parcel kimenő szervere most TCP-kapcsolatot nyit a preferált MX-géphez a 25-ös porton. Az SMTP szöveges protokoll: a kliens parancsokat küld, a szerver számozott válaszokat ad. Itt egy leegyszerűsített munkamenet az üzenetünkhöz, ahol az S: a fogadó, a C: a küldő. A gépek és a méretadat ehhez a kitalált példához tartoznak.
S: 220 mx1.mail-provider.example ESMTP ready
C: EHLO out.brightparcel.example
S: 250-mx1.mail-provider.example
S: 250-STARTTLS
S: 250 SIZE 26214400
C: STARTTLS
S: 220 Ready to start TLS
(TLS-kézfogás, aztán újra EHLO)
C: MAIL FROM:<bounce@brightparcel.example>
S: 250 OK
C: RCPT TO:<quietfox42@veylax.com>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: (fejlécek, üres sor, törzs, majd egy sor egyetlen ponttal)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye
| Parancs | Cél | Mit jelent a temp mailnek |
|---|---|---|
EHLO | Azonosítja a küldőt, és megkérdezi, mit támogat a szerver | A válasz bővítményeket sorol fel, például a STARTTLS-t és a legnagyobb SIZE-ot |
STARTTLS | TLS-re emeli a kapcsolatot (RFC 3207) | Ezt az egy szakaszt védi. Nem végpontok közötti titkosítás |
MAIL FROM | Beállítja a boríték feladóját, ahová a visszapattanó levelek mennek | Gyakran eltér a látható From sortól, főleg tömeges küldőknél |
RCPT TO | Megnevez egy címzettet | A gyűjtőcímes fogadó 250-nel válaszol a domainjein bármelyik felhasználónévre |
DATA | Elindítja az üzenet tartalmát | Egyetlen ponttal a saját sorában ér véget |
QUIT | Lezárja a munkamenetet | A kézbesítést már a DATA utáni 250 eldöntötte |
A pillanat, amikor a felelősség gazdát cserél
Az a záró 250 a munkamenet legfontosabb sora. Addig az üzenet a Bright Parcel szerveréé, és ha a kapcsolat megszakad, újra próbálkozik. Utána a fogadó elfogadta a felelősséget. A feladó irányítópultja ezután jellemzően azt mutatja, „kézbesítve”, ami csak annyit jelent, hogy ez a szakasz sikerült. Nem jelenti, hogy bárki bármit látott.
A válaszkódok az emberek által látott viselkedés jó részét megmagyarázzák:
- A 2xx siker, és a
250azt jelenti, elfogadva. - A 3xx közbenső lépés, és a
354megmondja a küldőnek, hogy küldje az üzenetet. - A 4xx átmeneti hiba, például
421vagy451. A küldő a sorában tartja az üzenetet, és újra próbálkozik. - Az 5xx végleges hiba, például
550(a postaláda nem elérhető vagy elutasított) vagy552(túl nagy). A küldő feladja, és általában visszapattanó üzenetet generál.
A 4xx és az 5xx különbsége megmagyarázza a „lassú” levelek nagy részét. Ha a fogadó ezen a ponton 451-gyel válaszolt volna, mondjuk szürkelistázás miatt (RFC 6647), az üzenetünk a Bright Parcel sorában ülne, se el nem veszve, se kézbesítve. Az RFC 5321 általában legalább 30 perces újrapróbálkozási időközt és legalább négy-öt napos feladási időt javasol, bár a valódi rendszerek saját ütemezést állítanak be, és sokan hamarabb próbálkoznak újra. Ezért érkezhet meg az egyik megerősítés néhány másodperc alatt, a következő pedig húsz perc múlva, anélkül hogy bármelyik esetben hiba lenne.
Két címkészlet
Az SMTP-nek két címzési rétege van. A boríték, a MAIL FROM és az RCPT TO, az, amit a szerverek az útválasztáshoz használnak. A fejlécek, a From:, a To: és a Subject:, az üzenet tartalmához tartoznak, és ezeket látod a képernyőn. Eltérhetnek. Egy hírlevél megjeleníthet To: subscribers sort, bár a boríték címzettje az ideiglenes címed volt. A fogadó rendszer ezért a boríték címzettje szerint rendezi az üzeneteket, mert ez a megbízható érték. Ezért rögzíti a végső kézbesítéskor hozzáadott Return-Path fejléc is a boríték feladóját, nem a látható From címet.
4. szakasz: Miért nem kellett léteznie a quietfox42-nek
Az RCPT TO pontnál egy normál levelezőszerver megnézi, létezik-e a postaláda, és 550-nel válaszol, ha nem. A temp mail domain fordítva működik. Gyűjtőcímes, vagyis helyettesítő karakteres fogadóként fut: minden helyi részt (a @ előtti részt) elfogad.
Ez az egyetlen döntés teszi lehetővé a azonnali címeket. Amikor a VookMail megmutat egy véletlenszerű címet, semmit nem kellett létrehozni egyetlen levelezőszerveren sem. Amikor megnyomod az Új gombot, beírod a saját felhasználónevedet, választasz domaint, és megnyomod a nyilat, az a név már „létezik”, mert a domain minden nevet elfogad. Az alkalmazásnak csak azokat az üzeneteket kell mutatnia, amelyek címzettje egyezik a képernyődön lévő címmel.
Két kis szabály vonatkozik ezekre a nevekre. A szabvány szerint a helyi rész kis- és nagybetűérzékeny lehet, de szinte minden valódi rendszer a Test@-t és a test@-t egy postaládának tekinti, ezért egy temp mail rendszer okosan normalizálja a kis- és nagybetűket, hogy a feladó nagybetűzése ne vágjon ketté egy postaládát. Az RFC 5321 pedig 64 oktettre korlátozza a helyi részt, egy teljes címnél pedig 254 karakter a gyakorlati korlát, ezért a generált neveknek bőven ezen belül kell maradniuk.
5. szakasz: A levelezési protokolltól a webes kérésig
Az üzenetünket most elfogadta egy SMTP-t beszélő gép. A postaládát megjelenítő weboldal viszont webalkalmazás. Valaminek össze kell kötnie a kettőt.
Az egész internet felé nyitott levelezőszerver üzemeltetése komoly munka: TLS, kapcsolatözönök, sorok, kártevők, és a jó hírnév fenntartása. Ezért sok modern alkalmazás az SMTP oldalt egy erre szakosodott bejövő szolgáltatóra bízza, és az üzeneteket webes kérésként kapja meg, ezt a mintát gyakran inbound parse webhooknak hívják. A VookMail ezt a modellt használja. Így működik:
- A szolgáltató MX-gépei elfogadják az üzenetet a feladó szerverétől, ahogy a fenti munkamenetben.
- A szolgáltató becsomagolja, vagy nyers MIME-forrásként, vagy már feldolgozott mezőkként, például feladó, címzettek, tárgy, szöveg, HTML és mellékletek.
- HTTPS POST kérésben elküldi ezt a csomagot a temp mail alkalmazás által üzemeltetett végpontra, ami titkosítja a tartalmat e két pont között.
- Az alkalmazás sikeres állapotkóddal válaszol. Ha nem érhető el, vagy hibát ad, egy rendesen viselkedő szolgáltató a saját szabályai szerint újra próbálkozik.
- Az alkalmazás ellenőrzi a kérést, a címzettet egy címhez rendeli, és ideiglenesen eltárolja az üzenetet.
| Szempont | Saját üzemeltetésű SMTP-fogadó | Bejövő szolgáltató és HTTPS |
|---|---|---|
| Kitettség | A 25-ös port nyitva az internet minden gépe felé | A szolgáltató veszi át az SMTP-forgalmat, az alkalmazás csak HTTPS-kéréseket lát |
| Forgalmi csúcsok | Az üzemeltetőnek kell kapacitást biztosítania | A szolgáltató infrastruktúrája kezeli a hullámokat |
| MIME-feldolgozás | Az üzemeltető írja vagy tartja karban a feldolgozót | Gyakran a szolgáltató végzi, bár a nyers forrás is használható |
| Illeszkedés a webalkalmazáshoz | Hidat kell építeni a levélsortól az alkalmazásig | Az üzenet úgy érkezik, mint bármilyen API-kérés |
| Függőség | Kevesebb külső fél | A szolgáltató elérhetőségére és beállításaira támaszkodik |
Az utolsó sor valódi költség. Ha egy bejövő szolgáltatónál leállás vagy beállítási hiba van, a mögötte lévő összes domainre megállhat a kézbesítés, amíg ki nem javítják, még akkor is, ha maga a temp mail weboldal rendesen működik. Azok az üzenetek, amelyeket ez idő alatt átmeneti hibával utasítottak vissza, az eredeti küldők újrapróbálkozásakor még átjuthatnak, attól függően, mennyi ideig tartják őket a sorok.
A végpont védelme
A webhook-végpont nyilvános URL, így bárki megpróbálhat hamisított üzenetet küldeni rá. A gondos megvalósítások általában több védelmet kombinálnak:
- Aláírás-ellenőrzés, amikor a szolgáltató aláírja a kéréseket, és az alkalmazás elutasítja azokat, amelyek nem egyeznek.
- Titkos útvonal vagy token, amelyet csak a szolgáltató és az alkalmazás ismer.
- A kérések korlátozása a szolgáltató közzétett címtartományaira, ahol ilyenek vannak.
- Méretkorlátok, amelyek korán elutasítják a túlméretes adatcsomagokat a memória és a tárhely védelmére.
- Idempotencia. A szolgáltatók újra próbálkoznak, így ugyanaz az üzenet kétszer is megérkezhet, és a Message-ID vagy a szolgáltató eseményazonosítója megakadályozza a duplikátumokat.
6. szakasz: Az üzenet szétszedése
Ami megérkezik, az még nem olyan, amit egy ember kényelmesen elolvashatna. A MIME (Multipurpose Internet Mail Extensions, RFC 2045-től) lehetővé teszi, hogy egy üzenet több, különböző formátumú részt hordozzon. A megerősítő e-mailünk így lehet felépítve, példaként egy számlával kiegészítve:
| Rész | Mit tartalmaz |
|---|---|
multipart/mixed | A külső tároló, ha vannak mellékletek |
multipart/alternative | Ugyanaz a tartalom kétszer, text/plain és text/html formában. Az olvasó a leggazdagabb általa támogatott formát mutatja |
multipart/related | HTML a beágyazott képekkel csoportosítva, cid: azonosítókkal hivatkozva |
| Melléklet-rész | Egy Content-Disposition: attachment fejléc és fájlnév, majd a fájl kódolt adatai |
Ezek fölött vannak a fejlécek, köztük a Message-ID, a Date és a Received nyomkövető sorok, amelyek rögzítik az összes szervert, amelyen az üzenet áthaladt. Ha valaha tudni akarod, hol történt a késés, a Received sorok időbélyegeit érdemes megnézni.
A feldolgozónak több kódolást is vissza kell fejtenie. A Base64 a bináris mellékleteket hordozza, és nagyjából harmadával megnöveli őket, így egy 10 MB-os fájlból nagyjából 13-14 MB-os üzenet lesz. A Quoted-printable a többnyire ASCII szöveget kezeli úgy, hogy a különleges karaktereket =XX formában írja. A charset= érték megmondja, hogyan van kódolva a szöveg, általában UTF-8, ami sokat számít egy sok nyelven használt szolgáltatásnál. A nem ASCII karaktereket tartalmazó tárgysorok pedig az RFC 2047 szerinti =?UTF-8?B?...?= vagy =?UTF-8?Q?...?= szintaxist használják.
A HTML biztonságossá tétele a megjelenítéshez
Az e-mailek HTML-jét idegenek írják, ezért a megjelenítő nem engedheti, hogy kódot futtasson a weboldal környezetében. A gondos megvalósítások általában eltávolítják a szkripteket, az eseménykezelő attribútumokat és a veszélyes URL-sémákat, és az üzenetet elszigetelt keretben jelenítik meg, hogy a stílusai és a tartalma ne befolyásolhassák a környező oldalt.
A távoli képekre is gondolni kell. Egy kép betöltése elárulja a feladójának, hogy megnyitották az üzenetet, így működnek a követőpixelek. A VookMail eltávolítja a rejtett követőpixeleket, és a képeket kikapcsolva tartja, amíg nem engeded.
A megjelenítő a feldolgozott szöveggel hasznos dolgot is tehet. A megerősítő üzenetünknél a VookMail az üzenet fölött mutatja az ellenőrző kódot vagy a megerősítő linket, hogy senkinek ne kelljen egy hosszú sablonban görgetnie, hogy megtalálja.
Mellékletek
A mellékleteket dekódolják és ideiglenesen eltárolják, hogy letölthetők legyenek. A VookMailen a gyakori programfájlokat, például a .exe, .bat és .apk kiterjesztésűeket visszautasítjuk, az archívumok, például a .zip, figyelmeztetést mutatnak, és legnagyobb méretek érvényesek. A mellékleteket az üzenetekkel együtt töröljük. Ne feledd, hogy egy fájl biztonságának semmi köze ahhoz, hol tárolták: a makrókat engedélyező dokumentum ugyanolyan veszélyes, ha ideiglenes postaládából töltöd le.
7. szakasz: Eljut a képernyőre
Az üzenetünk most el van tárolva, de a quietfox42@veylax.com címet megjelenítő böngésző ezt még nem tudja. A webalkalmazásoknak több módjuk van rá, hogy ezt megtudják:
| Technika | Hogyan működik | Kompromisszumok |
|---|---|---|
| Rövid lekérdezés (short polling) | Az oldal néhány másodpercenként megkérdezi a szervert | Egyszerű és megbízható, de ismételt kéréseket generál |
| Hosszú lekérdezés (long polling) | A kérés nyitva marad, amíg hír van vagy lejár az idő | Kevesebb üres válasz, több nyitott kapcsolat |
| Server-Sent Events | Egyetlen hosszú életű adatfolyam a szervertől a böngészőig | Egy irányban hatékony, magától újracsatlakozik |
| WebSockets | Tartós kétirányú kapcsolat | Teljesen interaktív, külön infrastruktúrát igényel |
A VookMail postaládája néhány másodpercenként ellenőrzi a leveleket, a Frissítés gomb pedig kézzel, például miután az eszközöd aludt vagy megszakadt a hálózatod. Ez a pár másodperc általában az út legrövidebb szakasza. Ha a levél lassúnak tűnik, az idő szinte mindig korábban veszett el, a feladó sorában vagy egy újrapróbálkozásban.
A cím létrehozása egy kis botvédelemen is átmegy: egy rövid számításon a látogató böngészőjében, amelyet proof of work néven ismernek. Egy normál látogatónak szinte semmibe nem kerül, a tömeges címlétrehozást viszont drágábbá teszi.
A cím máshol is megnyitható. Mivel maga a cím azonosítja a postaládát, egy másik eszközre váltáshoz csak a címet kell átadni. A VookMail QR gombja olyan kódként mutatja, amelyet egy telefon beolvashat, így ugyanaz a postaláda ott is megnyitható, az Android és Huawei alkalmazások pedig ugyanígy mutatják a leveleket. Ez kényelmes, és azt is megmutatja, miért kevéssé privátak ezek a postaládák: bárki megnyithatja a postaládát, aki ismeri vagy kitalálja a címet. A véletlenszerű cím a biztonságosabb választás, mert sokkal nehezebb kitalálni, mint egy rövid nevet.
8. szakasz: Törlés
Körülbelül egy nappal a megerősítésünk megérkezése után eltűnik. A megőrzést egy temp mail rendszerben általában úgy valósítják meg, hogy minden tárolt üzenethez időbélyeg tartozik, és egy ütemezett feladat eltávolít mindent, ami régebbi a határnál. A külön fájlként tárolt mellékletek ugyanakkor mennek. Más megoldások tárolási szintű lejáratot használnak, amikor maga az adatbázis távolítja el a régi rekordokat egy élettartam-beállítással. A kötegelt feladatok az egyik oka annak, hogy a szolgáltatások hajlamosak a lejáratot „körülbelül” egy napnak mondani, mert a pontos pillanat azon múlik, mikor fut a feladat. A VookMailen az üzenetek, a mellékletek és a címek körülbelül 24 órán belül törlődnek, a Törlés gombbal pedig korábban is eltávolíthatod őket.
A rövid megőrzés egyszerre két célt szolgál. Védi a magánszférát, és kapacitási szükségszerűség is: az eldobható postaládák sok marketinglevelet kapnak, és ha sokáig tartanák meg, az senkinek nem lenne jó. Az adatvédelmi szabályzatunk és a módszertani oldalunk részletesebben tárgyalja az adatkezelést.
Vedd észre, mihez nem nyúl a törlés. A Bright Parcel ügyféltáblájában még megvan a cím, és a naplói még mindig azt mutatják, hogy „kézbesítve”. Csak a postaláda oldali másolat tűnt el.
Az egész útvonal egy táblázatban
| Szakasz | Összetevő | Protokoll vagy mechanizmus | Jellemző port vagy formátum |
|---|---|---|---|
| Összeállítás | Alkalmazás vagy levelezőkliens | RFC 5322 üzenet, MIME | Szöveg fejlécekkel és részekkel |
| Beadás | A feladó levelezési szolgáltatása | SMTP-beadás vagy küldő API | 587 vagy 465 |
| Útválasztási keresés | DNS-névfeloldó | MX, majd A vagy AAAA lekérdezések | DNS, 53-as port |
| Továbbítás | A feladó szervere a címzett MX-éhez | SMTP opportunista STARTTLS-sel | 25 |
| Bejövő fogadás | Levélkézbesítő szolgáltató | Gyűjtőcímes elfogadás a domainekre | 250, 4xx, 5xx válaszok |
| Továbbküldés | A szolgáltatótól a VookMailnek | HTTPS-kérés | 443 |
| Feldolgozás | Temp mail alkalmazás | MIME-feldolgozás, tisztítás, tárolás | Adatbázis és fájltárolás |
| Megjelenítés | Böngésző vagy mobilalkalmazás | Néhány másodpercenként ellenőriz, plusz kézi Frissítés | HTTPS |
| Lejárat | Ütemezett takarítás | Megőrzési szabály | A VookMailen körülbelül egy nap |
Hol jön be az SPF, a DKIM és a DMARC
Ez a három szinte minden e-mailes beszélgetésben szóba kerül, ezért hasznos pontosan tudni, hol helyezkednek el ezen az útvonalon. Mindhárom azzal foglalkozik, hogy igazolják, ki küldte az üzenetet. Egyik sem dönti el, hogy egy ideiglenes cím fogadhatja-e.
Az SPF (RFC 7208) egy DNS TXT rekord, amely felsorolja azokat a szervereket, amelyek a boríték feladójában szereplő domain nevében küldhetnek, a fogadók pedig ehhez hasonlítják a csatlakozó IP-t. A DKIM (RFC 6376) kriptográfiai aláírás, amelyet a küldő domain ad a kiválasztott fejlécekhez és a törzshöz, és a DNS-ben lévő nyilvános kulccsal ellenőrizhető. A DMARC (RFC 7489) szabályzat, amely megmondja a fogadóknak, mit tegyenek, ha egy üzenet nem felel meg az SPF és a DKIM igazításának a látható From domainnel, és hová küldjenek jelentéseket.
Az üzenetünknél ezek az ellenőrzések nagyjából a 3. szakasz körül történnek. A Bright Parcel szerverét ellenőrizték az SPF-rekordja alapján, és a DKIM-aláírása a közzétett kulccsal ellenőrizhető. A fogadó szolgáltató ezekkel az eredményekkel jelezheti az adathamisítást. A továbbítás kicsit bonyolítja a dolgot: a DKIM-aláírás megmarad, amíg az üzenetet nem módosítják, az SPF-eredmény viszont csak az utolsó csatlakozó szerverre vonatkozik. Továbbított levélnél az ARC (Authenticated Received Chain, RFC 8617) rögzítheti a korábbi eredményeket. Végül azonban az MX-rekord és a fogadó elfogadása juttatja célba az üzenetet.
Amikor egy üzenet nem érkezik meg
A fenti szakaszok mindegyike olyan hely, ahol egy üzenet megakadhat. A feladó végétől haladva általában a leggyorsabb megtalálni a hibát.
| Szakasz | Mi ment félre | Mit látsz vagy teszel |
|---|---|---|
| Küldés előtt | Elgépelés a címben | A levél máshová ment, vagy visszapattant. Használd a Másolás gombot |
| Elhagyja a feladót | Az üzenet sorban áll, vagy lassúak a kötegek | Egyes szolgáltatásoknál egy-két perc normális. Várj |
| Elhagyja a feladót | Az oldal csendben kihagyja az eldobható domaineket | Semmi nem érkezik. Fogadd el, és használj ott tartós címet vagy aliast |
| SMTP | 4xx válasz és későbbi újrapróbálkozás | Az üzenet késéssel érkezik meg, ami percektől tovább is tarthat |
| SMTP | Az üzenet túllépi a méretkorlátot | 552 elutasítás és visszapattanás a feladónak |
| Bejövő szolgáltató | Leállás vagy DNS-probléma | A kézbesítés minden domainre szünetelhet a megoldásig |
| Postaláda | Az idő letelt, vagy a címet törölték | Az üzenet túl későn érkezik, hogy láthasd |
A hiba értelmezése, ha a küldő oldal a tiéd
Ha a saját alkalmazásodat teszteled, sokkal többet láthatsz, mint egy felhasználó, és a fejlesztőknek szóló ideiglenes e-mail útmutatónk részletesebben tárgyalja a tesztek tervezését. Az ellenőrzések ésszerű sorrendje:
- Nyisd meg az alkalmazásod levelezési naplóit vagy a küldő szolgáltatód irányítópultját. Elfogadták az üzenetet, és milyen végső állapotot mutat?
- Keress visszapattanásokat vagy webhook-eseményeket, amelyek a címzett oldaláról 5xx kódot jeleznek. A kód utáni szöveg gyakran megnevezi az okot.
- Oldd fel a címzett domain MX-rekordjait a szervered hálózatáról, a fenti parancsokkal. Az ottani névfeloldási probléma máshol nem biztos, hogy látszik.
- Győződj meg róla, hogy a küldő domainednél be van állítva az SPF, a DKIM és a DMARC, mert egyes fogadók gyanakvással kezelik a hitelesítetlen leveleket.
- Küldj egy kis sima szöveges üzenetet, hogy kizárd a méret- vagy tartalomszűrést.
- Használj tesztenként külön felhasználónevet, hogy tudd, melyik futás melyik üzenetet hozta.
Ha egy üzenet későn ér a postaládába, olvasd a Received fejléceit alulról felfelé. Két időbélyeg közötti nagy rés megmutatja, melyik szakasz tartotta vissza, figyelembe véve az esetleges eltérést a szerverek óráiban.
Miért futtat sok domaint?
A VookMail több mint 30 domain közül enged választani. Ennek gyakorlati okai vannak. A tesztelők domain szerint választhatják szét a projekteket vagy tesztkészleteket. Ha az egyik domainnél DNS- vagy kézbesítési probléma van, a többi még működhet. És kevésbé támaszkodunk egyetlen névre, ami akkor segít, ha a küldő rendszerek a címzett domaineket is megítélik, nem csak a küldőket.
A több domain nem eszköz azoknak az oldalaknak a kijátszására, amelyek szándékosan elutasítják az eldobható címeket. Ha egy szolgáltatás elutasít egy temp mail domaint, azt jelzi, hogy tartós elérhetőséget szeretne, és a helyes választás ahhoz a szolgáltatáshoz a valódi címed vagy egy tartós alias. Az elutasítás jöhet az űrlapnál, egy domainlistán vagy a 2. szakaszban látotthoz hasonló MX-kereséssel, vagy később, amikor a feladó nem hajlandó küldeni.
Mit árul el az útvonal a biztonságról
Miután végigkövetted az üzenetet, pontosan látod, meddig ér el az egyes védelem.
A titkosítás szakaszonként érvényesül. A STARTTLS védi az egyes szerver-szerver szakaszokat, ha mindkét fél támogatja, és gyakran opportunista, ezért a kapcsolat visszaeshet sima szövegre, hacsak valamilyen szabályzat, például az MTA-STS (RFC 8461) mást nem ír elő. A HTTPS védi a továbbítási és a megtekintési szakaszt. Ez egyike sem végpontok közötti titkosítás: az üzenetet kezelő minden rendszer elolvashatja.
A hozzáférés a másik fele. Jelszó nélkül a cím ismerete ad belépést, ezért soha ne engedj oda semmi bizalmasat küldeni. A rövid megőrzés korlátozza az esetleges kitettség kárát, de azt is jelenti, hogy a postaláda nem szolgálhat nyilvántartásként. És mivel a tartalom nem megbízható, adathalászat és kártevő ebbe a postaládába is érkezhet, mint bármelyikbe. Az ideiglenes postaláda a valódi címedet védi, az eszközödet viszont alig, ha rossz fájlt nyitsz meg. A megfelelő felhasználások a magánszféra védelme, a spam kezelése és a tesztelés, ahogy az általános szerződési feltételeink rögzítik, a fontos fiókok pedig máshová valók.
Hogyan néz ez ki a VookMailen
A fenti gépezet mind a helyén van, mielőtt megérkeznél. Amikor megnyitod a VookMailt, egy cím már kész. Megnyomhatod az Új gombot, hogy felhasználónevet írj be és domaint válassz, vagy használhatod a sárga Véletlen gombot, amelyet a VookMail használatáról szóló útmutatónk ír le. Nincs mit regisztrálni, mert a domain már minden nevet elfogad. Amikor egy feladó levelet kézbesít, az MX-rekordok mögötti szolgáltató SMTP-n átveszi, HTTPS-en továbbítja, és a következő ellenőrzéskor megjelenik a postaládádban az esetleges mellékletekkel együtt. Körülbelül egy nappal később eltűnik.
A szolgáltatás alkalmazásként is elérhető a Google Playen és a Huawei AppGalleryben.
Még néhány technikai kérdés
Melyik portot használja a bejövő e-mail?
A levelezőszerverek közötti kézbesítés SMTP-t használ a 25-ös TCP-porton. Az 587-es és a 465-ös port a kimenő levelek saját szolgáltatódnak való beadására szolgál, ezért az 1. szakaszban szerepelnek, nem a 3.-ban. Ezért tud általában egy olyan otthoni kapcsolat is küldeni a szolgáltatóján keresztül, amely blokkolja a 25-ös portot.
Láthatja egy temp mail szolgáltatás az üzeneteimet?
Technikailag igen. Az üzenet olvasható formában jut el a szolgáltatáshoz, mert így tudja megmutatni neked, és ugyanez igaz az útközben kezelő kézbesítő szolgáltatóra is. Ez a hagyományos tárhelyen futó e-mailre is igaz, hacsak a tartalmat nem titkosítják végponttól végpontig. Ez is egy ok, hogy minden érzékeny dolgot távol tarts az ideiglenes postaládától.
Miért gondolhatja a feladó, hogy egy üzenet kézbesítve lett, ha én nem látok semmit?
Mert a feladó irányítópultján a „kézbesítve” a fogadó szerver 250 válaszára utal. Az az utáni események, például a továbbítási lépés vagy a postaláda kiürítése utáni késői megérkezés, láthatatlanok a feladónak.
Észreveheti egy feladó, hogy a címem gyűjtőcím?
Gyakran. Egy ellenőrző eszköz kipróbálhat egy kitalált felhasználónevet a domainen, és ha a szerver elfogadja, a domain valószínűleg gyűjtőcímes. Ez önmagában nem bizonyítja, hogy a domain eldobható, mert sok hétköznapi céges domain is így van beállítva, ezért az ilyen eszközök általában más jelekkel kombinálják.
Működnek a válaszok az üzenetre?
A te oldaladról küldött válaszok nem a tervezés lényege, mert a postaláda főleg fogad. Ha kétirányú levelezésre van szükséged, jobb választás egy hagyományos postaláda vagy egy válaszokat támogató aliasszolgáltatás.
A termékről többet a GYIK-ban találsz. A VookMail a PAYATE ingyenes eszközhálózatának része.