[Postfixbuch-users] smtpd_recipient_restrictions aus mysql

[Thomas Schwenski]

Thomas Walter schrieb:
> Thomas Schwenski schrieb:
>> Das hängt natürlich von Deinen Kunden ab, aber wenn ich auch nur einem
>> Kunden erklären muss, dass seine Mail Verspätung hat, weil meine Technik
>> versagt, dann ...
>> ... ist das schon ein gewaltiger Unterschied im Vergleich zu
>> Verzögerungen aufgrund technischer Erfordernisse und/oder
>> Schutzmaßnahmen (wie zum Beispiel Greylisting).
> 
> Also erstens sagt man Kunden sowas nicht, sondern gibt grundsätzlich
> immer den anderen die Schuld. So hat es mir jedenfalls ein Kollege
> erklärt, der bei einem großen Telekommunikationsanbieter arbeitet ;).

Das andere das machen, weiß ich - aber einen Kunden, der gehäuft
Probleme mit seinem Vertragspartner hat, interessiert am Ende wenig bis
gar nicht, ob der die Probleme selbst verursacht, sie anderen in Schuhe
schiebt oder komplett unschuldig ist.
Dann heißt es nur noch "bei Anbieter XY funktioniert es doch auch" und
andere Argumente zählen nichts mehr.
Außerdem ist es doch einfacher (und für die Nerven gesünder) solche
Diskussionen von vornherein möglichst zu vermeiden.

> Und zweitens haben wir auch seltsame Kunden, die bei einem technischen
> Problem die Nase rümpfen, aber ausflippen, wenn ich ihnen mitteile, dass
> wir Mails absichtlich verzögern, um empfangenen Spam zu minimieren.

Wie gesagt, jeder hat seine Kunden mit eigenen Vorstellungen.
Das muss man als Anbieter selbst einschätzen.

> Naja, in den Scripten können auch Fehler sein, oder in der Datenbank
> oder der DB-Anbindung beim Auslesen durch das Script, usw. das ist alles
> eine Frage der Einstellung.

Für Fehler in den Scripten werden ja diverse Tests vor dem
Produktiveinsatz durch geführt und Fehler in der Datenbank und beim
Auslesen sollten durch das Script erkannt und abgefangen werden.

Man kann natürlich auch einfach nur blind darauf vertrauen, dass die
Datenbank nur gültige Werte enthält, aber das wäre wie als wenn ein
Programmierer darauf vertraut, dass ein User nur gültige Werte in ein
Feld eingibt.


> Ich wollte darauf hinaus, dass man ihm die MySQL-Datenbank nicht gleich
> als Teufelswerk ausreden sollte, ohne den genauen Zweck zu wissen.

Nun das habe ich ja auch nicht tun wollen und meines Erachtens auch
nicht getan:

Wie ich schrieb ist es unter Umständen schon sehr riskant bei gewissen
Maps auf einen funktionierenden SQL-Server zu vertrauen, diesem dann
aber noch einen wirklich wichtigen Teil der Dienst-Konfiguration
anzuvertrauen halte ich aber nunmal für fahrlässig.
Dazu kommt, dass sich die Datenbasis für Mailboxen relativ häufig
ändern, die Konfiguration der smtpd_*_restrictions in der Regel nach der
Einrichtung und Testphase eher selten.

> Es gibt bestimmt auch Gründe, die für den Einsatz sprechen. Spontan
> würden mir dynamisch generierte Listen einfallen, die sich relativ
> häufig ändern oder bei denen ein Update pro Tag nicht ausreicht, usw.

Das sind dann aber auch eher Gründe für einen kürzeren Export-Intervall.
Wenn Du die Datenbank sinnvoll gestaltest (mit VIEWs und Indizes),
kannst Du auch bei einem großen Datenbestand die Exportzeit verkürzen.
Denkbar wäre auch jedem Datensatz ähnlich wie bei DNS eine Seriennummer
mitzugeben anhand derer Veränderungen festgestellt und eventuell auch
zeitlich zugeordnet werden können.
Auf diese Art und Weise könnte man bei wirklich großen Datebeständen nur
geänderte Datensätze aktualisieren.

Prinzipiell spricht aber auch nichts gegen kürzere
Aktualisierungsintervalle als 1d.
Schlussendlich lässt sich eine Aktualisierung des Exports aber auch
(zusätzlich) manuell anstoßen, wenn Änderungen vorgenommen wurden.

Der Königsweg könnte zum Beispiel sein in einem mittleren
Aktualisierungsintervall (z.B. 1d) alle Datensätze zu exportieren und
gleichzeitig auf Inkonsistenzen zu überprüfen (am besten außerhalb von
Stoßzeiten) und bei Änderungen, die innerhalb des Intervalls erfolgen
manuell nur einzelne Datensätze, die verändert wurden, im Export zu
aktualisieren.


Wie ich ebenfalls schon geschrieben hatte, bedeutet so ein Setup
natürlich einmalig einen etwas höheren Zeit- und Personalaufwand, der
sich aber schon rentiert, wenn man dem gegenüber die deutlich größere
Wahrscheinlichkeit/Häufigkeit von Engpässen beim MySQL-Server setzt.

Zusätzlich schont man mit dieser Methode auch Ressourcen und
beschleunigt wahrscheinlich auch noch Zugriffszeiten.

Ein Zwischenweg wäre eventuell noch der Einsatz von SQLite als Backend,
allerdings unterstützt Postfix dieses Datenbankformat nicht nativ.
Ein entsprechender Patch existiert zwar, wird aber anscheinend nur
sporadisch gepflegt, erfordert eine eigene Kompilierung von Postfix.
Detaillierte Hinweise kann ich mangels Erfahrung damit, dazu allerdings
nicht geben.

Thomas