Tegyük fel, hogy a csapatod új jelszó-visszaállító e-mailt ad ki. A QA jóváhagyja a stagingen: az üzenet megjelenik, a link működik, a sablon jól néz ki. A kiadás után két nappal a támogatásnál jegyek sorakoznak. A Gmail-címmel rendelkezők azt mondják, hogy a levél meg sem érkezett. Néhány nagy cég dolgozói szerint megérkezett, de a link már az első kattintáskor „már felhasznált” volt. A staging és az éles között senki nem változtatott a kódon, és minden teszt továbbra is zöld.
Melyik teszt e-mail-cím fejlesztőknek fogta volna meg ezt? Egyetlen sem. Egy helyi SMTP-fogó a napi fejlesztéshez jó, a szolgáltatód sandboxa vagy egy általad kezelt tesztdomain az automatizált tesztekhez, egy valódi külső postaláda pedig annak a kézi ellenőrzéséhez, hogy a levél elhagyja az élesre hasonlító környezetedet, és eljut egy idegen domainre. Egy ideiglenes postaláda, például a VookMail ezt az utolsó esetet beállítás nélkül lefedi, mert az oldal betöltésekor már kész a cím. Az ezek által nem látott részt a nagy levelezőszolgáltatóknál tartott teszt fiókok fedik le. Az útmutató hátralévő része arról szól, hogyan válassz ezek közül, hogyan olvasd le a hibákat, ha bekövetkeznek, és mely ellenőrzések tartoznak egy kiadásba.
Miért ment át a visszaállítás a stagingen
A staging és az éles ritkán olyan hasonló, mint ahogy a telepítési ábra sugallja, és az e-mail jobban leleplezi a különbségeket, mint a legtöbb funkció. Egy üzenet áthalad az alkalmazásodon, egy soron, egy szolgáltatón, a DNS-en, a címzett szerverén és a címzett kliensén. A staging ezek szinte mindegyikének más verzióját használhatja.
Vegyük az első jegyet, a Gmail-felhasználókat, akik semmit nem kaptak. Tegyük fel, hogy a staging egy olyan szolgáltatói aldomainen keresztül küld, amelyet hónapokkal ezelőtt hitelesítettek, míg az éles egy új From domainről, amelyet az arculatváltással vezettek be. A Google feladói irányelvei szerint minden feladónak SPF-fel vagy DKIM-mel kell hitelesítenie magát, a Gmail hibatáblázata pedig a hitelesítetlen levelekre az 5.7.26 kódot sorolja fel. A saját domaineden lévő belső QA-postaláda ugyanazt az üzenetet átengedheti, mert a saját szervered megbízhat a saját továbbítódban. A teszt így sosem bukhatott el.
A második jegy, a „már felhasznált” link, más okból van. A vállalati biztonsági átjárók gyakran megnyitják a bejövő levelek linkjeit, hogy átvizsgálják őket, mielőtt az ember meglátná a levelet. Ha a linked egy egyszerű GET kéréssel váltja be a tokent, a vizsgáló felhasználja, és a dolgozó egy halott linkre kattint. A stagingen egyetlen postaládád sem futtat ilyen vizsgálót, hacsak a saját céged nem használ egyet.
Ezt a két hibát nem lehet ugyanonnan látni. Az egyikhez valódi kézbesítés kell egy olyan fogadó rendszerhez, amelyet nem te üzemeltetsz. A másikhoz a link viselkedésének megváltoztatása kell, amit egy kódátnézés könnyebben elkap, mint egy teszt. Ez a rétegzett tesztelés érve: minden címfajta egy kérdésre válaszol, a többire hallgat.
| Gyakran eltér a staging és az éles között | Mit rejthet el |
|---|---|
Küldő domain és From cím | Hiányzó vagy nem illeszkedő SPF és DKIM |
| Szolgáltatói fiók vagy alfiók | Sandbox mód, küldési korlátok, más IP-hírnév |
| Címzettek | Belső domainek, amelyek megbíznak benned, és engedélyezőlisták, amelyek elrejtik a rossz címeket |
| Kattintáskövetés | Átírt linkek, amelyek elromlanak, vagy érvényes tanúsítvány nélküli követő domain |
| Forgalom | Sorok és sebességkorlátok, amelyek csak terhelés alatt éreztetik hatásukat |
| Letiltási listák | Éles címek, amelyek egyszer visszapattantak, és most csendben kimaradnak |
| Alap URL beállítások | Rossz hosztra mutató linkek |
Melyik cím melyik kérdésre felel
Itt vannak a lehetőségek, mindegyik azzal a kérdéssel, amelyre ténylegesen válaszolni tud.
Helyi fogó: „mit állított elő az alkalmazásom?”
Az SMTP-fogó mindent elfogad, amit az alkalmazásod küld, és megjeleníti egy weboldalon, anélkül hogy bármit kézbesítene. A Mailpit népszerű nyílt forráskódú választás. Alapból a 1025-ös porton figyeli az SMTP-t, a webes felületét pedig a 8025-ös porton szolgálja ki, így a fejlesztői beállításaidat a localhost:1025 címre irányítod, és megnyitod a http://localhost:8025 címet. A Nodemailer Etherealja hasonló ötlet, egy tárolt álszolgáltatással. A fogó gyors és privát, és bármilyen címre küldhetsz vele anélkül, hogy valódi emberhez jutna el. A DNS-ről, a hitelesítésről vagy a szűrésről viszont semmit nem mond, mert semmi nem lép ki az internetre.
A keretrendszer tesztsegédje: „a kódom a megfelelő levelet kérte?”
A legtöbb keretrendszer a teszt futása alatt a memóriában rögzíteni tudja a kimenő leveleket. A Laravelben van Mail::fake(), a Django a levelek a django.core.mail.outbox listába gyűjti, a Railsben pedig ott az ActionMailer::Base.deliveries. Ezekkel ellenőrizheted, hogy egy feladat egyszer fut le, a megfelelő címzettel és tokennel. Ez a leggyorsabb visszajelzés, amit kaphatsz, és a külvilágból még a fogónál is kevesebbet tesztel.
A szolgáltató tesztmódja: „működik az integrációm?”
A szolgáltatók különféle segítséget kínálnak, és a különbségek számítanak. Az Amazon SES-nek van postaládaszimulátora olyan címekkel, mint a success@simulator.amazonses.com, a bounce@simulator.amazonses.com és a complaint@simulator.amazonses.com, amelyek a hírnevedet károsítás nélkül hozzák létre ezeket az eredményeket. Egy új SES-fiók ráadásul sandboxban indul, ahol csak ellenőrzött címekre küldhet. A SendGrid a mail_settings.sandbox_mode.enable beállítással bekapcsolható sandbox módja kézbesítés nélkül érvényesíti a kérésedet. A Postmark ugyanerre a célra elfogadja a POSTMARK_API_TEST tokent. Ezek jók az API-hibákhoz, valamint a visszapattanási és panaszwebhookokhoz, de nem bizonyítják, hogy a levél eljutott valakihez. Nézd meg a saját szolgáltatód aktuális dokumentációját, mert ezek a funkciók változnak.
Saját tesztdomain: „működik a teljes folyamat, ismételten?”
Az automatizált végponttól végpontig tartó tesztekhez állíts be egy általad kezelt domaint vagy aldomaint, gyűjtőpostaládával vagy bejövő webhookkal, hogy a tesztkódod API-n keresztül olvashassa a leveleket. Beállítani kell egy kis munka, de privát és stabil, és nem függ senki más weboldalától. Ne találj ki címeket olyan domainen, amely nem a tiéd. Lehet, hogy valaki birtokolja a testuser@gmail.com címet, és megkapja, amit küldesz. Az RFC 2606 fenntartja az example.com domaint, valamint a .test és .example legfelső szintű neveket, hogy a dokumentációnak és a tesztadatoknak legyen hova biztonságosan mutatniuk. Ezek a nevek nem tudnak levelet fogadni, ezért tesztadatokhoz jók, kézbesítési tesztekhez használhatatlanok.
Valódi külső ideiglenes postaláda: „megkapná ezt egy idegen domain?”
Itt éri meg a helyét az ideiglenes postaláda. Ez egy valódi postaláda egy olyan domainen, amelyet nem te irányítasz, és amelyhez nincs engedélyezőlistád. Az üzenetednek meg kell találnia az MX-rekordot, SMTP-kapcsolatot kell létesítenie, és el kell fogadtatnia magát. A VookMailen a domainek MX-rekordjai egy levélkézbesítő szolgáltatóra mutatnak, amely fogadja az üzenetet, és HTTPS-en továbbítja. Egy friss cím azt is jelenti, hogy nincs előzmény: nincsenek régi üzenetek, nincs korábbi visszapattanás a letiltási listádon, nincsenek szűrők. Így gyors módja annak, hogy reprodukáld a „új címmel regisztráltam, és nem kaptam semmit” esetet. Nem fejlesztőknek is hasznos. Egy tervező vagy termékmenedzser elolvashatja, mit kap egy új felhasználó, az eszközeidhez való hozzáférés nélkül.
Teszt fiókok a nagy levelezőszolgáltatóknál: „hova érkezik meg?”
Az egyik domainen kézbesített üzenet semmit nem mond egy másik domain spam mappájáról. Tarts egy kis készletet valódi fiókokból azoknál a szolgáltatóknál, amelyeket a felhasználóid tényleg használnak, és ellenőrizd az elhelyezést jelentős sablon- vagy domainváltozások előtt. Aztán a kiadás után figyeld a visszapattanási és panaszszámokat. Ha a leveleid spamnek látszanak, ezeken a fiókokon látod meg először.
| Megközelítés | Átlépi az internetet | Beállítás | Automatizálás | Tartalom adatvédelme | Legjobb szakasz |
|---|---|---|---|---|---|
| Keretrendszer tesztsegéd | Nem | Nincs | Kiváló | A folyamaton belül marad | Egység- és funkcióteszt |
| Helyi SMTP-fogó | Nem | Alacsony | Jó | Helyi marad | Fejlesztés |
| Szolgáltatói tesztmód | Általában nem | Alacsony | Jó | A szolgáltatónál marad | Integrációs teszt |
| Saját tesztdomain | Igen | Közepes-magas | Jó | Te irányítod | CI végponttól végpontig, staging |
| Ideiglenes postaláda | Igen | Nincs | Nem ajánlott | Kezeld nyilvánosként | Kézi QA és kiadás előtti ellenőrzés |
| Teszt fiókok | Igen | Közepes | Korlátozott | Mérsékelt | Elhelyezési ellenőrzés |
Kézi lefutás ideiglenes postaládával
Itt egy megismételhető végigmenet egy regisztrációs folyamaton a stagingen vagy egy élesre hasonlító környezetben. Ha egyszer tudod, nagyjából tíz percet vesz igénybe.
- Győződj meg róla, hogy a környezet a hitelesítő adatokat leszámítva ugyanazt a szolgáltatói konfigurációt használja, mint az éles, és csak kitalált adatot tartalmaz. Ha nem, írd le, mert ez korlátozza, mire következtethetsz.
- Nyisd meg a VookMailt, és nyomd meg az Új gombot. Írj be egy felhasználónevet, amely kódolja a tesztet, például
email-signup-03-x7, válassz a több mint 30 domain közül, és nyomd meg a nyilat. Használd a sárga Véletlen gombot, ha a levélben bármi érzékeny lehet, mert a postaládát bárki megnyithatja, aki ismeri vagy kitalálja a címet. - Nyomd meg a Másolás gombot, és regisztrálj új felhasználóként kitalált profiladatokkal.
- Jegyezd fel a beküldés idejét és azt, mikor jelenik meg az üzenet. A postaláda pár másodpercenként keres új levelet, így a percekben mérhető késés a soronra vagy a szolgáltatóra utal. Ha biztosra akarsz menni, nyomd meg a Frissítés gombot.
- Olvasd el az üzenetet úgy, ahogy egy új felhasználó: feladó neve, tárgy, előnézeti szöveg, törzs, gomb, sima link, lábléc. A VookMail az üzenet fölött megmutatja a felismert kódokat és megerősítő linkeket, ami nagyjából azt ellenőrzi, hogy a kódod és a linked könnyen kiválasztható-e.
- Nézd meg kikapcsolt képekkel. A VookMail addig nem tölti be a képeket, amíg nem engeded, és eltávolítja a rejtett követőpixeleket. Ha az üzenetnek ebben az állapotban nincs értelme, a felhasználóid egy része is ezt látja. Ne ezt a postaládát használd a nyitáskövetés megítélésére, mert a pixelek nem aktiválódnak.
- Nyomd meg a QR gombot, olvasd be a címet egy teszttelefonnal, és nyisd meg ott ugyanazt a postaládát, hogy valódi eszközön koppints a valódi linkre, különösen ha univerzális linkeket vagy app linkeket használsz.
- Fejezd be az igazolást, és ellenőrizd, hogy a fiók állapota úgy változik, ahogy kell.
- Futtasd le az alábbi ellenőrzőlista negatív eseteit: használd újra a linket, várd ki a lejáratot, kérj újraküldést.
- Mentsd el a bizonyítékot: képernyőképeket, időbélyegeket és a használt címet. Az üzenetek körülbelül egy nap után törlődnek, így a jövő héten írt hibajelentésnek nem lesz mire hivatkoznia.
- Nyomd meg a Törlés gombot, és töröld a tesztfiókot, ha a folyamatod megköveteli.
Egy böngészőben több cím is tartható, így egy meghívó és egy meghívott, vagy egy e-mail-cím-csere régi és új címe egyszerre nyitva lehet. Ha a tesztedben fájlokat csatolsz, ne feledd, hogy a VookMail elutasítja a gyakori programfájlokat, például az .exe-t, és az archívumoknál figyelmeztetést jelenít meg, így egy ott visszautasított melléklet nem biztos, hogy a te oldaladon hiba.
A hiba leolvasása
A „nem érkezett meg az e-mail” egy tünet, amely nagyjából hat helyen keletkezhet, és a csapatok órákat veszítenek azzal, hogy rossz helyen kezdik. A kódodtól kifelé haladj az úton, és ott állj meg, ahol először nem látod többé az üzenetet.
- Megpróbálta az alkalmazás? Keresd meg az alkalmazásnaplóban a küldési kísérletet és az esetleges kivételt. Keress olyan feladatot, amely sosem jött létre, gyakran azért, mert egy feltétel vagy funkciókapcsoló hamis volt.
- Lefutott a worker? Nézd meg az elakadt, sikertelen vagy újrapróbált feladatokat. Egy sorfeldolgozó, amelyet telepítés után nem indítottak újra, régi kódot futtathat, az újrapróbálási szabály pedig duplikátumokat küldhet.
- Elfogadta a szolgáltató? Keresd meg a címzettet vagy a
Message-IDértéket a szolgáltatód tevékenységnaplójában. Az elfogadott, a késleltetett, a visszapattant és az eldobott négy különböző történet. - Le volt tiltva? Ha az a cím korábban visszapattant vagy panaszt kapott, sok szolgáltató csendben kihagyja a jövőbeli küldéseket. Ez gyakran a régi címet újrahasználó tesztelőket éri.
- Mit mondott a fogadó szerver? A szolgáltatói naplók általában mutatják az SMTP-választ, és ez a szöveg a vizsgálat leghasznosabb sora.
- Jó a DNS? Ellenőrizd az SPF-et, a DKIM-et és a DMARC-ot a tényleges küldő domainre.
- Megvan, de rejtve van? A spam mappák, a fülek és a kliensszűrők vannak utoljára, miután egy teszt fiók meg tudja mutatni.
Mit mond az SMTP-válasz
Az RFC 5321 szerint a 4-gyel kezdődő válasz átmeneti hiba, és a feladónak később újra kell próbálnia. Az 5-tel kezdődő válasz végleges. Az RFC 3463 kibővített állapotkódjai ezután részletet adnak hozzá. Egy kitalált naplósor így nézhet ki, kizárólag a formátum példájaként:
Csak példa: to=user@gmail.example status=bounced reply="550 5.7.26 unauthenticated sender"
Olvasd balról jobbra. Az 5 azt jelenti, hogy az újrapróbálkozás nem segít. Az 5.7-es család a biztonságról vagy a szabályzatról szól, ami a DNS-hez és az aláíráshoz vezet, és eltávolít a címzett címétől. Az alábbi táblázat kiindulópontot ad a gyakori mintákhoz.
| Amit látsz | Legvalószínűbb réteg | Hol nézd először |
|---|---|---|
| Semmi a szolgáltatói naplóban | Alkalmazás vagy sor | Alkalmazásnaplók és sikertelen feladatok |
| A szolgáltató „dropped” vagy „suppressed” állapotot mutat | A szolgáltató letiltási listája | Töröld a tesztcímet, vagy használj újat |
| Az API sikert ad vissza, de sosem naplózzák elküldöttként | A sandbox mód még be van kapcsolva | A szolgáltató beállításai az adott környezethez |
5.1.1 vagy hasonló | Címzett címe | Elírások, és az űrlap-ellenőrzés, amely módosította a címet |
5.7.26 a Gmailnél | Hitelesítés | SPF, DKIM és az illeszkedés a From domainhez |
4xx halasztások, amelyek egy idő után elmúlnak | A fogadó lassít téged | Forgalom, hírnév vagy új küldő IP |
| Kézbesítve egy külső postaládába, hiányzik a Gmailnél | A fogadó szabályzata vagy szűrése | Teszt fiókok és a Google feladói irányelvei |
| Megérkezik, de a link „már felhasznált” | Vizsgáló, amely előre lekéri a linket | A tokent POST-tal váltsd be, ne GET-tel |
| A link biztonsági figyelmeztetéshez vezet | Kattintáskövető domain | A követő aldomain tanúsítványa |
| Kétszer érkezik meg | Újrapróbálási logika | A feladat idempotenciája és az újrapróbálást kiváltó időtúllépések |
| Nagyon későn érkezik | Sor | A worker kapacitása, és hogy a visszaállító levelek egy sorban vannak-e a tömeges levelekkel |
Ez az utolsó sor tervezési szempont, amely megérdemel még egy mondatot. Ha a jelszó-visszaállítások egy hírlevélküldéssel osztoznak egy soron, azok mögé kerülnek. Add a tranzakciós levelezésnek saját sort, lehetőleg saját aldomaint és küldési folyamot is, hogy egy marketingprobléma ne késleltessen egy bejelentkezést.
Parancsok, amelyek lerövidítik a keresést
A legtöbbet a terminálod elhagyása nélkül ellenőrizheted. Ezekben a példákban cseréld le a példaneveket a sajátjaidra.
- A
dig +short MX example.commegmutatja, hol fogad levelet egy domain. Az üres válasz alaposabb vizsgálatot kíván, mert az RFC 5321 megengedi a feladóknak az címrekordra való visszalépést, a0 .válasz viszont az RFC 7505 szerinti null MX, ami azt jelenti, hogy a domain egyáltalán nem fogad levelet. - A
dig +short TXT example.commegmutatja az SPF-rekordot a többi szöveges rekord között. - A
dig +short TXT selector._domainkey.example.commegmutat egy DKIM-kulcsot. A valódi selectort az üzenetDKIM-Signaturefejlécéneks=értékéből vedd. - A
dig +short TXT _dmarc.example.commegmutatja a DMARC-szabályzatot. - Az
openssl s_client -starttls smtp -connect smtp.example.com:587ellenőrzi, hogy eléred-e a továbbítódat, és megmutatja a tanúsítványát. Itt a hiba tűzfal- vagy TLS-probléma, jóval a tartalom előtt. - A
swaks --to qa@example.test --from app@example.test --server localhost:1025kézzel küld egy egyszerű üzenetet. Megkerüli az alkalmazásodat, így megtudhatod, hogy a probléma a kódodhoz vagy az útvonalhoz tartozik.
Fejléc szintű bizonyítékhoz a legmegbízhatóbb nézet egy általad kezelt postaláda egy nagy szolgáltatónál. A Gmailben nyisd meg az üzenetet, használd a hárompontos menüt, és válaszd az Eredeti üzenet megjelenítése lehetőséget, amely felül felsorolja az SPF-, DKIM- és DMARC-eredményeket. Ne feledd, hogy az egyik fogadó „átment” eredménye nem garantálja a másikét.
Mit ellenőrizz az egyes folyamatokban
A „megérkezett?” az első kérdés, és általában a legkevésbé érdekes. Minden folyamatnak megvannak a maga módjai, hogy utána elromoljon.
Jelszó-visszaállítás
Az OWASP Forgot Password Cheat Sheet az a referencia, amelyre építhetsz. Következetes üzenetet kér attól függetlenül, hogy létezik-e a fiók, egységes idő alatt érkező válaszokat, véletlenszerű, hosszú, biztonságosan tárolt és egyszer használható tokeneket, valamint Referrer-Policy: no-referrer fejlécet a visszaállító oldalon.
- A kérőoldal ugyanazt az üzenetet mutatja regisztrált és nem regisztrált címekre, és nagyjából ugyanannyi idő alatt. Az ismeretlen címekre adott azonnali válasz ugyanannyit árul el, mint a megfogalmazás.
- A link egyszer működik. Ha másodszor nyitod meg, egyértelmű magyarázatot kapsz, és kérhetsz másikat.
- Az új visszaállítás kérése érvényteleníti a régebbi linkeket, vagy a tervezésed szándékosan mást mond.
- A lejáratot a szerver érvényesíti, és megvárással vagy egy tesztkörnyezetben az idő módosításával tesztelték.
- A sikeres visszaállítás megerősítő e-mailt küld, és a többi munkamenetet a szabályzatod szerint kezeled.
- A link megnyitása önmagában nem változtat semmit. A tokent az űrlap beküldésekor váltják be.
- A visszaállító oldal nem küldi el az URL-jét harmadik fél analitikájának vagy hibakövetőjének.
- A sebességkorlátok fiókonként és IP-nként is érvényesek, így senki nem tud elárasztani egy idegen postaládát.
- A kis- és nagybetűket vegyesen vagy plusz jelet tartalmazó címek ugyanúgy működnek, mint az egyszerűek.
Regisztrációs igazolás
- Egy regisztráció egy üzenetet küld, akkor is, ha a feladatot újrapróbálják.
- A link vagy a kód egyszer működik, és a lejárt linkek oldala utat kínál a továbblépéshez.
- Az újraküldés vagy érvényteleníti az előző tokent, vagy a terv szerint együtt él vele, és sebességkorlátozott.
- A nem igazolt fiókokra pontosan azok a korlátozások vonatkoznak, amelyeket szántál.
- Ha egy regisztrált címmel újra regisztrálnak, az nem árulja el egy névtelen látogatónak, hogy a fiók létezik, ha a termékeden ezt érzékenynek tekintik. Gyakori minta, hogy ehelyett a meglévő tulajdonosnak küldenek e-mailt.
- A link a megfelelő környezetre mutat. Egy éles környezetre mutató staging-üzenet előbb-utóbb éles adatokat fog módosítani.
Belépési kódok és varázslinkek
- A kódok elég hosszúak, gyorsan lejárnak, és van próbálkozási korlátjuk.
- A varázslinkek gombos céloldalt mutatnak, és az arról induló POST-tal váltják be őket, így a vizsgáló GET kérése nem árt.
- A link másik eszközön való megnyitása azt teszi, amit a terved mond, és a felhasználó látja, mi történt.
- A tárgysor csak akkor tartalmaz kódot, ha eldöntötted, hogy ez elfogadható, mert az értesítések a zárolási képernyőn megjelenítik.
E-mail-cím módosítása
- A megerősítés az új címre megy, és addig semmi nem változik, amíg meg nem erősítik.
- Értesítés megy a régi címre, hogy a valódi tulajdonos reagálhasson egy jogosulatlan módosításra.
- A függőben lévő visszaállító tokenek a módosítás után nem működnek.
- Két ideiglenes postaláda gyorssá teszi ennek kézi lefuttatását.
Meghívók, nyugták és értesítések
- A fiók nélküli személynek szóló meghívó regisztrációhoz vezet, az előre kitöltött vagy zárolt címmel, a terv szerint. A lejárt vagy visszavont meghívó ezt kimondja.
- A meghívót másik fiók nem fogadhatja el, hacsak a terved nem engedi.
- A nyugták helyes összegeket, pénznemeket, dátumokat és időzónákat mutatnak a felhasználó területi beállítása szerint, a mellékleteknek értelmes nevük van, és rendesen megnyílnak.
- A beállítások módosítása a következő küldéstől érvényesül.
- A nem létfontosságú levélnek működő leiratkozása van, a fiók- és biztonsági levél pedig egyértelműen elkülönül. A hírlevél-túlterhelésről szóló cikkünk megmutatja, hogyan néz ez ki az olvasó oldaláról.
- Minden támogatott nyelvhez létezik lefordított sablon, ahol releváns, helyes jobbról balra írású elrendezéssel, és a tárgyban nincsenek lefordítatlan töredékek.
A tokenkód átnézése
A postaládán keresztüli tesztelés a viselkedést mutatja. Egy rövid kódátnézés olyan tervezési hibákat fog meg, amelyeket egy postaláda sem mutat meg. Amikor a visszaállítás, az igazolás és a varázslinkek mögötti kódot olvasod, ezekre figyelj.
- A véletlenforrás. Kriptográfiailag biztonságos generátornak kell lennie, például
secrets.token_urlsafe(32)Pythonban,crypto.randomBytes(32)Node-ban vagyrandom_bytes(32)PHP-ban. Az időbélyeg, a növekvő azonosító vagy az e-mail hash-e nem elfogadható. - Hosszúság. A linktokenek általában legalább 128 bit véletlenszerűséget hordoznak. A hatjegyű kód csak szoros lejárattal és próbálkozási korláttal rendben.
- Tárolás. A token hash-ét tárold, hogy egy adatbázis-szivárgás ne adjon ki működő visszaállító linkeket.
- Összehasonlítás. Használj állandó idejű függvényt, például
hmac.compare_digest,hash_equalsvagycrypto.timingSafeEqual, ahol titkos értékeket közvetlenül hasonlítasz össze. - Cél. Egy igazoló token nem működhet visszaállító tokenként, és az egyik fiók tokenje nem működhet egy másikén.
- Lejárat. A lejárati időt a szerver tárolja, így a link szerkesztésével nem módosítható.
- Érvénytelenítés. A token felhasználása, a jelszó más úton való megváltoztatása vagy az e-mail-cím módosítása egyaránt törölje a függőben lévő tokeneket.
- Naplózás. A tokent tartalmazó teljes URL-ek nem kerülhetnek az alkalmazásnaplókba, az analitikai eseményekbe vagy a hibakövetőkbe. Nézd meg a HTTP-hozzáférési naplóidat is.
Fejlécek és hitelesítés
Nyisd meg a nyers forrást egy fogóban, hogy lásd, mit állított elő az alkalmazásod, és egy általad kezelt postaládában egy nagy szolgáltatónál, hogy lásd, mit tett hozzá a szolgáltató és a hálózat.
| Fejléc vagy elem | Mit ellenőrizz |
|---|---|
From | A helyes márkanév, egy általad birtokolt és hitelesített domainen |
Reply-To | Figyelt postaláda, vagy szándékosan kihagyva |
Return-Path | A visszapattanási domain, a te domainedhez igazítva, ha a DMARC-hoz az SPF-re támaszkodsz |
DKIM-Signature | Jelen van, a From domainhez illeszkedő d= domainnel |
Message-ID | Jelen van és egyedi, mert ez a nyomon követés kulcsa a szolgáltatói naplókban |
Content-Type | multipart/alternative HTML és egyszerű szöveges résszel is |
List-Unsubscribe, List-Unsubscribe-Post | Jelen van a tömeges és marketinglevelekben, az RFC 8058 szerinti egykattintásos leiratkozást támogatva |
Auto-Submitted | auto-generated az automatizált leveleken, az RFC 3834 szerint, a válaszhurkok megelőzésére |
Néhány szabály, amelyet új küldő domain kiadása előtt ellenőrizz. Egy SPF-kiértékelés nem lépheti túl a tíz DNS-lekérdezést (RFC 7208), és a korlát átlépése könnyű módja a megbukásnak, ha még egy szállítót veszel fel a rekordodba. A DKIM-hez a szolgáltató selector-rekordjának közzétettnek és ellenőrizhetőnek kell lennie. A DMARC-hoz a From domaineden kell egy rekord, amely általában p=none értékkel indul bekapcsolt jelentésekkel, és az illeszkedés megerősítése után szigorodik.
A forgalom is megváltoztatja a szabályokat. A Google irányelvei akkor tekintenek egy feladót tömegesnek, ha naponta nagyjából 5000 üzenetet küld személyes Gmail-fiókokba, és a tömeges feladóknak kell az SPF, a DKIM és a DMARC, az egykattintásos leiratkozás a promóciós leveleken, valamint a felhasználók által jelentett spamarány 0,3% alatt tartása, 0,1%-os ajánlott célértékkel. Más szolgáltatóknak saját szabályaik vannak. Az Amazon SES például 5%-os visszapattanási aránynál vagy 0,1%-os panaszaránynál felülvizsgálat alá helyez egy fiókot. Mielőtt ezekre építenél, olvasd ki az aktuális számokat a szolgáltatód dokumentációjából, mert változnak.
Címkezelés és érvényesítés
Az űrlapok az emberek gondolatánál gyakrabban utasítanak el érvényes címeket, és egy előtte lévő érvényesítési hiba pontosan úgy nézhet ki, mint egy kézbesítési hiba. Teszteld az űrlapodat ezekkel.
| Bemenet | Várt kezelés | Gyakori hiba |
|---|---|---|
user+tag@example.com | Elfogad | Egy reguláris kifejezés elutasítja a plusz jelet |
User@Example.COM | Elfogad, és a domaint kis- és nagybetű-függetlenként kezeli | Csak a kis- és nagybetűben különböző duplikált fiókok |
o'brien@example.com | Elfogad | Elutasítja, vagy megtöri a lekérdezést vagy sablont, ha nincs escape-elve |
first.last@sub.example.co.uk | Elfogad | Az érvényesítés egyetlen pontot feltételez a domainben |
| Kezdő vagy záró szóközök | Először vágd le | „Érvénytelen e-mail” egy helyes beillesztésre |
| Nagyon hosszú cím | Érvényesítsd a 64 karaktert a helyi résznél és a 254-et összesen | Egy rövid adatbázisoszlop csendben levágja |
| Nemzetköziesített domainek és címek | Elfogad vagy elutasít következetesen, érthető üzenettel | Összeomlás a kódolásban vagy a naplózásban |
| Levélútvonal nélküli domain | Figyelmeztet vagy elutasít | Olyan fiók, amely sosem tud igazolni |
Az űrlapban érvényesíts lazán, aztán hagyd, hogy az igazoló e-mail bizonyítsa, hogy a cím működik. A szigorú reguláris kifejezés valódi felhasználókat veszít neked, és nagyon keveset mond arról, hogy létezik-e a postaláda.
Ha a termékeden éles környezetben visszautasítod az eldobható domaineket, a QA-folyamatodnak is kell egy átjáró a stagingen. A lehetőségek közé tartozik a tesztdomainek engedélyezőlistája az élesen kívül, egy kapcsoló, amely a tesztkörnyezetekben kikapcsolja az ellenőrzést, vagy a saját tesztdomained. Ne gyengítsd az éles szabályt a tesztelés megkönnyítéséért. És ha azon gondolkodsz, legyen-e egyáltalán ilyen szabályod, a miért tiltják le az oldalak az eldobható e-mailt című írásunk a tulajdonos szemszögéből mutatja be a költségeket és hasznokat.
Hogyan jelenik meg
A megjelenítésnél segít a legtöbbet egy tervező átnézése, és ehhez valódi üzenetek kellenek valódi kliensekben.
- Az egyszerű szöveges rész jól olvasható, és tartalmazza a teljes linket. A „kattints az alábbi gombra” ott használhatatlan.
- A sötét mód nem tünteti el a logókat, és megőrzi a kontrasztot. A VookMailnek van sötét módja, ami kezdetnek jó, az igazi próba viszont a felhasználóid által kedvelt kliensek.
- Blokkolt képekkel a cselekvésre ösztönző elem még mindig valódi szöveges link vagy HTML-gomb.
- A gombok elég nagyok a koppintáshoz, és a hosszú URL-ek nem törik meg a telefonos elrendezést.
- Az előnézeti szöveg szándékosan van megírva, a sablon maradék szövege nélkül.
- A címsorok szemantikusak, a kontraszt elégséges, a linkszövegek leíróak, és a HTML-nek van nyelvi attribútuma.
- A hiányzó adat nem eredményez „Szia {first_name}” vagy „Szia ,” üdvözlést.
- Az üzenet mérete jóval 102 KB alatt marad, ez az a pont, ahol a Gmail a széles körben közölt adatok szerint levágja a hosszú üzeneteket. A levágás elrejtheti a láblécet és a törzsben lévő leiratkozási linket.
Védőkorlátok a balesetek ellen
A kínos e-mail-incidensek többnyire konfigurációs hibák: a staging levelei valódi ügyfelekhez jutnak, az éles tesztkulccsal fut, linkek a localhost címre mutatnak. Néhány beállítás megelőzi a legtöbbet.
Tarts külön hitelesítő adatokat környezetenként, környezeti változókban vagy titokkezelőben. Az élesen kívül használj címzett-engedélyezőlistát, hogy a levelező csak jóváhagyott tesztdomainekre kézbesítsen, minden mást pedig átirányítson vagy eldobjon. Minden linket egyetlen beállításból építs, például az APP_URL értékből, hogy a sablonokban ne legyenek beégetett hosztok. Az éles környezeten kívüli tárgyakat lásd el előtaggal, például [STAGING], hogy a rossz helyre ment üzenet bárkinek egyértelmű legyen, aki megkapja.
Ha éles adatot másolsz a stagingbe, minden valódi címet cserélj szintetikusra, mielőtt bármelyik levélküldő worker elindul. A sorrend számít, mert az először induló worker azonnal elkezdheti feldolgozni az ütemezett leveleket. És minden környezetnél tudatosan kövesd a sandbox módot. Az éles indítás sandboxban maradva klasszikus hiba: az API sikert ad vissza, a naplók tiszták, és egy levél sem megy ki.
Az automatizált tesztek maradjanak az általad kezelt infrastruktúrán
A nyilvános ideiglenes postaláda rossz függőség a CI-hez. Valaki más weboldalát lekaparni törékeny, és a buildjeid a kódodhoz nem kapcsolódó okokból bukhatnak el. Emellett a tesztforgalmadat egy olyan szolgáltatásra teszi, amelyet nem te üzemeltetsz. Az ottani üzeneteket bárki elolvashatja, aki ismeri a címet, így semmilyen automatizált dolog nem függhet tőlük.
Egy észszerű elrendezés így néz ki. A keretrendszer segédei azt ellenőrzik, hogy a megfelelő levelet kérték. A tesztkörnyezetedben lévő Mailpit-konténer fogadja a valódi üzenetet, a teszted pedig a Mailpit HTTP API-ján (GET /api/v1/messages) olvassa ki, kinyeri a linket, és követi azt. A szolgáltató tesztmódja a webhookokat és a hibakezelést gyakorolja. A saját tesztdomaineden futó éjszakai feladat a valódi szolgáltatón keresztül küld, és bejövő webhookon át olvassa az eredményt, így naponta kapsz jelzést arról, hogy a valódi kézbesítés még működik.
Az ideiglenes levelezés az emberi tesztelési részekbe való: a felfedező ülésekbe, ahol gyorsan kell egy friss identitás, a kiadás előtti füsttesztbe, egy felhasználó jelentésének reprodukálásába, a szöveg- és dizájnátnézésekbe, valamint a telefonon végzett tesztelésbe. Ez utóbbihoz a QR gomb vagy a Google Play vagy a Huawei AppGallery alkalmazás juttatja el a postaládát egy tesztkészülékre. Ellenőrizd, hogy a linkek megnyitják az alkalmazásodat, ha telepítve van, és működő weboldalra térnek vissza, ha nincs, és hogy az alkalmazás új bejelentkezés nélkül észleli az igazolt állapotot.
Teszteset, amely túléli az átadást
Az egységes tesztesetek könnyebben megismételhetők minden kiadásnál, és könnyebben adhatók át a tesztelők között. Ez a példa azokat a mezőket tartalmazza, amelyek általában számítanak.
| Mező | Példa |
|---|---|
| Teszt azonosítója | EMAIL-RESET-03 |
| Folyamat | Jelszó-visszaállítás, token újrafelhasználása |
| Előfeltételek | Igazolt tesztfiók a stagingen, friss ideiglenes címmel |
| Lépések | Kérj visszaállítást, nyisd meg a linket, állíts be új jelszót, nyisd meg ugyanazt a linket újra |
| Várt eredmény | A második használatkor elmagyarázza, hogy a link már nem érvényes, és új kérést ajánl |
| Bizonyíték | Képernyőképek, Message-ID ha elérhető, időbélyegek, használt cím |
| Környezet | Staging buildszáma és levelezési konfiguráció |
Ha a teszt azonosítóját a felhasználónévbe írod, mint az email-reset-03-x7 esetében, minden postaládát a saját esetéhez kötsz, és megakadályozod, hogy két tesztelő ugyanazon a címen ütközzön. A rövid véletlen utótag azért van ott, mert bárki megnyithat egy postaládát, ha kitalálja a nevet.
Mit ne küldj nyilvános postaládába
Bármelyik ideiglenes postaládát kezeld úgy, mintha bárki elolvashatná, aki ismeri a címet, és eszerint tesztelj.
- Csak szintetikus adatot küldj: álneveket, álrendeléseket, álcímeket. Valódi ügyféladat nem tartozik oda, és attól függően, hol működsz, a küldése jogi problémát is okozhat neked.
- Soha ne küldj API-kulcsokat, adatbázis-hitelesítő adatokat vagy valódi rendszerek adminisztrátori meghívóit.
- Rendszeresen töröld a tesztfiókokat, különösen a kiemelt jogosultságúakat. Egy nyilvános postaládához kötött admin tesztfelhasználó belépő lehet, ha valaki más megnyitja azt a postaládát, és visszaállítást kér. Mivel a cím a kiürítés után nincs számodra lefoglalva, ez a kockázat a teszt után is fennáll.
- Soha ne használj ideiglenes címet valódi éles fiók vagy a cégedre támaszkodó harmadik fél szolgáltatás tulajdonosaként.
- Ismerd a megőrzési időt. Az üzenetek és mellékletek körülbelül egy nap után törlődnek, a részleteket pedig az adatvédelmi szabályzat tartalmazza.
A saját terméked tesztelése az eldobható e-mail egyik legegyértelműbb jogos felhasználása. Maradjon is az: olyan rendszereket tesztelj, amelyek a tieid, vagy amelyek tesztelésére felhatalmazásod van. Ne használj ideiglenes postaládát arra, hogy más cégek szolgáltatásain a feltételeik ellenében fiókot hozz létre, próbaverziókat gyűjts, vagy valaki más regisztrációs űrlapját terheléses teszttel próbáld ki. A felhasználási feltételek az elfogadható használatot tárgyalják, a módszertani oldal pedig elmagyarázza, hogyan működik a szolgáltatás. A VookMail a PAYATE ingyenes eszközhálózatának része.
Kiadás előtt
- Az SPF, a DKIM és a DMARC ellenőrizve a tényleges éles küldő domainre, a
Fromdomainhez igazítva. - Az éles levelező éles hitelesítő adatokon, kikapcsolt sandbox móddal, egy valódi üzenettel megerősítve.
- A regisztrációs igazolás egy friss külső címen megérkezett, a link egyszer használva, a lejárat tesztelve.
- A jelszó-visszaállítás végponttól végpontig tesztelve, az ismeretlen címekre adott azonos válaszokkal és a megerősítő üzenettel együtt.
- A visszaállító és varázslink-tokeneket űrlapbeküldéssel váltják be, hogy a vizsgáló GET kérése ne használja fel őket.
- Az e-mail-cím módosítása az új és a régi címre is küld.
- Minden link HTTPS-en az éles hosztra mutat, a kattintáskövetés által átírtakat is beleértve.
- A tranzakciós levelezés el van választva a tömeges levelektől, legalább a sorában.
- A HTML és az egyszerű szöveg is jelen van és olvasható, ellenőrzött sötét móddal és blokkolt képekkel.
- Elhelyezési ellenőrzés a teszt fiókoknál, ha a domain vagy a sablon jelentősen változott.
- A leiratkozás működik a nem létfontosságú leveleken, és a lefordított sablonok átnézve.
- A bizonyíték csatolva a kiadási jegyhez, a visszapattanási és panaszszámok pedig egy műszerfalon, amelyet valaki figyel az indulás után.
Kérdések, amelyeket a fejlesztők feltesznek
Egy valódi postaláda elfogadta a levelemet. Biztonságban vagyok a Gmailnél?
Nem. Az egyik domainre történő kézbesítés azt mutatja, hogy az üzeneted elhagyta a rendszert, talált egy útvonalat, és ott elfogadták. A Gmail saját hitelesítési szabályokat és szűrést alkalmaz, ahogy minden más nagy szolgáltató is. Erre a kérdésre használj teszt fiókokat és a Google Postmaster Tools eszközét.
Újra felhasználhatom ugyanazt a teszt címet?
Egy munkameneten belül igen, de egy friss cím tisztább tesztet ad. A régi címek letiltási bejegyzéseket és régi üzeneteket gyűjtenek, és egy ideiglenes szolgáltatásnál a postaláda körülbelül egy nap után úgyis kiürül.
A levél megérkezik a fogómhoz, de külsőleg nem. Hol kezdjem?
A fogó azt mutatja, hogy az alkalmazásod előállított egy üzenetet, és semmi többet, ezért a szolgáltató tevékenységnaplójával kezdj. Legtöbbször a válasz egy sandbox-beállítás, egy letiltási bejegyzés, rossz hitelesítő adat, vagy egy hitelesítést megnevező SMTP-elutasítás.
Meddig legyen érvényes egy visszaállító link?
Elég rövid ideig ahhoz, hogy korlátozza a kárt, és elég hosszú ideig ahhoz, hogy a lassú levél megérkezzen. Sok csapat valahol 15 perc és egy óra közé teszi, de ez a kockázatodtól és a levelek kézbesítési sebességétől függ, a felhasználóid levele pedig a te hatókörödön túl is késhet. Bármit választasz, teszteld a lejárt állapotot, és mondd meg az embereknek, mit tegyenek ezután.