Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comm.software.mailserver > #6337

Re: Postfix / Parameter delay_warning_time

From Marcus Jodorf <trap@killfile.de>
Newsgroups de.comm.software.mailserver
Subject Re: Postfix / Parameter delay_warning_time
Date 2021-03-12 19:02 +0100
Organization n/a
Message-ID <87v99wqmhk.fsf-bofh@killfile.de> (permalink)
References (2 earlier) <s2ddrq$ipl$1@tota-refugium.de> <87sg51ferr.fsf-bofh@killfile.de> <slrns4lb7s.agl.amk@msgid.krell.zikzak.de> <87k0qdfavg.fsf-bofh@killfile.de> <slrns4mitu.6jj.amk@msgid.krell.zikzak.de>

Show all headers | View raw


Andreas M. Kirchwitz <amk@spamfence.net> schrieb:

> Wenn es nur um die Haupt-User an sich ginge, wäre das machbar,
> aber ich kenne Mailserver so, dass dort oft ein gigantischer
> Zoo an Aliases, Weiterleitungsregeln und sonstigen Sonderlocken
> existiert, und das möchte man eigentlich nicht doppelt verwalten. 

Kleinteiliges Gemurkse hast Du normal nur bei Bastelservern. Sobald das
nicht nur ein Hobbyserver ist, hat man ohnehin (hoffentlich) passende
Verwaltungstools in place. Dann kann man sich die Adressen auch
normalerweise von einer source-of-truth ziehen (AD/ldap/sql/...) oder
das wird vorzugsweise gleich auf die Server repliziert.

> Kurz und knapp, ich habe nicht die Erfahrung gemacht, dass Absender
> zuverlässig eine Zustellung wiederholen. Wahlweise wird die Mail
> "nur" verworfen. Oder mit etwas Pech wird man als Empfänger gleich
> dauerhaft gelöscht.

Super, dann kann die Mail ja nicht wichtig gewesen sein und das spart
dem Empfänger Zeit.

> Selbst wenn es eine Wiederholung gibt, wie lange dauert sie an?

Das ist vermutlich länger als Du glaubst. Postfix default ist z.B. 5
Tage out-of-the-box. Ich habe auch eigentlich bisher noch keine Server
gesehen, die es weniger als 5 oder auch gerne 7 Tage lang versuchen.

Bei einigen Großen Betreibern mag es fallweise aufgrund des Volumens
kürzer eingestellt sein, aber nach nur ein paar Stunden geben die auch
noch lange nicht auf.

Falls Dein Server mal einen Tag oder zwei weg ist, verlierst Du daher
normalerweise keinerlei Mails.

> Fällt der Mailserver nachts aus, ist bis zum Morgen für mehrere
> Stunden Schicht im Schacht, bis dahin hat die Gegenseite bereits
> aufgegeben.

Das ist sehr unwahrscheinlich.

> Was soll jemand, der vielleicht viel Mail verschickt (z.B.
> ganz banal Mailinglisten) auch anderes machen? Wenn man da
> auf jede Gegenseite ewig Rücksicht nimmt, hat mein schnell
> eine Monster-Queue, die man nicht mehr abarbeiten kann.

Solange Du keinen richtig großen Userkreis bedienen mußt, ist das nicht
so dramatisch. Mal ein paar hundert Mails in der queue kommt auch bei
kleinen Servern öfter mal vor und wenn es aufgrund irgendwelcher
Ereignisse mal ein paar tausend sind, ist das noch ganz weit entfernt
von Drama.
Gerade Mailinglisten sind das allerkleinste Problem, da die Art der
Mails da meist eher klein und harmlos ist.

Sobald die ganze Geschichte größer wird, hat man dann ohnehin andere
Infrastruktur und bastelt nicht mehr nur mit einem oder wenigen Servern
rum.

> Backup-MX halte ich für unverzichtbar, wenn einem der Empfang
> von Mail wichtig ist. Was man kriegen kann, nimmt man sofort ab,
> damit hat man es und ist nicht mehr auf die Gegenseite angewiesen.

Das halte ich für die allermeisten normalen Fälle schlicht für eine
Fehleinschätzung. Ausfälle über die Queue des Senders abfedern lassen,
ist normal viel unproblematischer.
Wenn man aber damit rechnet, einen Server nicht mehr binnen
schlimmstenfalls ein oder zwei Tagen neu an den Start bringen zu können,
dann hat man schon vorher eine komplette Fehlplanung hingelegt und dann
gehört man auch eher nicht zu den Leuten, die einen backup-mx betreiben
sollten.

> Ja, man hat dadurch rechtlich eine Situation erzeugt, dass man
> die Mail gewissermassen "empfangen" hat. Aber man hätte sie ja
> unter normalen Umständen ebenfalls angenommen.

Bedingt u.a., daß auch der backup dieselben anti-spam Maßnahmen laufen
hat, wie der Main (sollte er aber auch ohnehin immer - daß Spammer es
auch gerne mal über den Backup versuchen, ist uralt).
Mehr Aufwand, nächster Grund gegen backup.

Nebenbei wird dasselbe Problem auch bei Anti-Spam Maßnahmen gerne
übersehen. Da muß man auch wegen der rechtlichen Problematik darauf
achten, daß man im Verdachtsfall eine Mail vorzugsweise gar nicht erst
annimmt.
Statt sie anzunehmen und dann erst mal in eine Quarantäne oder
Spamfolder zu kippen, wo sie dann vielleicht auch noch gerne vergessen
wird.

> Für wen das tatsächlich im Alltag ein existenzbedrohendes Dilemma ist,
> der betreibt eben keinen Backup MX, sondern lässt lieber Mail
> wegwerfen. Aber das halte ich nicht für den Normalfall.

Mails mit Fristproblematik wird z.B. sofort ein Thema, wenn Du häufiger
Geschäftsbeziehungen mit Partern im Ausland hast, die meist sehr viel
freier mit Verträgen per Email umgehen (weil nicht früher jahrelang durch
Signaturgesetz drangsaliert und zum Fax gezwungen). Aber mittlerweile
ist das auch hier praktisch schon genauso normal, zumindest bei schon
etablierten Geschäftsbeziehungen.


Gruß,

Marcus
⚂⚃

Back to de.comm.software.mailserver | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Postfix / Parameter delay_warning_time Frank Graf <f.graf@firemail.de> - 2021-03-11 13:45 +0000
  Re: Postfix / Parameter delay_warning_time Sven Hartge <sh-213@svenhartge.de> - 2021-03-11 16:07 +0100
    Re: Postfix / Parameter delay_warning_time Tim Ritberg <tim@server.invalid> - 2021-03-11 16:43 +0100
      Re: Postfix / Parameter delay_warning_time Marcus Jodorf <trap@killfile.de> - 2021-03-12 00:32 +0100
        Re: Postfix / Parameter delay_warning_time "Andreas M. Kirchwitz" <amk@spamfence.net> - 2021-03-11 23:51 +0000
          Re: Postfix / Parameter delay_warning_time Marcus Jodorf <trap@killfile.de> - 2021-03-12 01:56 +0100
            Re: Postfix / Parameter delay_warning_time "Andreas M. Kirchwitz" <amk@spamfence.net> - 2021-03-12 11:08 +0000
              Re: Postfix / Parameter delay_warning_time Marcus Jodorf <trap@killfile.de> - 2021-03-12 19:02 +0100
      Re: Postfix / Parameter delay_warning_time Bastian Blank <usenet@waldi.eu.org> - 2021-03-12 07:26 +0000
        Re: Postfix / Parameter delay_warning_time Paul Muster <exp-311221@news.muster.net> - 2021-03-12 11:30 +0100
          Re: Postfix / Parameter delay_warning_time Tim Ritberg <tim@server.invalid> - 2021-03-12 13:45 +0100
            Re: Postfix / Parameter delay_warning_time Paul Muster <exp-311221@news.muster.net> - 2021-03-12 14:19 +0100
              Re: Postfix / Parameter delay_warning_time Tim Ritberg <tim@server.invalid> - 2021-03-12 14:56 +0100
  Re: Postfix / Parameter delay_warning_time Marcus Jodorf <trap@killfile.de> - 2021-03-12 01:33 +0100
    Re: Postfix / Parameter delay_warning_time Frank Graf <f.graf@firemail.de> - 2021-03-13 12:34 +0000
      Re: Postfix / Parameter delay_warning_time Arno Welzel <usenet@arnowelzel.de> - 2021-03-14 04:56 +0100
        Re: Postfix / Parameter delay_warning_time Paul Muster <exp-311221@news.muster.net> - 2021-03-15 17:45 +0100
          Re: Postfix / Parameter delay_warning_time Tim Ritberg <tim@server.invalid> - 2021-03-15 18:23 +0100
            Re: Postfix / Parameter delay_warning_time Paul Muster <exp-311221@news.muster.net> - 2021-03-15 19:00 +0100
            Re: Postfix / Parameter delay_warning_time Arno Welzel <usenet@arnowelzel.de> - 2021-03-16 15:08 +0100
              Re: Postfix / Parameter delay_warning_time Tim Ritberg <tim@server.invalid> - 2021-03-16 15:19 +0100
                Re: Postfix / Parameter delay_warning_time Markus Schaaf <mschaaf@elaboris.de> - 2021-03-17 10:39 +0100
          Re: Postfix / Parameter delay_warning_time Arno Welzel <usenet@arnowelzel.de> - 2021-03-16 15:08 +0100
            Re: Postfix / Parameter delay_warning_time Tim Ritberg <tim@server.invalid> - 2021-03-16 15:18 +0100
            Re: Postfix / Parameter delay_warning_time Paul Muster <exp-311221@news.muster.net> - 2021-03-16 18:58 +0100

csiph-web