PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Frage zu RBL



pombaer
29.05.09, 13:40
Ich möchte zen.spamhaus.org in meine Postfix Konfiguration einbauen, wie kann ich prüfen ob das ding auch richtig funktioniert?

Ich habe folgendes in meine main.cf eingebaut:

smtpd_client_restrictions =
permit_inet_interfaces
permit_mynetworks
reject_rbl_client zen.spamhaus.org

Wieso ist "zen.spamhaus.org" nicht über DNS auflösbar (zumindest bei mir nicht)? Nur um sicherzugehen, im Prinzip handelt es sich dabei um so etwas wie eine DNS Abfrage, dh. es wird der gleiche Port verwendet, ich muss also nur meinen Postfixserver in der Firewall für den DNS Port freigeben, oder?

Thovan
29.05.09, 14:06
Die Postfix-Dokumentation (http://www.postfix.org/uce.html) meint dazu:


reject_rbl_client domain.tld
Reject the request when the reversed client network address is listed with an A record under domain.tld. The maps_rbl_reject_code parameter specifies the response code for rejected requests (default: 554), the default_rbl_reply parameter specifies the default server reply, and the rbl_reply_maps parameter specifies tables with server replies indexed by RBL domain.

Das heißt Postfix ermittelt die IP-Adresse des Clients, dreht diese herum (also aus 127.0.0.1 würde dann 1.0.0.127) und fragt davon den A-Record in der Domain domain.tld ab.

Wenn ich das richtig verstehe entspricht das einem
dig -t a 1.0.0.127.domain.tld auf der Konsole.

Deine smtpd_*_restrictions sind noch deutlich ausbaufähig.
Ich hoffe Du betreibst damit keinen eigenen Root-/Mailserver.

Generell würde ich Dir anraten die smtpd_client_restrictions leer zu lassen und alles in die smtpd_recipient_restrictions zu packen.

pombaer
29.05.09, 14:32
Danke für deine Antwort, dazu noch eine Frage, zu viele Restrictions möchte ich nicht in Postfix hinterlegen, ich weis dass da noch einiges möglich ist, doch ich bezweifle auch ob es nicht zuviel des guten wäre, ich wähle da mal lieber den Mittelweg, es kommt ja noch MailScanner, Spamassasin, ein Virenscanner dazu, darum löse ich nicht alles über Postfix, revese DNS ev. noch.

Verstehe ich dich da Richtig dass ich diese Restrictions die ich bei "smtpd_client_restrictions" hinterlegt habe so auch bei "smtpd_recipient_restrictions" verwenden kann (in der Postfix Docu ist das so nicht erklärt)? Habe das, glaube ich, schon mal in einer Beispiel Config gesehen, aber nicht verstanden. Wo ist der Vorteil, bzw. überhaupt der Unterschied? Wäre dir da noch mal dankbar über eine Antwort.

Sam Fisher
29.05.09, 15:08
Hallo !

Danke für deine Antwort, dazu noch eine Frage, zu viele Restrictions möchte ich nicht in Postfix hinterlegen, ich weis dass da noch einiges möglich ist, doch ich bezweifle auch ob es nicht zuviel des guten wäre, ich wähle da mal lieber den Mittelweg, es kommt ja noch MailScanner, Spamassasin, ein Virenscanner dazu, darum löse ich nicht alles über Postfix, revese DNS ev. noch.
Das ist totaler Unsinn, Thovan meinte damit ja nicht, dass du dir 50 RLB's reinknallen sollst. Es gibt da auch noch viele andere nützliche Parameter die man setzen sollte. Des weiteren ist Postfix genau der Punkt wo du so viel wie möglich blocken solltest, denn alles was weiter geht belegt Rechenleistung auf deinem System.

Ich rate dir zu dme Postfix Buch von Peer Heinlein und rate dir ebenfalls bis du das gelernt hast KEINEN Root-Server oder so zu betreiben, dass kann böße ins Auge gehen.

Nur mal so als Anregung, so habe ich es auf meinem Testserver zur Zeit laufen. Bei den LIVE-Servern ist es noch viel Feiner.

smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_non_fqdn_hostname,
reject_invalid_hostname,
reject_rhsbl_client rhsbl.sorbs.net,
reject_rhsbl_sender rhsbl.sorbs.net,
reject_rbl_client ix.dnsbl.manitu.net,
reject_rbl_client dialup.blacklist.jippg.org,
reject_rbl_client cbl.abuseat.org,
reject_unauth_pipelining

smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_destination,
reject_unlisted_recipient,
reject_unauth_pipelining


Viele Grüße
Sam

pombaer
29.05.09, 15:37
Das meinte ich auch nicht, es stimmt sicher das deine Restrictions Sinn machen, nur setzt das halt oft auch vorraus dass alle Mailserver richtig konfiguriert sind, zB. mit dem "reject_unknown_client_hostname" kann es schon sein dass einige Domains mit falsch konfigurierten DNS herusfallen, wie gesagt, ich bin Zur Zeit noch am Testen, deshalb ist das noch nicht so eng zu sehen, kommt schon noch.

Aber was ich nicht verstehe, was ist der Unterschied zwischen

smtpd_recipient_restrictions = permit_mynetworks
und
smtpd_helo_restrictions = permit_mynetworks,

Wieso hast du "permit_mynetworks" 2x in deinen Restrictions, wo wirkt sich das unterschiedlich aus?

Thovan
29.05.09, 18:11
Das meinte ich auch nicht, es stimmt sicher das deine Restrictions Sinn machen, nur setzt das halt oft auch vorraus dass alle Mailserver richtig konfiguriert sind, zB. mit dem "reject_unknown_client_hostname" kann es schon sein dass einige Domains mit falsch konfigurierten DNS herusfallen, wie gesagt, ich bin Zur Zeit noch am Testen, deshalb ist das noch nicht so eng zu sehen, kommt schon noch.

Aber was ich nicht verstehe, was ist der Unterschied zwischen

smtpd_recipient_restrictions = permit_mynetworks
und
smtpd_helo_restrictions = permit_mynetworks,

Wieso hast du "permit_mynetworks" 2x in deinen Restrictions, wo wirkt sich das unterschiedlich aus?

Weil das auch "unsinnig" ist.
Die unterschiedlichen smtpd_*_restrictions sind für die unterschiedlichen Stadien der SMTP-Kommunikation zuständig: Die smtpd_client_restrictions müssten schon beim Verbindungsaufbau greifen, die smtpd_helo_restrictions greifen nachdem der Client sein HELO/EHLO gesendet hat, die smtpd_sender_restrictions greifen beim MAIL FROM, die smtpd_recipient_restrictions beim RCPT TO und die smtpd_data_restrictions beim DATA.

Meine Empfehlung: Schmeiß alles bei den smtpd_recipient_restrictions rein - dort sind die Checks gut aufgehoben, die meisten Überprüfungen sind dort möglich, der Mehr-Traffic gegenüber den vorher greifenden Restrictions vernachlässigbar größer.
Außerdem hast Du den Vorteil, dass Du im Log alle nötigen Infos über Absender und Empfänger hast - sehr nützlich um rauszufinden, warum eine E-Mail abgewiesen wurde. Du kannst immer nach dem Absender greppen (was zum Beispiel bei den smtpd_client_restrictions nichtmöglich wäre, weil die schon greifen bevor Postfix der Absender bekannt ist).

Für die Abfrage von RBLs empfiehlt sich Policyd-weight - lass Dich nicht davon verunsichern, dass es angeblich nicht weiterentwickelt wird.
Zusätzlich noch postgrey für's Greylisting und Amavis als Interface für ClamAV und Spamassassin.
Von Mailscanner würde ich abraten: das Setup ist kompliziert und Support nur auf der Mailscanner-Mailingliste zu bekommen. Insgesamt verwurschtelt es ein Postfix-Setup zu sehr und es ist IMHO sogar ein Patch für Postfix nötig.

Die Buchempfehlung ist Gold wert. Peer Heinlein weiß aus jahrelanger Erfahrung, worüber er schreibt. Auch interessant ist das Buch von Ralf Hildebrand und Patrick Ben Koetter. Alle Drei sind Profis was Postfix und Mailserver betrifft und pflegen auch Kontakt zu Wietse Venema (Autor von Postfix).


Ich kann nur nochmal betonen: Lass die Finger davon einen Rootserver selbst einzurichten, sondern lies dich in das Thema ein und übergib das Ganze in der Zwischenzeit jemandem der sich damit auskennt.
Peer (Heinlein) umreißt in dem Buch auch einige rechtliche Konsequenzen - und Du solltest die ernst nehmen bzw. unsere Warnungen - das Projekt Mailserver kann ganz schön in die Hose gehen und dann wird es verdammt teuer.

pombaer
02.06.09, 14:28
Irgendwann steht man immer am Anfang wenn man sich mit neuer Materie befaßt, was mich noch interessieren würde ist worauf du anspielst mit dem "in die Hose gehen" und teuer werden. Meinst du das in Hinblick auf ein offenes Mail Relay und damit verbundenen "Unannehmlichkeiten" oder was ganz anderes?

Thovan
02.06.09, 22:34
Irgendwann steht man immer am Anfang wenn man sich mit neuer Materie befaßt, was mich noch interessieren würde ist worauf du anspielst mit dem "in die Hose gehen" und teuer werden. Meinst du das in Hinblick auf ein offenes Mail Relay und damit verbundenen "Unannehmlichkeiten" oder was ganz anderes?

Unter Anderem meine ich auch das.
Noch ein Beispiel:
Dein schlecht konfigurierter Mailserver wird zur Backscatter-Quelle. Daraufhin landet er auf Blacklists, Mails von Deinem Server werden nicht mehr angenommen.
Wichtige E-Mails eines Deiner (eventuellen) Kunden werden nicht zugestellt.
Dadurch entsteht ihm ein finanzieller Schaden (teurer Auftrag geht durch die Lappen).
Je nach Konfiguration Deines Server ist Dir fahrlässiges Handeln nachweisbar ...

Oder einige der vom Backscatter betroffenen Personen klagen auf Unterlassung oder Schadensersatz.

Oder durch eine schlechte Konfiguration gelingt einem Dritten der Zugriff auf den Inhalt einer fremden Mailbox.

Die Liste lässt sich beliebig fortführen und ist nicht nur auf Mailserver-Dienste anwendbar.

Glaub' jahrelanger Erfahrung: Auch wenn Du glaubst zu wissen was Du tust und denkst, dass es nicht so schlimm werden wird. Verlass Dich lieber auf die Erfahrung von Profis, die eben diese haben.
Lass die Dein System konfigurieren und ordentlich dokumentieren und nach Möglichkeit Dich komplett einweisen.
Diese (finanzielle und zeitliche) Investition rentiert sich allemal und ist deutlich geringer als auch nur ein Rechtsstreit wegen eines Gurkensystems.