Ich verwende Postfix auf einem Linode.
Linux redacted 5.3.11-x86_64-linode131 #1 SMP PREEMPT Wed Nov 13 18:51:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
amavisd-new-postfix/xenial,xenial,now 1:2.10.1-2ubuntu1 all [installed]
postfix/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-mysql/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-pcre/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-policyd-spf-python/xenial,xenial,now 1.3.2-1 all [installed,automatic]
Anstatt mich mit einer Quarantäne herumzuschlagen, habe ich meine Postfix-Installation so konfiguriert, dass RBL- und SPFFAIL-E-Mails abgelehnt werden. Leider muss ich E-Mails von einer Firma empfangen, deren SPF-Eintrag schon seit einiger Zeit falsch ist. Daher erhalte ich statt E-Mails nur nette Protokolle wie diese:
1. Apr. 10:41:42 redigiertes Postfix/smtpd[18833]: NOQUEUE: Ablehnung: RCPT von us-smtp-delivery-134.mimecast.com[216.205.24.134]: 550 5.7.1: Empfängeradresse abgelehnt: Nachricht abgelehnt aufgrund von: SPF-Fehler – nicht autorisiert. Bitte beachten Siehttp://www.openspf.net/Why?s=mfrom;id=redacted;ip=216.205.24.134;r=redacted; von=< redigiert> bis=< redigiert> proto=ESMTP helo=< us-smtp-delivery-134.mimecast.com>
Das besagte Unternehmen hat auf seiner Website oder in seinen WHOIS-Informationen keinen Ansprechpartner, der das Problem beheben könnte (ich gehe davon aus, dass ein Registrant @dnstinations.com [ein Drittanbieter] eine E-Mail von einem Drittanbieter, in der es heißt, dass DNS falsch konfiguriert sei, ignorieren wird).
Als ich dieses Protokoll zum ersten Mal statt einer E-Mail erhielt, versuchte ich, *.mimecast.com auf die Whitelist zu setzen, aber das machte keinen Unterschied. Deshalb habe ich mir heute meine main.cf angesehen. Ich sah, dass die SPF-Konfiguration in einer anderen Zeile stand als meine Whitelists, also dachte ich, ich könnte vielleicht eine separate SPF-spezifische Whitelist erstellen. So sah meine main.cf vorher aus:
smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access regexp:/etc/postfix/rbl_client_regex, check_client_access hash:/etc/postfix/rbl_client_override, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service unix:private/policy-spf
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access, reject_unknown_sender_domain
So sieht es jetzt aus:
smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access regexp:/etc/postfix/rbl_client_regex, check_client_access hash:/etc/postfix/rbl_client_override, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, regexp:/etc/postfix/spf_client_regex, check_policy_service unix:private/policy-spf
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access, reject_unknown_sender_domain
Im Grunde habe ich der main.cf nur Folgendes hinzugefügt:regulärer Ausdruck:/etc/postfix/spf_client_regex," Vor "check_policy_service unix:privat/policy-spf" im "SMTPD-Empfängerbeschränkungen" Abschnitt.
Ich habe außerdem /etc/postfix/spf_client_regex mit diesem Eintrag erstellt (das scheint sicher genug, da Mimecast ein Antispam-Anbieter ist):
/.*\.mimecast\.com$/ OK
Ich habe das mit postmap -q getestet, das erwartete „OK“-Ergebnis erhalten, „postmap /etc/postfix/spf_client_regex“ ausgeführt, um alles zu aktualisieren, was aktualisiert wird, und Postfix neu geladen. Leider werden E-Mails von diesem Absender weiterhin wegen SPF-Fehlern blockiert.
Ich habe also erwartet, dass die obigen Schritte korrekt sind, da sie im Grunde dieselben sind wie die Schritte für die Whitelist-Regeln im Abschnitt smtpd_client_restrictions, die dazu führen, dass reject_rbl_client-Regeln ignoriert werden, aber es funktioniert nicht. Wie im Titel dieses Beitrags angegeben: Kann ich die SPF-Richtlinie mithilfe einer Whitelist außer Kraft setzen? Wie?
Antwort1
OK, ich habe also nach dem Kommentar vonCliff Armstrong, und ich glaube, ich habe eine Lösung gefunden. Zuerst habe ich festgestellt, dass sowohl smtpd_client_restrictions als auch smtpd_sender_restrictions das Parsen von Tabellen ermöglichen, aber keines von beiden das Verarbeiten von Richtlinien erlaubt. Als nächstes habe ich festgestellt, dassbenutzerdefinierte Richtlinienkann erstellt werden, aber dies schien etwas zu sein, für dessen Lösung ich keine Programmiersprache lernen müsste, also führte ich eine Suche durch, die mich zudieser Beitragmit einigen berechtigten Kritikpunkten an einem bestimmten SPF-Richtliniendelegierten und Erklärungen zum Aufnehmen in die Whitelist beider derzeit verfügbarer SPF-Richtliniendelegierter.
Wie es der Zufall wollte, hatte ich den „besseren“ Policy-Delegierten bereits installiert, sodass ich das nicht ändern musste:
~$ apt list | grep policyd-spf
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
postfix-policyd-spf-perl/xenial,xenial 2.010-2 all
postfix-policyd-spf-python/xenial,xenial,now 1.3.2-1 all [installed,automatic]
Als Nächstes überprüfte ich die kommentierte Datei (in meinem Fall war sie gzippt, also erstellte ich eine Kopie in gunzip und löschte diese Kopie, als ich fertig war) und fand diese relevanten Kommentare:
# Whitelist: CIDR Notation list of IP addresses not to check SPF for.
# Example (default is no whitelist):
# Whitelist = 192.168.0.0/31,192.168.1.12
# Domain_Whitelist: List of domains whose sending IPs (defined by passing
# their SPF check should be whitelisted from SPF.
# Example (default is no domain whitelist):
# Domain_Whitelist = pobox.com,trustedforwarder.org
Auf dieser Grundlage klingt es wieDomänen-Whitelistfunktioniert bei mir nicht, da der Kommentar besagt: „definiert durch Bestehen der SPF-Prüfung sollte von SPF auf die Whitelist gesetzt werden.“ Das scheint seltsam (wenn der Absender die SPF-Prüfung der Domäne bestanden hätte, müsste ich nicht auf die Whitelist gesetzt werden), aber ich habe immer noch dieWhitelistOption, also fand ichMimecast SPF-Dokumentationund dann die IPs mit nslookup gesammelt:
~$ nslookup
> set type=txt
> us._extnetblocks.mimecast.com
;; Truncated, retrying in TCP mode.
Server: 50.116.58.5
Address: 50.116.58.5#53
Non-authoritative answer:
us._extnetblocks.mimecast.com text = "v=spf1 ip4:207.211.30.40 ip4:207.211.30.41 ip4:207.211.30.42 ip4:207.211.30.43 ip4:207.211.30.44 ip4:207.211.30.45 ip4:207.211.30.46 ip4:207.211.30.47 ip4:207.211.30.48 ip4:207.211.30.49 ip4:205.139.111.40 ip4:205.139.111.41 ip4:205.139.111.42 " "ip4:205.139.111.43 ip4:205.139.111.44 ip4:205.139.111.45 ip4:205.139.111.46 ip4:205.139.111.47 ip4:205.139.111.48 ip4:205.139.111.49 ~all"
Authoritative answers can be found from:
mimecast.com nameserver = dns02.mimecast.net.
mimecast.com nameserver = dns03.mimecast.net.
mimecast.com nameserver = dns04.mimecast.net.
mimecast.com nameserver = dns01.mimecast.net.
Dann habe ich diese Ergebnisse genommen und sie in die Konfigurationsdatei eingefügt:
Whitelist = 207.211.30.40, 207.211.30.41, 207.211.30.42, 207.211.30.43, 207.211.30.44, 207.211.30.45, 207.211.30.46, 207.211.30.47, 207.211.30.48, 207.211.30.49, 205.139.111.40, 205.139.111.41, 205.139.111.42, 205.139.111.43, 205.139.111.44, 205.139.111.45, 205.139.111.46, 205.139.111.47, 205.139.111.48, 205.139.111.49
Das ist nicht ideal, da diese IPs dann automatisch von anderen Domänen gesendet werden und die IPs den Besitzer wechseln könnten, aber für meine private Implementierung ist es gut genug. Daher werde ich nicht versuchen, zu lernen, wie ich meinen eigenen Delegierten erstelle, oder jemanden damit beauftragen, einen für mich zu erstellen. Wenn ich trotz dieser Änderungen ein weiteres ähnliches NOQUEUE-Ergebnis erhalte, werde ich dieser Antwort eine Anmerkung hinzufügen.