Google lehnt hin und wieder E-Mails ab, die per IPv6 eingeliefert werden. Der Mailserver ist korrekt konfiguriert, SPF, DKIM, DMARC und DANE sind vorhanden, kein Eintrag auf irgendeiner Blacklist. Per IPv4 geht die gleiche Mail problemlos durch.
Die Fehlermeldung
550-5.7.1 Our system has detected that this message is likely
550-5.7.1 unsolicited mail. To reduce the amount of spam sent
550-5.7.1 to Gmail, this message has been blocked.
Der verlinkte Support-Artikel hilft nicht weiter. Alle Vorgaben sind erfüllt. Googles Antwort auf Nachfrage: „Warum genau eine E-Mail abgewiesen wird, können wir Ihnen leider nicht mitteilen.“ Das betrifft gmail.com, googlemail.com und jede bei Google gehostete Domain gleichermaßen.
Workaround: IPv4-only für Google
Da Google per IPv4 keine Probleme macht, lässt sich Postfix so konfigurieren, dass E-Mails an Google-Domains nur über IPv4 zugestellt werden. Das ist unnötig, ärgerlich und widerspricht dem Gedanken hinter IPv6. Aber es funktioniert.
In /etc/postfix/master.cf einen eigenen SMTP-Service anlegen, der nur IPv4 spricht:
smtp4 unix - - - - - smtp -o inet_protocols=ipv4
In /etc/postfix/main.cf die Transport Map aktivieren:
transport_maps = hash:/etc/postfix/transport
Die betroffenen Domains in /etc/postfix/transport eintragen:
googlemail.com smtp4:
gmail.com smtp4:
Anwenden und Postfix neu laden:
postmap /etc/postfix/transport
service postfix reload
E-Mails an Google-Domains gehen ab sofort nur noch über IPv4 raus. Wer weitere Domains pro Ziel steuern will, findet in Postfix TLS Policy Maps einen ähnlichen Ansatz.
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.
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.
Mir rennt hier gerade eine Kiste aus ?Schweden? ganz schön die Bude ein und versucht seinen SPAM bei mir abzuladen..
Alles von post.lidingo.se[194.22.4.7]… Ein wc -l sagt mir nach einem grep mit |der letzten Stunde: 7606
Die Kiste steht bereits ganz fett in allen möglichen RBL Listen, was ist denn da los? Na ja, für Spaß habe ich noch mal etwas in deren Abuse Mailbox gekippt, vielleicht reagiert ja jemand.
Sind die Schweden jetzt die neuen „Chinesen“? Solche Aktionen bin ich sonst eher von dort gewohnt. Da kann man sich die abuse mail aber auch meist sparen!
Es ist ja nicht zu glauben… Da scheint eine ganze Chinabude nichts weiter zutun zu haben als SSH Burte Force Attacken durchlaufen zu lassen. Dieser Netzowner geht mir gerade tierisch auf die Nerven. Ich bekommen durchgehen Angriffe aus Netzen bei dem er der Eigentümer ist. Das ist im Moment auch echt massiv 🙁
Ich war mal wieder auf so einem lustigen Postfixvortrag… Die verschiedenen Möglichkeiten der Spamabwehr waren natürlich wieder Thema. Der Vortragende ist dabei tierisch auf sender adress verification abgegangen. Er hat es quasie als Lösung aller Probleme verkauft. Puhh, ich habe mich bald an der Mate verschluckt. Ich mein… OK in ganz besonderen Fällen kann es möglicherweise helfen (mir fallen zwar gerade keine ein aber…) und früher ging da vielleicht mal was. Im Grunde macht diese Art der „Spamabwehr“ nur Stress.
Versucht jemand eine E-Mail einzuliefern, versucht Postfix vor der Annahme der E-Mails zuerst selbst eine E-Mail an den Absender zuzustellen. Klappt dieses nimmt er die E-Mail an und wenn es nicht geht, dann nicht. Kommt also eine E-Mail vom Absender: spam@spamgott.net versucht Postfix diesem Absender eine E-Mail zuzustellen. Es wird also geprüft ob es die Domain überhaupt gibt, dann wird geschaut ob es einen MX-RECORD gibt, dann wird versucht eine Verbindung zu diesem Server aufzubauen. Ist es nicht möglich würde Postfix die jeweilige Meldung an den einliefernden „durchreichen“. Damit würden E-Mails nicht abgewiesen nur weil der Maileingangsserver des vermeintlichen Absenders gerade Stress hat oder dort Greylisting aktiviert ist. Wäre es möglich eine E-Mail einzuliefern wird die E-Mail erst überhaupt angekommen und die Absenderadresse in folgender Datei abgelegt:
/var/lib/postfix/verify_cache.db
Aktiviert wird der ganze Foo in der Postfix Konfigurationsdatei /etc/postfix/main.cf:
Klingt alles erst einmal ganz gut, oder? Ne überhaupt nicht…. Die Idee ist nett aber wenn man sich nun mal vorstellt eine Domain wird zum versenden von Spam missbraucht, dann schlagen bei diesem Server nicht nur die ganzen Bounce E-Mails auf, sondern zusätzlich noch der ganze Verification Krims. Es soll auch Absender geben die man wirklich nicht erreichen kann (sinnfrei, ist mir auch klar). Diese E-Mails kommen natürlich nicht an…. Versucht immer mal wieder jemand E-Mails an Empfänger zuzustellen, welche es nicht gibt, machen Mailserver gerne mal für eine gewisse Zeit dicht. Was ebenfalls nicht gut ist.
Und mal im Ernst, niemand will wirklich Strom, Traffic und Hardwareleistung bezahlen für den Mist. Wenn man sich einfach nur unnötige Last auf sein System ziehen will, wäre SETI@home mein Tipp! Mit etwas Hirnschmalz in seine Konfiguration gibt es deutlich bessere und effektivere Möglichkeiten. Dieser Weg ist einfach mal wieder der Versuch die Arbeit anderen aufzuhalsen.
Da schicke ich doch heute eine E-Mail ab und bekommen Sekunden später etwas wie das Folgende zurück:
Ihre E-Mail wird aus Gründen der Spam- und Virenabwehr zurückgehalten bis ihr Absender bestätigt wurde. Klicken sie zur Bestätigung auf diesen Link oder antworten sie auf diese E-Mail mit dem Betreff: „Supperspamabwehr8857“
O_o ist das ein Scherz? Wie arm ist denn dieser Versuch? Ja, ok… Vor vielen vielen Jahren war es wohl eine erste Notlösung aber so etwas setzt man doch heute nicht mehr ein. Zumindest war ich davon überzeugt!
Jetzt mal im Ernst, dem durchschnittlichen User kann man so etwas nicht zumuten. Er wird es einfach nicht verstehen, selbst wenn man es in deutsch schreibt. Mailinglisten, Onlineshops oder ähnliches würden zusätzlich nicht auf so etwas reagieren. Ein ordentlich konfigurierter Mailserver sollte hier wohl besser funktionieren – oh ja, dann müssten hier nicht die User sonder der „Admin“ denken….
Ich halte dieses fast so überflüssig wie das Gefummel mit den E-Mail Adressen. Auf vielen Webseiten steht unter -Kontakt- oft etwas wie: E-Mail: wurstsuppe – at – wurstdomain.de
Davon mal abgesehen dass jeder Spamroboter dieses schon beim einlesen herausfiltern kann, steht ja oft im Link hinter dieser Adressverwurstung die korrekte E-Mail Adresse im mailto:
Selbst wenn es in einem Bild hängt, ganz ohne Link… Glaubt wirklich noch jemand dass diese Spamroboter kein OCR beherrschen? Den einzigen denen man mit so etwas das Leben schwer macht, sind User welche einem wirklich eine E-Mail schicken wollen.
Bei dem ganzen Thema sind, wie so oft, einfach mal die Admins gefragt. Diese sollten ihren Job machen und nicht versuchen es über Dinge wie Challenge-Response auf die User abzuwälzen! Wie war es noch gleich: „Früher war alles besser“
AMaViS ist eine bewährte Lösung, um eingehende E-Mails nach Viren und Spam zu filtern. Was viele nicht wissen: Es gibt zwei grundverschiedene Wege, AMaViS an Postfix anzubinden. Die meisten HowTos beschreiben content_filter. Es gibt aber auch smtpd_proxy_filter, und der ist mein persönlicher Favorit.
content_filter: Erst annehmen, dann filtern
Postfix nimmt die Verbindung vom einliefernden Mailserver an und empfängt die komplette E-Mail. Der einliefernde Server bekommt ein „OK, E-Mail erhalten“ und baut die Verbindung ab. Postfix speichert die Nachricht zwischen und schiebt sie an AMaViS weiter. Hat AMaViS gerade alle Hände voll zu tun, versucht Postfix es einfach immer wieder.
Erkennt AMaViS die E-Mail als Spam oder Virus, passiert je nach Konfiguration: Info an Absender/Empfänger, Quarantäne, Tagging, oder die Nachricht verschwindet einfach. In jedem Fall hat Postfix die Nachricht zu diesem Zeitpunkt bereits angenommen und die Verantwortung übernommen.
smtpd_proxy_filter: Filtern vor der Annahme
Hier leitet Postfix die E-Mail während der SMTP-Session direkt durch AMaViS. Der einliefernde Server bekommt nicht einfach ein „OK“, sondern die durchgereichte Antwort von AMaViS: „Nein, das ist Spam“ oder „Virus im Anhang, abgelehnt“. Unser Mailsystem nimmt die E-Mail nur an, wenn AMaViS nichts dagegen hat.
Das bringt uns rechtlich auf eine andere Seite. Man kann uns nicht nachsagen, dass wir eine anvertraute Nachricht unterdrückt oder vorenthalten hätten. Wir haben die Nachricht nie angenommen.
Die Nachteile
AMaViS braucht zur Bewertung Zeit. Genau diese Zeit halten wir den einliefernden Mailserver fest und die Verbindung offen. Das kostet Ressourcen. Über diesen Weg können weniger E-Mails gleichzeitig angenommen werden als wenn Postfix sie erst zwischenspeichert. Mehr Leistung bedeutet mehr parallele AMaViS-Prozesse.
Ist gerade kein AMaViS-Prozess frei, wird die E-Mail nicht abgewiesen. Postfix liefert einen temporären Fehler (4xx), und der einliefernde Server probiert es später noch einmal. Das ist normales SMTP-Verhalten.
Konfiguration
In /etc/postfix/master.cf die Anbindung über smtpd_proxy_filter statt content_filter einrichten:
Wichtig: Auch receive_override_options = no_address_mappings muss auskommentiert werden. Sonst schaut Dovecot bei der lokalen Zustellung nicht nach virtuellen Alias-Einträgen. Die E-Mails werden dann mit „user unknown“ zurückgewiesen:
Dovecot findet den User nicht in der SQL-Tabelle, weil Postfix die Alias-Auflösung übersprungen hat. Ohne no_address_mappings löst Postfix den virtuellen Alias zuerst auf, und Dovecot bekommt den richtigen Usernamen.
Wer inzwischen auf rspamd umgestiegen ist: rspamd arbeitet standardmäßig als Milter, was die Proxy-vs-Content-Filter-Frage komplett eliminiert. Als Milter prüft rspamd die E-Mail während der SMTP-Session, genau wie smtpd_proxy_filter, aber ohne den Umweg über einen zweiten SMTP-Dienst.
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.