[Postfixbuch-users] MySQL und Restriction für gefälschtes EHLO

[Peer Heinlein]

Am Samstag, 26. Januar 2008 schrieb Christian Roessner:


> der smtpd_recipient_restrictions unterzubringen. Diese selbst ist so
> strukturiert, dass
>
> - Prüfe alles, was lokal zu prüfen geht
> - Nimm dann evtl. MySQL-Abfragen hinzu
> - Schließe mit Remote-Abfragen ab


Das ist keine gute Idee.

Und es kann -wenn  man alles durchdenkt und für alles vorbereitet sein 
will- auch nicht funktionieren. Wirklich nicht. Kann nicht.

Spätestens wenn man prüft, ob die Absender- oder Empfänger-Domain 
überhaupt existiert, hat man remote-Abfragen im Spiel. Schon dieses 
kleine Beispiel zeigt, daß diese Trennung nicht funktionieren KANN.

Und: Sie macht auch keinerlei Sinn. Man spart nichts.

Im Gegenteil: Eine unsinnig angenommene E-Mail kostet mehr als 500 
DNS-Abfragen. Also nicht versuchen hier irgendein Krümel-Peanut zu 
sparen, sondern robust, stabil udn vorbereitet sein, damit einen nichts 
erschüttern kann und man jedes Verhalten per Knopfdruck realisiert kriegt 
ohne daß Restrictions im Notfall umgebaut werden müssen.

> smtpd_recipient_restrictions =
>          permit_mynetworks

Da geht's ja schon los. Sowas liebe ich ja. Zuerst mal "permit_mynetworks" 
reinknallen.  Nicht gut.

Warum nimmst Du von Deinen eigenen Nutzern Mails an, die
-eine nicht-existente Empfänger-Domain haben. Hilfst Du ihnen damit? Nein.
-eine nicht-existente Absender-Domain haben. Hilfst Du ihnen damit? Nein.

Wie sperrst Du einen einzelnen Amoklaufenden Nutzer anhand
-Absender-Mailadresse, Client-IP und/oder HELO?

Kannst Du nicht. Weil die checks dazu erst nach permit_mynetworks stehen. 
Gefährlich und nicht hilfreich! Falsche Reihenfolge!

>          reject_non_fqdn_recipient
>          reject_non_fqdn_sender
>          reject_unknown_recipient_domain
>          reject_unknown_sender_domain

Da stehen sie ja. Aber warum gelten sie nicht für Deine eigenen Nutzer?

>          reject_unverified_recipient
>          reject_unlisted_recipient
>          permit_tls_clientcerts

Warum machst Du einen Unterschied, ob Nutzer A auf seinem Laptop ein 
Zertifikat hat, oder ob er nur mit der IP-Adresse ankommt?

Ist er in mynetworks darf er Unsinn versenden, ist er mit ein- und 
demselben Laptop draußen vor Ort beim Kunden darf er es nicht mehr. Macht 
keinen Sinn.

>          reject_unauthenticated_sender_login_mismatch
>          reject_sender_login_mismatch
>          permit_sasl_authenticated

Auch hier. Ist er in mynetworks darf er Unsinn senden, kommt er per 
Username daher gelten plötzlich ganz andere Regeln, obwohl User, sein 
Laptop und seine Konfiguration sich nicht verändert haben.

>          reject_unauth_destination
>          check_client_access pcre:/etc/postfix/maps/dynip.pcre

Vorsicht. Es ist zurecht *SEHR* umstritten um das pauschale Blocken 
dynamischer IP-Adressen eine gute Idee ist. Kannst Du machen, wenn Du 
willst, aber es gibt auch gute Gründe dagegen.

>          reject_unknown_helo_hostname

Damit wirst Du mehr echte E-Mails von schlecht konfigurierten Mailservern 
verlieren, als daß es Dir Spam vom Hals hängt. Definitiv nicht 
empfehlenswert und einfach auch sinnfrei. Es schützt nicht, es schadet 
nur.

>          check_policy_service unix:private/policyd-spf

Vor dem Einsatz von SPF kann ich nur warnen. Das System funktioniert nicht 
und sorgt wenn man es auch zum Blocken einsetzt für Mailverluste 
(Stichwort: Weiterleitungen, Mailinglisten).

>          check_policy_service inet:127.0.0.1:12525

Angenommen es gibt einen Dir wichtigen Client, den Du vom Policyd-Weight 
ausnehmen willst. Wie richtest Du ein whitelisting ein? Das sieht Deine 
Config nicht vor. Also schneidest Du Dir ohne Notwendigkeit Deine 
Handlungsmöglichkeiten ab.

>          reject_rhsbl_sender dsn.rfc-ignorant.org

Du hast doch den Policyd-Weight. Der macht das mit mehr Sinn und Verstand, 
als wenn man das hier hart auswerten läßt. 


Peer




-- 
Heinlein Professional Linux Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg, 
Geschäftsführer: Peer Heinlein  -- Sitz: Berlin