Frage, smtpd restrictions, dkim und spf

Domi

Member
Hallo Leute, ich hätte zu den restrictions mal die eine oder andere Frage :)

Wenn ich mich nicht verlesen habe, kann ich über restrictions sowohl DKIM als auch SPF prüfen lassen. Die Frage ist nur, macht das jemand und macht so etwas sinn um dem SPAM ein wenig entgegen zu wirken?

Ich hatte mal eine restrictions hinterlegt, die den MX-Record oder PTNR der Absender prüft. An sich nicht schlecht, allerdings hatte damals eine Versicherung den Eintrag falsch gesetzt und wir bekamen keine E-Mails mehr von denen :D Ich glaube bei meinem persönlichen Server gab es (wenn ich mich nicht irre) sogar mal Probleme mit E-Mails die von Amazon Market kam. Aus irgend einem Grund konnten mir dann die Rechnungen der Verkäufer nicht zugestellt werden.

Daher wäre halt die Frage ob DKIM und SPF zur Prüfung Sinn macht, oder ob dies aufgrund der "Fehleranfälligkeit" noch nicht zu empfehlen wäre?!

Gruß, Domi
 
Sowohl SPF als auch DKIM sind keine Mechanismen zur Spamabwehr. Beide sichern nur die Validität der (Absender)-Angaben. SPF ist darüber hinaus broken by design. In den restrictions bringt es also gar nichts. Falls irgendein Spamfilter Angaben prüft, kannst Du mit DKIM feststellen, dass Du dabei die richtigen Werte prüfst, mehr nicht.

--
.A.
 
Moin, dass DKIM und SPF keine Mechanismen war mir bewusst. Das sind Einträge die ich beim Server / im Nameserver hinterlegen kann.

Ich dachte halt, wenn ich meiner E-Mail Domain ein DKIM gebe und im Nameserver den Key hinterlege, dass man daraus eine Art Validierung erstellen könnte ob dieser Server auch wirklich echt ist.

Wenn ich ja nun eine E-Mail schreibe und versende, wird der Key angehängt und mit dem Nameserver Eintrag abgeglichen. Mein Gedanke war halt, dass man daraus im Umkehrschluss sagen kann "ne, Server ist nicht echt" :)

Gruß, Domi
 
Schau Dir mal DMARC an, dann kannst Du sicher sein, ob der (echte) Inhaber der verwendeten Domains eine bestimmte Aktion durchsetzen möchte. SPF und DKIM für sich alleine taugen ansonsten maximal zur Erhöhung des Spam Scores.
 
Hallöchen, vielen Dank für den Tipp... DMARC hatte ich in der Kombination auch schon gesehen, hab das aber erst einmal außen vor gelassen.

Mein Gedanke war halt, wenn man mit SPF und DKIM seine Identität etwas verbessern kann (SPAM Score verbessern), wäre es auch möglich im Umkehrschluss zu gucken wer eine SPAM schleuder sein könnte :)

Mir ging es nämlich auch darum, das SPAM Aufkommen zu meinem Server und die Glaubwürdigkeit meines Server selbst etwas zu verbessern. Bekannter von mir besitzt nämlich einen eigenen Server mit ähnlichen Einstellungen, und hatte mir mal versehentlich mal an meine Gmail Adresse geschrieben und seine E-Mail wurde sofort als SPAM eingestuft.

Bis jetzt kommen meine E-Mails alle an, wollte aber gerne solch ein Szenario vorbeugen und (wie erwähnt) den SPAM der zu mir kommt, etwas minimieren.

Das war ein Grundgedanke von mir :)

Gruß, Domi
 
Hallo Leute, ich hätte zu den smtpd_restrictions noch einmal eine kleine Frage, verwendet jemand von euch den Parameter reject_unknown_client?

Dieser prüft ja (wenn ich mich nicht irre) den PTR des Absenders. Frage ist, ob das Sinnvoll ist, diesen prüfen zu lassen um den SPAM noch etwas einzudämmen, oder eher nicht so?!

Postfix arbeitet mit postgrey, amavis und postconf... Wenn ich es im Log und aus der Config korrekt interpretiert habe, kommt als allererstes postgrey zum Einsatz. Anschließend durchläuft die E-Mail postscreen_dnsbl_sites und danach zu amavis.

Da ich vor ein paar Wochen einen Cronjob erstellt habe,
Code:
sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --spam /var/vmail/*/*/Maildir/.Junk
sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --ham /var/vmail/*/*/Maildir/cur
sa-update -D
glaube ich, dass dieser sogar recht gut funktioniert. Grund der Annahme ist, dass ich locker 20 - 30 E-Mails pro Postfach mit ***SPAM*** im JUNK Ordner habe.

Verschieben lasse ich diese übrigens automatisch mit einer SIEVE Regel was auch funktioniert. Da aber viele dieser E-Mails (grob 98%) wirklich SPAM sind, wäre meine Frage wo man am besten ansetzt um das vielleicht noch zu verbessern?!

Postgrey ist installiert, da ich mittlerweile faul bin und mir den Server mittels ISPconfig und deren Tutorials aufgesetzt habe und weil ich ein paar Freunde auf dem Server habe die ihre Konten selbst verwalten.

Da aber nicht jeder von denen mit IMAP arbeitet, machen diese natürlich auch ein wenig "mi mi mi" und fragen, ob ich Server-seitig nicht schon den SPAM besser filtern könnte? Daher komme ich noch einmal auf euch zu und wollte fragen mit welchen Settings man mal experimentieren könnte.

Was die Gewichtung der postscreen_dnsbl_sites angeht, wollte ich nicht groß etwas verstellen da ich mir bei diesen etwas unsicher bin. Zumal ich die Wertung hier aus dem Forum von Joe User seinem Post übernommen habe.

Gruß, Domi
 
Hallo Leute, ich hätte zu den smtpd_restrictions noch einmal eine kleine Frage, verwendet jemand von euch den Parameter reject_unknown_client?

Dieser prüft ja (wenn ich mich nicht irre) den PTR des Absenders. Frage ist, ob das Sinnvoll ist, diesen prüfen zu lassen um den SPAM noch etwas einzudämmen, oder eher nicht so?!

Du meinst sicherlich die Option "reject_unknown_client_hostname"? Die verwende ich schon seit längerem (1-2 Jahre) und sehe hin und wieder mal, dass darüber eine Mail abgelehnt wurde. Allerdings kann ich nicht sagen, ob die Mail nicht auch noch an anderen Restriktionen gescheitert wäre, da ich diese Überprüfung sehr früh konfiguriert habe.
Es wird übrigens nicht nur die Existenz des PTR geprüft (das wäre reject_unknown_reverse_client_hostname), sondern auch, ob es dazu passend einen A-Record gibt, der wieder auf die IP auflöst.
Meiner Meinung nach ist der Einsatz unproblematisch, denn auch größere Anbieter (z.B. GMX, Web.de) setzen diesen Check ein, so dass jeder Mailserver-Betreiber eigentlich seine Hausaufgaben bez. DNS-Einträgen gemacht haben sollten (oder es ihm egal ist, ob seine Mails angkommen).

Da aber nicht jeder von denen mit IMAP arbeitet, machen diese natürlich auch ein wenig "mi mi mi" und fragen, ob ich Server-seitig nicht schon den SPAM besser filtern könnte? Daher komme ich noch einmal auf euch zu und wollte fragen mit welchen Settings man mal experimentieren könnte.

Wenn du den Spam schon per SIEVE auf dem Server filterst, sollten die Spammails per POP3 doch gar nicht auf den Client ankommen?
 
Du meinst sicherlich die Option "reject_unknown_client_hostname"?
Ich müsste gleich noch einmal nachschauen, aber ja anhand deiner Beschreibung ist es genau das was ich gesucht hatte :)

Meiner Meinung nach ist der Einsatz unproblematisch, denn auch größere Anbieter (z.B. GMX, Web.de) setzen diesen Check ein, so dass jeder Mailserver-Betreiber eigentlich seine Hausaufgaben bez. DNS-Einträgen gemacht haben sollten (oder es ihm egal ist, ob seine Mails angkommen).
Genau da sprichst du das richtige an, eine Versicherungsgesellschaft mit der wir im Büro zusammen arbeiten, hatte den PTR + A-Record nicht korrekt gepflegt und schon kamen deren E-Mails nicht mehr bei uns an. Im Protokoll hatte Postfix auch geschrieben das da etwas nicht passt. Als ich der Versicherung das dann erklärt hatte, meinten sie das mein Server falsch eingestellt wäre :rolleyes: Um nicht lange zu diskutieren, hatte ich die Funktion damals heraus genommen und irgendwann aus den Augen verloren.

Wenn du den Spam schon per SIEVE auf dem Server filterst, sollten die Spammails per POP3 doch gar nicht auf den Client ankommen?
Ja, dass war von mir etwas missverständlich ausgedrückt... ich habe nur für die Konten bei denen ich weiß das sie via IMAP abgerufen werden, diese SIEVE Regel hinterlegt. Bei allen anderen wo ich glaube das sie via POP abgerufen werden, habe ich diese Regel nicht aktiviert :D

Daher kam auch der Gedanke / Ansatz, ob man nicht noch irgendwo relativ fein einstellen kann das er SPAM ab einem gewissen Maß "reject'n" soll.

Ich habe mich ja nun durch das englische Manual von postscreen (sowie diverse Tutorials) geschlagen. Wenn ich nun folgendes machen würde...
Code:
postscreen_dnsbl_threshold = 5
postscreen_dnsbl_action: drop

müsste er doch die E-Mails die anhand des Scoring (welches ich von Joe User übernommen habe) die E-Mail ablehnen, oder irre ich mich? Zumindest habe ich es in den Texten so verstanden das "drop" die E-Mails ablehnt wenn das scoring (in meinem Beispiel, 5) erreicht wird.

Dann hätte ich fast den gleichen Effekt wie in den smtpd_restrictions "reject rbl xxx", aber basierend auf den Bewertungen.

Gruß, Domi
 
Als ich der Versicherung das dann erklärt hatte, meinten sie das mein Server falsch eingestellt wäre :rolleyes: Um nicht lange zu diskutieren, hatte ich die Funktion damals heraus genommen und irgendwann aus den Augen verloren.

Ich will nicht ausschließen, dass GMX und Co da evtl. Whitelisten pflegen, denn sie haben ja ein Interesse daran, dass legitime Mails auch ankommen.

Ja, dass war von mir etwas missverständlich ausgedrückt... ich habe nur für die Konten bei denen ich weiß das sie via IMAP abgerufen werden, diese SIEVE Regel hinterlegt. Bei allen anderen wo ich glaube das sie via POP abgerufen werden, habe ich diese Regel nicht aktiviert :D

Bei mir erfolgt die Spam-Filterung generell auf dem Server, allerdings können User ihre Filter-Regeln im Webmail pflegen und da eine Filterregel erstellen, die das verhindert. Außerdem läuft nachts ein Cronjob, der in die Spamordner schaut und wenn was neues dazu gekommen ist, eine Liste mit den neuen Spammails per Mail ans jeweilige Postfach verschickt.
Für Dovecot habe ich außerdem ein Plugin laufen, dass Mails beim Spamassassin neu anlernt, wenn sich manuell in den Spam-Ordner verschoben oder rausgeholt werden (False-Negative bzw. False-Positive)
 
Also da ich mich ja mit den smtpd_restrictions immer etwas schwer tue, bin ich mir aber bei einer Sache relativ sicher. Die werden von oben nach unten abgearbeitet :D

Das heißt, wenn ich bei "smtpd_client_restrictions" den Parameter "reject_unknown_client_hostname" einsetze (zumindest würde ich ihn dort einsetzen) und davor einen "check_client_access" setze, sollten doch meine "erlaubten" Server durch kommen, auch wenn der PTR oder A-Record nicht ganz korrekt sind.

Allerdings müsste ich dann noch ein "permit_sasl_authenticated" ganz an den Anfang stellen, sonst werden wohl meine Clients Probleme haben. Oder irre ich? Beispiel wäre ja dann ungefähr so...
Code:
smtpd_client_restrictions =
  permit_sasl_authenticated,
  check_client_access xxxx,
  reject_unknown_client_hostname

oder mache ich da einen Denkfehler?

Was die Konfig-Möglichkeiten angeht, da ich ISPconfig auf dem Server laufen habe, können meine Freunde / Bekannte die eine oder andere Einstellung ebenfalls selbst vornehmen. Darunter sind auch individuelle SIEVE Regeln :)

Ich denke und hoffe mal, dass passt so... der einzige Zusatz wäre noch, dem "postscreen_dnsbl_action" ein "drop" zu verpassen, aber bevor ich dies tun würde, war halt mein Ansatz erst einmal hier zu fragen.

Gruß, Domi
 
Ja, das mit den smtpd_client_restrictions sollte so passen. Ich persönlich habe allerdings kein permit_sasl_authnticated drin, das gibt es bei mir nur auf dem Submission-Port.
 
Ah... stimmt, habe eben noch mal nachgeschaut und gesehen das ich in der master.cf den passenden Parameter drin stehen habe. Über Submission (587) wäre das eine Option :D

Gruß, Domi

Nachtrag: Gab es da nicht mal einen Befehl mit dem man sehen konnte wie viel SPAM blockiert oder abgewährt wurde? Mich würde nämlich mal interessieren ob der "sa-learn" funktioniert, den ich in Post 6 erwähnt habe.
 
Last edited by a moderator:
Back
Top