QMail + Patches

F

Fireball22

Registered User
Hallo zusammen,

mein Ziel ist es von Plesk weg hin zu einem selbst konfiguriertem System zu gehen.

Postfix macht zwar einen guten Eindruck, das einzige Manko ist allerdings der fehlende "Spamdyke".
Einiges lässt sich zwar direkt über die Postfix-Konfiguration nachziehen, aber leider nicht alles (z. B. Erkennung dynamische IP-Adressen).

Das ist der Grund, weshalb ich mich für eine QMail-Installation unter Debian interessiere.

Viel nützliches habe ich bereits hier gefunden:
http://www.cargal.org/downloads/HOW-TO/debianqmail/debianqmail.html

Leider scheitert die Installation allerdings beim Anwenden der Patches. Vermutlich habe ich ein neueres Built.

Kennt von euch jemand eine gute Quelle für gängige QMail-Patches?

Oder was meint ihr? Doch weg von QMail gehen und an Postfix festhalten?

MfG
Fireball22
 
Fireball22 said:
Doch weg von QMail gehen und an Postfix festhalten?
Click to expand...
Dazu ein Definitives "JA".
Alles was Qmail kann, kann Postfix viel besser. Alles was im Qmail mit Patches gemacht wird, kann Postfix per content_filter nachrüsten.
Und alles was Du an Patches einbauen willst, kann Amavisd.

Schau Dir einfach die Geschichte von Qmail an:
Seit über 10 Jahren wird es nicht mehr weiter entwickelt. Statt dessen findest man für verschiedene Alltags-Probleme vereinzelte Patches die fast genau so alt sind.
Ich denke allein das spricht schon für sich.

huschi.
 
Dafür gibt es Blocklisten und Spamassassin...
Click to expand...

Als Ersatz für Spamdyke unter Postfix?
Spamassassin würde ich ungern einsetzen, da allein schon durch Greylisting und durch eine saubere Mailserver-Konfiguration der meiste SPAM abgefangen wird.
Blocklisten verwende ich bereits in meiner Konfiguration.

Grüße
Fireball22
 
Vielen Dank, Huschi!

Nur wie setze ich denn unter Postfix Regln wie z. B. reject-ip-in-cc-rdns (aus Spamdyke) um?

Grüße
Fireball22
 
Für RBL-Blocker unter Postfix gibt es dutzende von Howtos. Einfach mal Tante Google befragen.
Es gibt nämlich auch noch unterschiedliche Ansätze. Z.B. kannst Du "reject_rbl_client" beliebig in recipient-/helo-/sender-Restrictions einsetzten. Welchen Vorteil welche Version hat, musst Du Dir anlesen und entscheiden, was Du willst.

Und für Greylisting ist "Postgrey" am einfachsten installiert.

huschi.
 
Genau, so habe ich es auch bisher konfiguriert.

Lediglich die Möglichkeit, dynamische Sender-IPs abzuweisen fehlt mir noch, ist euch da etwas bekannt wie man das anstellen könnte?

Grüße
Fireball22
 
Vielleicht hat hierfür noch jemand einen kleinen Tipp für mich:

In meiner Postfix-Config gibt es unter den smtpd_sender_restrictions die Regel reject_unknown_client_hostname.

Jedoch selbst wenn ich eine Mail mit MAIL FROM: <sdkfljdklsf@jsdklfjklsdfjsdzfzzzisdflmxxkljkldf.com> versende beschwert er sich nicht darüber und nimmt die Mail an.

Was mache ich falsch?

Grüße
Fireball22
 
Welche Postfix-Version hast Du drauf?
Statt reject_unknown_client_hostname könnte man das etwas schwächere reject_unknown_reverse_client_hostname nehmen. Das reicht auch um Spammer von Fremd-Servern zu bannen und birgt weniger Probleme mit echten Email-Servern.
Hast Du "smtpd_delay_reject=yes" drin?

huschi.
 
Es ist Version 2.7.1 installiert.

smtpd_delay_reject ist auf yes.

Ich habe die Regel nun mal gegen reject_unknown_reverse_client_hostname getauscht, aber ebenfalls keine Wirkung.

Aber nun erklärt sich auch wieso: Im Verbose-Logging konnte ich finden, dass er den Check mit dem Client-Hostname macht, statt mit dem MAIL-FROM-Namen, ist das normal?
Macht ja irgendwie dann keinen Sinn die Verwendung in diesem Parameter zuzulassen, wenn sie sich auf die client_restrictions auswirkt.

Evtl. ist dann reject_unverified_sender das was ich suche.

Grüße
Fireball22
 
Du musst in der Postfix-Doku genau schauen, wo die Restriction steht. Die reject_unknown_reverse_client_hostname steht bei smtpd_client_restrictions. Auch wenn man es in die smtpd_sender_restrictions schreibt, tut es dennoch nur das, was es tut: den Client prüfen. Aber eben erst wenn MAIL FROM kam. Das allerdings nur wenn smtpd_delay_reject gesetzt ist.

huschi.
 
Bzw. erst wenn RCPT TO kam, weil ab diesem Zeitpunkt werden ja erst alle Restricitions überprüft, richtig?

Das bedeutet ich kann eig. auf die client_restrictions ganz verzichten, weil deren Regeln z. B. alle in die recipient_restrictions aufnehmen kann.
Und un in die sender_restrictions nehme ich nur die da möglichen Regeln auf, oder?

Grüße
Fireball22
 
Es ist relativ egal wie Du sie mischst.
Ich bin ein Fan davon sie in die Restrictions zu schreiben, zu denen sie eigentlich gehören.

huschi.
 
Wie habt ihr das eig. mit der Blockade von Early-Talkers gemacht?

Generell lässt sich dies ja mittels (z. B. unter helo_restrictions)

sleep 5, reject_unauth_pipelining
Click to expand...

realisieren, aber leider nur wenn smtpd_delay_reject deaktiviert ist.

Ich kann dies aber nicht deaktivieren, da meine sasl-auth. davon abhängt.

Grüße
Fireball22
 
You must log in or register to reply here.
Back
Top