Postfix/SMTP-Relay und Zugriff

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 http://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.