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

Groups > de.comm.software.mailserver > #6324 > unrolled thread

Postfix / Parameter delay_warning_time

Back to article view | Back to de.comm.software.mailserver

Contents

  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

Page 1 of 2  [1] 2  Next page →

#6324 — Postfix / Parameter delay_warning_time

Hallo,

gehe ich recht in der Annahme dass Postfix bei setzen des folgenden 
Parameters:

delay_warning_time = 4h

sowohl den Absender informiert der eine Mail direkt über einen MUA 
eingeliefert hat, als auch einen Absender dessen Mail Postfix in seiner 
Eigenschaft als Backup-MX entgegen genommen hat?

Angenommen Postfix nimmt als Backup-MX Mails an, und kann sie wegen 
Ausfall des primären MX nicht zustellen, dann würde er die Absender 
informieren?

Ich denke wegen:

"Cloud Computing: 3,6 Millionen Webseiten nach Brand bei OVH offline"

https://glm.io/154844?t 

darüber nach einen Backup-MX einzurichten. Nein, ich bin nicht betroffen 
von dem aktuellen Brand.


Frank

[toc] | [next] | [standalone]

#6325

Frank Graf <f.graf@firemail.de> wrote:

> gehe ich recht in der Annahme dass Postfix bei setzen des folgenden 
> Parameters:

> delay_warning_time = 4h

> sowohl den Absender informiert der eine Mail direkt über einen MUA 
> eingeliefert hat, als auch einen Absender dessen Mail Postfix in seiner 
> Eigenschaft als Backup-MX entgegen genommen hat?

> Angenommen Postfix nimmt als Backup-MX Mails an, und kann sie wegen 
> Ausfall des primären MX nicht zustellen, dann würde er die Absender 
> informieren?

> Ich denke wegen:

> "Cloud Computing: 3,6 Millionen Webseiten nach Brand bei OVH offline"

> https://glm.io/154844?t 

> darüber nach einen Backup-MX einzurichten. Nein, ich bin nicht betroffen 
> von dem aktuellen Brand.

Bei einem Backup-MX in der heutigen Zeit sollte man vor allem beachten,
das dieser unabhängig vom Haupt-MX auch alle existierenden Mail-Adressen
kennt und nicht-existierende ablehnen kann.

Es ist nämlich immer noch eine durchaus beliebte Taktik den SPAM beim
Backup-MX einzuliefern in der Hoffnung, das dieser weder einen aktiven
SPAM-Erkenner noch eine User-Datenbank hat und einfach alles annimmt und
dann später an den Haupt-MX zustellt. Und dieser vertraut natürlich dem
Backup-MX und nimmt die Mails an.

Wenn man nun auf dem Haupt-MX einen SPAM-Filter mit sofortiger Ablehnung
aktiv hat, so erzeugt man plötzlich Late-Bounces vom Backup-MX und
belästigt dann plötzlich Dritte, deren Absender mißbraucht worden ist.

Was am Ende also bedeutet, dass du irgendwie den Backup-MX möglichst
identisch zum Haupt-MX einrichten musst, inklusive Benutzer-Daten und
SPAM-Filter.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#6326

Am 11.03.21 um 16:07 schrieb Sven Hartge:
>
> 
> Bei einem Backup-MX in der heutigen Zeit sollte man vor allem beachten,
> das dieser unabhängig vom Haupt-MX auch alle existierenden Mail-Adressen
> kennt und nicht-existierende ablehnen kann.
> 
Das macht Postfix mehr oder weniger automatisch. Beide Mxer sollten aber 
die gleiche Prio haben, damit der Backup-MX auch mal Post bekommt und so 
seine Negativ-DB gefüttert wird.

Tim

[toc] | [prev] | [next] | [standalone]

#6327

Tim Ritberg <tim@server.invalid> schrieb:

> Das macht Postfix mehr oder weniger automatisch.

Weniger. Das muß genauso konfiguriert werden, wie die meisten anderen
Sachen auch. Und das ist - auch wenn postfix das noch verhältnismäßig
gut macht - natürlich insgesamt eine wackeligere Angelegenheit als eine
ordentliche Userdb/recipient-list.

> Beide Mxer sollten aber die gleiche Prio haben, damit der Backup-MX
> auch mal Post bekommt und so seine Negativ-DB gefüttert wird.

Da fangen die Workarounds ja auch schon an. Und wenn ein User seltener
Mails bekommt als die Cache Expire-Times und der Hauptserver ist
zufällig down, wenn so eine Mail dann kommt - dann ist man mit solchem
Gebastel auch schon wieder am Ende.

Das ist IMHO einfach Murks und das macht man nur im Notfall, wenn man
absolut keine Chance hat, anderweitig und sicher eine ordentliche
userdb/recipient-list an den Start zu bringen.

Überhaupt benötigen die meisten Leute keinen backup mx - und auch wenn
sie das (noch) nicht wissen, wollen sie auch gar keinen.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#6328

Marcus Jodorf <trap@killfile.de> wrote:

>> Das macht Postfix mehr oder weniger automatisch.
>
> Weniger. Das muß genauso konfiguriert werden, wie die meisten anderen
> Sachen auch. Und das ist - auch wenn postfix das noch verhältnismäßig
> gut macht - natürlich insgesamt eine wackeligere Angelegenheit als eine
> ordentliche Userdb/recipient-list.

Solange beide laufen, kann der Backup-Postfix nicht den Master-Postfix
in Echtzeit fragen, ob ein Account existiert oder nicht? Dadurch könnte
der Backup zumindest teilweise bewusst "dumm" bleiben.

Für die kurze Zeit, wo der Master mal ausfallen sollte, nimmt der
Backup halt zwangsweise alles an, davon geht die Welt nicht unter,
sollte hoffentlich die Ausnahme bleiben.

> Überhaupt benötigen die meisten Leute keinen backup mx - und auch wenn
> sie das (noch) nicht wissen, wollen sie auch gar keinen.

Warum benötigen die meisten Leute keinen Backup-MX?

	Grüße, Andreas

[toc] | [prev] | [next] | [standalone]

#6330

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


>> Weniger. Das muß genauso konfiguriert werden, wie die meisten anderen
>> Sachen auch. Und das ist - auch wenn postfix das noch verhältnismäßig
>> gut macht - natürlich insgesamt eine wackeligere Angelegenheit als
>> eine ordentliche Userdb/recipient-list.
>
> Solange beide laufen, kann der Backup-Postfix nicht den Master-Postfix
> in Echtzeit fragen, ob ein Account existiert oder nicht?

Doch genau das kann er. Entspechend konfiguriert kann er das auch
persistent lokal cachen.

> Dadurch könnte der Backup zumindest teilweise bewusst "dumm" bleiben.

Das braucht ein paar Zeilen Konfiguration. Aber es ist meistens auch
wieder nicht so wesentlich mehr Arbeit, für eine vernünftige
recipient-list zu sorgen.
Dafür reichen schon recht einfache Mittel, wie z.B. ein cronjob, der
alle paar Minuten mal mit dem Domaincontroller/ldap/der userdb oder
sonstwas abgleicht. Wir reden hier ja im einfachsten Falle nur von einer
ganz schlichten Textliste mit Mailadressen.

Einzig bei schrottigen Appliances muß man mit so einem Zustand manchmal
leben, weil man da manchmal keinen Weg hat, empfängerdaten zu
verfüttern.

> Für die kurze Zeit, wo der Master mal ausfallen sollte, nimmt der
> Backup halt zwangsweise alles an, davon geht die Welt nicht unter,
> sollte hoffentlich die Ausnahme bleiben.

Ich hatte da mal vor Jahren den schönen Fall im Bekanntenkreis. Da ist
der Hauptserver mit Hardwareschaden ausgefallen.
Hardware getauscht, System restored, neu gestartet. Und dann ist er
erstmal gegen die Wand gefahren. Weil der Backup hat catch-all gespielt
und die ganze Zeit über jeden Schrott angenommen.
Kaum ist der Hauptserver wieder da gewesen, ist er dann (Virenscanner
usw. nat. auch nur auf dem Hauptserver) von dem Schrott überrollt worden
und die Load an die Decke gegangen.
Aber auch kein Problem - sie mußten ihn dann sowie sofort wieder hart
abschalten, weil er natürlich gleich tausende Backscattermails
rausgehauen hat, die dir einen Ehrenplatz auf jeder RBL bringen. Dann
hat sich das ganze Thema Email sowieso erst mal für die nächsten Wochen
erledigt.

>> Überhaupt benötigen die meisten Leute keinen backup mx - und auch
>> wenn sie das (noch) nicht wissen, wollen sie auch gar keinen.
>
> Warum benötigen die meisten Leute keinen Backup-MX?

Siehe u.a. parallele Antwort auf Ursprungsposting.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#6333

Marcus Jodorf <trap@killfile.de> wrote:

>> Solange beide laufen, kann der Backup-Postfix nicht den Master-Postfix
>> in Echtzeit fragen, ob ein Account existiert oder nicht?
>
> Doch genau das kann er. Entspechend konfiguriert kann er das auch
> persistent lokal cachen.

Prima, das ist doch zumindest eine Möglichkeit des Betriebs.
(Muss ja nicht jeder so machen, aber ist eine valide Option.)

>> Dadurch könnte der Backup zumindest teilweise bewusst "dumm" bleiben.
>
> Das braucht ein paar Zeilen Konfiguration. Aber es ist meistens auch
> wieder nicht so wesentlich mehr Arbeit, für eine vernünftige
> recipient-list zu sorgen.

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. 

>>> Überhaupt benötigen die meisten Leute keinen backup mx - und auch
>>> wenn sie das (noch) nicht wissen, wollen sie auch gar keinen.
>>
>> Warum benötigen die meisten Leute keinen Backup-MX?
>
> Siehe u.a. parallele Antwort auf Ursprungsposting.

Okay, war viel Text, habe ich gelesen.

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. Selbst wenn es eine Wiederholung gibt, wie
lange dauert sie an? Fällt der Mailserver nachts aus, ist bis zum
Morgen für mehrere Stunden Schicht im Schacht, bis dahin hat die
Gegenseite bereits aufgegeben.

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.

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.

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. Man sollte halt
jetzt nicht ewig bummeln mit der Reparatur seines Mailservers,
aber wenn das Ding so kaputt ist, dass man selbst bei maximaler
Arbeitskraft Wochen oder Monate für die Reparatur benötigt,
ist das vor Gericht üblicherweise anrechenbar. Das ist aber so
eine merkwürdige Extrembetrachtung. 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.

	Grüße, Andreas

[toc] | [prev] | [next] | [standalone]

#6337

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
⚂⚃

[toc] | [prev] | [next] | [standalone]

#6331

Tim Ritberg wrote:
> Das macht Postfix mehr oder weniger automatisch. Beide Mxer sollten aber 
> die gleiche Prio haben, damit der Backup-MX auch mal Post bekommt und so 
> seine Negativ-DB gefüttert wird.

Du meinst "recipient verification"? Das erfüllt nicht ganz die Forderung
nach "unabhängig nutzbar".

Bastian

[toc] | [prev] | [next] | [standalone]

#6332

Am 12.03.2021 um 08:26 schrieb Bastian Blank:
> Tim Ritberg wrote:

>> Das macht Postfix mehr oder weniger automatisch. Beide Mxer sollten aber
>> die gleiche Prio haben, damit der Backup-MX auch mal Post bekommt und so
>> seine Negativ-DB gefüttert wird.
> 
> Du meinst "recipient verification"? Das erfüllt nicht ganz die Forderung
> nach "unabhängig nutzbar".

Macht es für einen einliefernden Mailserver einen Unterschied, ob er a) 
gar keinen MX erreicht oder b) von einem Backup-MX, der aktuell den 
primären MX nicht erreichen und somit den Empfänger nicht verifizieren 
kann, mit z.B. "451 Temporary local problem - please try later" (oder so 
ähnlich) vertröstet wird?
Meiner Meinung nach nicht, somit ist ein Backup-MX nur mit eigener Kopie 
der Nutzerdatenbank brauchbar. Denn nur dann kann er E-Mails für 
vorhandene Empfänger annehmen und andere abweisen.


Nächste Hürde: Die benutzerspezifische Bayes-Datenbank am Backup-MX 
vorhalten bzw. zwischen mehreren primary MX synchronisieren.


mfG Paul

[toc] | [prev] | [next] | [standalone]

#6334

Am 12.03.21 um 11:30 schrieb Paul Muster:

> 
> Macht es für einen einliefernden Mailserver einen Unterschied, ob er a) 
> gar keinen MX erreicht oder b) von einem Backup-MX, der aktuell den 
> primären MX nicht erreichen und somit den Empfänger nicht verifizieren 
> kann, mit z.B. "451 Temporary local problem - please try later" (oder so 
> ähnlich) vertröstet wird?
nein. oh moment doch, Exchange mit kaputten Ego vielleicht :-P

> Meiner Meinung nach nicht, somit ist ein Backup-MX nur mit eigener Kopie 
> der Nutzerdatenbank brauchbar. Denn nur dann kann er E-Mails für 
> vorhandene Empfänger annehmen und andere abweisen
richtig bzw s.o. mein Posting oben.

Tim

[toc] | [prev] | [next] | [standalone]

#6335

Am 12.03.2021 um 13:45 schrieb Tim Ritberg:
> Am 12.03.21 um 11:30 schrieb Paul Muster:

>> Meiner Meinung nach nicht, somit ist ein Backup-MX nur mit eigener 
>> Kopie der Nutzerdatenbank brauchbar. Denn nur dann kann er E-Mails für 
>> vorhandene Empfänger annehmen und andere abweisen

> richtig bzw s.o. mein Posting oben.

Das Posting, in dem du behauptest, Postfix mache das (den Abgleich von 
gültigen Zieladressen) "mehr oder weniger automatisch", was aber ganz 
einfach falsch ist, weil Postfix da natürlich genau garnichts 
automatisch macht?


mfG Paul

[toc] | [prev] | [next] | [standalone]

#6336

Am 12.03.21 um 14:19 schrieb Paul Muster:
> 
> Das Posting, in dem du behauptest, Postfix mache das (den Abgleich von 
> gültigen Zieladressen) "mehr oder weniger automatisch", was aber ganz 
> einfach falsch ist, weil Postfix da natürlich genau garnichts 
> automatisch macht?

Nö, das ist nicht falsch und scheinbar hast du die nicht richtig mit 
Postfix beschäftigt.
Es merkt sich standardmäßig 3 Tage lang, welche Adressen nicht existieren.

Tim

[toc] | [prev] | [next] | [standalone]

#6329

Frank Graf <f.graf@firemail.de> schrieb:

> gehe ich recht in der Annahme dass Postfix bei setzen des folgenden 
> Parameters:
>
> delay_warning_time = 4h
>
> sowohl den Absender informiert der eine Mail direkt über einen MUA
> eingeliefert hat, als auch einen Absender dessen Mail Postfix in
> seiner Eigenschaft als Backup-MX entgegen genommen hat?

Ja. Deshalb schaltet man das auf einem Backup-MX normalerweise
auch aus. Weil es besteht halt eine gewisse Gefahr von Backscatter.

> Angenommen Postfix nimmt als Backup-MX Mails an, und kann sie wegen 
> Ausfall des primären MX nicht zustellen, dann würde er die Absender 
> informieren?

Ja, würde er - aber so willst Du einen Backup-MX nicht konfigurieren.

> Ich denke wegen:
>
> "Cloud Computing: 3,6 Millionen Webseiten nach Brand bei OVH offline"
>
> https://glm.io/154844?t 
>
> darüber nach einen Backup-MX einzurichten.

Dann denk nochmal genauer darüber nach.
Du willst das mit ziemlicher Sicherheit nicht machen.

Über Zustellprobleme zu unterrichten, ist Sache des ausliefernden
Servers. Die policies dafür legt dessen Admin fest, der seine User
kennen oder das zumindest halbwegs vernünftig eingestellt haben sollte.
Mit backup-mx hebelst Du diese policies aus.
Falls Du z.B. die Benachrichtigungsintervalle oder die Queuehaltezeit
länger auslegst als es die Absenderseite wünscht, dann handelst Du
schonmal gegen die Interessen des Absenders.

Normale Mailserver versuchen i.d.R. wenigstens einige Tage lang
zuzustellen. Da bringt es grundsätzlich nicht viel, die Mail stattdessen
ebenso tagelang oder noch länger auf Deinem backup-mx rumliegen zu
lassen - falls der Ausfall so lange dauert.
Hat eigentlich nur Nachteile und ändert letzlich meist nichts an der
schlußendlichen Zustellung, weil die meisten Ausfälle nicht so lange
dauern.
Falls doch die sender queue Zeit ausläuft, weiß der Absender dann
Bescheid, das die Zustellung gescheitert ist. Falls es wichtig ist, wird
er nochmal senden oder anrufen oder sonstwie tätig werden.

Rechtlich ist es auch nicht unkritisch. Sobald der backup mx die Mail
annimmt, ist sie in Deiner Einflußsphäre angekommen. Da kannst Du dich
dann hinterher bei irgendwelchen Fristen nicht mit rausreden, daß man
die Mail aber doch nicht lesen konnte, weil die noch tagelang auf dem
backup rumlag. Das ist dann Dein ganz persönliches Problem.
Backup-mx ist letztlich nur sinnvoll, wenn er im Fehlerfall doch die
emails am ausgefallenen Hauptserver vorbei ausliefern kann. Also
deutlich mehr Aufwand.

Falls es nur hobbytechnische Spielerei zum Ausprobieren und Lernen ist:
Viel Spaß.
Aber ansonsten - falls Du nicht Mailprovider bist: Vergiß das Thema
besser. Der Schaden ist da schnell größer als potentieller Nutzen.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#6338

Am Fri, 12 Mar 2021 01:33:36 +0100 schrieb Marcus Jodorf:

> Frank Graf <f.graf@firemail.de> schrieb:
> 
>> gehe ich recht in der Annahme dass Postfix bei setzen des folgenden
>> Parameters:
>>
>> delay_warning_time = 4h
>>
>> sowohl den Absender informiert der eine Mail direkt über einen MUA
>> eingeliefert hat, als auch einen Absender dessen Mail Postfix in seiner
>> Eigenschaft als Backup-MX entgegen genommen hat?
> 
> Ja. Deshalb schaltet man das auf einem Backup-MX normalerweise auch aus.
> Weil es besteht halt eine gewisse Gefahr von Backscatter.

[...]

> Falls doch die sender queue Zeit ausläuft, weiß der Absender dann
> Bescheid, das die Zustellung gescheitert ist. Falls es wichtig ist, wird
> er nochmal senden oder anrufen oder sonstwie tätig werden.
> 
> Rechtlich ist es auch nicht unkritisch. Sobald der backup mx die Mail
> annimmt, ist sie in Deiner Einflußsphäre angekommen. Da kannst Du dich
> dann hinterher bei irgendwelchen Fristen nicht mit rausreden, daß man
> die Mail aber doch nicht lesen konnte, weil die noch tagelang auf dem
> backup rumlag. Das ist dann Dein ganz persönliches Problem.
> Backup-mx ist letztlich nur sinnvoll, wenn er im Fehlerfall doch die
> emails am ausgefallenen Hauptserver vorbei ausliefern kann. Also
> deutlich mehr Aufwand.
> 
> Falls es nur hobbytechnische Spielerei zum Ausprobieren und Lernen ist:
> Viel Spaß.
> Aber ansonsten - falls Du nicht Mailprovider bist: Vergiß das Thema
> besser. Der Schaden ist da schnell größer als potentieller Nutzen.

Ich bin kein Mailprovider, es geht um zwei eigene Domains und zwei 
Server. Ich wickele einen Teil meiner privaten Mails darüber ab.

Folgendermaßen:

Server 1:	Primärer MX für Domain A
Server 1:	Sekundärer MX für Domain B # noch nicht konfiguriert

Server 2:	Primärer MX für Domain B
Server 2:	Sekundärer MX für Domain A # noch nicht konfiguriert

Die Server stehen bei unterschiedlichen Providern in verschiedenen RZ. 
Die Server laufen auf echter Hardware aber ohne RAID, die HDD kann nach 
jahrelangem Betrieb einfach ausfallen. Das wollte ich u. a. absichern.

Meist fällt die Hardware aus wenn man im Urlaub ist und keine Möglichkeit 
hat das Problem schnell zu beheben.


Leider verursachen die Spam-Bekämpfungsmaßnahmen der Mailprovider immer 
wieder Kollateralschäden. Habe auch schon negative Erfahrungen sammeln 
dürfen. Da ist ein eigener Mailserver vorteilhaft. Das ist natürlich für 
wenige eine Option. Aktuell wieder:

"Spam: GMX- und Web.de-Kunden erhalten wichtige Mails nicht"

https://glm.io/154910?t 

Die Sperren sind offenbar so umfassend, dass die E-Mails der Stadt 
Mülheim an der Ruhr oder des E-Mail-Anbieters Mailbox.org nicht 
angenommen werden. So erhalten GMX- oder Web.de-Nutzer keine E-Mails der 
Stadtverwaltung. Termine beim Bürgeramt verfallen, weil die 
Bestätigungsmails aufgrund der Blockade nicht ankamen. Allein gestern 
sollen daher 46 Termine verfallen sein.

Laut Mailbox.org bestehen die massiven Probleme beim Empfang von E-Mails 
bereits seit Donnerstagnachmittag. Die Probleme hätten nichts mit 
Mailbox.org zu tun und träten weltweit auf. "Hier ist leider Geduld 
gefragt, bis die Kollegen ihr Problem gelöst haben", schreibt der 
Mailanbieter auf Twitter.


Rechtlich hoffe ich da nicht in Probleme zu geraten, es geht um meine 
privaten Mails. Mit einem Postfach z. B. bei gmx bin ich nicht besser 
dran. Die werden im Zweifel kaum Logfiles zur Verfügung stellen ob eine 
Mail angenommen oder abgewiesen wurden.


Frank

[toc] | [prev] | [next] | [standalone]

#6339

Frank Graf:

[...]
> Leider verursachen die Spam-Bekämpfungsmaßnahmen der Mailprovider immer 
> wieder Kollateralschäden. Habe auch schon negative Erfahrungen sammeln 
> dürfen. Da ist ein eigener Mailserver vorteilhaft. Das ist natürlich für 
> wenige eine Option. Aktuell wieder:
> 
> "Spam: GMX- und Web.de-Kunden erhalten wichtige Mails nicht"
> 
> https://glm.io/154910?t 

Ah - GMX und Web.de sind jetzt da, wo Microsoft schon seit Jahren ist.
Deren Server schmeißen auch etliche Mails einfach weg, wenn denen die
Server nicht passen. Dummerweise so, dass weder der Absender noch der
Empfänger davon informiert werden.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6340

Am 14.03.2021 um 04:56 schrieb Arno Welzel:
> Frank Graf:

>> Leider verursachen die Spam-Bekämpfungsmaßnahmen der Mailprovider immer
>> wieder Kollateralschäden. Habe auch schon negative Erfahrungen sammeln
>> dürfen. Da ist ein eigener Mailserver vorteilhaft. Das ist natürlich für
>> wenige eine Option. Aktuell wieder:
>>
>> "Spam: GMX- und Web.de-Kunden erhalten wichtige Mails nicht"
>>
>> https://glm.io/154910?t
> 
> Ah - GMX und Web.de sind jetzt da, wo Microsoft schon seit Jahren ist.
> Deren Server schmeißen auch etliche Mails einfach weg, wenn denen die
> Server nicht passen. Dummerweise so, dass weder der Absender noch der
> Empfänger davon informiert werden.

Glaube ich jetzt einfach mal nicht, denn in .de ist 
Nachrichtenunterdrückung strafbewehrt, sogar für Subunternehmer:

https://dejure.org/gesetze/StGB/206.html

-----

*Verletzung des Post- oder Fernmeldegeheimnisses*

(1) Wer unbefugt einer anderen Person eine Mitteilung über Tatsachen 
macht, die dem Post- oder Fernmeldegeheimnis unterliegen und die ihm als 
Inhaber oder Beschäftigtem eines Unternehmens bekanntgeworden sind, das 
geschäftsmäßig Post- oder Telekommunikationsdienste erbringt, wird mit 
Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe bestraft.

(2) Ebenso wird bestraft, wer als Inhaber oder Beschäftigter eines in 
Absatz 1 bezeichneten Unternehmens unbefugt
	1. 	eine Sendung, die einem solchen Unternehmen zur Übermittlung 
anvertraut worden und verschlossen ist, öffnet oder sich von ihrem 
Inhalt ohne Öffnung des Verschlusses unter Anwendung technischer Mittel 
Kenntnis verschafft,
	2. 	eine einem solchen Unternehmen zur Übermittlung anvertraute Sendung 
unterdrückt oder
	3. 	eine der in Absatz 1 oder in Nummer 1 oder 2 bezeichneten 
Handlungen gestattet oder fördert.

(3) Die Absätze 1 und 2 gelten auch für Personen, die
	1. 	Aufgaben der Aufsicht über ein in Absatz 1 bezeichnetes Unternehmen 
wahrnehmen,
	2. 	von einem solchen Unternehmen oder mit dessen Ermächtigung mit dem 
Erbringen von Post- oder Telekommunikationsdiensten betraut sind oder
	3. 	mit der Herstellung einer dem Betrieb eines solchen Unternehmens 
dienenden Anlage oder mit Arbeiten daran betraut sind.

[...]

-----


mfG Paul

[toc] | [prev] | [next] | [standalone]

#6341

Am 15.03.21 um 17:45 schrieb Paul Muster:

> Glaube ich jetzt einfach mal nicht, denn in .de ist 
> Nachrichtenunterdrückung strafbewehrt, sogar für Subunternehmer:
> 
> https://dejure.org/gesetze/StGB/206.html
> 


Wirklich kein Bounce?

Tim

[toc] | [prev] | [next] | [standalone]

#6342

On 15.03.21 18:23, Tim Ritberg wrote:
> Am 15.03.21 um 17:45 schrieb Paul Muster:

>> Glaube ich jetzt einfach mal nicht, denn in .de ist 
>> Nachrichtenunterdrückung strafbewehrt, sogar für Subunternehmer:
>>
>> https://dejure.org/gesetze/StGB/206.html

> Wirklich kein Bounce?

Was du fragen wollen?


mfG Paul

[toc] | [prev] | [next] | [standalone]

#6344

Tim Ritberg:

> Am 15.03.21 um 17:45 schrieb Paul Muster:
> 
>> Glaube ich jetzt einfach mal nicht, denn in .de ist 
>> Nachrichtenunterdrückung strafbewehrt, sogar für Subunternehmer:
>>
>> https://dejure.org/gesetze/StGB/206.html
>>
> 
> 
> Wirklich kein Bounce?

Nein, kein Bounce. Mails verschwinden einfach. Das kann ich jederzeit
live vorführen.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comm.software.mailserver

csiph-web