SMTP Dialog Restriktionen

Aus
Version vom 18. März 2009, 08:55 Uhr von Jahlives (Diskussion | Beiträge) (Die Seite wurde neu angelegt: == About == Postfix, der SMTP Part der Mailstation, erlaubt es sehr detailliert auf allen Stufen des SMTP Dialogs Prüfungen anzulegen und darauf basierend Emails resp ...)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

About

Postfix, der SMTP Part der Mailstation, erlaubt es sehr detailliert auf allen Stufen des SMTP Dialogs Prüfungen anzulegen und darauf basierend Emails resp Clients abzulehnen. Dazu bietet Postfix in der Konfigurationsdatei /usr/syno/mailstation/etc/main.cf diverse Einstellungsmöglichkeiten und Prüfungen der verschiedenen SMTP "Stationen". Zusätzlich - und das macht Postfix so flexibel - wird die Möglichkeit geboten bei jeder Stufe des SMTP Dialogs userspezifische reguläre Ausdrücke zu verwenden und entsprechend deren Resultaten zu reagieren. Die Konfiguration von SMTP und den verschiedenen Stufen der Prüfung ist sehr umfangreich (gibt ganze Foren zu diesem Thema). Im folgenden möchte ich auch zwei sehr gute Beiträge zum Thema verweisen: Beitrag bei jimsun.linxnet.com (englisch) und eine gute deutsche Zusammenfassung bei chains.ch. Auch kann es nicht schaden sich den Ablauf der SMTP Dialogs nochmals vor Augen zu führen. Denn an diesem Ablauf orientiert sich die Reihenfolge der Prüfungen. So ist es z.B. schlecht wenn eine HELO Prüfung nach der Sender Adress Prüfung gesetzt wird, denn angekommen bei der Senderdirektive ist das HELO bereits Geschichte: Das heisst also die Reihenfolge der Direktiven und ihrer Optionen (zumindest im 2. Abschnitt) ist wichtig für ein korrektes Alaufen der Prüfungen

Sinn und Zweck

Viele werden sich fragen, warum man überhaupt so einen Aufwand betreiben sollte. Kurs und bündig: Verminderung von Spam. Wiederum könnte man fragen: Aber warum denn man kann ja spamassassin einfach mit Postfix koppeln und der Spam fliegt raus. Wiederum kurze Antwort: Verminderung der Serverlast. Was so offensichtlich Spam ist, dass es von den Postfix Regeln erkannt werden kann, sollte man dem Spamassassin gar nicht servieren. Neben dem Spamassassin wird so auch die Last auf dem Postfix vermindert. Denn die Emails werden so verworfen bevor auch nur eine Zeile in die Mailwarteschlange (und damit dem Dateisystem) geschrieben wurde. Ausserdem sind die regulären Ausdrücke von Postfix nicht so ressourcenhungrig wie diejenigen vom Spamassassin. Der SA kann u.U. tausende von regulären Ausdrücken habe und das geht auf die Zeit. Ich habe das bei mir zu Hause getestet (ein Postfix Port mit Spamassassin und einer ohne). Die Verarbeitung ohne Spamassassin war in dem Moment wo ich auf Senden geklickt habe bereits abgeschlossen und die Email in der Inbox. Beim Versand via SA Port kann das bis zu 2 Sekunden dauern, ehe die Email im Eingang ist

Beispiel aus der main.cf

Nachfolgend findet ihr die Konfiguration, so wie ich sie bei meinem Postfix Server einsetze. Das soll ganz klar nicht "die Lösung" sein, sondern einfach zeigen wie man es machen kann. Dazu habe ich die Konfiguration in drei Abschnitte eingeteilt und werde die nacheinander abarbeiten und kommentieren. Dabei ist wie obenerwähnt die Reihenfolge beim 2. Abschnitt sehr wichtig! smtpd_delay_reject = no smtpd_helo_required = yes

smtpd_client_restritions = check_client_access regexp:/opt/etc/postfix/check_client, permit_mynetworks, reject_unknown_client, reject_rbl_client, reject_rhsbl_client smtpd_helo_restrictions = check_helo_access regexp:/opt/etc/postfix/check_helo, permit_mynetworks,reject_unknown_hostname, reject_invalid_hostname, reject_non_fqdn_hostname smtpd_sender_restrictions = reject_unknown_sender_domain, check_sender_access regexp:/opt/etc/postfix/sendermaps smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_rbl_client pbl.spamhaus.org, reject_unauth_destination smtpd_data_restrictions = reject_unauth_pipelining

body_checks = regexp:/opt/etc/postfix/body_check mime_header_checks = regexp:/opt/etc/postfix/mime_check

Weiter geht's unten, der Thread wurde zu lang