Google schaut in die E-Mails seiner gmail Nutzer, wertet den Inhalt aus und zeigt dem Nutzer dann maßgeschneiderte Werbung…. OK, ist jetzt nichts Neues! Nun hat Google aber bekanntgegeben dass sie zumindest keine Schüler mehr in dieser Form abschnorcheln will.
Toll, oder? Super… Alle freuen sich…. ALLE FREUEN SICH! Leute, schlaft ihr alle? Google durchsucht, nach eigenen Angaben, keine E-Mail Accounts von Schülern mehr und SCHÜTZT sie somit vor Werbung welche zu E-Mail Inhalten passt!!!!!
Das ist so als wenn der Postbote die Briefe liest und immer direkt das passende Werbeprospekt beilegt. Warum freuen sich alle? Ich verstehe es nicht, tut mir leid!
Oh, da ging ja heute ein kleines Beben durchs Internet. Eine weitere RIR ist schon am letzten /8, die ARIN…. Ich bin ja fast vom Glauben abgefallen, das hat tatsächlich noch einige Leute überrascht.
Das gefällt mir … Nachdem nun Yahoo die Eier hatte einfach mal ihre DMARC Policy „scharf“ (reject) zu schalten und sich so viel Schimpfe von aller Welt dafür eingesammelt hat und beschuldigt wurde die Mailinglisten „kaputt“ zu machen…. Tja, da zieht AOL nun in gewisser Weise nach: https://web.archive.org/web/20151222062444/http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/
AOL hat nämlich gerade ein tierisches Spam-Problem. Also jetzt nicht direkt, eher haben andere das Problem, es betrifft AOL nur in soweit das deren Absenderdomain dafür missbraucht wird. Die Spam E-Mails sehen also so aus als wenn sie von AOL kommen. AOL hat nun also ihre DMARC Policy scharf geschaltet um das Problem damit etwas eindämmen zu können. Ob nun wohl so langsam Google und Microsoft ebenfalls nachziehen? Inzwischen sollten die Admins der Mailinglisten ja schon mal „warm“ gelaufen sein
Mailgraph von David Schweikert ist ein simples Perl-Script, das Postfix-Logdateien parst und daraus RRDtool-Graphen erzeugt. Empfangene, gesendete, abgelehnte Mails auf einen Blick. Für kleinere Mailserver oder Testsysteme reicht das völlig.
Was mailgraph nicht kann: SPF-, DMARC– und DKIM-Ergebnisse darstellen. Wie viele Mails bestehen den SPF-Check? Wie oft schlägt DMARC fehl? Gibt es einen Trend? Ich habe zwar einen existierenden SPF-Patch für mailgraph gefunden, wollte aber alle drei Protokolle in einem Aufwasch.
Die folgenden Patches erweitern mailgraph 1.14 um drei zusätzliche Graphen: SPF (pass/none/fail), DMARC (pass/none/fail) und DKIM (pass/none/fail). Ausgelegt für Postfix mit postfix-policyd-spf, opendkim und opendmarc.
Installation
Auf einem Debian-System müssen zwei Dateien ersetzt werden: /usr/sbin/mailgraph (der Daemon) und /usr/lib/cgi-bin/mailgraph.cgi (die Weboberfläche). Vorher sichern.
Der Daemon-Patch fügt neun RRD-Datasources hinzu (spfnone, spffail, spfpass, dmarcnone, dmarcfail, dmarcpass, dkimnone, dkimfail, dkimpass) und parst die Logzeilen von policy-spf, opendmarc und opendkim:
Der CGI-Patch erzeugt die drei neuen Graphen (SPF, DMARC, DKIM) und bindet sie in die HTML-Ausgabe ein. Jeder Graph zeigt pass als Fläche, none als Stack und fail als Linie:
Der Daemon-Patch erweitert die RRD-Datenbank um neun Datasources und erkennt im Syslog die Ausgaben von drei Diensten:
Dienst
Log-Pattern
Ergebnis
policy-spf
Received-SPF: pass/none/*
spfpass, spfnone, spffail
opendmarc
pass/none/fail
dmarcpass, dmarcnone, dmarcfail
opendkim
DKIM verification successful / no signature data / bad signature data
dkimpass, dkimnone, dkimfail
Der CGI-Patch erzeugt drei neue Graphen unterhalb der bestehenden. Jeder zeigt pass als Fläche, none als Stack darüber und fail als rote Linie. Die Zeiträume (Tag, Woche, Monat, Jahr) werden wie bei den Standard-Graphen automatisch erzeugt.
Hinweise
Die Patches sind für mailgraph 1.14 geschrieben. Weil mailgraph die RRD-Datasources beim ersten Start festlegt, muss nach dem Patchen die bestehende mailgraph.rrd gelöscht werden. Die alten Daten gehen dabei verloren, die neuen Graphen fangen bei Null an.
Wer heute mit dem Monitoring anfängt: rspamd bringt eine eigene Weboberfläche mit und prüft SPF, DKIM und DMARC in einem Durchgang. Zusammen mit Prometheus und Grafana bekommt man deutlich flexiblere Dashboards als mit RRDtool. Mailgraph bleibt trotzdem nützlich wenn man schnell was Schlankes braucht, das ohne externe Abhängigkeiten läuft.
Man ist das hässlich… Da sitze ich hier an einem Sabayon System und bekomme keine saubere Uhrzeit. Zwar sollte ntpd.service beim Start die Uhrzeit abgleichen.. Der Dienst verkackt aber seinen Starten, weil er „noch“ kein Netzwerk hat. Dabei ist sogar hinterlegt dass es er erst nach dem Netzwerkmanager startet, denn noch scheint der Netzwerkmanager so schnell keine Verbindung zu bekommen. Der initiale Abgleich vom ntpd.service schlägt daher fehlt, der Dienst bleibt aus und es probiert es auch später nicht mehr. Grütze..
$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
ntpdate.service loaded failed failed Set time via NTP using ntpdate
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
Ich lasse jetzt mal das Bughunting und setzte einfach auf chrony. Nur für Zeitsync ist das ok für mich!
Eine DMARC-Policy zu veröffentlichen ist die eine Seite. Die andere ist, eingehende Mails gegen die DMARC-Policy des Absenders zu prüfen. Postfix kann das nicht selbst. Dafür gibt es zwei Wege: OpenDMARC als eigenständigen Milter oder rspamd, der DMARC als eines von vielen Modulen mitbringt.
Variante 1: OpenDMARC
OpenDMARC ist ein dedizierter DMARC-Milter. Er liest die Ergebnisse von SPF und DKIM aus den Mailheadern und prüft ob die DMARC-Policy des Absenders erfüllt ist.
RejectFailures false ist ein guter Startwert. Damit werden Mails die den DMARC-Check nicht bestehen nicht sofort abgelehnt, sondern nur markiert. So kann man erst beobachten bevor man scharf schaltet. AuthservID muss zum Hostnamen des Mailservers passen.
Wichtig: OpenDMARC verlässt sich darauf, dass SPF und DKIM bereits geprüft wurden und die Ergebnisse in den Authentication-Results-Headern stehen. Die Reihenfolge der Milter in Postfix ist daher entscheidend: SPF und DKIM müssen vor OpenDMARC laufen.
Postfix-Integration
In der main.cf den Milter registrieren. OpenDMARC muss nach dem DKIM-Milter stehen:
Port 8891 ist hier OpenDKIM, Port 8893 OpenDMARC. Nach einem postfix reload prüft OpenDMARC jede eingehende Mail und schreibt einen Authentication-Results-Header mit dem DMARC-Ergebnis.
Variante 2: rspamd
Wer rspamd als Spamfilter einsetzt, braucht keinen separaten DMARC-Milter. rspamd prüft SPF, DKIM und DMARC in einem Durchgang und verrechnet das Ergebnis mit dem Gesamtscore. Das DMARC-Modul ist standardmäßig aktiv und unterstützt auch DMARC-Reporting (rua/ruf).
Der Vorteil von rspamd: Statt einer harten Ablehnung bei DMARC-Fail fließt das Ergebnis in die Gesamtbewertung ein. Eine Mail die DMARC nicht besteht aber sonst sauber aussieht, wird nicht sofort abgelehnt. Umgekehrt kann eine Mail die DMARC besteht trotzdem als Spam markiert werden wenn andere Indikatoren dagegen sprechen.
Was passt besser?
OpenDMARC
rspamd
Aufwand
Eigener Dienst, eigene Config
Bereits als Milter integriert
Verhalten
Harte Entscheidung (reject/accept)
Score-basiert, flexibel
Reporting
Eigenes Reporting-Tool nötig
rua-Reports eingebaut
Abhängigkeiten
Braucht SPF/DKIM in den Headern
Prüft SPF/DKIM selbst
Für neue Setups ist rspamd meist die bessere Wahl, weil es SPF, DKIM, DMARC, ARC und Spam-Filterung in einem Paket liefert. OpenDMARC ist sinnvoll wenn man einen minimalen Stack ohne Content-Filter will oder bereits einen anderen Spamfilter einsetzt.
Übrigens: DMARC und Mailinglisten vertragen sich nicht ohne Weiteres. ARC löst das Problem. Fragen? Einfach melden.
LEUTE… am 13 August 1982 wurde von einem Herrn David H. Crocker das RFC 733 überarbeitet. Somit wurde das RFC 733 ersetzt durch das RFC 822.
In diesem nun knapp 32 Jahre alten Dokument wurden die Mailheader In-Reply-To und Message-ID definiert. Warum ich das schreibe? Ganz einfach… Weil es noch nicht bei allen angekommen zu sein scheint, was jetzt nicht böse zu verstehen ist!
Ich möchte es daher einmal kurz erklären. Sollte ich jemanden auf diesen Eintrag verweisen, also bitte lesen
Wenn ich eine E-Mail an Klaus schreibe, dann erhält meine E-Mail automatisch eine einmalige Message-ID. Diese landet dann, für den Anwender unsichtbar im Mailheader. Antwortet Klaus nun auf diese E-Mail, bekommt seine Antwort natürlich ebenfalls eine MessageID, zusätzlich wird noch das Feld In-Reply-To gefolgt von der MessageID der Nachricht auf welche er gerade geantwortet hat in die E-Mail Header geschrieben.
Was bringt dieses? Nun, viele E-Mail Clients (japp Outlook seit ein paar Jahren auch) können E-Mail Nachrichten in der Form eines Gesprächsverlaufes anzeigen. Selbst wenn sich Betreff oder E-Mail-Inhalt komplett ändern. Dieses macht einem nicht nur das nachträgliche Verfolgen der E-Mail Kommunikation einfacher, sondern erleichtert einem extrem die Übersicht zu behalten. Da die E-Mail ja an eine völlig falsche Stelle einsortiert wird.
Alles funktioniert perfekt bis zu dem Moment in welchem jemand in einem völlig anderem Zusammenhang auf eine E-Mail antwortet. Also irgendeine alte E-Mail heraussuchen, auf antworten klicken, Betreff und Hinhalt löschen und eine „neue“ E-Mail schreiben. Das verbrennt nicht nur die Übersicht, sondern sorgt dafür das E-Mails sehr spät oder überhaupt nicht gelesen/beantwortet werden.
Habe ich dich auf diesen Text verwiesen, dann möchte ich dich (aus dem genannten Grund) mit Nachdruck darum bitte, mit bei neuen Themen eine neue E-Mail zu schreiben. Alle anderen nehmen es bitte als Information auf!
Für Detail bitte im RFC 822 besonders den Punkt 4.6.2. IN-REPLY-TO lesen: https://datatracker.ietf.org/doc/html/rfc822 und natürlich RTFM beim eigenen MUA betreiben. Bei Fragen, einfach fragen
Bei mir ist mal wieder die Frage angekommen, wie man denn seine Kennwörter wählen sollte. Ich habe wieder auf das Programm pwgen hingewiesen. Das ist ein kleiner Password-Generator für die Bash/Konsole.
Warum ein Kennwort Generator? Nun ja, Software dieser Art hat aus meiner Sicht ein paar Vorteile…
So hindert man seinen eigenen Schweinehund daran immer das gleiche Kennwort zu benutzen. Das ist ja bekanntlich mehr als gefährlich, denn wenn bei irgendeinem Anbieter mal wieder ein Sicherheitsloch ausgenutzt wurde, ja dann ist das Kennwort schon in den „falschen Händen“, meist zusammen mit der E-Mail Adresse. Fast überall kann man sich mit der Kombination E-Mail Adresse/Kennwort anmelden. Ist es immer gleich, kann sich der Mensch mit den „falschen Händen“ direkt überall anmelden. Daher sollte es ein eigenes Kennwort für jeden Dienst geben. Dabei ist ein: SuperTollesKennwort.Dienstname besser als nichts… Nur so schlau dieses zu probieren ist im Zweifel der Mensch mit den „falschen Händen“ ebenfalls. Will man es auf die Spitze treiben legt man sogar für jeden Dienst eine eigene E-Mail Adresse an. Dann hat der Angreifer nicht nur kein einheitliches Kennwort, sondern auch keine einheitliche E-Mail Adresse. Zurück zu pwgen…
Als weiteren Vorteil sehe ich dass die erstellten Kennwörter „zufällig“ sind (es macht natürlich einen guten Kennwort Generator aus, dass er immer zufällige Kennwörter rechnet ). Einem selbst gehen schnell die Zufälle aus. Selbst wenn man immer nur auf der Tastatur hämmert, werden sie sich ähneln.
Zudem lässt sich pwgen gut in Scripten verwursten um direkt beim anlegen von Accounts schöne initiale Kennwörter zu generieren. Es wäre ja schön blöde immer die gleichen Kennwörter für neue Kunden zu vergeben.
Nun wollen wir mal ein paar Kennwörter würfeln. Der folgende Aufruf sollte viele Kennwörter mit Groß-/Kleinschreibung, 8 Zeichen und Ziffern erstellen:
So viele Kennwörter benötigt man normalerweise nicht. Ein einziges Kennwort mit Groß-/Kleinschreibung, 8 Zeichen und ohne Ziffern (dann kann es sich ein Anwender meist besser merken) generiert sich mit folgendem Aufruf:
$ pwgen -1 -0
chaisaeM
Soll es einmal sicher werden erstellt der folgende Aufruf ein Kennwort mit Groß-/Kleinschreibung, 14 Zeichen, Ziffern, Symbolen und der deaktivierten pronounceable Funktion von pwgen. Die pronounceable (aussprechbar) Funktion von pwgen sorgt sonst dafür das die Kennwörter besser zu merken sind. Dieses macht es natürlich etwas weniger zufällig.
$ pwgen -1 -s -y 14
SKf|.k.]m}o'Q3
Man sieht schon, solche Ausgaben lassen sich sehr gut in irgendwelchen Scripten nutzen! Wie immer bringen die man-pages noch mehr Beispiele und Informationen mit. Also bitte RTFM….
Ich habe heute, wenn auch etwas angeschlagen, wieder vor einem System gestanden welches von einem „selbsternannten“ Profi eingerichtet wurde. Dabei gab es Fehler die ich jetzt nicht näher ausführen kann, denn noch ist es mal wieder Zeit für einen ordentlichen double facepalm!
Nur falls sich jemand wundert warum ich in den nächsten Tagen dauerkopfschüttelnd herumlaufe. Jetzt glaubt bitte nicht dass ich fehlerfrei bin. Ganz sicher nicht!
Na was lese ich denn da wieder bei golem.de? Yahoo soll Mailinglisten kaputt machen weil DMARC eingesetzt wird?
Über DMARC habe ich ja schon etwas geschrieben, auch dass man mit Mailinglisten Probleme bekommen kann, wenn man eine Policy veröffentlicht. Denn die meisten Mailinglisten arbeiten leider nicht DKIM konform. Denn DKIM signiert den Body und ebenfalls den Betreff einer E-Mail. Wenn die Mailingliste nun den Betreff ändert um ein [Mailinglistenname] in den Betreff zu schreiben (damit die Anwender darüber besser „filtern“ können und wegen Übersicht bla bla). Sowie einen kleinen Footer mit Infos zur Liste in den Body hängen, ja dann ist die DKIM Signatur ungültig. Soll ja so sein! Mailinglisten lassen sich prima über den Mail-Header: List-id Filtern, die Infos zur Mailingliste im Footer liest eh keiner und es produziert nur unnötig viele Daten, da sie an jede E-Mail gehangen werden. Übersicht? Filtert man seine E-Mail sauber und sortiert sie in die passenden Ordner, dann ist die Übersicht gegeben.
Wie auch immer… DKIM Signaturen werden durch Mailinglisten schon seit vielen Jahren gebrochen. Einige Mailinglisten werfen sogar die DKIM Signaturen aus den E-Mails bevor sie „weitergeleitet“ werden. Damit kann es zwar keine ungültige/gebrochene Signatur mehr geben, in Kombination mit einer DMARC Policy gibt es denn noch ein Problem. Denn wenn in der Policy steht: E-Mails sind immer DKIM und SPF signiert und wenn sie es nicht sind oder wenn die Signatur ungültig ist, dann weise die E-Mail zurück. Dann passiert das so!
All dieses ist schon seit längerem fest in ein RFC gegossen. Eingesetzt wird DMARC bereits von vielen der großen Anbieter… Bisher war nur noch keiner cool genug es „scharf“ zu schalten. Ist völlig legitim, denn auch die Mailinglisten Admins sollen eine gewisse „Übergangszeit“ haben. Wie so oft hat nur kaum einer reagiert. Ist ja nur mal wieder Security oder Features welche die User nicht direkt betreffen. Ja, es ist eine gewisse Art ~Vergewaltigung~!
Der DMARC-RECORD von yahoo.com gibt eine klare Policy vor: