Ta én melding. En oppdiktet nettbutikk, Bright Parcel, har nettopp fått en besøkende som registrerte seg med adressen quietfox42@veylax.com, og systemet trykker det som tilsvarer Send på en bekreftelsesmelding. Litt senere ligger meldingen på den besøkendes skjerm, og et døgn etter det finnes den ikke lenger noe sted hos innboks-tjenesten. Denne artikkelen følger den hele veien.
Hvordan fungerer da midlertidig e-post? Den bruker det vanlige maskineriet for e-post på internett med ett vri: mottakersiden tar imot post til et hvilket som helst brukernavn på domenene sine og beholder den bare en kort stund. Avsenderens server slår opp domenets MX-post i DNS, kobler seg til verten som er oppført over SMTP på port 25, og leverer meldingen. Systemet for midlertidig e-post tolker den så, viser den i en innboks og sletter den etter en tidsplan. Hos VookMail peker domenenes MX-poster til en leverandør av e-postlevering, som tar imot SMTP-økten og sender hver melding videre til VookMail over HTTPS.
Trinn 1: Å forlate avsenderen
Bright Parcels applikasjon bygger meldingen. En melding er strukturert tekst, lagt opp etter Internet Message Format (RFC 5322): overskrifter som From, To og Subject, så en tom linje, så selve teksten. Applikasjonen leverer den vanligvis ikke direkte. Den gir den videre til en tjeneste for utgående e-post, enten over en autentisert SMTP-tilkobling på port 587 (eller 465 med TLS fra første stund) eller gjennom avsenderfirmaets nett-API.
Den første forsinkelsen kan oppstå allerede her. Mange applikasjoner legger utgående post i en jobbkø og arbeider seg gjennom den i omganger, særlig markedsføringsplattformer. Øyeblikket et nettsted sier «sjekk e-posten din», kan derfor ligge et stykke foran øyeblikket posten forlater det. I eksempelet vårt sier vi at køen bruker tjue sekunder. Ingenting har nådd mottakersiden ennå, og ingen tjeneste for midlertidig e-post kan se det eller få det til å gå fortere.
Trinn 2: Å finne ut hvor veylax.com tar imot post
Den utgående serveren leser delen etter @, her veylax.com, og spør DNS om domenets MX-poster. En MX-post (mail exchanger) navngir en server som tar imot post for domenet. I sonefilnotasjon kan et domenes poster se slik ut. Navnene er funnet på for illustrasjonens skyld:
example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.
3600 er TTL (time to live), antall sekunder en resolver kan mellomlagre dette svaret. 10 og 20 er preferanser: avsendere prøver det laveste tallet først og faller tilbake på det høyere hvis den første ikke er tilgjengelig. Vertsnavnet må ha sin egen A-post (IPv4) eller AAAA-post (IPv6). En MX-post bør peke til et vertsnavn, og ikke direkte til en IP-adresse eller et CNAME-alias.
Du kan kjøre dette oppslaget selv for et hvilket som helst domene:
| System | Kommando |
|---|---|
| Windows Ledetekst | nslookup -type=mx example.com |
| Windows PowerShell | Resolve-DnsName example.com -Type MX |
| macOS og Linux | dig MX example.com +short |
Systemer mot misbruk bruker det samme oppslaget til å oppdage domener som sender post til kjent infrastruktur for engangsadresser. Det er én grunn til at noen nettsteder kjenner igjen domener for midlertidig e-post selv når selve domenet er nytt.
To spesialtilfeller i DNS
Et domene uten MX-post er ikke automatisk uten kontakt. RFC 5321, SMTP-standarden, definerer en reserveløsning: avsenderen kan behandle domenets egen A- eller AAAA-post som en underforstått e-postvert. Et domene som ikke vil ha post i det hele tatt, kan si det med en null-MX (RFC 7505), som er en MX-post med preferanse 0 og et enkelt punktum som vert. Domener for midlertidig e-post publiserer vanlige MX-poster, selvsagt, siden mottak er hele poenget deres.
Mellomlagring kan også komme i veien når en tjeneste legger til et domene. Resolvere som nylig fikk svaret «ingen slik post», kan beholde det til den negative mellomlagringstiden går ut, styrt av domenets SOA-post (RFC 2308). Et helt nytt domene kan derfor trenge litt tid før det mottar pålitelig fra alle avsendere.
Trinn 3: Samtalen mellom to servere
Bright Parcels utgående server åpner nå en TCP-tilkobling til den foretrukne MX-verten på port 25. SMTP er en tekstprotokoll: klienten sender kommandoer, og serveren svarer med nummererte svar. Her er en forenklet økt for meldingen vår, der S: er mottakeren og C: er avsenderen. Vertene og størrelsestallet hører til dette oppdiktede eksempelet.
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-håndtrykk, deretter EHLO på nytt)
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: (overskrifter, tom linje, tekst, så en linje med bare ett punktum)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye
| Kommando | Formål | Hva det betyr for midlertidig e-post |
|---|---|---|
EHLO | Identifiserer avsenderen og spør hva serveren støtter | Svaret lister utvidelser som STARTTLS og største SIZE |
STARTTLS | Oppgraderer tilkoblingen til TLS (RFC 3207) | Beskytter dette ene leddet. Det er ikke ende-til-ende-kryptering |
MAIL FROM | Setter konvoluttavsenderen, dit returpost går | Er ofte en annen enn den synlige Fra-linjen, særlig for massesendere |
RCPT TO | Navngir en mottaker | En catch-all-mottaker svarer 250 for et hvilket som helst brukernavn på domenene sine |
DATA | Starter meldingsinnholdet | Slutter med ett enkelt punktum på en egen linje |
QUIT | Avslutter økten | Leveringen var allerede avgjort av 250 etter DATA |
Øyeblikket ansvaret skifter hender
Det siste 250-svaret er den viktigste linjen i økten. Fram til da tilhører meldingen Bright Parcels server, og hvis tilkoblingen faller, prøver den på nytt. Etter det har mottakeren tatt på seg ansvaret. Avsenderens kontrollpanel vil nå vanligvis si «levert», noe som bare betyr at dette leddet lyktes. Det betyr ikke at et menneske har sett noe.
Svarkodene forklarer mye av det folk opplever:
- 2xx er suksess, og
250betyr godtatt. - 3xx er et mellomtrinn, og
354ber avsenderen overføre meldingen. - 4xx er en midlertidig feil, for eksempel
421eller451. Avsenderen beholder meldingen i køen sin og prøver på nytt. - 5xx er en varig feil, for eksempel
550(postkassen er utilgjengelig eller avvist) eller552(for stor). Avsenderen gir opp og lager vanligvis en returmelding.
Forskjellen mellom 4xx og 5xx forklarer det meste av «treg» post. Hadde mottakeren svart 451 på dette punktet, kanskje på grunn av greylisting (RFC 6647), ville meldingen vår ligget i Bright Parcels kø, verken tapt eller levert. RFC 5321 anbefaler et gjentaksintervall på vanligvis minst 30 minutter og en oppgivelsestid på minst fire til fem dager, selv om virkelige systemer setter sine egne tidsplaner, og mange prøver tidligere. Derfor kan én bekreftelse dukke opp etter noen sekunder og den neste etter tjue minutter, uten at noe er galt i noen av tilfellene.
To sett med adresser
SMTP har to lag med adressering. Konvolutten, MAIL FROM og RCPT TO, er det serverne bruker til ruting. Overskriftene, From:, To: og Subject:, er en del av meldingsinnholdet og er det du ser på skjermen. De kan være forskjellige. Et nyhetsbrev kan vise To: subscribers selv om konvoluttmottakeren var den midlertidige adressen din. Et mottakende system sorterer derfor meldinger etter konvoluttmottaker, den pålitelige verdien. Det er også grunnen til at overskriften Return-Path, som legges til ved sluttlevering, registrerer konvoluttavsenderen og ikke den synlige Fra-adressen.
Trinn 4: Hvorfor quietfox42 ikke trengte å finnes
Ved RCPT TO sjekker en vanlig e-postserver om postkassen finnes, og svarer 550 hvis den ikke gjør det. Et domene for midlertidig e-post fungerer motsatt. Det kjører som en catch-all-mottaker, eller jokertegn-mottaker: hver lokaldel (delen før @) godtas.
Akkurat dette valget gjør øyeblikkelige adresser mulig. Når VookMail viser deg en tilfeldig adresse, trengte ingenting å opprettes på noen e-postserver. Når du trykker Ny, skriver ditt eget brukernavn, velger et domene og trykker på pilen, «finnes» det navnet allerede, fordi domenet godtar alle navn. Applikasjonen trenger bare å vise deg meldingene der mottakeren samsvarer med adressen på skjermen din.
To små regler gjelder for disse navnene. Standarden sier at en lokaldel kan skille mellom store og små bokstaver, men nesten alle virkelige systemer behandler Test@ og test@ som én postkasse, så et system for midlertidig e-post normaliserer fornuftig nok bokstavstørrelsen for å hindre at en avsenders store bokstaver deler en innboks i to. Og RFC 5321 begrenser lokaldelen til 64 oktetter, med en praktisk grense på 254 tegn for en hel adresse, så genererte navn bør holde seg godt innenfor.
Trinn 5: Fra e-postprotokoll til nettforespørsel
Meldingen vår er nå godtatt av en maskin som snakker SMTP. Nettstedet som viser innboksen, er en nettapplikasjon. Noe må koble de to sammen.
Å drive en e-postserver som vender mot hele internett er skikkelig arbeid: TLS, flom av tilkoblinger, køer, skadevare og det å holde et godt omdømme. Derfor overlater mange moderne applikasjoner SMTP-delen til en spesialisert leverandør for innkommende post og mottar meldinger som nettforespørsler, et mønster som ofte kalles en inbound parse webhook. VookMail bruker denne modellen. Slik fungerer den:
- Leverandørens MX-verter tar imot meldingen fra avsenderens server, som i økten ovenfor.
- Leverandøren pakker den, enten som rå MIME-kilde eller som ferdig tolkede felt som avsender, mottakere, emne, tekst, HTML og vedlegg.
- Den sender pakken i en HTTPS POST til et endepunkt drevet av applikasjonen for midlertidig e-post, som krypterer innholdet mellom de to punktene.
- Applikasjonen svarer med en suksessstatus. Hvis den ikke er tilgjengelig eller gir en feil, prøver en veloppdragen leverandør på nytt etter sin egen policy.
- Applikasjonen validerer forespørselen, kobler mottakeren til en adresse og lagrer meldingen midlertidig.
| Hensyn | Egen SMTP-mottaker | Leverandør for innkommende post pluss HTTPS |
|---|---|---|
| Eksponering | Port 25 åpen for alle verter på internett | Leverandøren tar SMTP-trafikken, og appen ser bare HTTPS-forespørsler |
| Trafikktopper | Driveren må sørge for kapasitet | Leverandørens infrastruktur håndterer byger |
| MIME-tolking | Driveren skriver eller vedlikeholder en parser | Gjøres ofte av leverandøren, selv om rå kilde fortsatt kan brukes |
| Passer til en nettapplikasjon | Trenger en bro fra postkø til app | Meldingen kommer som en hvilken som helst API-forespørsel |
| Avhengighet | Færre utenforstående parter | Er avhengig av leverandørens tilgjengelighet og oppsett |
Den siste raden er en reell kostnad. Hvis en leverandør for innkommende post har et driftsavbrudd eller et konfigurasjonsproblem, kan leveringen til alle domener bak den stoppe til det er rettet, selv mens nettstedet for midlertidig e-post kjører som normalt. Meldinger som ble avvist med en midlertidig feil i den perioden, kan likevel komme gjennom når de opprinnelige avsenderne prøver på nytt, avhengig av hvor lenge køene deres holder på dem.
Å beskytte endepunktet
Et webhook-endepunkt er en offentlig URL, så hvem som helst kan prøve å sende en forfalsket melding til det. Nøye implementeringer kombinerer ofte flere forsvar:
- Signaturverifisering, der leverandøren signerer hver forespørsel og applikasjonen avviser dem som ikke stemmer.
- En hemmelig sti eller et token som bare leverandøren og applikasjonen kjenner.
- Å begrense forespørsler til leverandørens publiserte adresseområder, der slike finnes.
- Størrelsesgrenser, som avviser for store pakker tidlig for å beskytte minne og lagring.
- Idempotens. Leverandører prøver på nytt, så den samme meldingen kan komme to ganger, og en Message-ID eller leverandørens hendelses-ID hindrer duplikater.
Trinn 6: Å ta meldingen fra hverandre
Det som kommer, er ennå ikke noe et menneske kan lese komfortabelt. MIME (Multipurpose Internet Mail Extensions, RFC 2045 og utover) lar én melding bære flere deler i ulike formater. Bekreftelsesmeldingen vår kan være bygd opp slik, med en faktura lagt til som eksempel:
| Del | Hva den inneholder |
|---|---|
multipart/mixed | Den ytre beholderen når vedlegg er med |
multipart/alternative | Det samme innholdet to ganger, som text/plain og text/html. Leseren viser den rikeste formen den støtter |
multipart/related | HTML gruppert med innebygde bilder, henvist til med cid:-identifikatorer |
| Vedleggsdel | En Content-Disposition: attachment-overskrift og et filnavn, så filens kodede data |
Over disse ligger overskriftene, blant andre Message-ID, Date og sporingslinjene Received, som registrerer hver server meldingen har vært innom. Hvis du noen gang vil vite hvor en forsinkelse oppstod, er tidsstemplene i Received-linjene stedet å se.
En parser må også reversere flere kodinger. Base64 bærer binære vedlegg og blåser dem opp med omtrent en tredjedel, så en fil på 10 MB blir en melding på rundt 13 til 14 MB. Quoted-printable håndterer tekst som for det meste er ASCII ved å skrive spesialtegn som =XX. Verdien charset= sier hvordan tekst er kodet, vanligvis UTF-8, noe som betyr mye for en tjeneste som brukes på mange språk. Og emnelinjer med tegn utenfor ASCII bruker syntaksen =?UTF-8?B?...?= eller =?UTF-8?Q?...?= fra RFC 2047.
Å gjøre HTML-en trygg å vise
HTML i e-post er skrevet av fremmede, så en leser må ikke la den kjøre kode i nettstedets sammenheng. Nøye implementeringer fjerner vanligvis skript, attributter for hendelseshåndterere og farlige URL-skjemaer, og viser meldingen i en isolert ramme slik at stilene og innholdet ikke kan påvirke siden rundt.
Eksterne bilder krever også omtanke. Å laste ett forteller avsenderen at meldingen ble åpnet, og slik fungerer sporingspiksler. VookMail fjerner skjulte sporingspiksler og holder bilder av til du tillater dem.
En leser kan også gjøre noe nyttig med den tolkede teksten. For bekreftelsesmeldingen vår viser VookMail bekreftelseskoden eller bekreftelseslenken over meldingen, så ingen må bla gjennom en lang mal for å finne den.
Vedlegg
Vedlegg dekodes og lagres midlertidig slik at de kan lastes ned. Hos VookMail avvises vanlige programfiler som .exe, .bat og .apk, arkiver som .zip viser en advarsel, og det gjelder maksimale størrelser. Vedlegg slettes sammen med meldingene. Husk at en fils sikkerhet ikke har noe med hvor den ble lagret å gjøre: et dokument med makroer er like farlig når det lastes ned fra en midlertidig innboks.
Trinn 7: Å nå skjermen
Meldingen vår er nå lagret, men nettleseren som viser quietfox42@veylax.com, vet ikke det ennå. Nettapplikasjoner har flere måter å finne det ut på:
| Teknikk | Slik fungerer den | Avveininger |
|---|---|---|
| Kort polling | Siden spør serveren hvert par sekunder | Enkelt og pålitelig, men gir gjentatte forespørsler |
| Lang polling | En forespørsel blir stående åpen til det er nytt eller tiden går ut | Færre tomme svar, flere åpne tilkoblinger |
| Server-Sent Events | Én langvarig strøm fra server til nettleser | Effektivt i én retning, kobler til på nytt av seg selv |
| WebSockets | En vedvarende toveis tilkobling | Fullt interaktivt, trenger egen infrastruktur |
VookMails innboks sjekker etter post hvert par sekunder, og Oppdater-knappen sjekker manuelt, for eksempel etter at enheten har sovet eller nettverket har falt ut. Disse sekundene er vanligvis den korteste delen av reisen. Hvis posten virker treg, har tiden nesten alltid gått et sted tidligere, i avsenderens kø eller i et nytt forsøk.
Å opprette en adresse går også gjennom en liten del botbeskyttelse: en kort utregning i den besøkendes nettleser, kjent som proof of work. Den koster en vanlig besøkende nesten ingenting, og den gjør det dyrere å opprette adresser i massevis.
Adressen kan også åpnes andre steder. Fordi selve adressen identifiserer innboksen, krever det å flytte den til en annen enhet bare at adressen sendes videre. VookMails QR-knapp viser den som en kode en telefon kan skanne, slik at den samme innboksen kan åpnes der, og Android- og Huawei-appene viser post på samme måte. Dette er praktisk, og det viser også hvorfor disse innboksene gir lite personvern: alle som kjenner eller gjetter en adresse, kan åpne innboksen. En tilfeldig adresse er det tryggeste valget, fordi den er langt vanskeligere å gjette enn et kort navn.
Trinn 8: Sletting
Omtrent et døgn etter at bekreftelsen vår kom, er den borte. Oppbevaring i et system for midlertidig e-post implementeres vanligvis med et tidsstempel på hver lagrede melding og en planlagt jobb som fjerner alt som er eldre enn grensen. Vedlegg som ligger som egne filer, forsvinner samtidig. Andre løsninger bruker utløp på lagringsnivå, der selve databasen fjerner gamle poster gjennom en time-to-live-innstilling. Batchjobber er én grunn til at tjenester gjerne sier at utløpet skjer «omtrent» etter et døgn, siden det nøyaktige tidspunktet avhenger av når jobben kjører. Hos VookMail slettes meldinger, vedlegg og adresser innen omtrent 24 timer, og Slett-knappen lar deg fjerne ting tidligere.
Kort oppbevaring tjener to formål samtidig. Den beskytter personvernet, og den er også en kapasitetsnødvendighet: engangsinnbokser får mye markedsføringspost, og å beholde den lenge ville gagnet ingen. Personvernerklæringen og metodesiden vår dekker databehandlingen mer detaljert.
Legg merke til hva slettingen ikke rører. Bright Parcel har fortsatt adressen i kundetabellen sin, og loggene deres viser fortsatt at den ble «levert». Alt som er borte, er kopien på innboksiden.
Hele ruten i én tabell
| Trinn | Komponent | Protokoll eller mekanisme | Typisk port eller format |
|---|---|---|---|
| Oppretting | App eller e-postklient | RFC 5322-melding, MIME | Tekst med overskrifter og deler |
| Innlevering | Avsenderens e-posttjeneste | SMTP-innlevering eller sende-API | 587 eller 465 |
| Ruteoppslag | DNS-resolver | MX-, så A- eller AAAA-spørringer | DNS, port 53 |
| Videresending | Avsenderens server til mottakerens MX | SMTP med opportunistisk STARTTLS | 25 |
| Innkommende mottak | Leverandør av e-postlevering | Catch-all-mottak for domenene | Svar 250, 4xx, 5xx |
| Videresending | Leverandøren til VookMail | HTTPS-forespørsel | 443 |
| Behandling | Applikasjonen for midlertidig e-post | MIME-tolking, rensing, lagring | Database og fillagring |
| Visning | Nettleser eller mobilapp | Sjekker hvert par sekunder, pluss manuell Oppdater | HTTPS |
| Utløp | Planlagt opprydding | Oppbevaringsregel | Omtrent et døgn hos VookMail |
Hvor SPF, DKIM og DMARC kommer inn
Disse tre nevnes i nesten enhver diskusjon om e-post, så det hjelper å være presis om hvor de står på denne ruten. Alle handler om å bevise hvem som sendte en melding. Ingen av dem avgjør om en midlertidig adresse kan motta den.
SPF (RFC 7208) er en DNS TXT-post som lister serverne som har lov til å sende med et domene i konvoluttavsenderen, og mottakere sammenligner den tilkoblede IP-adressen mot den. DKIM (RFC 6376) er en kryptografisk signatur som avsenderdomenet legger til utvalgte overskrifter og teksten, verifisert med en offentlig nøkkel i DNS. DMARC (RFC 7489) er en policy som forteller mottakere hva de skal gjøre når en melding feiler SPF- og DKIM-samsvar med det synlige Fra-domenet, og hvor de skal sende rapporter.
For meldingen vår skjer disse kontrollene rundt trinn 3. Bright Parcels server ble sjekket mot SPF-posten sin, og DKIM-signaturen kan verifiseres med den publiserte nøkkelen. Den mottakende leverandøren kan bruke resultatene til å flagge forfalskning. Videresending kompliserer saken litt: en DKIM-signatur overlever så lenge meldingen ikke endres, mens et SPF-resultat bare gjelder den siste tilkoblede serveren. Når post videresendes, kan ARC (Authenticated Received Chain, RFC 8617) registrere tidligere resultater. Til syvende og sist er det likevel MX-posten og mottakerens aksept som får meldingen levert.
Når en melding aldri dukker opp
Hvert trinn ovenfor er et sted en melding kan stoppe. Å arbeide fra avsenderens ende finner som regel problemet raskest.
| Trinn | Hva som gikk galt | Hva du ser eller gjør |
|---|---|---|
| Før sending | En skrivefeil i adressen | Posten gikk et annet sted eller kom i retur. Bruk Kopier-knappen |
| Forlater avsenderen | Meldingen ligger i kø, eller omgangene går sakte | Et minutt eller to er normalt for noen tjenester. Vent |
| Forlater avsenderen | Nettstedet hopper stille over engangsdomener | Ingenting kommer. Respekter det og bruk en permanent adresse eller et alias der |
| SMTP | Et 4xx-svar og et senere nytt forsøk | Meldingen kommer etter en forsinkelse som kan være minutter eller mer |
| SMTP | Meldingen overskrider størrelsesgrensen | Et 552-avslag og en returmelding til avsenderen |
| Leverandør for innkommende post | Et driftsavbrudd eller DNS-problem | Leveringen til alle domener kan stå stille til det er løst |
| Innboks | Vinduet er forbi, eller adressen ble slettet | Meldingen kommer for sent til å bli sett |
Å lese en feil når du eier sendersiden
Hvis du tester din egen applikasjon, kan du se mye mer enn en bruker kan, og guiden vår om midlertidig e-post for utviklere går dypere inn på utformingen av tester. En fornuftig rekkefølge på kontrollene:
- Åpne applikasjonens e-postlogger eller kontrollpanelet hos leverandøren du sender med. Ble meldingen godtatt, og hvilken sluttstatus viser den?
- Se etter returmeldinger eller webhook-hendelser som melder om en 5xx fra mottakersiden. Teksten etter koden nevner ofte årsaken.
- Slå opp mottakerdomenets MX-poster fra serverens nettverk, med kommandoene ovenfor. Et resolver-problem der vises kanskje ikke noe annet sted.
- Bekreft at avsenderdomenet ditt har SPF, DKIM og DMARC satt opp, fordi noen mottakere behandler uautentisert post med mistenksomhet.
- Send en liten ren tekstmelding for å utelukke størrelses- eller innholdsfiltrering.
- Bruk et eget brukernavn per test, så du vet hvilken kjøring som ga hvilken melding.
Hvis en melding kommer sent til innboksen, les Received-overskriftene nedenfra og opp. Et langt gap mellom to tidsstempler viser hvilket ledd som holdt den tilbake, når du tar hensyn til eventuelle forskjeller mellom klokkene på disse serverne.
Hvorfor drive mange domener?
VookMail lar deg velge blant mer enn 30 domener. Det finnes praktiske grunner til det. Testere kan skille prosjekter eller testsett etter domene. Hvis ett domene har et DNS- eller leveringsproblem, kan de andre fortsatt fungere. Og det er mindre avhengighet av ett enkelt navn, noe som hjelper når sendesystemer vurderer mottakerdomener i tillegg til avsendere.
Flere domener er ikke et verktøy for å komme rundt nettsteder som bevisst avviser engangsadresser. Hvis en tjeneste avviser et domene for midlertidig e-post, signaliserer den at den vil ha en permanent kontakt, og det riktige valget er din ekte adresse eller et permanent alias for den tjenesten. Avvisningen kan komme i skjemaet, gjennom en domeneliste eller et MX-oppslag som det i trinn 2, eller senere, når avsenderen nekter å sende.
Hva ruten forteller om sikkerhet
Etter å ha fulgt meldingen kan du se nøyaktig hvor langt hver beskyttelse rekker.
Kryptering brukes ledd for ledd. STARTTLS beskytter hvert ledd mellom servere når begge sider støtter det, og det er ofte opportunistisk, så en tilkobling kan falle tilbake til ren tekst med mindre en policy som MTA-STS (RFC 8461) krever noe annet. HTTPS beskytter leddene for videresending og visning. Ingenting av dette er ende-til-ende-kryptering: hvert system som håndterer meldingen, kan lese den.
Tilgang er den andre halvdelen. Uten passord er det å kjenne adressen som gir inngang, så la aldri noe fortrolig sendes dit. Kort oppbevaring begrenser skaden av enhver eksponering, men det betyr også at innboksen ikke kan fungere som arkiv. Og siden innholdet ikke er til å stole på, kan phishing og skadevare komme til denne innboksen som til enhver annen. En midlertidig innboks beskytter din ekte adresse, og den gjør lite for enheten din hvis du åpner en dårlig fil. Passende bruk er personvern, spamkontroll og testing, slik vilkårene våre beskriver, og viktige kontoer hører hjemme et annet sted.
Slik ser dette ut hos VookMail
Alt maskineriet ovenfor er på plass før du kommer. Når du åpner VookMail, er en adresse klar. Du kan trykke Ny for å skrive et brukernavn og velge et domene, eller bruke den gule Tilfeldig-knappen som beskrives i guiden vår om å bruke VookMail. Det er ingenting å registrere, fordi domenet allerede godtar alle navn. Når en avsender leverer post, tar leverandøren bak MX-postene imot den over SMTP og sender den videre over HTTPS, og den dukker opp i innboksen din sammen med eventuelle vedlegg neste gang siden sjekker. Omtrent et døgn senere er den borte.
Tjenesten finnes også som app på Google Play og Huawei AppGallery.
Noen flere tekniske spørsmål
Hvilken port bruker innkommende e-post?
Levering mellom e-postservere bruker SMTP på TCP-port 25. Portene 587 og 465 er for innlevering av utgående post til din egen leverandør, så de dukker opp i trinn 1 og ikke i trinn 3. Det er også grunnen til at en hjemmetilkobling som blokkerer port 25, som regel fortsatt kan sende gjennom leverandøren sin.
Kan en tjeneste for midlertidig e-post se meldingene mine?
Teknisk sett, ja. Meldingen når tjenesten i lesbar form, for slik kan den vise den til deg, og det samme gjelder leverandøren som håndterer den på veien. Dette gjelder også vanlig e-post hos en vertstjeneste, med mindre innholdet er kryptert ende-til-ende. Det er enda en grunn til å holde alt sensitivt unna en midlertidig innboks.
Hvorfor kan avsenderen tro at en melding er levert når jeg ikke ser noe?
Fordi «levert» i en avsenders kontrollpanel viser til 250-svaret fra den mottakende serveren. Hendelser etter det punktet, som videresendingen eller en sen ankomst etter at innboksen ble tømt, er usynlige for avsenderen.
Kan en avsender se at adressen min er en catch-all?
Ofte. Et verifiseringsverktøy kan teste et oppdiktet brukernavn på domenet, og hvis serveren godtar det, er domenet sannsynligvis en catch-all. Det alene beviser ikke at domenet er et engangsdomene, siden mange vanlige firmadomener er satt opp på samme måte, så slike verktøy kombinerer det vanligvis med andre signaler.
Fungerer svar på meldingen?
Svar fra din side er ikke poenget med designet, siden innboksen hovedsakelig mottar. Hvis du trenger en toveis utveksling, passer en vanlig postkasse eller en aliastjeneste som støtter svar bedre.
For mer om selve produktet, se FAQ-en vår. VookMail er en del av PAYATE-nettverket av gratisverktøy.