AW: Non-Delivery-Notification an Absender bei fehlendem MX-Record in Ziel-Domain

[lst_hoe02 at kwsoft.de]

Zitat von Uwe Drießen <driessen at fblan.de>:

> Im Auftrag von lst_hoe02 at kwsoft.de
>>
>> Zitat von Roland Schmid <roland.schmid at messegrafik-schreiber.de>:
>>
>> > Hallo,
>> >
>> >>
>> >> Bekommt der Absender automatisch. Mail geht bei sowas an den
>> Absender
>> >> zurück
>> >>
>> >
>> > wann bekommt der Absender die Benachrichtigung ?
>> >
>> >> delay_warning_time                  =   8h
>>
>> Nach dieser Zeit eine Warnung...
>>
>> >> maximal_queue_lifetime              =   12h
>>
>> Und das solltest du nicht tun wenn dir E-Mail wichtig ist. Die RFC
>> verlangt 5 Tage, unter 3 solltest du nicht gehen.
>
> Das zeig mich mal das RFC 5 TAGE vorschreibt und wenn das  
> vorgeschrieben ist dann ist auch 3 Tage indiskutabel weil RFC sollte  
> man sich dran halten.
> Und die Einstellung rührt wenn dann aus einer Zeit als Mail über  
> Mailboxen per Dialin chaotisch nur ein oder 2 mal am Tage  
> ausgetauscht wurden. (1990 oder so, Oh man bin ich schon alt )
> Da dauerte eine Mail unter Umständen auch noch 3 Wochen über den  
> Teich und Briefpost war weitaus schneller (zumindest die Luftpost).
>
> Wer hindert dich daran eine Mail erneut zu senden?
> Du hast dafür Sorge zu tragen das eine Mail zugestellt wird dem  
> Absender weil es ein Problem gibt oder dem Empfänger
> Und kann eine Mail 12 Stunde lang nicht zugestellt werden dann  
> existiert ein Problem. Ob die Mail dann nach 12 Stunden und einer  
> Minute zugestellt werden kann dann wird sie das auch wenn du die  
> Sendung wiederholst
>
> Mir spart das so einige anrufe wo denn die Mail hängt
>

E-Mail ist und war schon immer asynchron und die queue_lifetime gibt  
der Gegenstelle Zeit eventuelle Probleme zu beheben. Wenn man eine  
direkte Rückmeldung braucht gibt es Telefon. Wenn eine E-Mail nach 12  
Stunden irrelevant ist war sie es eigentlich vorher schon und nochmal  
senden macht keiner, da die wenigsten Endbenutzer Bounces verstehen.


>>
>> >> transport_retry_time                =   7m
>>
>> Default belassen!
>
> Willst du sicher um Greylistung dann gibt eine Karenzzeit drauf.  
> Wenn die Mail beim ersten zustellversuch nicht angenommen wird dann  
> ist es auch nicht von belang ob da 2 min mehr für die Wiederholung  
> drin sind.
> So manch einer hat statt 5 min greylistung sogar bis zu X Stunden  
> drin (einen kenne ich zumindest und das bin nicht ich)
>

Hat nichts mit Greylisting zu tun sondern mit dem "wegoptimieren" der  
anderen falsch gesetzten Werte durch einen weiteren Parameter.


>>
>> >> bounce_queue_lifetime               =   0
>>
>> Das ist ein Spammer Wert. Wenn dich die Unzustellbarkeit deiner E-Mail
>> nicht interessiert solltest du keine E-Mail verschicken!
>
> Sorry wo liegt das Problem wenn ich meinen eigenen User innerhalb  
> der Zeit  keine BounceMail zustellen kann wem dann ?
> Das heißt nicht das es keine Bouncemeldungen  gibt! (ich bounce  
> zudem nicht sondern lehne sofort ab wenn die Mail nicht zugestellt  
> werden kann aus welchem Grund auch immer)
> Es gibt mit der Einstellung keine verschollene Mails.

Dieser Wert bedeutet das ich mir sicher bin das der Bounce eh nicht  
"benötigt" wird und man die "Problemfälle" los werden will anstatt  
sich um das Problem zu kümmern, also typisches Spammer verhalten. Die  
Einstellung "0" bedeutet Versuch eine Zustellung und schmeiß den  
Bounce dann weg.

Aber wer E-Mail komplett nutzlos machen will darf es natürlich tun.  
Dein Server deine Regeln aber dann bitte auch nicht rumjammern wenn  
andere sich an Standards halten, das ist nämlich der größte Vorteil  
von E-Mail das es kein geschlossenes System ist sondern jeder  
teilnehmen kann der sich an Standards hält.

Gruß

Andreas




-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 5840 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <http://de.postfix.org/pipermail/postfix-users/attachments/20160322/1658cda1/attachment.bin>