Archiv:SMTP Dialog Restriktionen - Versionsgeschichte

Tommes: Tommes verschob die Seite SMTP Dialog Restriktionen nach Archiv:SMTP Dialog Restriktionen

2025-03-15T07:16:19Z

Tommes verschob die Seite SMTP Dialog Restriktionen nach Archiv:SMTP Dialog Restriktionen

← Nächstältere Version	Version vom 15. März 2025, 07:16 Uhr
(kein Unterschied)

imported>Jahlives: /* Tipp */

2010-09-12T12:24:01Z

Tipp

← Nächstältere Version		Version vom 12. September 2010, 12:24 Uhr
Zeile 99:		Zeile 99:

	So ist der Aufwand den Postfix nach einem Firmware Update wieder einzurichten minimal.		So ist der Aufwand den Postfix nach einem Firmware Update wieder einzurichten minimal.
			[[Category:Mailstation]]
			[[Category:Postfix]]

imported>Jahlives: Änderung 2074 von Jahlives (Diskussion) wurde rückgängig gemacht.

2010-04-15T20:41:45Z

Änderung 2074 von Jahlives (Diskussion) wurde rückgängig gemacht.

← Nächstältere Version		Version vom 15. April 2010, 20:41 Uhr
Zeile 12:		Zeile 12:
	== Beispiel aus der main.cf ==		== 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!		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!
	<span style="font-family:monospace;display:block;border-style:dotted;border-width:0.1em;border-color:#2F6FAB;background-color:#F9F9F9;padding:20px;">smtpd_delay_reject = ~~yes~~<br />smtpd_helo_required = yes<br /><br />~~smtpd_client_restrictions~~ =~~<br~~ />permit_mynetworks,~~<br />~~reject_rbl_client,<br />~~reject_rhsbl_client<br~~ /><br />		<span style="font-family:monospace;display:block;border-style:dotted;border-width:0.1em;border-color:#2F6FAB;background-color:#F9F9F9;padding:20px;">
	smtpd_sender_restrictions =~~<br~~ /~~>reject_unknown_address,<br~~ /~~>reject_unknown_sender_domain<br~~ /><br />		smtpd_delay_reject = no<br />
	smtpd_recipient_restrictions =<br />~~reject_unauth_destination,~~<br />~~reject_unknown_recipient_domain,~~<br />~~permit~~<br /><br />		smtpd_helo_required = yes
	~~smtpd_data_restrictions~~ = ~~reject_unauth_pipelining~~		<br /><br />
			smtpd_client_restritions = check_client_access regexp:/opt/etc/postfix/check_client, permit_mynetworks, reject_unknown_client, reject_rbl_client, reject_rhsbl_client<br />
			smtpd_helo_restrictions = check_helo_access regexp:/opt/etc/postfix/check_helo, permit_mynetworks,reject_unknown_hostname, reject_invalid_hostname, reject_non_fqdn_hostname<br />
			smtpd_sender_restrictions = reject_unknown_sender_domain, check_sender_access regexp:/opt/etc/postfix/sendermaps<br />
			smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_rbl_client pbl.spamhaus.org, reject_unauth_destination<br />
			smtpd_data_restrictions = reject_unauth_pipelining<br />
			<br /><br />
			body_checks = regexp:/opt/etc/postfix/body_check<br />
			mime_header_checks = regexp:/opt/etc/postfix/mime_check
	</span>		</span>
	=== 1. Abschnitt ===		=== 1. Abschnitt ===

imported>Jahlives: /* Beispiel aus der main.cf */

2010-04-15T20:40:00Z

Beispiel aus der main.cf

← Nächstältere Version		Version vom 15. April 2010, 20:40 Uhr
Zeile 12:		Zeile 12:
	== Beispiel aus der main.cf ==		== 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!		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!
	<span style="font-family:monospace;display:block;border-style:dotted;border-width:0.1em;border-color:#2F6FAB;background-color:#F9F9F9;padding:20px;">		<span style="font-family:monospace;display:block;border-style:dotted;border-width:0.1em;border-color:#2F6FAB;background-color:#F9F9F9;padding:20px;">smtpd_delay_reject = yes<br />smtpd_helo_required = yes<br /><br />smtpd_client_restrictions =<br />permit_mynetworks,<br />reject_rbl_client,<br />reject_rhsbl_client<br /><br />
	smtpd_delay_reject = no<br />		smtpd_sender_restrictions =<br />reject_unknown_address,<br />reject_unknown_sender_domain<br /><br />
	smtpd_helo_required = yes		smtpd_recipient_restrictions =<br />reject_unauth_destination,<br />reject_unknown_recipient_domain,<br />permit<br /><br />
	<br /><br />		smtpd_data_restrictions = reject_unauth_pipelining
	~~smtpd_client_restritions~~ = ~~check_client_access regexp:~~/~~opt/etc/postfix/check_client,~~ permit_mynetworks, ~~reject_unknown_client,~~ reject_rbl_client, reject_rhsbl_client<br />
	~~smtpd_helo_restrictions~~ = ~~check_helo_access regexp:~~/~~opt/etc/postfix/check_helo, permit_mynetworks,reject_unknown_hostname, reject_invalid_hostname~~, ~~reject_non_fqdn_hostname~~<br />
	~~smtpd_sender_restrictions =~~ reject_unknown_sender_domain~~, check_sender_access regexp:~~/~~opt/etc/postfix/sendermaps~~<br />
	smtpd_recipient_restrictions = ~~permit_sasl_authenticated, permit_mynetworks, reject_rbl_client pbl.spamhaus.org, reject_unauth_destination~~<br />
	~~smtpd_data_restrictions = reject_unauth_pipelining~~<br />
	<br /><br />
	~~body_checks = regexp:/opt/etc/postfix/body_check~~<br />
	~~mime_header_checks~~ = ~~regexp:/opt/etc/postfix/mime_check~~
	</span>		</span>
	=== 1. Abschnitt ===		=== 1. Abschnitt ===

imported>Raymond: /* Tipp */ typo

2009-10-22T15:26:59Z

Tipp: typo

← Nächstältere Version		Version vom 22. Oktober 2009, 15:26 Uhr
Zeile 98:		Zeile 98:
	dann könnt ihr die main.cf unter dem angegebenen Pfad nach Herzenslust bearbeiten und habt immer eine funktionierende Ursprungsversion im Default Verzeichnis. Nach einem FW Update müsst ihr einzig obige Zeile wieder in die Haupt-Konfig eintragen und den Postfix neustarten. Kopiert auch gleich die master.cf in das Verzeichnis auf /volume1 und legt alle RexExp Files ebenfalls unter diesem neuen Pfad an.		dann könnt ihr die main.cf unter dem angegebenen Pfad nach Herzenslust bearbeiten und habt immer eine funktionierende Ursprungsversion im Default Verzeichnis. Nach einem FW Update müsst ihr einzig obige Zeile wieder in die Haupt-Konfig eintragen und den Postfix neustarten. Kopiert auch gleich die master.cf in das Verzeichnis auf /volume1 und legt alle RexExp Files ebenfalls unter diesem neuen Pfad an.

	So ist der Aufwand den Postfix nach einem Firmware Update wieder einzurichten minimal		So ist der Aufwand den Postfix nach einem Firmware Update wieder einzurichten minimal.

imported>Raymond: /* 2. Abschnitt */ typo

2009-10-03T14:52:49Z

2. Abschnitt: typo

← Nächstältere Version		Version vom 3. Oktober 2009, 14:52 Uhr
Zeile 70:		Zeile 70:

	Die letzte Direktive muss man ein bisschen abgetrennt von den anderen beachten (man könnte sie auch in den 3. Abschnitt verfachten). Denn bei allen bis auf die letzte Direktive weiß der Client oder Spammer nicht ob die Empfangsadresse überhaupt existiert resp. akzeptiert wurde. Meist probieren Spammer bei einer Domain mehrere Emailadressen aus, bis sie eine finden die aktzeptiert wird.		Die letzte Direktive muss man ein bisschen abgetrennt von den anderen beachten (man könnte sie auch in den 3. Abschnitt verfachten). Denn bei allen bis auf die letzte Direktive weiß der Client oder Spammer nicht ob die Empfangsadresse überhaupt existiert resp. akzeptiert wurde. Meist probieren Spammer bei einer Domain mehrere Emailadressen aus, bis sie eine finden die aktzeptiert wird.
	Bei einer Fehlermeldung bei der letzten Direktive weiss der Client oder Spammer aber bereits, dass die Adresse ~~aktzeptiert~~ wurde. Und kann eine erneute Zustellung mit einem besseren Benehmen versuchen.		Bei einer Fehlermeldung bei der letzten Direktive weiss der Client oder Spammer aber bereits, dass die Adresse akzeptiert wurde. Und kann eine erneute Zustellung mit einem besseren Benehmen versuchen.

	=== 3. Abschnitt ===		=== 3. Abschnitt ===

imported>Raymond: /* 2. Abschnitt */ typos

2009-10-03T14:51:35Z

2. Abschnitt: typos

← Nächstältere Version		Version vom 3. Oktober 2009, 14:51 Uhr
Zeile 69:		Zeile 69:
	* '''smtpd_data_restrictions'''<br />Viele Spambot Schreiber ersparen sich die Mühe den SMTP Dialog ihrer Bots korrekt gemäss RFC zu implementieren oder reagieren/warten nicht korrekt auf Anworten des Servers. Häufig gesehen bei Spambots ist es, dass sie bereits direkt nach dem DATA Client Kommando mit der Datenübertragung anfangen wollten, bevor der Server sein "okay to send data" (unauthorized pipelining) schicken konnte. Solche Clients können bedenkenlos knallhart abgewürgt werden.		* '''smtpd_data_restrictions'''<br />Viele Spambot Schreiber ersparen sich die Mühe den SMTP Dialog ihrer Bots korrekt gemäss RFC zu implementieren oder reagieren/warten nicht korrekt auf Anworten des Servers. Häufig gesehen bei Spambots ist es, dass sie bereits direkt nach dem DATA Client Kommando mit der Datenübertragung anfangen wollten, bevor der Server sein "okay to send data" (unauthorized pipelining) schicken konnte. Solche Clients können bedenkenlos knallhart abgewürgt werden.

	Die letzte Direktive muss man ein bisschen abgetrennt von den anderen beachten (man könnte sie auch in den 3. Abschnitt verfachten). Denn bei allen bis auf die letzte Direktive ~~weiss~~ der Client oder Spammer nicht ob die Empfangsadresse überhaupt existiert resp ~~aktzeptiert~~ wurde. Meist probieren Spammer bei einer Domain mehrere Emailadressen aus, bis sie eine finden die aktzeptiert wird.		Die letzte Direktive muss man ein bisschen abgetrennt von den anderen beachten (man könnte sie auch in den 3. Abschnitt verfachten). Denn bei allen bis auf die letzte Direktive weiß der Client oder Spammer nicht ob die Empfangsadresse überhaupt existiert resp. akzeptiert wurde. Meist probieren Spammer bei einer Domain mehrere Emailadressen aus, bis sie eine finden die aktzeptiert wird.
	Bei einer Fehlermeldung bei der letzten Direktive weiss der Client oder Spammer aber bereits, dass die Adresse aktzeptiert wurde. Und kann eine erneute Zustellung mit einem besseren Benehmen versuchen.		Bei einer Fehlermeldung bei der letzten Direktive weiss der Client oder Spammer aber bereits, dass die Adresse aktzeptiert wurde. Und kann eine erneute Zustellung mit einem besseren Benehmen versuchen.

imported>Raymond: /* 3. Abschnitt */ typo

2009-10-03T14:50:24Z

3. Abschnitt: typo

← Nächstältere Version		Version vom 3. Oktober 2009, 14:50 Uhr
Zeile 73:		Zeile 73:

	=== 3. Abschnitt ===		=== 3. Abschnitt ===
	Wie bereits oben erwähnt ~~weiss~~ der Client oder Spammer zu diesem Zeitpunkt bereits, dass die Emailadresse okay ist. Trotzdem ist Postfix noch in der Lage vor dem finalen "Message Accepted" auf den Inhalt der Email zu reagieren und den Empfang ggf zurückzuweisen.		Wie bereits oben erwähnt weiß der Client oder Spammer zu diesem Zeitpunkt bereits, dass die Emailadresse okay ist. Trotzdem ist Postfix noch in der Lage vor dem finalen "Message Accepted" auf den Inhalt der Email zu reagieren und den Empfang ggf zurückzuweisen.
	Dazu werden 3 Direktiven verwendet, wovon ich selber aber nur zwei benutze. Erwähnen möchte ich trotzdem alle drei		Dazu werden 3 Direktiven verwendet, wovon ich selber aber nur zwei benutze. Erwähnen möchte ich trotzdem alle drei

imported>Raymond: /* About */ typo

2009-10-03T14:49:13Z

About: typo

← Nächstältere Version		Version vom 3. Oktober 2009, 14:49 Uhr
Zeile 3:		Zeile 3:
	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.		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 [http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt jimsun.linxnet.com (englisch)] und eine gute [http://chains.ch/docs/postfix-UCE-HOWTO-de.html deutsche Zusammenfassung bei chains.ch].		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 [http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt jimsun.linxnet.com (englisch)] und eine gute [http://chains.ch/docs/postfix-UCE-HOWTO-de.html deutsche Zusammenfassung bei chains.ch].
	Auch kann es nicht schaden sich den [http://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#Das_Protokoll Ablauf des 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		Auch kann es nicht schaden sich den [http://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#Das_Protokoll Ablauf des 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 heißt 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 ===		=== Sinn und Zweck ===

imported>Jahlives: /* 2. Abschnitt */

2009-03-19T18:41:24Z

2. Abschnitt

← Nächstältere Version		Version vom 19. März 2009, 18:41 Uhr
Zeile 31:		Zeile 31:
	=== 2. Abschnitt ===		=== 2. Abschnitt ===
	Hier kommen also die entscheidenen Anweisungen für den Postfix und wie bereits erwähnt ist die Reihenfolge wichtig. Neben Standartchecks (z.B. reject_unknown_sender_domain) sieht man mehrere Anweisungen die ein regexp:/ beinhalten. Dabei handelt es sich um Files mit regulären Ausdrücken, die Postfix beim SMTP Dialog ebenfalls verwenden soll.		Hier kommen also die entscheidenen Anweisungen für den Postfix und wie bereits erwähnt ist die Reihenfolge wichtig. Neben Standartchecks (z.B. reject_unknown_sender_domain) sieht man mehrere Anweisungen die ein regexp:/ beinhalten. Dabei handelt es sich um Files mit regulären Ausdrücken, die Postfix beim SMTP Dialog ebenfalls verwenden soll.

	Wichtig ist es im Hinterkopf zu behalten, dass die einzelnen Direktiven von oben nach unten und die Optionen der Direktiven von links nach rechts ausgeführt und geprüft werden. Dabei wird eine Prüfung einen der drei Stati (OK, REJECT oder DUNNO) zurückgeben. Ein OK oder REJECT bricht die Prüfung der ganzen Direktive ab. Ein DUNNO ist wie NULL und bei einem solchen Wert wird die Direktive nicht abgebrochen sondern die nächste Option geprüft.		Wichtig ist es im Hinterkopf zu behalten, dass die einzelnen Direktiven von oben nach unten und die Optionen der Direktiven von links nach rechts ausgeführt und geprüft werden. Dabei wird eine Prüfung einen der drei Stati (OK, REJECT oder DUNNO) zurückgeben. Ein OK oder REJECT bricht die Prüfung der ganzen Direktive ab. Ein DUNNO ist wie NULL und bei einem solchen Wert wird die Direktive nicht abgebrochen sondern die nächste Option geprüft.

	Ein OK führt zur nächsten Direktive und ein REJECT je nach Konfiguration von '''smtpd_delay_reject''' auch. Denn ist dieser Wert auf YES dann kommt auch bei REJECT die nächste Direktive dran. Aber auch wenn die dann ein OK zurückgibt wird die Email nach Erhalt der Empfänger Adresse in JEDEM Fall abgelehnt werden (einmal REJECT immer REJECT). Wenn der Wert in der Config NO ist, dann wird sofort und ohne Prüfung der nächsten Direktive die Verbindung zum Client mit einer Fehlermeldung gekappt (natürlich nur wenn eine Option einer Direktive ein REJECT zurückgegeben hat)		Ein OK führt zur nächsten Direktive und ein REJECT je nach Konfiguration von '''smtpd_delay_reject''' auch. Denn ist dieser Wert auf YES dann kommt auch bei REJECT die nächste Direktive dran. Aber auch wenn die dann ein OK zurückgibt wird die Email nach Erhalt der Empfänger Adresse in JEDEM Fall abgelehnt werden (einmal REJECT immer REJECT). Wenn der Wert in der Config NO ist, dann wird sofort und ohne Prüfung der nächsten Direktive die Verbindung zum Client mit einer Fehlermeldung gekappt (natürlich nur wenn eine Option einer Direktive ein REJECT zurückgegeben hat)

			----

	* '''smtpd_client_restrictions'''<br />Bevor der Server überhaupt einen SMTP Dialog für den Client öffnet wird diese Direktive ausgeführt. Dabei werden Prüfungen auf IP Basis des Clients ausgeführt (der Hostname kommt erst im HELO zum Zug)<br />Zuerst lege ich über ein userspezifisches File einen oder mehrere reguläre Ausdrücke fest, bei denen der weitere Zugriff verboten wird. Hier kann man IP Adressen von bekannten Spammern einbauen		* '''smtpd_client_restrictions'''<br />Bevor der Server überhaupt einen SMTP Dialog für den Client öffnet wird diese Direktive ausgeführt. Dabei werden Prüfungen auf IP Basis des Clients ausgeführt (der Hostname kommt erst im HELO zum Zug)<br />Zuerst lege ich über ein userspezifisches File einen oder mehrere reguläre Ausdrücke fest, bei denen der weitere Zugriff verboten wird. Hier kann man IP Adressen von bekannten Spammern einbauen
	<pre>		<pre>