Bounce besked
En bounce-besked ( engelsk bounce , bounce ',' throw back ') og Non Delivery Notification (NDN) , Non-Delivery Report / Receipt (NDR) eller kort Bounce called, er en fejlmeddelelse fra en mailserver oprettes automatisk, når en e-mail kan ikke leveres. Det er en af flere mulige typer leveringsstatusmeddelelser (DSN).
Denne fejlmeddelelse sendes via e-mail til afsenderen ( konvolutafsender ) af den ikke-leverbare e-mail og har en tom konvolutafsender ( <>) selv for at forhindre e-mail-løkker . Den From:adresse eller bruges ofte som adresse .
MAILER-DAEMON@mailserverPOSTMASTER@mailserver
Der skelnes mellem hårde afvisninger , der er forårsaget af permanente fejl, for eksempel hvis modtagerens e-mail-adresse ikke findes, og bløde afvisninger , der genereres i tilfælde af midlertidige problemer, f.eks. Hvis diskkvoten i modtagerens postkasse er opbrugt, eller harddisken er fuld. er.
indhold
En afvisningsmeddelelse indeholder i. d. Normalt forskellige henvisninger, der hjælper afsenderen af den ikke-leverbare e-mail til at finde ud af, hvorfor hans besked ikke kunne leveres. Dette inkluderer
- Dato og tid, f.eks. B.
Date: Mon, 20 Jun 2005 16:59:51 +0200 - Mailserveren, der genererede fejlmeddelelsen, f.eks. B.
host mail.example.com [192.0.43.10] - Årsagen til, at meddelelsen ikke kunne leveres, f.eks. B.
550 Diese E-Mail Adresse existiert nicht. sorry, no mailbox here by that name (#5.1.1) - De headere af den ikke kan leveres email, f.eks B.
------ This is a copy of the message, including all the headers. ------ Return-path: <[email protected]> Received: from postmaster by mail.absen.der with local (Exim 4.41) id 1DkNkc-000OXB-Ib; Mon, 20 Jun 2005 16:59:50 +0200 Date: Mon, 20 Jun 2005 16:59:50 +0200 From: <[email protected]> To: [email protected] Cc: *deleted* Subject: Re: testing Message-ID: <[email protected]> References: <[email protected]> <[email protected]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <[email protected]>
- Den ikke-leverbare besked eller dens begyndelse
test - please reply.
årsager
Almindelige årsager til afvisningsmeddelelser er forkert adressering, filtre eller hardwareproblemer, for eksempel:
Forkert adressering
550 sorry, no mailbox here by that name 550 Empfaenger unbekannt / recipient e-mail adress unknown 550 5.1.1 <SMTPchocolate_dai811013@****>... User unknown 550 Diese E-Mail Adresse existiert nicht. sorry, no mailbox here by that name (#5.1.1)
filter
550 relay not permitted 550 5.1.8 Only registered users may use this system 550 Mail was identified as spam 554 Relay access denied
Hardware problemer
554 Error writing message to safe storage; message could not be stored to disk
Midlertidige problemer
En MTA bør ikke reagere direkte på midlertidige fejl med en afvisning, da det kan antages, at posten kan leveres på et senere tidspunkt. I dette tilfælde holder mailserveren mails i køen og prøver at levere dem med jævne mellemrum. Kun hvis e-mailen har været i køen for længe, skal han skrive en afvisning og slette e-mailen fra køen.
451 Temporary local problem - please try later 451 VS14-RT5 Mailbox bounce arrival rate exceeds system limit (#4.2.2) 450 <mail.X[X]>: Client host rejected: try again later
Bounce-problemer
Sortliste
Enhver mailserver, der sender afvisningsmeddelelser, risikerer at ende på sorte lister (RBL) . Dette problem forværres med såkaldte Joe-job . En server, der accepterer mails fra et sådant Joe-job og svarer dem med NDN'er til eksisterende adresser, skaber en stor mængde spam . Denne sikkerheds spam fører i mange tilfælde til poster på forskellige RBL'er.
Den eneste effektive modforanstaltning er kun at sende meddelelser om ikke-levering til kendte afsendere. Dette er normalt kun muligt på den mailserver, som e-mailen leveres fra afsenderens e- mail-klient . Dette er også grunden til, at ingen server skal acceptere mail, som den ikke kan eller ikke vil videresende. Med andre ord: E-mails, der ikke kan leveres, skal afvises med en 500-fejl, mens de modtages (på SMTP-tid). I dette tilfælde skal den afsendende server generere afvisningen. Hvis den afsendende server er en god server, er dette ikke et problem, da den kun modtager mails fra kendte afsendere og derfor kan levere den ikke-leverbare besked korrekt til dem - men hvis det er en dårlig server (f.eks. Spam-bot) , vil han ikke sende afvisningsmeddelelser, da det ikke nytter, og hvis han gør det, vil han (med rette) blive sortlistet.
E-mail-sløjfer
Nogle forkert implementerede mailserverer genererer ikke-leverbare meddelelser med en eksisterende / leverbar afsender. Hvis denne meddelelse, der ikke kan leveres, også kan leveres, kasseres den ikke som normalt, men sendes til den angivne afsender. Hvis afsenderens server sender en anden afvisningsmeddelelse (f.eks. I tilfælde af automatiske svar på grund af fravær), er cirklen komplet.
Sikkerhedsbrud
I forbindelse med den indtastede svaradresse til e-mails kan afvisninger også blive et alvorligt sikkerhedsproblem. Administratorer kan lide at indtaste en ikke-eksisterende adresse til e-mails, der ikke skal besvares, og bruger ofte domænet donotreply.com , især til engelske e-mails . Dette domæne er dog registreret og har en opsamling på sine e-mail-adresser. I sidste ende kan dette føre til z. B. Ved afsendelse af e-mails internt i en virksomhed, hvis der bruges en @ donotreply.com-svaradresse, videresendes e-mailen udad gennem en afvisning .
Tilknyttede RFC'er
- RFC 3461 - Simple Mail Transfer Protocol (SMTP) Service Extension til leveringsstatusmeddelelser (DSN'er)
- RFC 3463 - Statuskoder til udvidet mailsystem
- RFC 3464 - Et udvideligt meddelelsesformat til meddelelser om leveringsstatus
