[Postfixbuch-users] MySQL und Restriction für gefälschtes EHLO

Di Jan 29 14:20:46 CET 2008

Hallo Peer,

> Ich glaube nicht, daß vier Restrictions-Positionen früher oder später 
> soviel Zeit sparen, daß Du 75% Deiner Resourcen freibekommst. Die 
> unterschiedliche Positionierung in den Restrictions wird über 100.000 
> E-Mails vermutlich so gut wie nicht meßbar sein (kann ja mal messen).

da hast Du völlig Recht. Ich hatte unterschlagen, dass ich fail2ban 
einsetze. Ich weiß, dass das ohne Verstand der Materie zu fatalen 
Problemen führen würde, aber ich habe ein relativ humanes Set an Regeln 
definieren müssen, damit die Server nicht absaufen. Ich persönlich hasse 
solche Brachialmethoden, aber mir blieb kein anderes mir bekanntes Mittel.

> Ich finde es nur immer etwas gefährlich, wenn solche Configs die auf 
> Besonderheiten basieren, dann so kommentarlos veröffentlich werden. 
> Andere nutzen das anders, übernehmen sowas per Cut & Paste und holen sich 
> dann Probleme ins Haus -- die Du so ggf. nie hattest, wenn Du mynetworks 
> de facto nicht benutzt. Okay, könnte Dir egal sein. Aber andererseits 
> stellt sich eben doch die Frage: warum nicht gleich generisch so machen, 
> daß es immer für alle geht? Warum nicht so machen, daß auch Du es ggf., 
> einfach so für andere Zwecke übernehmen kannst? Man wächst und verändert 
> sich ja auch in den Aufgaben.
> 

Ich hatte beim Schreiben dieser Mail das Problem, dass sie sowieso sehr 
groß zu werden schien. Ich habe aber daraus gelernt, dass es u.U. ganz 
wichtig ist, den Verwendungszweck des Setups mit zu erklären. Da war ich 
leider etwas nachlässig.

Wegen der Idee, eine Config etwas generischer zu bauen um sie evtl. 
öfters verwenden zu können, habe ich permit_mynetworks nun verschoben. 
Es unterliegt so nun auch den gleichen Restriktionen wie 
permit_sasl_authenticated.

Was permit_tls_clientcerts anging, kam es zu folgendem Problem: Wenn man 
diese Restriktion mit dem hier in der Liste sehr stark umstrittenen 
sender_login_missmatch veruscht zu kombinieren, dann erntet man 
folgenden Fehler des Servers:

Sender address rejected: not logged in

Ich habe für mich nun die Entscheidung getroffen, dass 
sender_login_mismatch & Co keine hohe Relevanz haben, da a) Dienste wie 
SPF sowieso problematisch sind und b) die Zahl Derer, die mit einer 
anderen Absenderadresse verschicken verschwindend gering ist.

> 
> Nochmal zum nachfassen: Ich finde diese Punkte sehr wichtig. Für mich 
> müssen/sollten sie auf jeden Fall über dem permit für die eigenen Nutzer 
> stehen.

Ich kann diese Gedanken gut nachvollziehen. Ich sehe das genauso.

> 
> Und: reject_unverified_recipients vor Deinen tls-authentifizierten Mails? 
> Das würde bedeuten, daß Postfix susi at web.de verifizieren muß, bevor du 
> versenden darfst. 

Das war ursprünglich so gewollt. Der Gedanke dahinter war: Vertippt sich 
der Absender in der RCPT-TO-Zeile, so sagt ihm schon gleich der eigene 
MTA, dass das Ziel erfolglos sein wird. Verschicke ich die Mail ohne 
Prüfung, so könnte ja der Remote-MTA nur ein 45x produzieren (Weil 
vielleicht das Mail-Konto noch gar nicht eingerichtet wurde; und es 
wegen des Tippfehlers wohl auch nie wird). Konsequenz wäre, dass der 
Kunde nun denkt: Meine Mail ist ja angenommen worden und versandt. Da 
für viele Mail so wichtig ist, wollte ich dort eine DAU-Sicherheit einbauen.

>>>>          check_policy_service inet:127.0.0.1:12525
>>> Angenommen es gibt einen Dir wichtigen Client, den Du vom
>>> Policyd-Weight ausnehmen willst. Wie richtest Du ein whitelisting
>>> ein? Das sieht Deine Config nicht vor. Also schneidest Du Dir ohne
>>> Notwendigkeit Deine Handlungsmöglichkeiten ab.
>> Das ist ein gutes Argument. Wie könnte ich das etwas dynamischer
>> konfigurieren? Über FILTER in einer extra Datei?
> 
> Nein, über die richtige Reihenfolge in den Restricitions.
> 
> Ich glaube, ich habe da vor einigen Wochen mal einen längeren 
> grundsätzlichen Artikel zur optimalen Restriction hier dazu geschrieben. 
> ich schau mal, ob ich den gleich noch wiederfinde, dann muß ich nicht 
> alles neu tippen. :-)

Das wäre natürlich zuckerst. Würde mich freuen.

>> Was mein Thema angeht: Ich habe heute ca. 10 Stunden dran gesessen und
>> mir ein Skript gebaut, was mir Flat-Files aus der MySQL-DB erzeugt. Hat
>> auch den Vorteil, dass ich a) den MySQL-Server stark entlaste und b)
>> einen Single-Point-of-Failure weniger habe.
> 
> Jau, lokale Dateien sind aus Sicht der Stabilität und Performance immer 
> besser. Wenn man auf Echtzeit-Daten verzichten kann, sind lokale Dateien 
> das Mittel der Wahl.

Das hat mich von Anfang an an syscp so genervt. War leider Werkvertrag 
:-( (Hoffe, ich sage da jetzt  nicht den falschen juristischen Begriff)

> Sorry, Entschuldigung. Ich wollte dir damit nicht auf die Füße treten, ich 
> akzeptiere gerne, daß ich hier offensichtlich zu brachial reingegangen 
> bin. Sorry -- ich erkläre das leider zweimal am Tag irgendwem, da wird 
> man irgendwann "hart" in seinen Antworten, gerade wenn man das im Akkord 
> alles abarbeitet -- und ich gelobe hiermit Besserung. Auf die Füße treten 
> wollte ich Dir keinesfalls, das tut mir ernsthaft leid und war nicht so 
> gemeint.

Vielen lieben Dank.

Grüße
Christian

-- 
Roessner Network Solutions (R.N.S.)

Licher Str. 19a
35394 Gießen

USt-IdNr.: DE225643613

Fon: +49 641 2097252
Fax: +49 641 2097253
Mobil: +49 171 3611230

URL: http://www.roessner-net.com/
PGP: http://www.roessner-net.com/0x6B929997.asc

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 252 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20080129/630025c2/attachment.asc>