Bounce -besked - Bounce message

En bounce -besked eller bare "bounce" er en automatisk besked fra et e -mail -system, der informerer afsenderen om en tidligere besked om, at meddelelsen ikke er blevet leveret (eller at der er opstået et andet leveringsproblem). Den originale besked siges at have "hoppet".

Denne feedback kan være øjeblikkelig (nogle af årsagerne beskrevet her), eller hvis afsendelsessystemet kan prøve igen, kan den ankomme dage senere, efter at disse forsøg er afsluttet.

Mere formelle vilkår for bounce-besked omfatter "Ikke-leveringsrapport" eller "Ikke-leveringskvittering" (NDR), [Fejl] "Besked om leveringsstatus" (DSN) eller en "Ikke-leveringsmeddelelse" (NDN).

Hopper klassificering

Selvom SMTP er en moden teknologi, der tæller mere end tredive år, bliver arkitekturen i stigende grad belastet af både normal og uopfordret belastning. E -mail -systemerne er blevet forbedret med omdømmesystemer, der er knyttet til den faktiske afsender af e -mailen, med tanken om, at modtagerens e -mailservere afviser e -mail, når der bruges en forfalsket afsender i protokollen. Derfor er der blevet oprettet to typer e -mail -bounces: hårde bounces og soft bounces. Begge påvirker afsenderens IP -omdømme, fordi e -mailtjenesteudbydere (ESP'er) betragter den samlede afvisningsprocent som en beslutningsfaktor, når e -mailen dirigeres til en brugers indbakke. Kort fortalt beregnes den samlede bounce rate som summen af ​​den hårde bounce rate og soft bounce rate.

Hårde hopp

Hårde bounces er permanente, og de scorer højere med hensyn til afsenderens IP -skade. Hårde afvisning opstår, når afsenderens mailserver afgør, at der er stor sandsynlighed for, at modtageren ikke er tilgængelig og sandsynligvis vil forblive det. Et par af de tilfælde, hvor der opstår hårde afvisning, er, når modtageren af ​​e -mailen befinder sig i en af ​​følgende situationer: forkert identifikator/forkert domæne (f.eks. En stavefejl i e -mailadressen eller i domænet) eller hans server ikke accepterer e -mails mere. I dette tilfælde er fjernelse af de e -mailadresser, der hopper tilbage, obligatorisk.

Bløde studs

Bløde studs er midlertidige. En tilbagevendende besked, der oplever et blødt bounce, kan blive forsøgt genudleveret på et andet tidspunkt. Soft bounces sker, når modtageren af ​​e -mailen enten har en fuld indbakke og derfor ikke har plads til at gemme en anden e -mail, eller en grænse for størrelsen på de e -mails, som det er tilladt at modtage. Yderligere situationer, hvor der vises et soft bounce, er en blok, der er oprettet på modtagerens e -mail for at markere en bestemt afsender som en 'spam' -afsender eller for at sortliste en bestemt afsender. Desuden er en midlertidig suspension af modtagerens e -mail eller en midlertidig fejl på hans servere også årsager til, at der udløses et soft bounce.

Leveringsfejl

Der kan forekomme fejl flere steder i postleveringen. En afsender kan undertiden modtage en bounce -besked fra sin egen mailserver, der rapporterer, at den ikke har været i stand til at sende en besked, eller alternativt fra en modtagers mailserver, der rapporterer, at selvom den havde accepteret meddelelsen, er den ikke i stand til at levere den til den angivne bruger. Når en server accepterer en besked til levering, accepterer den også ansvaret for at levere en bounce -besked i tilfælde af at leveringen mislykkes.

Bounce på grund af mangel på diskplads

Når en e-mail ankommer til destinationsserveren for en adresse (f.eks. Mymail.example, når den sendes til alice@mymail.example ), kan det være, at e-mail- dæmonen ikke kan deponere meddelelsen i den angivne brugers postkasse, hvis underliggende harddisk på serveren har utilstrækkelig plads.

Bounce på grund af utilgængelig destination

Når du sender en e-mail, kan den service, som e-mailen sendes fra, muligvis ikke nå destinationsadressen. I sådanne tilfælde modtager afsenderen en bounce -besked fra deres egen mailserver. Almindelige årsager til, at mailservere ikke kan nå en destination:

  • Destinationsadressen kunne ikke løses . For eksempel hvis domænenavnet ikke findes.
  • Kan ikke oprette forbindelse til destinationsadressen. For eksempel, hvis IP -adressen ikke er tildelt en server, eller hvis serveren er offline .

Afvisning fra forfalsket besked

Brugere modtager muligvis fejlagtige bounce -beskeder om meddelelser, de faktisk aldrig har sendt. Dette kan især ske i forbindelse med e -mail -spam eller e -mail -vira , hvor en spammer (afsender) kan smede en besked til en anden bruger (tiltænkt modtager af spam) og smede meddelelsen til at blive vist fra endnu en bruger (en tredjepart) . Hvis meddelelsen ikke kan leveres til den tiltænkte modtager, vil bouncemeddelelsen blive "returneret" til tredjepart i stedet for spammeren. Dette kaldes backscatter .

Andre årsager

Havde biblioteket. Eksempel -mail -server vidst, at meddelelsen ikke kunne leveres (f.eks. Hvis Jill ikke havde en brugerkonto der), ville den ikke have accepteret meddelelsen i første omgang og derfor ikke have sendt bounce. I stedet ville det have afvist meddelelsen med en SMTP -fejlkode. Dette ville efterlade Jacks mailserver (på store.example ) forpligtelsen til at oprette og levere et bounce.

Terminologi

Bounces er en særlig form for autosvar . Autorespons (automatiske svar) er mails sendt af et program - i modsætning til en menneskelig bruger - som svar på en modtaget mail og sendt til bounce -adressen .

Eksempler på andre auto svar er ferie mails, udfordringer fra challenge-response spamfiltrering , svar fra listen servere og feedback-rapporter . Disse andre autosvar diskuteres i RFC 3834: autosvar skal sendes til det Return-Pathangivne i den modtagne mail, som har udløst autosvaret, og dette svar sendes typisk med en tom retursti; ellers kan auto responders blive fanget i at sende autosvar frem og tilbage.

Den Return-Pather synlig i leveret mail som overskriftsfelt Return-Pathindsat ved SMTP postomdeling agent ( MDA ) (som normalt kombineres med en mail transfer agent , eller MTA ). MDA kopierer ganske enkelt omvendt sti i SMTP MAIL FROM-kommandoen til Return-Path. MDA fjerner også falske Return-Pathheaderfelter indsat af andre MTA'er; dette headerfelt afspejler generelt den sidste omvendte sti set i MAIL FROMkommandoen.

I dag reduceres disse stier normalt til almindelige e -mail -adresser , da den gamle SMTP ' kilderouting ' blev udfaset i 1989; for nogle historiske baggrundsoplysninger se Afsenderskrivningsskema . En særlig form for en sti eksisterer stadig: den tomme sti MAIL FROM:<>, der bruges til mange autosvar og især alle afvisninger.

I streng forstand er afvisninger sendt med en ikke-tom Return-Pathforkert. RFC 3834 tilbyder nogle heuristikker til at identificere forkerte afvisninger baseret på den lokale del (venstre side før "@") af adressen i en ikke-tom Return-Path, og den definerer endda et mailhovedfelt,, Auto-Submittedtil at identificere autosvar. Men den mail-headeren er en del af de e-mail-data (SMTP kommando DATA), og MTA'erne typisk ikke kigge ind i mailen. De omhandler konvolutten , der inkluderer MAIL FROMadressen (aka Return-Path, Envelope-FROMeller "omvendt sti"), men ikke f.eks. RFC 2822- Fromi mailhovedfeltet From. Disse detaljer er vigtige for ordninger som BATV .

De resterende afvisninger med en tom Return-Pather ikke-leveringsrapporter ( NDR'er ) eller meddelelser om leveringsstatus (DSN'er). DSN'er kan eksplicit efterspørges med en SMTP -serviceudvidelse, men den bruges ikke i vid udstrækning. Eksplicitte anmodninger om leveringsfejl detaljer er meget mere almindeligt implementeret med variabel konvolutretursti (VERP), mens eksplicitte anmodninger om dem sjældent implementeres.

NDR'er er en grundlæggende SMTP -funktion. Så snart en MTA har accepteret en mail til videresendelse eller levering, kan den ikke i stilhed slette ("slippe") den; den skal oprette og sende en bounce -besked til ophavsmanden, hvis videresendelse eller levering mislykkedes.

Hoppende vs. afvisning

Med undtagelse af MDA'er videresender alle MTA'er mails til en anden MTA. Denne næste MTA er fri til at afvise mailen med en SMTP -fejlmeddelelse som "bruger ukendt" , "over kvote" osv. På dette tidspunkt skal den afsendende MTA afvise meddelelsen , dvs. informere dens ophavsmand. Et bounce kan også opstå uden en afvisende MTA, eller som RFC 5321 udtrykker det:

"Hvis en SMTP -server har accepteret opgaven med at videresende posten og senere finder ud af, at destinationen er forkert, eller at posten ikke kan leveres af en anden grund, SKAL den konstruere en" ikke -leverbar mail "-meddelelse og sende den til ophavsmanden af den ikke-leverbare mail (som angivet med omvendt sti). "

Denne regel er afgørende for SMTP: Som navnet siger, er det en 'enkel' protokol, den kan ikke fungere pålideligt, hvis post forsvinder stille i sorte huller, så det er nødvendigt at hoppe for at få øje på og løse problemer.

Beskeder tavs stille

I dag kan det dog være almindeligt at modtage mest spamReturn-Path -e -mails, som normalt bruger forfalskede s. Det er da ofte umuligt for MTA at informere ophavsmanden, og at sende et bounce til de forfalskede Return-Pathville ramme en uskyldig tredjepart. Derudover er der specifikke grunde til, at det er at foretrække at stille droppe en besked i stedet for at afvise det (endsige hoppe det):

  • Heuristisk filtreret spam . Spamfiltre er ikke perfekte. Afvisning af spam baseret på indholdsfiltrering indebærer at give spammere et testmiljø, hvor de kan prøve flere alternativer, indtil de finder indhold, der passerer filteret.
  • Virus og orme . De fleste gange sendes disse automatisk fra en inficeret maskine. Da et studs kan indeholde en kopi af selve ormen, kan det bidrage til dens spredning.

Citerer igen RFC 5321, afsnit 6.2:

"Som diskuteret i afsnit 7.8 og afsnit 7.9 nedenfor, er det tilladt i praksis at slippe post uden meddelelse fra afsenderen. Det er imidlertid ekstremt farligt og krænker en lang tradition og samfundsforventninger om, at post enten bliver leveret eller returneret. Hvis lydløs beskedfald er faldet misbruges, kan det let underminere tilliden til pålideligheden af ​​Internets mailsystemer. Så stille tab af meddelelser bør kun overvejes i de tilfælde, hvor der er meget stor tillid til, at meddelelserne er alvorligt svigagtige eller på anden måde upassende. "

Ikke at validere afsenderen er en iboende fejl i nutidens SMTP, som er uden de forældede kilderuter, der er nævnt tidligere. Dette behandles af forskellige forslag, mest direkte af BATV og SPF .

Årsager til en bounce -besked

Der er mange grunde til, at en e -mail kan hoppe. En grund er, hvis modtageradressen er stavet forkert, eller simpelthen ikke findes på det modtagende system. Dette er en bruger ukendt tilstand. Andre årsager omfatter ressourceforbrug - f.eks. En fuld disk - eller afvisning af meddelelsen på grund af spamfiltre . Derudover er der MUA'er, der giver brugerne mulighed for at "bounce" en besked efter anmodning. Disse brugerinitierede bounces er falske bounces; per definition er et reelt bounce automatiseret og udsendes af en MTA eller MDA.

Afvisningsmeddelelser i SMTP sendes med konvolutafsenderadressen <>, kendt som nul -afsenderadressen . De sendes ofte med en From:overskriftsadresse MAILER-DAEMONpå modtagerens websted.

Typisk vil en bounce -besked indeholde flere oplysninger for at hjælpe den oprindelige afsender med at forstå, hvorfor hans besked ikke blev leveret:

  • Datoen og klokkeslættet for meddelelsen blev afvist,
  • Identiteten af ​​den mailserver, der afviste den,
  • Årsagen til at den blev hoppet (f.eks. Bruger ukendt eller postkasse fuld ),
  • Overskrifterne på den afviste besked og
  • Noget eller hele indholdet af den afviste besked.

RFC 3463 beskriver de koder, der bruges til at angive årsagen til afvisning. Almindelige koder er 5.1.1 (ukendt bruger), 5.2.2 (postkasse fuld) og 5.7.1 (afvist af sikkerhedspolitik/mailfilter).

Format

MTA'er, der er involveret i en afvisning , navngives i henhold til den rapporterende MTA's synspunkt . MTA navne er ofte af typen dns .

Formatet til rapportering af administrative meddelelser er defineret af RFC  6522 . Et DSN kan være en MIME -multipart-/rapportbesked , der består af tre dele:

  1. en menneskeligt læselig forklaring;
  2. en maskin, der kan deles om meddelelse/leveringsstatus , en liste over "navn: type; værdi" -linjer, der angiver flere mulige felter; og
  3. den originale meddelelse, eller en del deraf, som en enhed af typen meddelelse/rfc822 .

Den anden del af et DSN er også ret læsbar. Det er vigtigt at forstå, hvilken MTA der spillede hvilken rolle. Den Rapportering-MTA er ansvarlig for at oprette og sende DSN.

Når en Remote-MTA afviser en meddelelse under en SMTP-transaktion, kan et felt Diagnostic-Code af typen smtp bruges til at rapportere denne værdi. Bemærk, at udover den numeriske 3-cifrede værdi indeholder SMTP-svaret sig selv en af ​​mennesker, der kan læses. Oplysningerne 

Remote-MTA: dns; smtp.store.example [192.0.2.3]
Diagnostic-Code: smtp; 550 No such user here
rapporteres undertiden som f.eks.
while talking to smtp.store.example [192.0.2.3]
>>> RCPT TO:<nonexistinguser@store.example>
<<< 550 No such user here

Se også

Relaterede RFC'er

  • RFC  5321 - Simple Mail Transfer Protocol
  • RFC  3461 - Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSN'er)
  • RFC  6522 - Multipart/Report Media Type til rapportering af administrative systemmeddelelser i mailsystemet
  • RFC  3463 - Forbedrede statuskoder til SMTP
  • RFC  3464 - Et udvideligt meddelelsesformat til meddelelser om leveringsstatus
  • RFC  3834 - Anbefalinger til automatiske svar på elektronisk post
  • RFC  5337 - Internationaliseret leveringsstatus og meddelelser om disposition

Referencer

eksterne links