Postfix/SMTP-Relay und Zugriff: Unterschied zwischen den Versionen
K Textersetzung - „““ durch „"“ |
K Textersetzung - „http://“ durch „https://“ |
||
Zeile 5: | Zeile 5: | ||
* E-Mail-Server leiteten E-Mails gerne im Namen von irgendjemandem weiter jedes Ziel. | * E-Mail-Server leiteten E-Mails gerne im Namen von irgendjemandem weiter jedes Ziel. | ||
* Im heutigen Internet missbrauchen Spammer Server damit Mail von beliebigen Systemen weiterleiten, und missbrauchte Systeme landen auf Anti-Spam-Denylisten. | * Im heutigen Internet missbrauchen Spammer Server damit Mail von beliebigen Systemen weiterleiten, und missbrauchte Systeme landen auf Anti-Spam-Denylisten. | ||
* Siehe zum Beispiel die Informationen zu [ | * Siehe zum Beispiel die Informationen zu [https://www.mail-abuse.org/ https://www.mail-abuse.org/] und andere Websites. | ||
Standardmäßig hat Postfix einen moderat restriktiven Ansatz für E-Mail-Weiterleitung. | Standardmäßig hat Postfix einen moderat restriktiven Ansatz für E-Mail-Weiterleitung. | ||
* Postfix leitet E-Mails nur von vertrauenswürdigen Clients weiter Netzwerke, von Clients, die sich mit SASL authentifiziert haben, oder an Domänen, die als autorisiertes Relay konfiguriert sind Reiseziele. | * Postfix leitet E-Mails nur von vertrauenswürdigen Clients weiter Netzwerke, von Clients, die sich mit SASL authentifiziert haben, oder an Domänen, die als autorisiertes Relay konfiguriert sind Reiseziele. | ||
* Eine Beschreibung der standardmäßigen Mail-Relay-Richtlinie finden Sie unter siehe [ | * Eine Beschreibung der standardmäßigen Mail-Relay-Richtlinie finden Sie unter siehe [https://www.postfix.org/postconf.5.html#smtpd_relay_restrictions smtpd_relay_restrictions] im [https://www.postfix.org/postconf.5.html postconf(5)] -Handbuch Seite und die Informationen, auf die von dort aus verwiesen wird. | ||
HINWEIS: Postfix-Versionen vor 2.10 hatten dies nicht [ | HINWEIS: Postfix-Versionen vor 2.10 hatten dies nicht [https://www.postfix.org/postconf.5.html#smtpd_relay_restrictions smtpd_relay_restrictions] . | ||
* Sie kombinierten Mail-Relay und Spam Sperrrichtlinien unter [ | * Sie kombinierten Mail-Relay und Spam Sperrrichtlinien unter [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] . | ||
* Das könnte zu unerwarteten Ergebnissen führen. | * Das könnte zu unerwarteten Ergebnissen führen. | ||
* Zum Beispiel eine freizügige Spam-Blockierung könnte unerwartet zu einer permissiven Mail-Relay-Richtlinie führen. | * Zum Beispiel eine freizügige Spam-Blockierung könnte unerwartet zu einer permissiven Mail-Relay-Richtlinie führen. | ||
* Ein Beispiel dazu ist unter " [ | * Ein Beispiel dazu ist unter " [https://www.postfix.org/SMTPD_ACCESS_README.html#danger Gefährlich Verwendung von smtpd_recipient_restrictions] ". | ||
Die meisten Postfix-SMTP-Server-Zugriffskontrollen sind gezielt beim Stoppen von Junk-E-Mails. | Die meisten Postfix-SMTP-Server-Zugriffskontrollen sind gezielt beim Stoppen von Junk-E-Mails. | ||
Zeile 23: | Zeile 23: | ||
* Das Die Wirksamkeit dieser Denylisten hängt davon ab, wie vollständig und wie aktuell sind sie. | * Das Die Wirksamkeit dieser Denylisten hängt davon ab, wie vollständig und wie aktuell sind sie. | ||
* Schwellenwertorientiert: Einige SMTP-Server-Zugriffskontrollen versuchen um die Messlatte höher zu legen, indem entweder der Kunde mehr Arbeit macht (Greylisting) oder durch Einholung einer Zweitmeinung (SPF und Absender-/Empfängeradresse Überprüfung). | * Schwellenwertorientiert: Einige SMTP-Server-Zugriffskontrollen versuchen um die Messlatte höher zu legen, indem entweder der Kunde mehr Arbeit macht (Greylisting) oder durch Einholung einer Zweitmeinung (SPF und Absender-/Empfängeradresse Überprüfung). | ||
* Die Greylisting- und SPF-Richtlinien sind implementiert extern und sind Gegenstand des [ | * Die Greylisting- und SPF-Richtlinien sind implementiert extern und sind Gegenstand des [https://www.postfix.org/SMTPD_POLICY_README.html SMTPD_POLICY_README] . | ||
* Die Überprüfung der Absender-/Empfängeradresse ist Gegenstand der [ | * Die Überprüfung der Absender-/Empfängeradresse ist Gegenstand der [https://www.postfix.org/ADDRESS_VERIFICATION_README.html ADDRESS_VERIFICATION_README-] Dokument. | ||
Leider haben alle Junk-Mail-Kontrollen die Möglichkeit legitime Post fälschlicherweise zurückweisen. | Leider haben alle Junk-Mail-Kontrollen die Möglichkeit legitime Post fälschlicherweise zurückweisen. | ||
Zeile 30: | Zeile 30: | ||
* Für einige Benutzer ist dies nicht akzeptabel wenn irgendeine Junk-E-Mail durchrutscht, während für andere Benutzer die Welt endet, wenn eine einzelne legitime E-Mail-Nachricht blockiert wird. | * Für einige Benutzer ist dies nicht akzeptabel wenn irgendeine Junk-E-Mail durchrutscht, während für andere Benutzer die Welt endet, wenn eine einzelne legitime E-Mail-Nachricht blockiert wird. | ||
* Da es keine einzelne Richtlinie gibt, die für alle Benutzer "richtig" ist, Postfix unterstützt verschiedene SMTP-Zugriffsbeschränkungen für verschiedene Benutzer. | * Da es keine einzelne Richtlinie gibt, die für alle Benutzer "richtig" ist, Postfix unterstützt verschiedene SMTP-Zugriffsbeschränkungen für verschiedene Benutzer. | ||
* Dies ist im [ | * Dies ist im [https://www.postfix.org/RESTRICTION_CLASS_README.html RESTRICTION_CLASS_README] . | ||
== Einschränkungen, die für alle SMTP-Mails gelten == | == Einschränkungen, die für alle SMTP-Mails gelten == | ||
Neben den Einschränkungen, die pro konfigurierbar gemacht werden können Client oder pro Benutzer, wie im nächsten Abschnitt, Postfix, beschrieben implementiert einige Einschränkungen, die für alle SMTP-Mails gelten. | Neben den Einschränkungen, die pro konfigurierbar gemacht werden können Client oder pro Benutzer, wie im nächsten Abschnitt, Postfix, beschrieben implementiert einige Einschränkungen, die für alle SMTP-Mails gelten. | ||
* Die integrierten [ | * Die integrierten [https://www.postfix.org/postconf.5.html#header_checks header_checks-] und [https://www.postfix.org/postconf.5.html#body_checks body_checks] Inhalte Einschränkungen, wie im [https://www.postfix.org/BUILTIN_FILTER_README.html BUILTIN_FILTER_README] . | ||
* Dies geschieht, während Postfix E-Mails empfängt, bevor sie gespeichert werden die [ | * Dies geschieht, während Postfix E-Mails empfängt, bevor sie gespeichert werden die [https://www.postfix.org/QSHAPE_README.html#incoming_queue Eingangswarteschlange] . | ||
* Die externen Inhaltsbeschränkungen vor der Warteschlange, wie beschrieben im [ | * Die externen Inhaltsbeschränkungen vor der Warteschlange, wie beschrieben im [https://www.postfix.org/SMTPD_PROXY_README.html SMTPD_PROXY_README] . | ||
* Dies geschieht während Postfix empfängt E-Mails, bevor sie in der [ | * Dies geschieht während Postfix empfängt E-Mails, bevor sie in der [https://www.postfix.org/QSHAPE_README.html#incoming_queue Eingangswarteschlange] . | ||
* Erfordert, dass der Client den HELO- oder EHLO-Befehl sendet vor dem Senden des MAIL FROM- oder ETRN-Befehls. | * Erfordert, dass der Client den HELO- oder EHLO-Befehl sendet vor dem Senden des MAIL FROM- oder ETRN-Befehls. | ||
* Dies kann zu Problemen führen mit selbst entwickelten Anwendungen, die E-Mails senden. | * Dies kann zu Problemen führen mit selbst entwickelten Anwendungen, die E-Mails senden. | ||
* Aus diesem Grund ist die Anforderung ist standardmäßig deaktiviert (" [ | * Aus diesem Grund ist die Anforderung ist standardmäßig deaktiviert (" [https://www.postfix.org/postconf.5.html#smtpd_helo_required smtpd_helo_required] = no"). | ||
* Verbieten illegaler Syntax in MAIL FROM- oder RCPT TO-Befehlen. | * Verbieten illegaler Syntax in MAIL FROM- oder RCPT TO-Befehlen. | ||
* Dies kann Probleme mit selbst entwickelten Anwendungen verursachen, die senden Mail und mit alten PC-Mail-Clients. | * Dies kann Probleme mit selbst entwickelten Anwendungen verursachen, die senden Mail und mit alten PC-Mail-Clients. | ||
* Aus diesem Grund ist die Anforderung ist standardmäßig deaktiviert (" [ | * Aus diesem Grund ist die Anforderung ist standardmäßig deaktiviert (" [https://www.postfix.org/postconf.5.html#strict_rfc821_envelopes strict_rfc821_envelopes] = nein"). | ||
** Verbieten [https://tools.ietf.org/html/rfc822 RFC 822] -Adresssyntax (Beispiel: "MAIL FROM: the Alter <dude@example.com>"). | ** Verbieten [https://tools.ietf.org/html/rfc822 RFC 822] -Adresssyntax (Beispiel: "MAIL FROM: the Alter <dude@example.com>"). | ||
** Verbieten von Adressen, die nicht mit <> eingeschlossen sind (Beispiel: "MAIL FROM: dude@example.com"). | ** Verbieten von Adressen, die nicht mit <> eingeschlossen sind (Beispiel: "MAIL FROM: dude@example.com"). | ||
* Ablehnen von E-Mails von einer nicht existierenden Absenderadresse. | * Ablehnen von E-Mails von einer nicht existierenden Absenderadresse. | ||
* Diese Form der Egress-Filterung hilft, Würmer und andere Malware zu verlangsamen, aber kann Probleme mit selbst entwickelter Software verursachen, die E-Mails versendet Software mit einer nicht antwortbaren Adresse. | * Diese Form der Egress-Filterung hilft, Würmer und andere Malware zu verlangsamen, aber kann Probleme mit selbst entwickelter Software verursachen, die E-Mails versendet Software mit einer nicht antwortbaren Adresse. | ||
* Aus diesem Grund die Anforderung ist standardmäßig deaktiviert (" [ | * Aus diesem Grund die Anforderung ist standardmäßig deaktiviert (" [https://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_sender smtpd_reject_unlisted_sender] = no"). | ||
* Ablehnen von Mail für eine nicht vorhandene Empfängeradresse. | * Ablehnen von Mail für eine nicht vorhandene Empfängeradresse. | ||
* Dies Form der Ingress-Filterung hilft, die Mail-Warteschlange frei von zu halten unzustellbare MAILER-DAEMON-Nachrichten. | * Dies Form der Ingress-Filterung hilft, die Mail-Warteschlange frei von zu halten unzustellbare MAILER-DAEMON-Nachrichten. | ||
* Diese Anforderung ist aktiviert standardmäßig (" [ | * Diese Anforderung ist aktiviert standardmäßig (" [https://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_recipient smtpd_reject_unlisted_recipient] = yes"). | ||
== Selektiv werden mit SMTP-Zugriffsbeschränkung Listen == | == Selektiv werden mit SMTP-Zugriffsbeschränkung Listen == | ||
Postfix ermöglicht es Ihnen, Listen mit Zugriffsbeschränkungen anzugeben jeder Phase der SMTP-Konversation. | Postfix ermöglicht es Ihnen, Listen mit Zugriffsbeschränkungen anzugeben jeder Phase der SMTP-Konversation. | ||
* Individuelle Einschränkungen sind beschrieben in der [ | * Individuelle Einschränkungen sind beschrieben in der [https://www.postfix.org/postconf.5.html postconf(5) manpage] . | ||
;Beispiele für einfache Restriktionslisten | ;Beispiele für einfache Restriktionslisten | ||
/etc/postfix/ [ | /etc/postfix/ [https://www.postfix.org/postconf.5.html main.cf]: | ||
# Nur Verbindungen von vertrauenswürdigen Netzwerken zulassen. | # Nur Verbindungen von vertrauenswürdigen Netzwerken zulassen. | ||
[ | [https://www.postfix.org/postconf.5.html#smtpd_client_restrictions smtpd_client_restrictions] = [https://www.postfix.org/postconf.5.html#permit_mynetworks permission_mynetworks] , ablehnen | ||
# Sprechen Sie nicht mit Mailsystemen, die ihren eigenen Hostnamen nicht kennen. | # Sprechen Sie nicht mit Mailsystemen, die ihren eigenen Hostnamen nicht kennen. | ||
# Bei Postfix < 2.3 geben [ | # Bei Postfix < 2.3 geben [https://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname Sie "reject_unknown_hostname"] . | ||
[ | [https://www.postfix.org/postconf.5.html#smtpd_helo_restrictions smtpd_helo_restrictions] = [https://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname reject_unknown_helo_hostname] | ||
# Akzeptiere keine E-Mails von Domains, die nicht existieren. | # Akzeptiere keine E-Mails von Domains, die nicht existieren. | ||
[ | [https://www.postfix.org/postconf.5.html#smtpd_sender_restrictions smtpd_sender_restrictions] = [https://www.postfix.org/postconf.5.html#reject_unknown_sender_domain abgelehnte_unbekannte_sender_domain] | ||
# Spam-Kontrolle: Schließen Sie lokale Clients und authentifizierte Clients aus | # Spam-Kontrolle: Schließen Sie lokale Clients und authentifizierte Clients aus | ||
# von DNSBL-Lookups. | # von DNSBL-Lookups. | ||
[ | [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] = [https://www.postfix.org/postconf.5.html#permit_mynetworks permission_mynetworks] , | ||
[ | [https://www.postfix.org/postconf.5.html#permit_sasl_authenticated permission_sasl_authenticated] , | ||
#reject_unauth_destination [ | #reject_unauth_destination [https://www.postfix.org/postconf.5.html#reject_unauth_destination hier] nicht benötigt, wenn die mail | ||
# Relay-Richtlinie ist unter [ | # Relay-Richtlinie ist unter [https://www.postfix.org/postconf.5.html#smtpd_relay_restrictions smtpd_relay_restrictions] | ||
# (verfügbar ab Postfix 2.10). | # (verfügbar ab Postfix 2.10). | ||
[ | [https://www.postfix.org/postconf.5.html#reject_unauth_destination Ablehnen_unauth_destination] | ||
[ | [https://www.postfix.org/postconf.5.html#reject_rbl_client Ablehnen_rbl_client zen.spamhaus.org] , | ||
[ | [https://www.postfix.org/postconf.5.html#reject_rhsbl_reverse_client abgelehnt_rhsbl_reverse_client dbl.spamhaus.org] , | ||
[ | [https://www.postfix.org/postconf.5.html#reject_rhsbl_helo abgelehnt_rhsbl_helo dbl.spamhaus.org] , | ||
[ | [https://www.postfix.org/postconf.5.html#reject_rhsbl_sender abgelehnt_rhsbl_sender] dbl.spamhaus.org | ||
# Relay-Steuerung (Postfix 2.10 und höher): lokale Clients und | # Relay-Steuerung (Postfix 2.10 und höher): lokale Clients und | ||
# authentifizierte Clients können eine beliebige Zieldomäne angeben. | # authentifizierte Clients können eine beliebige Zieldomäne angeben. | ||
[ | [https://www.postfix.org/postconf.5.html#smtpd_relay_restrictions smtpd_relay_restrictions] = [https://www.postfix.org/postconf.5.html#permit_mynetworks permission_mynetworks] , | ||
[ | [https://www.postfix.org/postconf.5.html#permit_sasl_authenticated permission_sasl_authenticated] , | ||
[ | [https://www.postfix.org/postconf.5.html#reject_unauth_destination abgelehnt_unauth_destination] | ||
# Blockiere Kunden, die zu früh sprechen. | # Blockiere Kunden, die zu früh sprechen. | ||
[ | [https://www.postfix.org/postconf.5.html#smtpd_data_restrictions smtpd_data_restrictions] = [https://www.postfix.org/postconf.5.html#reject_unauth_pipelining reject_unauth_pipelining] | ||
# Kontingent für E-Mail-Volumen über Policy-Service-Callouts erzwingen. | # Kontingent für E-Mail-Volumen über Policy-Service-Callouts erzwingen. | ||
[ | [https://www.postfix.org/postconf.5.html#smtpd_end_of_data_restrictions smtpd_end_of_data_restrictions] = [https://www.postfix.org/postconf.5.html#check_policy_service check_policy_service] unix:private/policy | ||
Jede Beschränkungsliste wird von links nach rechts bis ausgewertet irgendeine Einschränkung erzeugt ein Ergebnis von PERMIT, REJECT oder DEFER (try später wieder). | Jede Beschränkungsliste wird von links nach rechts bis ausgewertet irgendeine Einschränkung erzeugt ein Ergebnis von PERMIT, REJECT oder DEFER (try später wieder). | ||
* Das Ende jeder Liste entspricht einem PERMIT-Ergebnis. | * Das Ende jeder Liste entspricht einem PERMIT-Ergebnis. | ||
* Indem Sie eine PERMIT-Beschränkung vor eine REJECT-Beschränkung setzen kann Ausnahmen für bestimmte Clients oder Benutzer machen. | * Indem Sie eine PERMIT-Beschränkung vor eine REJECT-Beschränkung setzen kann Ausnahmen für bestimmte Clients oder Benutzer machen. | ||
* Das nennt man Zulassungsliste; Das [ | * Das nennt man Zulassungsliste; Das [https://www.postfix.org/postconf.5.html#smtpd_relay_restrictions für smtpd_relay_restrictions] lässt E-Mails von lokal Netzwerken und von SASL-authentifizierten Clients, lehnt aber ansonsten E-Mails ab zu beliebigen Zielen. | ||
Die folgende Tabelle fasst den Zweck jedes SMTP-Zugriffs zusammen Beschränkungsliste. | Die folgende Tabelle fasst den Zweck jedes SMTP-Zugriffs zusammen Beschränkungsliste. | ||
Zeile 110: | Zeile 110: | ||
| '''Wirkung des REJECT- oder DEFER-Ergebnisses ''' | | '''Wirkung des REJECT- oder DEFER-Ergebnisses ''' | ||
|- | |- | ||
| | [ | | | [https://www.postfix.org/postconf.5.html#smtpd_client_restrictions smtpd_client_restrictions] | ||
| | Alle | | | Alle | ||
| | Optional | | | Optional | ||
| | Alle Client-Befehle ablehnen | | | Alle Client-Befehle ablehnen | ||
|- | |- | ||
| | [ | | | [https://www.postfix.org/postconf.5.html#smtpd_helo_restrictions smtpd_helo_restrictions] | ||
| | Alle | | | Alle | ||
| | Optional | | | Optional | ||
| | HELO/EHLO-Informationen ablehnen | | | HELO/EHLO-Informationen ablehnen | ||
|- | |- | ||
| | [ | | | [https://www.postfix.org/postconf.5.html#smtpd_sender_restrictions smtpd_sender_restrictions] | ||
| | Alle | | | Alle | ||
| | Optional | | | Optional | ||
| | MAIL FROM-Informationen ablehnen | | | MAIL FROM-Informationen ablehnen | ||
|- | |- | ||
| | [ | | | [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] | ||
| | ≥ 2.10 | | | ≥ 2.10 | ||
| | Erforderlich, wenn [ | | | Erforderlich, wenn [https://www.postfix.org/postconf.5.html#smtpd_relay_restrictions smtpd_relay_restrictions] nicht durchgesetzt wird Relaispolitik | ||
| | RCPT TO-Informationen ablehnen | | | RCPT TO-Informationen ablehnen | ||
|- | |- | ||
Zeile 133: | Zeile 133: | ||
|| Erforderlich | || Erforderlich | ||
|- | |- | ||
| | [ | | | [https://www.postfix.org/postconf.5.html#smtpd_relay_restrictions smtpd_relay_restrictions] | ||
| | ≥ 2.10 | | | ≥ 2.10 | ||
| | Erforderlich, wenn [ | | | Erforderlich, wenn [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] nicht durchgesetzt wird Relaispolitik | ||
| | RCPT TO-Informationen ablehnen | | | RCPT TO-Informationen ablehnen | ||
|- | |- | ||
Zeile 141: | Zeile 141: | ||
|| Nicht verfügbar | || Nicht verfügbar | ||
|- | |- | ||
| | [ | | | [https://www.postfix.org/postconf.5.html#smtpd_data_restrictions smtpd_data_restrictions] | ||
| | ≥ 2.0 | | | ≥ 2.0 | ||
| | Optional | | | Optional | ||
| | DATA-Befehl ablehnen | | | DATA-Befehl ablehnen | ||
|- | |- | ||
| | [ | | | [https://www.postfix.org/postconf.5.html#smtpd_end_of_data_restrictions smtpd_end_of_data_restrictions] | ||
| | ≥ 2.2 | | | ≥ 2.2 | ||
| | Optional | | | Optional | ||
| | END-OF-DATA-Befehl ablehnen | | | END-OF-DATA-Befehl ablehnen | ||
|- | |- | ||
| | [ | | | [https://www.postfix.org/postconf.5.html#smtpd_etrn_restrictions smtpd_etrn_restrictions] | ||
| | Alle | | | Alle | ||
| | Optional | | | Optional | ||
Zeile 160: | Zeile 160: | ||
== Verzögerte Auswertung von SMTP-Zugriffsbeschränkungslisten == | == Verzögerte Auswertung von SMTP-Zugriffsbeschränkungslisten == | ||
Frühe Postfix-Versionen haben Listen mit SMTP-Zugriffsbeschränkungen ausgewertet so früh wie möglich. | Frühe Postfix-Versionen haben Listen mit SMTP-Zugriffsbeschränkungen ausgewertet so früh wie möglich. | ||
* Die Client-Einschränkungsliste wurde ausgewertet bevor Postfix das Begrüßungsbanner "220 $ [ | * Die Client-Einschränkungsliste wurde ausgewertet bevor Postfix das Begrüßungsbanner "220 $ [https://www.postfix.org/postconf.5.html#myhostname myhostname] ..." an Beim SMTP-Client wurde zuvor die helo-Restriktionsliste ausgewertet Postfix antwortete auf den Befehl HELO (EHLO), die Absenderbeschränkung list ausgewertet wurde, bevor Postfix auf den MAIL FROM-Befehl geantwortet hat, usw. | ||
* Dieser Ansatz erwies sich als schwierig anzuwenden. | * Dieser Ansatz erwies sich als schwierig anzuwenden. | ||
Aktuelle Postfix-Versionen verschieben die Evaluierung des Clients, Helo- und Absenderbeschränkungslisten bis zum Befehl RCPT TO oder ETRN. | Aktuelle Postfix-Versionen verschieben die Evaluierung des Clients, Helo- und Absenderbeschränkungslisten bis zum Befehl RCPT TO oder ETRN. | ||
* Dieses Verhalten wird durch den [ | * Dieses Verhalten wird durch den [https://www.postfix.org/postconf.5.html#smtpd_delay_reject smtpd_delay_reject] . | ||
* Einschränkungslisten werden weiterhin in der richtigen Reihenfolge (Client, helo, etrn) oder (client, helo, sender, relay, receiver, data, or Datenende) Beschränkungen. | * Einschränkungslisten werden weiterhin in der richtigen Reihenfolge (Client, helo, etrn) oder (client, helo, sender, relay, receiver, data, or Datenende) Beschränkungen. | ||
* Wenn eine Beschränkungsliste (Beispiel: Client) zu REJECT or ausgewertet wird VERSCHIEBEN Sie die folgenden Beschränkungslisten (Beispiel: helo, sender usw.) werden übersprungen. | * Wenn eine Beschränkungsliste (Beispiel: Client) zu REJECT or ausgewertet wird VERSCHIEBEN Sie die folgenden Beschränkungslisten (Beispiel: helo, sender usw.) werden übersprungen. | ||
Ungefähr zu der Zeit, [ | Ungefähr zu der Zeit, [https://www.postfix.org/postconf.5.html#smtpd_delay_reject smtpd_delay_reject] eingeführt wurde, wurde Postfix wurde auch geändert, um gemischte Beschränkungslisten zu unterstützen, die kombiniert werden Informationen über den Auftraggeber, Helo, Absender und Empfänger oder etrn Befehl. | ||
Vorteile der verzögerten Beschränkungsauswertung und der Beschränkung Mischen: | Vorteile der verzögerten Beschränkungsauswertung und der Beschränkung Mischen: | ||
Zeile 183: | Zeile 183: | ||
== Gefährliche Verwendung von smtpd_recipient_restrictions == | == Gefährliche Verwendung von smtpd_recipient_restrictions == | ||
Inzwischen mag sich der Leser fragen, warum wir den smtpd-Client helo brauchen oder Absenderbeschränkungen, wenn deren Auswertung aufgeschoben wird den Befehl RCPT TO oder ETRN. | Inzwischen mag sich der Leser fragen, warum wir den smtpd-Client helo brauchen oder Absenderbeschränkungen, wenn deren Auswertung aufgeschoben wird den Befehl RCPT TO oder ETRN. | ||
* Einige Leute empfehlen, ALLE zu platzieren Zugriffsbeschränkungen in der [ | * Einige Leute empfehlen, ALLE zu platzieren Zugriffsbeschränkungen in der [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] . | ||
* Leider kann dies zu einem zu großzügigen Zugriff führen. | * Leider kann dies zu einem zu großzügigen Zugriff führen. | ||
* Wie ist das möglich? | * Wie ist das möglich? | ||
Der Zweck der [ | Der Zweck der [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] besteht darin steuern, wie Postfix auf den RCPT TO-Befehl antwortet. | ||
* Wenn die Einschränkung Liste wertet zu REJECT oder DEFER aus, die Empfängeradresse wird abgelehnt; keine Überraschungen hier. | * Wenn die Einschränkung Liste wertet zu REJECT oder DEFER aus, die Empfängeradresse wird abgelehnt; keine Überraschungen hier. | ||
* Wenn das Ergebnis PERMIT ist, dann der Empfänger Adresse akzeptiert. | * Wenn das Ergebnis PERMIT ist, dann der Empfänger Adresse akzeptiert. | ||
* Und hier können Überraschungen passieren. | * Und hier können Überraschungen passieren. | ||
Das Problem ist, dass es Postfix-Versionen vor 2.10 nicht gab [ | Das Problem ist, dass es Postfix-Versionen vor 2.10 nicht gab [https://www.postfix.org/postconf.5.html#smtpd_relay_restrictions smtpd_relay_restrictions] . | ||
* Sie kombinierten Mail-Relay und Spam Sperrrichtlinien unter [ | * Sie kombinierten Mail-Relay und Spam Sperrrichtlinien unter [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] . | ||
* Das Ergebnis besteht darin, dass sich unerwartet eine permissive Spam-Blockierungsrichtlinie ergeben könnte in einer permissiven Mail-Relay-Richtlinie. | * Das Ergebnis besteht darin, dass sich unerwartet eine permissive Spam-Blockierungsrichtlinie ergeben könnte in einer permissiven Mail-Relay-Richtlinie. | ||
Hier ist ein Beispiel, das zeigt, wann ein PERMIT-Ergebnis resultieren kann in zu viel Zugriffsberechtigung: | Hier ist ein Beispiel, das zeigt, wann ein PERMIT-Ergebnis resultieren kann in zu viel Zugriffsberechtigung: | ||
1 /etc/postfix/ [ | 1 /etc/postfix/ [https://www.postfix.org/postconf.5.html main.cf] : | ||
2 [ | 2 [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] = | ||
3 [ | 3 [https://www.postfix.org/postconf.5.html#permit_mynetworks permission_mynetworks] | ||
4 [ | 4 [https://www.postfix.org/postconf.5.html#check_helo_access check_helo_access-] [https://www.postfix.org/DATABASE_README.html#types Hash] :/etc/postfix/helo_access | ||
5 [ | 5 [https://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname Reject_unknown_helo_hostname] | ||
6 [ | 6 [https://www.postfix.org/postconf.5.html#reject_unauth_destination abgelehnt_unauth_destination] | ||
7 | 7 | ||
8 /etc/postfix/helo_access: | 8 /etc/postfix/helo_access: | ||
9 localhost.localdomain ERLAUBEN | 9 localhost.localdomain ERLAUBEN | ||
Zeile 5 weist Mail von Hosts zurück, die kein Proper angeben hostname im HELO-Befehl (bei Postfix < 2.3, spezifizieren [ | Zeile 5 weist Mail von Hosts zurück, die kein Proper angeben hostname im HELO-Befehl (bei Postfix < 2.3, spezifizieren [https://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname abgelehnter_unbekannter_Hostname] ). | ||
* Die Zeilen 4 und 9 machen eine Ausnahme E-Mail von einer Maschine zulassen, die sich mit "HELO localhost.localdomain". | * Die Zeilen 4 und 9 machen eine Ausnahme E-Mail von einer Maschine zulassen, die sich mit "HELO localhost.localdomain". | ||
Das Problem bei dieser Konfiguration ist das [ | Das Problem bei dieser Konfiguration ist das [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] ergibt für JEDEN Host PERMIT das sich als "localhost.localdomain" ankündigt und Postfix macht ein offenes Relais für alle diese Hosts. | ||
Bei Postfix vor Version 2.10 sollten Sie Nicht-Empfänger platzieren Einschränkungen NACH der [ | Bei Postfix vor Version 2.10 sollten Sie Nicht-Empfänger platzieren Einschränkungen NACH der [https://www.postfix.org/postconf.5.html#reject_unauth_destination Reject_unauth_destination-] Einschränkung, nicht Vor. | ||
* Im obigen Beispiel sollten die HELO-basierten Beschränkungen verwendet werden NACH [ | * Im obigen Beispiel sollten die HELO-basierten Beschränkungen verwendet werden NACH [https://www.postfix.org/postconf.5.html#reject_unauth_destination "reject_unauth_destination"] oder besser "HELO basierende Beschränkungen sollten unter [https://www.postfix.org/postconf.5.html#smtpd_helo_restrictions smtpd_helo_restrictions] wo sie keinen Schaden anrichten können. | ||
1 /etc/postfix/ [ | 1 /etc/postfix/ [https://www.postfix.org/postconf.5.html main.cf] : | ||
2 [ | 2 [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] = | ||
3 [ | 3 [https://www.postfix.org/postconf.5.html#permit_mynetworks permission_mynetworks] | ||
4 [ | 4 [https://www.postfix.org/postconf.5.html#reject_unauth_destination abgelehnt_unauth_destination] | ||
5 [ | 5 [https://www.postfix.org/postconf.5.html#check_helo_access check_helo_access-] [https://www.postfix.org/DATABASE_README.html#types Hash] :/etc/postfix/helo_access | ||
6 [ | 6 [https://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname Reject_unknown_helo_hostname] | ||
7 | 7 | ||
8 /etc/postfix/helo_access: | 8 /etc/postfix/helo_access: | ||
9 localhost.localdomain ERLAUBEN | 9 localhost.localdomain ERLAUBEN | ||
Der obige Fehler wird mit Postfix 2.10 und höher nicht passieren, wenn die Relay-Richtlinie unter [ | Der obige Fehler wird mit Postfix 2.10 und höher nicht passieren, wenn die Relay-Richtlinie unter [https://www.postfix.org/postconf.5.html#smtpd_relay_restrictions smtpd_relay_restrictions] , und die Spam-Blockierungsrichtlinie unter [https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_recipient_restrictions] . | ||
* Dann führt eine permissive Spam-Blockierungsrichtlinie nicht zu a Permissive Mail-Relay-Richtlinie. | * Dann führt eine permissive Spam-Blockierungsrichtlinie nicht zu a Permissive Mail-Relay-Richtlinie. | ||
Zeile 232: | Zeile 232: | ||
Postfix hat mehrere Funktionen, die bei der SMTP-Zugriffsregel helfen testen: | Postfix hat mehrere Funktionen, die bei der SMTP-Zugriffsregel helfen testen: | ||
[ | [https://www.postfix.org/postconf.5.html#soft_bounce soft_bounce] | ||
[ | [https://www.postfix.org/postconf.5.html main.cf] zu verhindern verhindert, dass der Postfix-SMTP-Server E-Mails dauerhaft ablehnt, indem er sich ändert alle 5xx SMTP-Antwortcodes in 4xx. | ||
[ | [https://www.postfix.org/postconf.5.html#warn_if_reject warn_if_reject] | ||
Wenn es vor einem Ablehnungstyp platziert wird Einschränkung, Zugriffstabellenabfrage oder [ | Wenn es vor einem Ablehnungstyp platziert wird Einschränkung, Zugriffstabellenabfrage oder [https://www.postfix.org/postconf.5.html#check_policy_service check_policy_service-] Abfrage, Dadurch wird eine "reject_warning"-Nachricht protokolliert, anstatt eine Anfrage abzulehnen (Wenn eine Zurückweisungsbeschränkung aufgrund eines vorübergehenden Fehlers fehlschlägt, dies protokolliert eine "reject_warning"-Meldung für jedes implizite " [https://www.postfix.org/postconf.5.html#defer_if_permit defer_if_permit] " Aktionen, die normalerweise verhindern würden, dass E-Mails angenommen werden einige spätere Zugriffsbeschränkungen). | ||
* Diese Funktion hat keine Auswirkung auf [ | * Diese Funktion hat keine Auswirkung auf [https://www.postfix.org/postconf.5.html#defer_if_reject defer_if_reject] Einschränkungen. | ||
XKUNDE | XKUNDE | ||
Mit dieser Funktion wird ein autorisiertes SMTP Client kann sich als andere Systeme ausgeben und realistisches SMTP ausführen Zugriffsregeltests. | Mit dieser Funktion wird ein autorisiertes SMTP Client kann sich als andere Systeme ausgeben und realistisches SMTP ausführen Zugriffsregeltests. | ||
* Beispiele für die Identität anderer Systeme zum Testen von Zugriffsregeln finden Sie am Ende der [ | * Beispiele für die Identität anderer Systeme zum Testen von Zugriffsregeln finden Sie am Ende der [https://www.postfix.org/XCLIENT_README.html XCLIENT_README] dokumentieren. | ||
* Diese Funktion ist in Postfix 2.1 verfügbar. | * Diese Funktion ist in Postfix 2.1 verfügbar. | ||
[[Kategorie:Postfix/Spam]] | [[Kategorie:Postfix/Spam]] | ||
[[Kategorie:Postfix/Sicherheit]] | [[Kategorie:Postfix/Sicherheit]] |
Version vom 7. April 2025, 14:39 Uhr
Der Postfix-SMTP-Server empfängt E-Mails aus dem Netzwerk und ist der großen bösen Welt von Junk-E-Mails und Viren ausgesetzt.
Relay-Steuerung, Junk-Mail-Steuerung und pro Benutzer Richtlinien
In einer fernen Vergangenheit war das Internet eine freundliche Umgebung.
- E-Mail-Server leiteten E-Mails gerne im Namen von irgendjemandem weiter jedes Ziel.
- Im heutigen Internet missbrauchen Spammer Server damit Mail von beliebigen Systemen weiterleiten, und missbrauchte Systeme landen auf Anti-Spam-Denylisten.
- Siehe zum Beispiel die Informationen zu https://www.mail-abuse.org/ und andere Websites.
Standardmäßig hat Postfix einen moderat restriktiven Ansatz für E-Mail-Weiterleitung.
- Postfix leitet E-Mails nur von vertrauenswürdigen Clients weiter Netzwerke, von Clients, die sich mit SASL authentifiziert haben, oder an Domänen, die als autorisiertes Relay konfiguriert sind Reiseziele.
- Eine Beschreibung der standardmäßigen Mail-Relay-Richtlinie finden Sie unter siehe smtpd_relay_restrictions im postconf(5) -Handbuch Seite und die Informationen, auf die von dort aus verwiesen wird.
HINWEIS: Postfix-Versionen vor 2.10 hatten dies nicht smtpd_relay_restrictions .
- Sie kombinierten Mail-Relay und Spam Sperrrichtlinien unter smtpd_recipient_restrictions .
- Das könnte zu unerwarteten Ergebnissen führen.
- Zum Beispiel eine freizügige Spam-Blockierung könnte unerwartet zu einer permissiven Mail-Relay-Richtlinie führen.
- Ein Beispiel dazu ist unter " Gefährlich Verwendung von smtpd_recipient_restrictions ".
Die meisten Postfix-SMTP-Server-Zugriffskontrollen sind gezielt beim Stoppen von Junk-E-Mails.
- Protokollorientiert: einige SMTP-Server-Zugriffskontrollen blockieren Mail, indem sie sehr streng in Bezug auf das SMTP-Protokoll sind; diese Fangen Sie schlecht implementierte und/oder schlecht konfigurierte Junk-E-Mails ab Software sowie E-Mail-Würmer, die mit ihrem eigenen Nicht-Standard geliefert werden SMTP-Client-Implementierungen.
- Protokollorientierte Zugriffskontrollen werden mit der Zeit weniger nützlich, da Spammer und Wurmschreiber es lernen RFC-Dokumente lesen.
- Denylist-orientiert: Einige Zugriffskontrollen für SMTP-Server Anfrageverweigerungslisten mit bekanntermaßen schlechten Seiten wie Open Mail Relais, offene Web-Proxys und Heimcomputer, die gewesen sind kompromittiert und von Kriminellen ferngesteuert werden.
- Das Die Wirksamkeit dieser Denylisten hängt davon ab, wie vollständig und wie aktuell sind sie.
- Schwellenwertorientiert: Einige SMTP-Server-Zugriffskontrollen versuchen um die Messlatte höher zu legen, indem entweder der Kunde mehr Arbeit macht (Greylisting) oder durch Einholung einer Zweitmeinung (SPF und Absender-/Empfängeradresse Überprüfung).
- Die Greylisting- und SPF-Richtlinien sind implementiert extern und sind Gegenstand des SMTPD_POLICY_README .
- Die Überprüfung der Absender-/Empfängeradresse ist Gegenstand der ADDRESS_VERIFICATION_README- Dokument.
Leider haben alle Junk-Mail-Kontrollen die Möglichkeit legitime Post fälschlicherweise zurückweisen.
- Dies kann ein Problem für Websites sein mit vielen verschiedenen Arten von Benutzern.
- Für einige Benutzer ist dies nicht akzeptabel wenn irgendeine Junk-E-Mail durchrutscht, während für andere Benutzer die Welt endet, wenn eine einzelne legitime E-Mail-Nachricht blockiert wird.
- Da es keine einzelne Richtlinie gibt, die für alle Benutzer "richtig" ist, Postfix unterstützt verschiedene SMTP-Zugriffsbeschränkungen für verschiedene Benutzer.
- Dies ist im RESTRICTION_CLASS_README .
Einschränkungen, die für alle SMTP-Mails gelten
Neben den Einschränkungen, die pro konfigurierbar gemacht werden können Client oder pro Benutzer, wie im nächsten Abschnitt, Postfix, beschrieben implementiert einige Einschränkungen, die für alle SMTP-Mails gelten.
- Die integrierten header_checks- und body_checks Inhalte Einschränkungen, wie im BUILTIN_FILTER_README .
- Dies geschieht, während Postfix E-Mails empfängt, bevor sie gespeichert werden die Eingangswarteschlange .
- Die externen Inhaltsbeschränkungen vor der Warteschlange, wie beschrieben im SMTPD_PROXY_README .
- Dies geschieht während Postfix empfängt E-Mails, bevor sie in der Eingangswarteschlange .
- Erfordert, dass der Client den HELO- oder EHLO-Befehl sendet vor dem Senden des MAIL FROM- oder ETRN-Befehls.
- Dies kann zu Problemen führen mit selbst entwickelten Anwendungen, die E-Mails senden.
- Aus diesem Grund ist die Anforderung ist standardmäßig deaktiviert (" smtpd_helo_required = no").
- Verbieten illegaler Syntax in MAIL FROM- oder RCPT TO-Befehlen.
- Dies kann Probleme mit selbst entwickelten Anwendungen verursachen, die senden Mail und mit alten PC-Mail-Clients.
- Aus diesem Grund ist die Anforderung ist standardmäßig deaktiviert (" strict_rfc821_envelopes = nein").
- Verbieten RFC 822 -Adresssyntax (Beispiel: "MAIL FROM: the Alter <dude@example.com>").
- Verbieten von Adressen, die nicht mit <> eingeschlossen sind (Beispiel: "MAIL FROM: dude@example.com").
- Ablehnen von E-Mails von einer nicht existierenden Absenderadresse.
- Diese Form der Egress-Filterung hilft, Würmer und andere Malware zu verlangsamen, aber kann Probleme mit selbst entwickelter Software verursachen, die E-Mails versendet Software mit einer nicht antwortbaren Adresse.
- Aus diesem Grund die Anforderung ist standardmäßig deaktiviert (" smtpd_reject_unlisted_sender = no").
- Ablehnen von Mail für eine nicht vorhandene Empfängeradresse.
- Dies Form der Ingress-Filterung hilft, die Mail-Warteschlange frei von zu halten unzustellbare MAILER-DAEMON-Nachrichten.
- Diese Anforderung ist aktiviert standardmäßig (" smtpd_reject_unlisted_recipient = yes").
Selektiv werden mit SMTP-Zugriffsbeschränkung Listen
Postfix ermöglicht es Ihnen, Listen mit Zugriffsbeschränkungen anzugeben jeder Phase der SMTP-Konversation.
- Individuelle Einschränkungen sind beschrieben in der postconf(5) manpage .
- Beispiele für einfache Restriktionslisten
/etc/postfix/ main.cf:
# Nur Verbindungen von vertrauenswürdigen Netzwerken zulassen. smtpd_client_restrictions = permission_mynetworks , ablehnen # Sprechen Sie nicht mit Mailsystemen, die ihren eigenen Hostnamen nicht kennen. # Bei Postfix < 2.3 geben Sie "reject_unknown_hostname" . smtpd_helo_restrictions = reject_unknown_helo_hostname # Akzeptiere keine E-Mails von Domains, die nicht existieren. smtpd_sender_restrictions = abgelehnte_unbekannte_sender_domain # Spam-Kontrolle: Schließen Sie lokale Clients und authentifizierte Clients aus # von DNSBL-Lookups. smtpd_recipient_restrictions = permission_mynetworks , permission_sasl_authenticated , #reject_unauth_destination hier nicht benötigt, wenn die mail # Relay-Richtlinie ist unter smtpd_relay_restrictions # (verfügbar ab Postfix 2.10). Ablehnen_unauth_destination Ablehnen_rbl_client zen.spamhaus.org , abgelehnt_rhsbl_reverse_client dbl.spamhaus.org , abgelehnt_rhsbl_helo dbl.spamhaus.org , abgelehnt_rhsbl_sender dbl.spamhaus.org # Relay-Steuerung (Postfix 2.10 und höher): lokale Clients und # authentifizierte Clients können eine beliebige Zieldomäne angeben. smtpd_relay_restrictions = permission_mynetworks , permission_sasl_authenticated , abgelehnt_unauth_destination # Blockiere Kunden, die zu früh sprechen. smtpd_data_restrictions = reject_unauth_pipelining # Kontingent für E-Mail-Volumen über Policy-Service-Callouts erzwingen. smtpd_end_of_data_restrictions = check_policy_service unix:private/policy
Jede Beschränkungsliste wird von links nach rechts bis ausgewertet irgendeine Einschränkung erzeugt ein Ergebnis von PERMIT, REJECT oder DEFER (try später wieder).
- Das Ende jeder Liste entspricht einem PERMIT-Ergebnis.
- Indem Sie eine PERMIT-Beschränkung vor eine REJECT-Beschränkung setzen kann Ausnahmen für bestimmte Clients oder Benutzer machen.
- Das nennt man Zulassungsliste; Das für smtpd_relay_restrictions lässt E-Mails von lokal Netzwerken und von SASL-authentifizierten Clients, lehnt aber ansonsten E-Mails ab zu beliebigen Zielen.
Die folgende Tabelle fasst den Zweck jedes SMTP-Zugriffs zusammen Beschränkungsliste.
- Alle Listen verwenden genau die gleiche Syntax; Sie unterscheiden sich nur in der Zeit der Bewertung und in der Wirkung einer ABLEHNUNG bzw DEFER-Ergebnis.
Name der Einschränkungsliste | Ausführung | Status | Wirkung des REJECT- oder DEFER-Ergebnisses |
smtpd_client_restrictions | Alle | Optional | Alle Client-Befehle ablehnen |
smtpd_helo_restrictions | Alle | Optional | HELO/EHLO-Informationen ablehnen |
smtpd_sender_restrictions | Alle | Optional | MAIL FROM-Informationen ablehnen |
smtpd_recipient_restrictions | ≥ 2.10 | Erforderlich, wenn smtpd_relay_restrictions nicht durchgesetzt wird Relaispolitik | RCPT TO-Informationen ablehnen |
< 2.10 | Erforderlich | ||
smtpd_relay_restrictions | ≥ 2.10 | Erforderlich, wenn smtpd_recipient_restrictions nicht durchgesetzt wird Relaispolitik | RCPT TO-Informationen ablehnen |
< 2.10 | Nicht verfügbar | ||
smtpd_data_restrictions | ≥ 2.0 | Optional | DATA-Befehl ablehnen |
smtpd_end_of_data_restrictions | ≥ 2.2 | Optional | END-OF-DATA-Befehl ablehnen |
smtpd_etrn_restrictions | Alle | Optional | ETRN-Befehl ablehnen |
Verzögerte Auswertung von SMTP-Zugriffsbeschränkungslisten
Frühe Postfix-Versionen haben Listen mit SMTP-Zugriffsbeschränkungen ausgewertet so früh wie möglich.
- Die Client-Einschränkungsliste wurde ausgewertet bevor Postfix das Begrüßungsbanner "220 $ myhostname ..." an Beim SMTP-Client wurde zuvor die helo-Restriktionsliste ausgewertet Postfix antwortete auf den Befehl HELO (EHLO), die Absenderbeschränkung list ausgewertet wurde, bevor Postfix auf den MAIL FROM-Befehl geantwortet hat, usw.
- Dieser Ansatz erwies sich als schwierig anzuwenden.
Aktuelle Postfix-Versionen verschieben die Evaluierung des Clients, Helo- und Absenderbeschränkungslisten bis zum Befehl RCPT TO oder ETRN.
- Dieses Verhalten wird durch den smtpd_delay_reject .
- Einschränkungslisten werden weiterhin in der richtigen Reihenfolge (Client, helo, etrn) oder (client, helo, sender, relay, receiver, data, or Datenende) Beschränkungen.
- Wenn eine Beschränkungsliste (Beispiel: Client) zu REJECT or ausgewertet wird VERSCHIEBEN Sie die folgenden Beschränkungslisten (Beispiel: helo, sender usw.) werden übersprungen.
Ungefähr zu der Zeit, smtpd_delay_reject eingeführt wurde, wurde Postfix wurde auch geändert, um gemischte Beschränkungslisten zu unterstützen, die kombiniert werden Informationen über den Auftraggeber, Helo, Absender und Empfänger oder etrn Befehl.
Vorteile der verzögerten Beschränkungsauswertung und der Beschränkung Mischen:
- Einige SMTP-Clients erwarten keine frühzeitige negative Antwort die SMTP-Sitzung.
- Wenn die schlechten Nachrichten bis zum RCPT TO verschoben werden Antwort, der Client geht weg, wie er soll, anstatt zu hängen herum, bis ein Timeout eintritt oder schlimmer noch, ins Endlos geht Verbinden-Ablehnen-Verbinden-Schleife.
- Postfix kann weitere nützliche Informationen protokollieren.
- Wann zum Beispiel Postfix lehnt einen Kundennamen oder eine Adresse ab und verzögert die Aktion bis zum Befehl RCPT TO kann es den Absender und den Empfänger protokollieren die Anschrift.
- Dies ist nützlicher, als nur den Client-Hostnamen zu protokollieren und IP-Adresse und nicht wissen, wessen E-Mail blockiert wurde.
- Das Mischen ist für komplexe Zulassungslisten-Richtlinien erforderlich.
- Zum B.
- um lokale Absenderadressen in E-Mails abzulehnen Nicht-lokale Clients müssen Sie in der Lage sein, Beschränkungen für Clients zu mischen Informationen mit Einschränkungen bezüglich der Absenderinformationen in derselben Beschränkungsliste.
- Ohne diese Fähigkeit greifen viele pro Benutzer zu Beschränkungen wären unmöglich auszudrücken.
Gefährliche Verwendung von smtpd_recipient_restrictions
Inzwischen mag sich der Leser fragen, warum wir den smtpd-Client helo brauchen oder Absenderbeschränkungen, wenn deren Auswertung aufgeschoben wird den Befehl RCPT TO oder ETRN.
- Einige Leute empfehlen, ALLE zu platzieren Zugriffsbeschränkungen in der smtpd_recipient_restrictions .
- Leider kann dies zu einem zu großzügigen Zugriff führen.
- Wie ist das möglich?
Der Zweck der smtpd_recipient_restrictions besteht darin steuern, wie Postfix auf den RCPT TO-Befehl antwortet.
- Wenn die Einschränkung Liste wertet zu REJECT oder DEFER aus, die Empfängeradresse wird abgelehnt; keine Überraschungen hier.
- Wenn das Ergebnis PERMIT ist, dann der Empfänger Adresse akzeptiert.
- Und hier können Überraschungen passieren.
Das Problem ist, dass es Postfix-Versionen vor 2.10 nicht gab smtpd_relay_restrictions .
- Sie kombinierten Mail-Relay und Spam Sperrrichtlinien unter smtpd_recipient_restrictions .
- Das Ergebnis besteht darin, dass sich unerwartet eine permissive Spam-Blockierungsrichtlinie ergeben könnte in einer permissiven Mail-Relay-Richtlinie.
Hier ist ein Beispiel, das zeigt, wann ein PERMIT-Ergebnis resultieren kann in zu viel Zugriffsberechtigung:
1 /etc/postfix/ main.cf :
2 smtpd_recipient_restrictions = 3 permission_mynetworks 4 check_helo_access- Hash :/etc/postfix/helo_access 5 Reject_unknown_helo_hostname 6 abgelehnt_unauth_destination 7 8 /etc/postfix/helo_access: 9 localhost.localdomain ERLAUBEN
Zeile 5 weist Mail von Hosts zurück, die kein Proper angeben hostname im HELO-Befehl (bei Postfix < 2.3, spezifizieren abgelehnter_unbekannter_Hostname ).
- Die Zeilen 4 und 9 machen eine Ausnahme E-Mail von einer Maschine zulassen, die sich mit "HELO localhost.localdomain".
Das Problem bei dieser Konfiguration ist das smtpd_recipient_restrictions ergibt für JEDEN Host PERMIT das sich als "localhost.localdomain" ankündigt und Postfix macht ein offenes Relais für alle diese Hosts.
Bei Postfix vor Version 2.10 sollten Sie Nicht-Empfänger platzieren Einschränkungen NACH der Reject_unauth_destination- Einschränkung, nicht Vor.
- Im obigen Beispiel sollten die HELO-basierten Beschränkungen verwendet werden NACH "reject_unauth_destination" oder besser "HELO basierende Beschränkungen sollten unter smtpd_helo_restrictions wo sie keinen Schaden anrichten können.
1 /etc/postfix/ main.cf :
2 smtpd_recipient_restrictions = 3 permission_mynetworks 4 abgelehnt_unauth_destination 5 check_helo_access- Hash :/etc/postfix/helo_access 6 Reject_unknown_helo_hostname 7 8 /etc/postfix/helo_access: 9 localhost.localdomain ERLAUBEN
Der obige Fehler wird mit Postfix 2.10 und höher nicht passieren, wenn die Relay-Richtlinie unter smtpd_relay_restrictions , und die Spam-Blockierungsrichtlinie unter smtpd_recipient_restrictions .
- Dann führt eine permissive Spam-Blockierungsrichtlinie nicht zu a Permissive Mail-Relay-Richtlinie.
Testen von SMTP-Zugriffsregeln
Postfix hat mehrere Funktionen, die bei der SMTP-Zugriffsregel helfen testen:
soft_bounce
main.cf zu verhindern verhindert, dass der Postfix-SMTP-Server E-Mails dauerhaft ablehnt, indem er sich ändert alle 5xx SMTP-Antwortcodes in 4xx.
warn_if_reject
Wenn es vor einem Ablehnungstyp platziert wird Einschränkung, Zugriffstabellenabfrage oder check_policy_service- Abfrage, Dadurch wird eine "reject_warning"-Nachricht protokolliert, anstatt eine Anfrage abzulehnen (Wenn eine Zurückweisungsbeschränkung aufgrund eines vorübergehenden Fehlers fehlschlägt, dies protokolliert eine "reject_warning"-Meldung für jedes implizite " defer_if_permit " Aktionen, die normalerweise verhindern würden, dass E-Mails angenommen werden einige spätere Zugriffsbeschränkungen).
- Diese Funktion hat keine Auswirkung auf defer_if_reject Einschränkungen.
XKUNDE
Mit dieser Funktion wird ein autorisiertes SMTP Client kann sich als andere Systeme ausgeben und realistisches SMTP ausführen Zugriffsregeltests.
- Beispiele für die Identität anderer Systeme zum Testen von Zugriffsregeln finden Sie am Ende der XCLIENT_README dokumentieren.
- Diese Funktion ist in Postfix 2.1 verfügbar.