Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comm.software.mailserver > #6337
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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