IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: SPF (Seite 2 von 2)

SPF Records

Veraltet: Der dedizierte SPF-DNS-Record-Typ (Typ 99) wurde mit RFC 7208 im Jahr 2014 als deprecated eingestuft. SPF wird heute ausschließlich über TXT-Records veröffentlicht. Siehe den aktuellen SPF-Beitrag.

Es gibt seit einiger Zeit einen dedizierten SPF-Record. Dieser wird auch bereits von vielen SPF-Filtern sowie Bind seit Version 9.4 unterstützt. Dieses entlastet etwas die TXT Anfragen und sorgt für mehr Ordnung. Wird dieser SPF Record vom jeweiligen SPF Filter unterstützt, fragt dieser meist zuerst nach dem SPF-Record und wenn es keine Antwort gibt als nächstes nach einem TXT-SPF Record.

Um diesen Filtern etwas Arbeit zu ersparen, das DNS etwas aufzuräumen und auf lange Sicht RFC konform zu bleiben (es würde mich nicht wundern wenn der TXT-SPF Record bald ausstirbt). Sollte man ebenfalls bei seiner SPF geschützten Domain einen solchen Record erstellen.

Für meinen Bind und die Domain kernel-error.de würde ein Beispiel wie folgt aussehen:

kernel-error.de.    IN    SPF    "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

Geprüft werden kann alles schnell und einfach mit DIG:

# dig kernel-error.de IN SPF +short
"v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

Sobald alle gängigen Filter die SPF-Records implementiert haben und alle Postmaster ihre Einführungszeit hatten, kann man dann sicher seinen TXT-SPF-Record entfernen. Dieses dauert sicher wieder ein paar Jahre! Ach ja, mein TXT SPF Record schaut so aus:

kernel-error.de.    IN    TXT    "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

 

 

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt

Telekommailserver verschärfte Bedingungen der Mailannahme

Na also, nun hat die Telekom die Sicherheitsrichtlinien ihrer E-Mail Server so angepasst dass helo, hostname und R-DNS zusammenpassen müssen. Sonst gibt es diese Meldung:

A problem occurred. (Ask your postmaster for help or to contact tosa@rx.t-online.de to clarify.)

So gefällt mir das! Meine Kiste macht dieses ja schon länger so und ich bekomme immer mal wieder die Info, man könne mir keine E-Mail schicken. Mein Mailserver sei wohl kaputt, er sage immer:

550 5.7.1 Client host rejected: cannot find your hostname….

Wenn ich dann erkläre um was es geht bekomme ich immer mal wieder den Vorwurf da zu –genau- zu sein. Da jetzt noch ein weiteres großes Unternehmen genau so verfährt werden sich wohl noch mehr Mailserver „Administratoren“ um dieses Problem kümmern müssen. Lustig finde ich ja dass die Telekom direkt eine E-Mail Adresse angegeben hat tosa@rx.t-online.de, was da wohl abgehen muss.

 

http://www.kernel-error.de/postfix-spam-und-virenabwehr-durch-helo

 

 

 

Siehe auch: SPF-Record einrichten

Fragen? Einfach melden.

RBL und DNSBL in Postfix: Spam auf Verbindungsebene abweisen

Realtime Blackhole Lists (RBL) bzw. DNS-based Blackhole Lists (DNSBL) sind eine der ältesten und effektivsten Methoden gegen Spam. Das Prinzip ist simpel: Der sendende Server wird gegen eine Liste bekannter Spam-Quellen geprüft, noch bevor die Mail angenommen wird. Steht die IP auf der Liste, wird die Verbindung sofort abgelehnt. Der Server muss die Mail gar nicht erst annehmen, filtern oder speichern.

Vorteile und Nachteile

Der große Vorteil: Die Abweisung passiert auf SMTP-Ebene, bevor Ressourcen verschwendet werden. Bei hohem Mailaufkommen macht das einen spürbaren Unterschied. 80 bis 90 Prozent des Spam-Verkehrs lassen sich so schon beim Verbindungsaufbau abfangen.

Der Nachteil: Man verlässt sich auf Dritte. Wer auf einer RBL landet, kommt nicht immer schnell wieder runter. Und wenn ein RBL-Betreiber seinen Dienst einstellt, kann das zu Problemen führen (dazu weiter unten mehr). RBLs ersetzen keinen Content-Filter, sie ergänzen ihn.

Postfix konfigurieren

Die RBL-Abfragen werden in smtpd_recipient_restrictions in der main.cf eingetragen. Zwei Typen:

reject_rbl_clientPrüft die IP-Adresse des sendenden Servers gegen die Liste
reject_rhsbl_senderPrüft die Domain des Absenders (rechte Seite der Adresse) gegen die Liste

Eine bewährte Kombination:

# /etc/postfix/main.cf (Auszug)
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client ix.dnsbl.manitu.net

zen.spamhaus.org ist die wichtigste Liste. Sie fasst mehrere Spamhaus-Listen zusammen (SBL, XBL, PBL) und deckt bekannte Spammer, Exploits und dynamische IP-Bereiche ab. bl.spamcop.net reagiert schnell auf aktuelle Spam-Wellen. ix.dnsbl.manitu.net (NiX Spam) ist eine deutsche Liste die besonders gut bei deutschsprachigem Spam funktioniert.

Die Reihenfolge ist wichtig: permit_mynetworks und permit_sasl_authenticated müssen vor den RBL-Checks stehen, damit eigene Benutzer und authentifizierte Verbindungen nicht gegen die Listen geprüft werden.

Tote RBL-Server erkennen

Stellt ein RBL-Betreiber seinen Dienst ein, werden DNS-Anfragen entweder nicht beantwortet oder liefern für jede IP einen Treffer zurück. Beides ist schlecht. Im ersten Fall laufen die Anfragen in Timeouts und bremsen alle DNS-Auflösungen aus. Im zweiten Fall wird plötzlich jede eingehende Mail abgewiesen.

Im Postfix-Log (/var/log/mail.log) erkennt man das an Timeout-Warnungen oder an plötzlich massenhaften Ablehnungen. Die Lösung: Tote Listen sofort aus der Config entfernen. Es lohnt sich, die RBL-Listen alle paar Monate zu prüfen. Bekannte Leichen aus der Vergangenheit: dnsbl.njabl.org (2013 abgeschaltet), rhsbl.ahbl.org (2015 abgeschaltet), dnsbl.sorbs.net (mehrfach instabil).

RBL-Ablehnungsmeldung anpassen

Standardmäßig schickt Postfix eine generische Fehlermeldung. Mit default_rbl_reply lässt sich eine aussagekräftigere Antwort konfigurieren, die dem Admin des sendenden Servers hilft:

default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}

RBL und rspamd

Wer rspamd einsetzt, kann RBL-Checks auch dort konfigurieren statt in Postfix. rspamd fragt die Listen asynchron ab und verrechnet das Ergebnis mit dem Gesamtscore der Mail. Das ist flexibler als die harte Ablehnung in Postfix: Eine IP auf einer einzelnen Liste führt nicht sofort zur Ablehnung, sondern erhöht den Spam-Score. Erst wenn mehrere Indikatoren zusammenkommen, wird die Mail abgewiesen.

Beide Ansätze lassen sich auch kombinieren: Die wichtigsten Listen (Spamhaus) direkt in Postfix für die sofortige Ablehnung, weitere Listen in rspamd für die feinere Bewertung.

RBLs sind ein Baustein im Gesamtsystem. Zusammen mit SPF, DKIM und DMARC decken sie verschiedene Angriffsvektoren ab. Fragen? Einfach melden.

SPF

Sender Policy Framework (früher Sender Permitted From), kurz SPF, ist eine Technik, die das Fälschen des Absenders einer E-Mail auf SMTP-Ebene erschweren soll.

Klingt komplex ist es aber nicht…

Es gibt eine simplen SPF-Generator, welcher einem einen fertigen Eintrag für seinen DNS-Server erstellt.

Einfach mal hier: http://www.spf-record.de/ schauen….

Möchte man seine SPF Konfiguration testen gibt einem folgende Webseite viele Möglichkeiten: http://www.kitterman.com/

Der SPF-Record könnte für meine Zone wie folgendes Beispiel aussehen:

kernel-error.de.    IN  TXT „v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all“

 

Bei Fragen oder Problemen, helfe ich natürlich gerne weiter!

Funktionsweise

Dazu wird in der DNS-Zone einer Domäne ein sog. Resource Record vom Typ TXT oder SPF mit Informationen darüber hinterlegt, welche Computer E-Mails für diese Domäne versenden dürfen. Anhand dieser Informationen soll nach RFC 4408 der Empfangs-Server dann sowohl die „MAIL FROM“-Identität als auch die „HELO“-Identität des Senders nachprüfen. Absenderangaben im E-Mail-Header werden nicht überprüft.

Im DNS-Eintrag einer Domäne sind bislang schon normale MX-Einträge vorhanden, die SMTP-Servern sagen, an welchen Host sie E-Mails für diese Domäne senden sollen. Wenn also ein SMTP-Server eine E-Mail an

test@example.org

Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, Sie müssen Javascript aktivieren, damit Sie es sehen können schicken soll, sieht er im MX-Record von example.org nach, an welchen Server er die Mail schicken soll. Mit SPF wird nun ein Record im Stil eines Reverse-MX den DNS-Einträgen einer Domäne hinzugefügt. Empfängt ein Mailserver eine E-Mail mit einem Absender von example.org, sieht er im SPF-Record von example.org nach, ob der zustellende Mailserver laut SPF-Record dazu berechtigt ist, Mails für diese Domain zu versenden. Mit dieser Technik lässt sich die Fälschung von Absenderadressen effektiv verhindern.

SPF kann so durch die leichtere Nachverfolgbarkeit von E-Mails auch zur Bekämpfung von Spam und zur Erschwerung von Phishing beitragen. SPF erhebt jedoch lediglich den Anspruch, Absenderadressfälschungen zu verhindern, nicht aber, direkt Spam zu bekämpfen.

SPF muss nur vom Empfängersystem unterstützt werden – am SMTP-Protokoll der Mailübertragung ändert sich nichts. Die Veröffentlichung von SPF-Records ist für eine Domäne freiwillig, Mails von Domains ohne SPF-Records sollen laut SPF-Spezifikation (RFC 4408) von Empfängern nicht negativ eingestuft werden; allerdings bleiben solche Domänen naturgemäß wie bisher gegen Umschlag-Adressfälschungen ungeschützt.

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt

Siehe auch: SPF-Record einrichten

Fragen? Einfach melden.

Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑