[Postfixbuch-users] Einzelne Tests selektiv abschalten

[Sandy Drobic]

Andre Tann wrote:
> Sandy Drobic, Freitag, 24. Oktober 2008 16:59: 
> 
>> - Hinter reject_unauth_destination gehen die Mails nur noch an
>>   deine eigenen Domains.
>> - Mails dieser Domains möchtest du annehmen.
>> - Dein Server kennt diese Domains
>> - wenn ein DNS-Problem dazu führt, dass die Domain von deinem
>> Server nicht aufgelöst werden kann, lehnt dein Server die Mails
>> ab. - dieses Phänomen nennt man "sich selbst ins Knie schießen".
>> - ein normaler Admin möchte dies nicht.
> 
> Ich bleibe hartnäckig. Du beziehst Dich doch auf meine ursprünglich 
> gepostete Prüfungsreihenfolge, oder? Auszug:

Sei meinetwegen hartnäckig, aber dies ist meine definitiv letzte Mail in
diesem Thread. Danach musst du selbst entscheiden.

Die Ausführungen oben bezogen sich auf das "reject_unknown_recipient_domain",
wenn dieser Check nach reject_unauth_destination kommt. Das ist eine
Kombination, welche nur Schaden anrichten kann, aber nichts nützt. Also sollte
man dies NICHT tun.

> [...andere Prüfungen...]

Dieses "andere Prüfungen" ist doch genau dein Problem, weil dort Checks
abgelaufen sind, die unerwünschte Folgen hatten, weil die Reihenfolge
suboptimal ist.

> reject_unauth_destination
> reject_unlisted_recipient
> check_policy_service unix:/var/spool/postfix/postgrey/socket
> reject_rbl_client ix.dnsbl.manitu.net
> [weitere RBLs]
> permit
> 
> Also: hinter unauth_destination kommen unlisted_recipient und 
> greylisting und RBLs. DNS-Probleme können dabei nur noch bei den 
> RBLs auftauchen. Meinst Du also, die RBLs sollten _vor_ 
> reject_unauth_destination stehen?
> 
> Ich verstehe einfach nicht, was Du meinst.

Ich verstehe einfach nicht, wo ich etwas unverständlich ausgedrückt habe.

Ein letztes mal mit etwas Hintergrund-Erklärung:

Zu klärende Prioritäten für mich als Mailserver-Admin:

a) gewünschte Mails sollen zuverlässig empfangen werden
b) eigene Mail sollen zuverlässig verschickt werden
c) unerwünschte Mails sollen nicht angenommen werden

Und das in dieser Reihenfolge. Hört sich simple an, nicht wahr? Aber hier sind
die Anforderungen an die Konfiguration, welche sich aus a)-c) ergeben:

zu a):
Ein zuverlässiger Empfang bedeutet, dass möglichst keine Mails abgewiesen
werden, welche erwünscht sind. Dies führt dazu, dass Checks, welche die Gefahr
eines False Positive in Kauf nehmen, entweder nur für verdächtige Clients
aktiv sind, nur als Teil einer gewichteten Entscheidung verwendet werden, oder
gar nicht verwendet werden.

Als Mindestforderung muss gelten, dass eine Whitelist zuverlässig die
gewünschten Mails zulässst.

zu b):
Um zuverlässig senden zu können, benötigt man neben einer technisch robusten
Einrichtung und einer korrekten DNS-Struktur auch eine gute Reputation, damit
man nicht auf Blacklisten landet.

Also verhindert man so gut wie möglich, dass man Mails versendet, welche von
den Zielservern als unerwünscht eingestuft werden. Dazu gehören Spam, Viren
und Bounces, welche an fremde Server gehen.

Für Punkt a) und b) ist eine einfache, robuste und wartbare Konfiguration
praktisch Voraussetzung.

Deine Konfiguration war nicht robust und nicht gut wartbar. Eine robuste
Konfiguration wird auch mit unvorgesehenen Problemen fertig. Mir ist z.B. mal
der DNS-Server fast ausgefallen, weil der mein Provider ohne Vorwarnung
beschlossen hatte, den DNS-Server umzukonfigurieren. Danach war der Server
noch erreichbar, machte aber für meinen Postfix keine Rekursion mehr. Also kam
für jeden Client nur noch "unknown". Das hatte zur Folge, dass die Mails wegen
dem Greylisting, das dadurch zuschlug, verzögert wurden, aber eben nicht
fortwährend abgewiesen wurden.

Ein reject_unknown_recipient_domain hätte hier sämtliche erwünschten Domains
abgewiesen.

Wenn jetzt die Whitelist vor dem reject_unlisted_recipient kommt, besteht die
Gefahr, dass Mails für unbekannte Domains angenommen und dann gebounced
werden. Sollte jetzt auch noch der Absender falsch sein, dan ist auch die
Bounce unzustellbar. Im schlimmsten Fall ist die Mail verloren, wenn sie dann
auch nicht an 2bounce_recipient zugestellt werden kann.

Du kannst jetzt einwenden, dass du jetzt nur den einen Check
reject_unknown_helo_hostname überbrücken willst für den einen Client und der
Rest der Checks inclusive reject_unlisted_recipient danach noch durchläuft.
Das geht für diesen einen Client für diesen Moment dann gut. In einem Monat
gibt es dann einen anderen Fehler, den der Client produziert, diesmal z.B. im
Hostnamen, der keinen passenden Reverse DNS-Eintrag mehr hat. Dann fängst du
an, wieder eine zweite Abfrage einzufügen, welche für den Client dann diesen
Check wieder überspringt.

Jetzt lasse mal ein paar Jahre ins Land ziehen und deine Konfig entsprechend
wuchern.

Danach hast du dann eine von den "gewachsenen Konfigurationen", welche nicht
mehr durchschaubar sind und wo man eine Stunde und viel Schweiß braucht, um
mal einen Host so zu whitelisten, dass er sauber durchkommt und man sich
selbst nicht unnötig öffnet.

Dies war z.B. der Fall mit dem check_helo_access, welches du eingesetzt
hattest. Wenn dieser Check nach reject_unauth_destination und nach
reject_unlisted_recipient kommt, kann er keinen Schaden anrichten: der
Empfänger existiert und die Domain gehört dir. Gleiches gilt für viele Andere
Checks, welche ein "ok" zurückgeben.

Deshalb hier noch einmal eine Beispielkonfig mit Anmerkungen:

# leer bedeutet, dass sie nicht benutzt werden
smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =

# alle checks hier einbauen, dies macht die Konfiguration einfacher, da die
# Checks jetzt von oben nach unten ablaufen, bis ein Check ein "OK/Permit"
# oder ein "4xx/5xx/reject" zurückgibt.

smtpd_recipient_restrictions =
# checks für alle Clients: keine Emailadressen akzeptieren, die
# nicht vollständig sind.
        reject_non_fqdn_sender
        reject_non_fqdn_recipient
# Relayen erlaubt für Clients, deren IP in mynetworks steht.
        permit_mynetworks
# Relayen erlaubt für Clients, die sich authentifizieren
        permit_sasl_authenticated

# Hiernach kommen nur noch Clients, welche nicht vertrauenswürdig sind.
# Also wird zuerst sichergestellt, dass:
#     - kein Relayen mehr möglich ist,
#     - dass die Mail zustellbar ist
#     - dass die Mail/der Client erwünscht (Whitelist) ist
#     - dass die Mail/der Client nicht unerwünscht ist (Antispam-Checks)
# und das in dieser Reihenfolge.


# nach reject_unauth_destination nur noch Annahme von Mails für eigene Domains,
# kein relayen:
        reject_unauth_destination
# Sicherstellen, dass die Mails auch ausgeliefert werden können:
        reject_unlisted_recipient

# Client Whitelist (nicht helo/sender, da diese fälschbar sind):
        check_client_access hash:/etc/postfix/whitelist_clients

# Danach kommen jetzt alle Checks, um unerwünschte Mails abzuweisen:
# Jetzt ist die Reihenfolge nicht mehr so kritisch, obwohl man üblicherweise
# die internen, schnellen Checks zuerst setzt. Warum die teuren externen
# Checks machen, wenn ein billiger interner Check die Mail ohnehin abweist?

        check_helo_access hash:/etc/postfix/tables/helo_block_own_name
        reject_invalid_helo_hostname
        reject_non_fqdn_helo_hostname
# reject_unknown_helo_hostname ist bekannt für viele False Posivive!!
        reject_unknown_helo_hostname
        check_sender_access hash:/etc/postfix/tables/check_sender_access
        reject_unknown_sender_domain
        reject_rbl_client ix.dnsbl.manitu.net
        reject_rbl_client dnsbl.njabl.org
        reject_rbl_client dnsbl.sorbs.net
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client bl.spamcop.net
        check_policy_service unix:/var/spool/postfix/postgrey/socket

Bezüglich "/etc/postfix/tables/check_sender_access": ich hatte vor einiger
Zeit mal eine Konfig mit etlichen check_xxx_access, die auch alle generische
Namen sender_access trugen. Nachdem ich davon sieben oder acht hatte, wusste
ich beim besten Willen nicht mehr, was in welchem Check geprüft wurde.

Also habe ich die Checks aufgeteilt nach ihrem Zweck (Blacklist, Whitelist
etc.) und die Dateien entsprechend benannt:

sender_blacklist, clients_for_greylisting, client_whitelist etc. Der Vorteil
war, dass ich direkt mit einem "postconf -n" sah, welche Checks wo stattfanden
und was sie machten. Bei "helo_block_own_name" hast du dies bereits gemacht.

Eine übersichtliche Konfig ist eine Menge wert, sie spart dir viel Schweiß und
lässt dich entspannt arbeiten und ermöglicht schnell Anpassungen ohne Stress.


Ich hoffe, dass dir diese Ausführungen helfen.

-- 
Sandy

Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com