E-Mail/Anti-Spam: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Bernd (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Bernd (Diskussion | Beiträge) |
||
| (6 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 8: | Zeile 8: | ||
! Liste !! Beschreibung !! Aktion | ! Liste !! Beschreibung !! Aktion | ||
|- | |- | ||
| | | b.barracudacentral.org || Barracuda Reputation Block List || Wird nicht angenommen | ||
|- | |- | ||
| | | --- || Intern gepflegte Whitelist || Greylisting wird übersprungen für gelistete Hosts | ||
|} | |} | ||
| Zeile 30: | Zeile 24: | ||
| MAIL FROM || DNS-Server der Domain nicht erreichbar || Domain syntaktisch nicht korrekt, Domain nicht gefunden, keine spitzen Klammern um die Adresse, kein Mailserver für eine Antwort zu ermitteln (DNS-Einstellungen der Domain kaputt) | | MAIL FROM || DNS-Server der Domain nicht erreichbar || Domain syntaktisch nicht korrekt, Domain nicht gefunden, keine spitzen Klammern um die Adresse, kein Mailserver für eine Antwort zu ermitteln (DNS-Einstellungen der Domain kaputt) | ||
|- | |- | ||
| RCPT TO || Mail an diesen Empfänger erzeugten bereits vorher temporäre Fehler (Fehlkonfiguration) || Empfänger unbekannt, Empfänger nicht lokal (Relaying | | RCPT TO || Mail an diesen Empfänger erzeugten bereits vorher temporäre Fehler (Fehlkonfiguration) || Empfänger unbekannt, Empfänger nicht lokal (Relaying) | ||
|- | |- | ||
| DATA || Erster Versuch beim [[/Greylisting|Greylisting]] || | | DATA || Erster Versuch beim [[/Greylisting|Greylisting]] || Ablehnung durch Spamfilter | ||
|} | |} | ||
== Greylisting und Spamfilter == | |||
Greylisting wird für alle Absender erzwungen, deren Server nicht auf unserer selbst gepflegten Whitelist stehen. Es wird jeweils das Triplett aus Absender, Empfänger und erste 24 Bit der IP-Adresse freigegeben. | |||
SpamAssassin läuft als Filtermodul im Mail-Server. Dafür wird eine zentrale Konfiguration verwendet, die Konfiguration im Benutzeraccount kann hier leider nicht benutzt werden. | |||
==Informationen zum HELO-Check== | ==Informationen zum HELO-Check== | ||
Laut [ | Laut [https://www.ietf.org/rfc/rfc2821.txt RFC 2821, Abschnitt 4.1.1.1] muss sich ein Rechner stets mit seinem korrekten Hostname (FQDN) melden. Sofern er keinen Hostname hat, ist eine IP-Adresse zu senden. | ||
Eigentlich sind sämtliche Mail-Server falsch konfiguriert, die sich mit einem anderen als ihrem eigenen Namen melden. Leider gibt es aber zu viele Mail-Server um diese Bedingung durchzusetzen. Oft melden sich Mail-Server nur mit ihrer Domain, die gar nicht oder zu einem anderen Rechner aufgelöst werden kann. | Eigentlich sind sämtliche Mail-Server falsch konfiguriert, die sich mit einem anderen als ihrem eigenen Namen melden. Leider gibt es aber zu viele Mail-Server um diese Bedingung durchzusetzen. Oft melden sich Mail-Server nur mit ihrer Domain, die gar nicht oder zu einem anderen Rechner aufgelöst werden kann. | ||
<!--Daher haben wir uns entschieden, diese Richtlinie nur von bestimmten Rechnern zu verlangen (siehe oben). Das sind Rechner, von denen ungleich mehr Spam kommt als von anderen. Jeder Mail-Server-Administrator hat die Möglichkeit, sein System korrekt zu konfigurieren und wird dann, auch wenn er auf einer der Blacklists steht, keine Probleme haben, E-Mails an unsere Benutzer zu senden.--> | <!--Daher haben wir uns entschieden, diese Richtlinie nur von bestimmten Rechnern zu verlangen (siehe oben). Das sind Rechner, von denen ungleich mehr Spam kommt als von anderen. Jeder Mail-Server-Administrator hat die Möglichkeit, sein System korrekt zu konfigurieren und wird dann, auch wenn er auf einer der Blacklists steht, keine Probleme haben, E-Mails an unsere Benutzer zu senden.--> | ||
Aktuelle Version vom 15. März 2025, 16:38 Uhr
Um unsere Benutzer so gut wie möglich vor Spam-E-Mails zu schützen, implementieren wir folgende Anti-Spam-Regeln.
DNS-Blacklists
Wir verwenden folgende Regeln anhand von DNS-Blacklists basierend auf IP-Adressen.
| Liste | Beschreibung | Aktion |
|---|---|---|
| b.barracudacentral.org | Barracuda Reputation Block List | Wird nicht angenommen |
| --- | Intern gepflegte Whitelist | Greylisting wird übersprungen für gelistete Hosts |
SMTP-seitig
Bevor unser Server eine E-Mail letztlich akzeptiert, werden die Angaben des Gegenüber zuerst geprüft. Folgende Tabelle zeigt die möglichen Fehler bei jedem Schritt.
| Als Antwort auf | temporärer Fehler | permanenter Fehler |
|---|---|---|
| HELO | - | SPF-Eintrag für Hostname oder Domain der HELO-Angabe vorhanden aber IP-Adresse nicht erlaubt |
| MAIL FROM | DNS-Server der Domain nicht erreichbar | Domain syntaktisch nicht korrekt, Domain nicht gefunden, keine spitzen Klammern um die Adresse, kein Mailserver für eine Antwort zu ermitteln (DNS-Einstellungen der Domain kaputt) |
| RCPT TO | Mail an diesen Empfänger erzeugten bereits vorher temporäre Fehler (Fehlkonfiguration) | Empfänger unbekannt, Empfänger nicht lokal (Relaying) |
| DATA | Erster Versuch beim Greylisting | Ablehnung durch Spamfilter |
Greylisting und Spamfilter
Greylisting wird für alle Absender erzwungen, deren Server nicht auf unserer selbst gepflegten Whitelist stehen. Es wird jeweils das Triplett aus Absender, Empfänger und erste 24 Bit der IP-Adresse freigegeben.
SpamAssassin läuft als Filtermodul im Mail-Server. Dafür wird eine zentrale Konfiguration verwendet, die Konfiguration im Benutzeraccount kann hier leider nicht benutzt werden.
Informationen zum HELO-Check
Laut RFC 2821, Abschnitt 4.1.1.1 muss sich ein Rechner stets mit seinem korrekten Hostname (FQDN) melden. Sofern er keinen Hostname hat, ist eine IP-Adresse zu senden.
Eigentlich sind sämtliche Mail-Server falsch konfiguriert, die sich mit einem anderen als ihrem eigenen Namen melden. Leider gibt es aber zu viele Mail-Server um diese Bedingung durchzusetzen. Oft melden sich Mail-Server nur mit ihrer Domain, die gar nicht oder zu einem anderen Rechner aufgelöst werden kann.