Si at teamet ditt lanserer en ny e-post for tilbakestilling av passord. QA godkjenner på staging: meldingen dukker opp, lenken virker, malen ser riktig ut. To dager etter lanseringen har kundestøtten en kø med saker. Folk med Gmail-adresser sier at e-posten aldri kom. Folk hos noen store selskaper sier at den kom, men at lenken var «allerede brukt» første gang de klikket. Ingen har endret koden mellom staging og produksjon, og alle tester består fortsatt.
Hvilken test-e-postadresse for utviklere ville fanget dette? Ingen enkeltadresse. En lokal SMTP-fanger passer til daglig utvikling, leverandørens sandkasse eller et testdomene du kontrollerer passer til automatiserte tester, og en ekte ekstern innboks passer til den manuelle sjekken av at e-posten forlater produksjonslignende oppsettet ditt og når en fremmed manns domene. En midlertidig innboks som VookMail dekker det siste tilfellet uten oppsett, fordi en adresse er klar når siden lastes. Testkontoer hos store e-postleverandører dekker så det ingen av de andre kan se. Resten av guiden handler om å velge blant disse alternativene, lese feil når de har skjedd, og sjekkene som hører hjemme i en lansering.
Hvorfor tilbakestillingen besto på staging
Staging og produksjon er sjelden så like som distribusjonsdiagrammet tilsier, og e-post avslører forskjellene mer enn de fleste funksjoner. En melding passerer gjennom applikasjonen din, en kø, en leverandør, DNS, mottakerens server og mottakerens klient. Staging kan bruke en annen versjon av nesten alle disse.
Ta den første saken, Gmail-brukerne som ikke fikk noe. Anta at staging sender gjennom et leverandørsubdomene som ble autentisert for flere måneder siden, mens produksjon sender fra et nytt From-domene som ble innført med ny merkevareprofil. Googles retningslinjer for avsendere krever at alle avsendere autentiserer med SPF eller DKIM, og Gmails feiltabell oppgir 5.7.26 for uautentisert e-post. En intern QA-postkasse på ditt eget domene kan slippe den samme meldingen gjennom, siden din egen server kan stole på ditt eget relé. Testen kunne aldri ha feilet.
Den andre saken, lenken som er «allerede brukt», har en annen årsak. Sikkerhetsporter i bedrifter åpner ofte lenker i innkommende e-post for å skanne dem før personen ser dem. Hvis lenken din løser inn tokenet ved en vanlig GET-forespørsel, bruker skanneren det opp, og den ansatte klikker på en død lenke. Ingen av dine staging-postkasser kjører den skanneren, med mindre ditt eget selskap tilfeldigvis bruker en.
Disse to feilene kan ikke ses fra samme sted. Den ene krever ekte levering til et mottakersystem du ikke driver. Den andre krever en endring i hvordan lenken oppfører seg, noe en gjennomgang fanger lettere enn en test. Det er argumentet for lagdelt testing: hver type adresse svarer på ett spørsmål og tier om de andre.
| Avviker ofte mellom staging og produksjon | Hva det kan skjule |
|---|---|
Avsenderdomene og From-adresse | Manglende eller feiljustert SPF og DKIM |
| Leverandørkonto eller underkonto | Sandkassemodus, sendegrenser, et annet IP-omdømme |
| Mottakere | Interne domener som stoler på deg, og tillatelseslister som skjuler dårlige adresser |
| Klikksporing | Omskrevne lenker som brekker, eller et sporingsdomene uten gyldig sertifikat |
| Volum | Køer og hastighetsgrenser som først gir utslag under last |
| Undertrykkelseslister | Produksjonsadresser som har bounset én gang og nå stille hoppes over |
| Innstillinger for basis-URL | Lenker som peker til feil vert |
Hvilken adresse svarer på hvilket spørsmål
Her er alternativene, hver med spørsmålet den faktisk kan svare på.
En lokal fanger: «hva produserte appen min?»
En SMTP-fanger tar imot alt appen din sender og viser det på en nettside uten å levere noe. Mailpit er et populært åpen kildekode-valg. Som standard lytter den etter SMTP på port 1025 og tilbyr nettgrensesnittet på port 8025, så du peker utviklingsinnstillingene mot localhost:1025 og åpner http://localhost:8025. Nodemailers Ethereal er en lignende idé med en vertsbasert falsk SMTP-tjeneste. En fanger er rask og privat, og den lar deg sende til hvilken som helst adresse uten risiko for å nå et ekte menneske. Den sier heller ingenting om DNS, autentisering eller filtrering, fordi ingenting krysser internett.
Et rammeverks testhjelper: «ba koden min om riktig e-post?»
De fleste rammeverk kan registrere utgående e-post i minnet under en testkjøring. Laravel har Mail::fake(), Django samler meldinger i django.core.mail.outbox, og Rails har ActionMailer::Base.deliveries. Bruk disse til å slå fast at en jobb utløses én gang med riktig mottaker og token. De gir raskest mulig tilbakemelding, og de tester enda mindre av omverdenen enn en fanger gjør.
En leverandørs testmodus: «virker integrasjonen min?»
Leverandører tilbyr ulike typer hjelp her, og forskjellene betyr noe. Amazon SES har en postkassesimulator med adresser som success@simulator.amazonses.com, bounce@simulator.amazonses.com og complaint@simulator.amazonses.com, som gir disse utfallene uten å skade omdømmet ditt. En ny SES-konto starter også i en sandkasse der den bare kan sende til verifiserte adresser. SendGrids sandkassemodus, satt gjennom mail_settings.sandbox_mode.enable, validerer forespørselen uten å levere. Postmark godtar tokenet POSTMARK_API_TEST til samme formål. Disse er gode for API-feil og for webhooks for bounce og klager, og de viser ikke at e-post nådde noen. Sjekk leverandørens egen aktuelle dokumentasjon, siden disse funksjonene endrer seg.
Et testdomene du eier: «virker hele flyten, gang på gang?»
For automatiserte ende-til-ende-tester setter du opp et domene eller subdomene du kontrollerer, med en catch-all-postkasse eller en innkommende webhook, slik at testkoden din kan lese e-posten gjennom et API. Det krever litt innsats å sette opp, men det er privat og stabilt, og det er ikke avhengig av noen andres nettsted. Ikke finn på adresser på domener du ikke eier. Noen kan eie testuser@gmail.com, og de vil motta det du sender. RFC 2606 reserverer example.com og toppnivånavnene .test og .example slik at dokumentasjon og testdata har et trygt sted å peke. Disse navnene kan ikke motta e-post, noe som gjør dem riktige for testdata og ubrukelige for leveringstester.
En ekte ekstern midlertidig innboks: «ville en fremmeds domene motta dette?»
Her fortjener en midlertidig innboks plassen sin. Det er en ekte postkasse på et domene du ikke kontrollerer og ikke har noen tillatelsesliste for. Meldingen din må finne MX-posten, opprette en SMTP-tilkobling og bli akseptert. På VookMail peker domenenes MX-poster til en leverandør av e-postlevering som mottar meldingen og videresender den over HTTPS. En ny adresse betyr også ingen historikk: ingen gamle meldinger, ingen tidligere bounce på undertrykkelseslisten din, ingen filtre. Det gjør den til en rask måte å gjenskape «jeg registrerte meg med en ny adresse og fikk ingenting». Den er også nyttig for dem som ikke er utviklere. En designer eller produktansvarlig kan lese hva en ny bruker mottar uten tilgang til verktøyene dine.
Testkontoer hos store e-postleverandører: «hvor havner den?»
En levert melding på ett domene sier ingenting om spam-mappen på et annet. Ha et lite sett med ekte kontoer hos leverandørene brukerne dine faktisk bruker, og sjekk plasseringen før større endringer i mal eller domene. Følg så med på tall for bounce og klager etter en lansering. Hvis e-posten din ser ut som et spam-problem, er det på disse kontoene du ser det først.
| Tilnærming | Krysser internett | Oppsett | Automatisering | Innholdets personvern | Best i trinn |
|---|---|---|---|---|---|
| Rammeverkets testhjelper | Nei | Ingen | Utmerket | Blir i prosessen | Enhets- og funksjonstester |
| Lokal SMTP-fanger | Nei | Lavt | God | Blir lokalt | Utvikling |
| Leverandørens testmodus | Vanligvis ikke | Lavt | God | Blir hos leverandøren | Integrasjonstester |
| Ditt eget testdomene | Ja | Middels til høyt | God | Du kontrollerer det | CI ende-til-ende, staging |
| Midlertidig innboks | Ja | Ingen | Ikke anbefalt | Regn med at den er offentlig | Manuell QA og sjekker før lansering |
| Testkontoer | Ja | Middels | Begrenset | Moderat | Plasseringssjekker |
En manuell gjennomgang med en midlertidig innboks
Her er en gjentakbar gjennomgang av en registreringsflyt på staging eller et miljø før produksjon. Det bør ta omtrent ti minutter når du kan det.
- Bekreft at miljøet bruker samme leverandøroppsett som produksjon, bortsett fra legitimasjonen, og bare inneholder oppdiktede data. Hvis ikke, skriv det ned, fordi det begrenser hva du kan konkludere.
- Åpne VookMail og trykk Ny. Skriv et brukernavn som koder testen, som
email-signup-03-x7, velg ett av de mer enn 30 domenene og trykk på pilen. Bruk den gule Tilfeldig-knappen hvis noe i e-posten kan være sensitivt, for alle som kjenner eller gjetter en adresse, kan åpne den innboksen. - Trykk Kopier og registrer deg som ny bruker med oppdiktede profildata.
- Noter tidspunktet du sendte inn og tidspunktet meldingen dukker opp. Innboksen sjekker med noen sekunders mellomrom, så et gap på minutter peker mot køen eller leverandøren din. Trykk Oppdater hvis du vil være sikker.
- Les meldingen slik en ny bruker ville gjort: avsendernavn, emne, forhåndsvisningstekst, brødtekst, knapp, vanlig lenke, bunntekst. VookMail viser oppdagede koder og bekreftelseslenker over meldingen, som er en grov sjekk på at koden og lenken din er lette å få øye på.
- Se på den med bilder av. VookMail holder bilder av til du tillater dem og fjerner skjulte sporingspiksler. Hvis meldingen ikke gir mening i den tilstanden, ser noen av brukerne dine det samme. Ikke bruk denne innboksen til å bedømme åpningssporingen din, for piklene utløses ikke.
- Trykk på QR-knappen, skann adressen med en testtelefon og åpne den samme innboksen der for å trykke på den ekte lenken på en ekte enhet, særlig hvis du bruker universelle lenker eller applenker.
- Fullfør verifiseringen og bekreft at kontoens tilstand endres som den skal.
- Kjør de negative tilfellene fra sjekklisten nedenfor: bruk lenken på nytt, vent ut utløpet, be om ny sending.
- Lagre bevisene dine: skjermbilder, tidspunkter og adressen som ble brukt. Meldinger fjernes etter omtrent ett døgn, så en feilrapport skrevet neste uke har ingenting å peke på.
- Trykk Slett og fjern testkontoen hvis prosessen din krever det.
Flere adresser kan holdes i én nettleser, så en som inviterer og en som blir invitert, eller den gamle og nye adressen i en e-postendring, kan være åpne samtidig. Hvis du legger ved filer i testen, husk at VookMail avviser vanlige programfiler som .exe og viser en advarsel på arkiver, så et avvist vedlegg der er ikke nødvendigvis en feil hos deg.
Å lese en feil
«E-posten kom aldri» beskriver et symptom på et av omtrent seks steder, og team taper timer på å begynne på feil sted. Gå langs veien fra koden din og utover, og stopp ved det første stedet der du ikke lenger kan se meldingen.
- Prøvde appen? Søk i applikasjonsloggen etter sendeforsøket og eventuelle unntak. Se etter en jobb som aldri ble opprettet, ofte fordi en betingelse eller et funksjonsflagg var usant.
- Kjørte arbeideren? Se etter fastlåste, feilede eller gjentatte jobber. En køarbeider som ikke ble startet på nytt etter en distribusjon, kan kjøre gammel kode, og en regel for nye forsøk kan sende duplikater.
- Godtok leverandøren den? Slå opp mottakeren eller
Message-IDi leverandørens aktivitetslogg. Akseptert, utsatt, bounset og droppet er fire ulike historier. - Ble den undertrykt? Hvis adressen har bounset eller klaget før, hopper mange leverandører stille over fremtidige utsendelser. Dette tar ofte testere som gjenbruker en gammel adresse.
- Hva sa mottakerserveren? Leverandørlogger viser vanligvis SMTP-svaret, og den teksten er den mest nyttige linjen i hele undersøkelsen.
- Er DNS riktig? Sjekk SPF, DKIM og DMARC for det faktiske avsenderdomenet.
- Er den der, men skjult? Spam-mapper, faner og klientfiltre kommer sist, når en testkonto kan vise deg det.
Hva SMTP-svaret forteller deg
Etter RFC 5321 er et svar som begynner med 4 en midlertidig feil, og avsenderen bør prøve igjen senere. Et svar som begynner med 5, er permanent. De utvidede statuskodene fra RFC 3463 legger til detaljer etter det. En oppdiktet loggelinje kan se slik ut, bare som et eksempel på formatet:
Bare et eksempel: to=user@gmail.example status=bounced reply="550 5.7.26 unauthenticated sender"
Les den fra venstre mot høyre. 5-tallet betyr at nye forsøk ikke hjelper. 5.7-familien gjelder sikkerhet eller policy, som sender deg til DNS og signering, og bort fra mottakerens adresse. Tabellen nedenfor gir deg et utgangspunkt for vanlige mønstre.
| Hva du ser | Mest sannsynlig lag | Første sted å se |
|---|---|---|
| Ingenting i leverandørloggen | App eller kø | Applikasjonsloggene og feilede jobber |
| Leverandøren sier «dropped» eller «suppressed» | Leverandørens undertrykkelsesliste | Fjern testadressen, eller bruk en ny |
| API-et returnerer suksess, men ingenting logges noen gang som sendt | Sandkassemodus er fortsatt på | Leverandørens innstillinger for det miljøet |
5.1.1 eller lignende | Mottakeradressen | Skrivefeil, og skjemavalidering som endret adressen |
5.7.26 hos Gmail | Autentisering | SPF, DKIM og samsvar med From-domenet |
4xx-utsettelser som forsvinner etter en stund | Mottakeren bremser deg | Volum, omdømme eller en ny sender-IP |
| Levert i en ekstern innboks, mangler hos Gmail | Mottakerens policy eller filtrering | Testkontoer og Googles retningslinjer for avsendere |
| Kommer frem, men lenken sier «allerede brukt» | Skanner som forhåndshenter lenken | Løs inn tokens med POST, ikke GET |
| Lenken fører til en sikkerhetsadvarsel | Klikksporingsdomene | Sertifikat på sporingssubdomenet |
| Kommer to ganger | Logikk for nye forsøk | Idempotens i jobben og tidsavbruddene som utløser nye forsøk |
| Kommer svært sent | Kø | Arbeiderkapasitet, og om tilbakestillings-e-post deler kø med masseutsendelser |
Den siste raden er et designpoeng som fortjener en setning til. Hvis tilbakestilling av passord deler kø med en nyhetsbrevutsendelse, venter den bak den. Gi transaksjonse-post sin egen kø, og helst sitt eget subdomene og sin egen sendestrøm, slik at et markedsføringsproblem ikke forsinker en pålogging.
Kommandoer som forkorter søket
Du kan sjekke det meste av dette uten å forlate terminalen. I disse eksemplene bytter du ut eksempelnavnene med dine egne.
dig +short MX example.comviser hvor et domene mottar e-post. Et tomt svar krever en nærmere titt, siden RFC 5321 lar avsendere falle tilbake på en adressepost, mens et svar med0 .er en null-MX etter RFC 7505, som betyr at domenet ikke tar imot e-post i det hele tatt.dig +short TXT example.comviser SPF-posten blant andre tekstposter.dig +short TXT selector._domainkey.example.comviser en DKIM-nøkkel. Ta den ekte selektoren fras=-verdien i meldingensDKIM-Signature-topptekst.dig +short TXT _dmarc.example.comviser DMARC-policyen.openssl s_client -starttls smtp -connect smtp.example.com:587sjekker at du når reléet ditt og viser sertifikatet. En feil her betyr et brannmur- eller TLS-problem, lenge før noe om innhold.swaks --to qa@example.test --from app@example.test --server localhost:1025sender en enkel melding for hånd. Den går utenom appen din, så du kan se om et problem hører til koden din eller til ruten.
For bevis på topptekstnivå er den mest pålitelige visningen en postkasse du kontrollerer hos en stor leverandør. I Gmail åpner du meldingen, bruker trepunktsmenyen og velger Vis original, som viser SPF-, DKIM- og DMARC-resultater øverst. Husk at én mottakers «bestått» ikke garanterer en annens.
Hva du skal sjekke i hver flyt
«Kom den frem?» er det første spørsmålet, og som regel det minst interessante. Hver flyt har sine egne måter å gå galt på etter det.
Tilbakestilling av passord
OWASP Forgot Password Cheat Sheet er referansen å bygge på her. Den ber om en konsekvent melding enten kontoen finnes eller ikke, svar som tar like lang tid, tokens som er tilfeldige, lange, lagret sikkert og kan brukes bare én gang, og Referrer-Policy: no-referrer på tilbakestillingssiden.
- Forespørselssiden viser den samme meldingen for registrerte og uregistrerte adresser, og tar omtrent like lang tid. Et umiddelbart svar for ukjente adresser lekker like mye som ordlyden ville gjort.
- Lenken virker én gang. Åpner du den en gang til, får du en tydelig forklaring med en måte å be om en ny på.
- En ny tilbakestillingsforespørsel gjør eldre lenker ugyldige, eller designet ditt sier noe annet med vilje.
- Utløpet håndheves av serveren og er testet ved å vente, eller ved å endre klokken i et testmiljø.
- En vellykket tilbakestilling sender en bekreftelse på e-post, og andre økter håndteres etter policyen din.
- Å åpne lenken endrer ikke noe i seg selv. Tokenet løses inn når skjemaet sendes inn.
- Tilbakestillingssiden sender ikke URL-en sin til tredjeparts analyse eller feilsporing.
- Hastighetsgrenser gjelder per konto så vel som per IP, slik at ingen kan oversvømme innboksen til en fremmed.
- Adresser med blandet store og små bokstaver eller plusstegn fungerer likt som enkle adresser.
Verifisering ved registrering
- Én registrering sender én melding, også når jobben forsøkes på nytt.
- Lenken eller koden virker én gang, og siden for utløpt lenke viser en vei videre.
- En ny sending gjør enten den forrige tokenen ugyldig eller sameksisterer med den som tenkt, og er hastighetsbegrenset.
- Uverifiserte kontoer har nøyaktig de begrensningene du hadde tenkt.
- En ny registrering med en registrert adresse forteller ikke en anonym besøkende at kontoen finnes, hvis produktet ditt behandler det som sensitivt. Et vanlig mønster er å sende e-post til den eksisterende eieren i stedet.
- Lenken peker til riktig miljø. En staging-melding som lenker til produksjon, vil før eller siden endre produksjonsdata.
Påloggingskoder og magiske lenker
- Koder er lange nok, utløper raskt og har en grense for antall forsøk.
- Magiske lenker viser en landingsside med en knapp og løser inn ved den POST-en, slik at en skanners GET ikke gjør skade.
- Å åpne lenken på en annen enhet gjør det designet ditt sier, og brukeren kan se hva som skjedde.
- Emnefeltet har en kode bare hvis du har bestemt at det er akseptabelt, siden varsler viser det på låseskjermer.
Endring av e-postadresse
- Bekreftelsen går til den nye adressen, og ingenting endres før den er bekreftet.
- Et varsel går til den gamle adressen, slik at den virkelige eieren kan reagere på en uautorisert endring.
- Utestående tilbakestillingstokens slutter å virke etter endringen.
- To midlertidige innbokser gjør denne enkel å kjøre for hånd.
Invitasjoner, kvitteringer og varsler
- En invitasjon til en person uten konto fører til registrering med adressen forhåndsutfylt eller låst, slik det er tenkt. En utløpt eller tilbakekalt invitasjon sier det.
- En invitasjon kan ikke aksepteres av en annen konto med mindre designet ditt tillater det.
- Kvitteringer viser riktige beløp, valutaer, datoer og tidssoner for brukerens språkområde, og vedlegg har fornuftige navn og åpnes riktig.
- Endringer i innstillinger trer i kraft ved neste utsendelse.
- Ikke-essensiell e-post har en fungerende avmelding, og konto- og sikkerhetse-post er tydelig adskilt. Artikkelen vår om nyhetsbrevoverbelastning viser hvordan det ser ut fra leserens side.
- Oversatte maler finnes for hvert støttede språk, med riktig høyre-til-venstre-layout der det er relevant, og ingen uoversatte biter i emnefeltet.
Gjennomgang av tokenkoden
Testing gjennom en innboks viser oppførsel. En kort kodegjennomgang fanger designfeil ingen innboks vil vise deg. Når du leser koden bak tilbakestilling, verifisering og magiske lenker, se etter disse.
- Den tilfeldige kilden. Den bør være en kryptografisk sikker generator, som
secrets.token_urlsafe(32)i Python,crypto.randomBytes(32)i Node ellerrandom_bytes(32)i PHP. Et tidsstempel, en økende ID eller en hash av e-postadressen er ikke akseptabelt. - Lengde. Lenketokens har ofte minst 128 biter tilfeldighet. En sekssifret kode er greit bare med stramt utløp og en grense for forsøk.
- Lagring. Lagre en hash av tokenet, slik at en databaselekkasje ikke deler ut fungerende tilbakestillingslenker.
- Sammenligning. Bruk en funksjon med konstant tid som
hmac.compare_digest,hash_equalsellercrypto.timingSafeEqualder du sammenligner hemmelige verdier direkte. - Formål. Et verifiseringstoken må ikke virke som et tilbakestillingstoken, og et token for én konto må ikke virke for en annen.
- Utløp. Serveren holder utløpstidspunktet, slik at det ikke kan endres ved å redigere lenken.
- Ugyldiggjøring. Bruk av tokenet, en passordendring på en annen vei eller en e-postendring bør alle annullere utestående tokens.
- Logging. Fullstendige URL-er med tokens skal ikke havne i applikasjonslogger, analysehendelser eller feilsporere. Sjekk HTTP-tilgangsloggene dine også.
Topptekster og autentisering
Åpne råkilden i en fanger for å se hva appen din produserte, og i en postkasse du kontrollerer hos en stor leverandør for å se hva leverandøren og nettverket la til.
| Topptekst eller element | Hva du skal verifisere |
|---|---|
From | Riktig merkenavn, på et domene du eier og autentiserer |
Reply-To | En overvåket postkasse, eller utelatt med vilje |
Return-Path | Bounce-domenet, justert med domenet ditt hvis du er avhengig av SPF for DMARC |
DKIM-Signature | Til stede, med et d=-domene som samsvarer med From-domenet |
Message-ID | Til stede og unik, siden den er nøkkelen din for sporing i leverandørlogger |
Content-Type | multipart/alternative med både HTML- og ren tekst-deler |
List-Unsubscribe, List-Unsubscribe-Post | Til stede på masse- og markedsføringse-post, med støtte for avmelding med ett klikk etter RFC 8058 |
Auto-Submitted | auto-generated på automatisk e-post, som definert i RFC 3834, for å hindre svarløkker |
Noen regler å sjekke før du slipper et nytt avsenderdomene. En SPF-evaluering kan ikke overstige ti DNS-oppslag (RFC 7208), og å gå over grensen er en enkel måte å feile på etter at du har lagt til enda en leverandør i posten din. DKIM trenger at leverandørens selektorpost er publisert og kan verifiseres. DMARC trenger en post på From-domenet ditt, vanligvis med p=none til å begynne med og rapporter slått på, og strammet inn når samsvar er bekreftet.
Volum endrer også reglene. Googles retningslinjer regner en avsender som masseavsender ved omtrent 5000 meldinger til personlige Gmail-kontoer på en dag, og masseavsendere trenger SPF, DKIM og DMARC, avmelding med ett klikk på reklame-e-post og en brukerrapportert spamandel holdt under 0,3 %, med 0,1 % som anbefalt mål. Andre leverandører har egne regler. Amazon SES setter for eksempel en konto under gjennomgang ved en bounce-rate på 5 % eller en klagerate på 0,1 %. Les aktuelle tall i leverandørens dokumentasjon før du planlegger rundt dem, siden de endrer seg.
Håndtering og validering av adresser
Skjemaer avviser gyldige adresser oftere enn folk er klar over, og en valideringsfeil tidligere i kjeden kan se akkurat ut som en leveringsfeil. Test dine med disse.
| Inndata | Forventet håndtering | Vanlig feil |
|---|---|---|
user+tag@example.com | Godta | Et regulært uttrykk avviser plusstegnet |
User@Example.COM | Godta, og behandle domenet som ufølsomt for store og små bokstaver | Dupliserte kontoer som bare skiller seg i store og små bokstaver |
o'brien@example.com | Godta | Avvist, eller ødelegger en spørring eller mal hvis den ikke escapes |
first.last@sub.example.co.uk | Godta | Valideringen antar ett enkelt punktum i domenet |
| Innledende eller avsluttende mellomrom | Trim først | «Ugyldig e-post» på en riktig innliming |
| En svært lang adresse | Håndhev 64 tegn for den lokale delen og 254 totalt | En kort databasekolonne kutter den stille |
| Internasjonaliserte domener og adresser | Godta eller avvis konsekvent, med en tydelig melding | Krasj i koding eller logging |
| Et domene uten e-postrute | Advar eller avvis | En konto som aldri kan verifiseres |
Valider løst i skjemaet, og la bekreftelses-e-posten bevise at adressen virker. Et strengt regulært uttrykk koster deg ekte brukere og forteller deg svært lite om en postkasse finnes.
Hvis produktet ditt avviser engangsdomener i produksjon, trenger QA-prosessen din likevel en vei gjennom på staging. Alternativer er en tillatelsesliste over testdomener utenfor produksjon, et flagg som slår av sjekken i testmiljøer, eller ditt eget testdomene. Ikke svekk produksjonsregelen for å gjøre testing enklere. Og hvis du vurderer om du i det hele tatt skal ha den regelen, setter artikkelen vår om hvorfor nettsteder blokkerer engangs-e-post opp kostnadene og fordelene fra eierens perspektiv.
Hvordan den vises
Visning er der en designers gjennomgang hjelper mest, og den krever ekte meldinger i ekte klienter.
- Ren tekst-delen leses godt og inneholder hele lenken. «Klikk på knappen nedenfor» er ubrukelig der.
- Mørk modus holder logoer synlige og bevarer kontrasten. VookMail har mørk modus, som er en start, og klientene brukerne dine foretrekker, er den virkelige testen.
- Med bilder blokkert er handlingsoppfordringen fortsatt en ekte tekstlenke eller en HTML-knapp.
- Knapper er store nok til å trykke på, og lange URL-er ødelegger ikke layouten på telefon.
- Forhåndsvisningsteksten er skrevet med vilje, uten rester av malspråk.
- Overskrifter er semantiske, kontrasten er tilstrekkelig, lenketeksten er beskrivende, og HTML-en har et språkattributt.
- Manglende data gir ikke «Hei {first_name}» eller «Hei ,».
- Meldingsstørrelsen holder seg godt under omtrent 102 KB, grensen der Gmail etter det som er mye rapportert, klipper lange meldinger. Klipping kan skjule bunnteksten og en eventuell avmeldingslenke i brødteksten.
Sikkerhetsnett mot uhell
Pinlige e-posthendelser er stort sett konfigurasjonsfeil: staging-e-post som når ekte kunder, produksjon på en testnøkkel, lenker til localhost. Noen få innstillinger forhindrer de fleste.
Hold separate legitimasjoner per miljø, i miljøvariabler eller en hemmelighetsbehandler. Utenfor produksjon bruker du en mottakertillatelsesliste slik at e-postsenderen bare leverer til godkjente testdomener og omdirigerer eller dropper alt annet. Bygg hver lenke fra én innstilling, som APP_URL, slik at maler ikke har hardkodede verter. Sett et prefiks som [STAGING] foran emnet utenfor produksjon, slik at en feilrettet melding er tydelig for den som mottar den.
Hvis du kopierer produksjonsdata til staging, bytt ut hver ekte adresse med en syntetisk før noen e-postarbeider starter. Rekkefølgen betyr noe, for en arbeider som starter først, kan begynne å jobbe seg gjennom planlagt e-post med en gang. Og hold bevisst orden på sandkassemodus for hvert miljø. Å lansere med produksjon fortsatt i sandkassen er en klassiker: API-et returnerer suksess, loggene ser rene ut, og ingen e-post går ut.
Automatiserte suiter bør holde seg på infrastruktur du kontrollerer
En offentlig midlertidig innboks er feil avhengighet for CI. Å skrape en annens nettside er skjørt, og byggene dine ville feilet av grunner som ikke har noe med koden din å gjøre. Det legger også testtrafikken din på en tjeneste du ikke driver. Meldinger der kan leses av alle som har adressen, så ingenting automatisert bør være avhengig av dem.
Et fornuftig oppsett ser slik ut. Rammeverkets hjelpere slår fast at riktig e-post blir bedt om. En Mailpit-container i teststakken din mottar den ekte meldingen, og testen din leser den gjennom Mailpits HTTP-API (GET /api/v1/messages), trekker ut lenken og følger den. Leverandørens testmodus øver på webhooks og feilhåndtering. En nattlig jobb på ditt eget testdomene sender gjennom den ekte leverandøren og leser resultatet gjennom en innkommende webhook, så du får et daglig signal om at ekte levering fortsatt virker.
Midlertidig e-post hører hjemme i de menneskelige delene av testingen: utforskende økter der du raskt trenger en ny identitet, en røyktest før lansering, gjenskaping av en brukers rapport, gjennomgang av tekst og design, og testing på telefon. For det siste får QR-knappen eller appen fra Google Play eller Huawei AppGallery innboksen over på en testenhet. Sjekk at lenker åpner appen din når den er installert og faller tilbake til en fungerende nettside når den ikke er det, og at appen merker den verifiserte statusen uten å kreve en ny pålogging.
Et testtilfelle som overlever en overlevering
Konsekvente testtilfeller er lettere å gjenta for hver lansering og å gi videre mellom testere. Dette eksemplet har feltene som pleier å telle.
| Felt | Eksempel |
|---|---|
| Test-ID | EMAIL-RESET-03 |
| Flyt | Tilbakestilling av passord, gjenbruk av token |
| Forutsetninger | Verifisert testkonto på staging, med en ny midlertidig adresse |
| Trinn | Be om en tilbakestilling, åpne lenken, sett et nytt passord, åpne den samme lenken igjen |
| Forventet resultat | Den andre bruken forklarer at lenken ikke lenger er gyldig og tilbyr en ny forespørsel |
| Bevis | Skjermbilder, Message-ID hvis tilgjengelig, tidspunkter, adressen som ble brukt |
| Miljø | Byggnummer for staging og e-postkonfigurasjon |
Å putte test-ID-en i brukernavnet, som i email-reset-03-x7, knytter hver innboks til sitt tilfelle og hindrer at to testere kolliderer på én adresse. Det korte tilfeldige suffikset er der fordi alle kan åpne en innboks hvis de gjetter navnet.
Hva du ikke skal sende til en offentlig innboks
Behandle enhver midlertidig innboks som lesbar for alle som kjenner adressen, og test deretter.
- Send bare syntetiske data: falske navn, falske bestillinger, falske adresser. Ekte kundedata hører ikke hjemme der, og avhengig av hvor du opererer, kan det å sende dem også skape et juridisk problem for deg.
- Send aldri API-nøkler, databaselegitimasjon eller admin-invitasjoner til ekte systemer.
- Slett testkontoer jevnlig, særlig privilegerte. En admin-testbruker knyttet til en offentlig innboks er en vei inn hvis noen andre åpner den innboksen og ber om en tilbakestilling. Siden adressen ikke er reservert for deg når den er tømt, består denne risikoen etter testen.
- Bruk aldri en midlertidig adresse som eier av en ekte produksjonskonto eller en tredjepartstjeneste selskapet ditt er avhengig av.
- Kjenn oppbevaringstiden. Meldinger og vedlegg forsvinner etter omtrent ett døgn, og personvernerklæringen har detaljene.
Å teste ditt eget produkt er en av de klareste legitime bruksområdene for engangs-e-post. Hold det slik: test systemer du eier eller har tillatelse til å teste. Ikke bruk midlertidige innbokser til å opprette kontoer hos andre selskapers tjenester i strid med vilkårene deres, til å samle prøveperioder eller til å lasttest andres registreringsskjema. Vilkårene og betingelsene dekker akseptabel bruk, og metodesiden forklarer hvordan tjenesten fungerer. VookMail er en del av PAYATE-nettverket av gratis verktøy.
Før du lanserer
- SPF, DKIM og DMARC verifisert for det faktiske produksjonsavsenderdomenet, med
From-domenet i samsvar. - Produksjonssenderen på produksjonslegitimasjon, med sandkassemodus av, bekreftet med en ekte melding.
- Registreringsverifisering mottatt på en ny ekstern adresse, lenke brukt én gang, utløp testet.
- Tilbakestilling av passord testet ende til ende, inkludert identiske svar for ukjente adresser og bekreftelsesmeldingen.
- Tokens for tilbakestilling og magiske lenker løst inn ved innsending av skjema, slik at en skanners GET ikke bruker dem opp.
- Endring av e-post sender til både den nye og den gamle adressen.
- Alle lenker peker til produksjonsverten over HTTPS, også de som er omskrevet av klikksporing.
- Transaksjonse-post skilt fra masseutsendelser, i det minste i køen.
- HTML og ren tekst begge til stede og lesbare, med mørk modus og blokkerte bilder sjekket.
- En plasseringssjekk på testkontoer hvis domenet eller malen er endret betydelig.
- Avmelding fungerer på ikke-essensiell e-post, og oversatte maler er gjennomgått.
- Bevis lagt ved lanseringssaken, og tall for bounce og klager på et dashbord noen vil følge med på etter lanseringen.
Spørsmål utviklere stiller om dette
En ekte innboks tok imot e-posten min. Er jeg trygg hos Gmail?
Nei. Levering til ett domene viser at meldingen din forlot systemet, fant en rute og ble akseptert der. Gmail bruker sine egne autentiseringsregler og filtrering, og det gjør alle andre store leverandører også. Bruk testkontoer og Googles Postmaster Tools til det spørsmålet.
Kan jeg gjenbruke den samme testadressen?
Du kan innenfor en økt, men en ny adresse gir en renere test. Gamle adresser samler undertrykkelsesoppføringer og gamle meldinger, og på en midlertidig tjeneste tømmes innboksen etter omtrent ett døgn uansett.
E-post kommer frem til fangeren min, men ikke eksternt. Hvor bør jeg begynne?
En fanger viser at appen din produserte en melding og ingenting utover det, så begynn med leverandørens aktivitetslogg. Som oftest er svaret en sandkasseinnstilling, en undertrykkelsesoppføring, feil legitimasjon eller et SMTP-avslag som nevner autentisering.
Hvor lenge bør en tilbakestillingslenke være gyldig?
Kort nok til å begrense skaden og lang nok til at langsom e-post rekker frem. Mange team lander et sted mellom 15 minutter og en time, men det avhenger av risikoen din og av hvor raskt e-posten din leveres, og brukernes e-post kan bli forsinket utenfor din kontroll. Uansett hva du velger, test tilstanden for utløpt lenke og fortell folk hva de skal gjøre videre.