Forum-Notificationmails landen im Spam (wegen Weiterleitung ohne ARC)


#1

Fortsetzung der Diskussion von DNS-Umzug forum.freifunk.net:

Nachtrag:
Es ist nicht nur dkim, sondern wir haben auch eine vergleichsweise strikte Regelung im SPF gewählt.

Folge: Wenn ihr Euch Foren-Mails weiterleiten lässt (hier im Forum Adresse A eingetragen. Und Server für A leitet dann weiter zu B):
Dann muss (sollte) der Server für A auch ARC-support (funktionsfähig implementiert) haben.
Warum?
Weil sonst die DKIM und der SPF-Host nicht mehr passen.

Will sagen: Wir haben gestern schon Beanstandungen von Google&Co für rund ein ganzes Dutzend 1&1, Schlund- und andere (Root-)Server bekommen, die allem Anschein nach versucht haben, Mails mit (eigentlich) gültiger DKIM von forum.freifunk.net z.B. an eine gmail-Adresse zu senden, aber mangels ARC-Signatur als Spam von Gmail&Co abgelehnt wurden.

Das wird dann natürlich abgelehnt, weil “nicht regelkonform”.

Wenn Euch also Notifications fehlen, dann prüft bitte, ob ihr Euch die Forenmails evtl. forwarden lasst von einem leicht veralteten Mailserver zu einem Provider “mit modernem Antispam-Whatever”.

Dann müsstest Ihr den Weiterleitungs-Server ertüchtigen oder gleich die richtige Zieladresse als Mailadresse hier im Forum angeben.


#2

Ich google scheinbar gerade schlecht. zufällig ein Howto für Exim und ARC zur Hand?


#3

ich finde leider nur Hinweise darauf, dass das “nur” in einem Exim-Experimental enthalten sei.


(Zeile 760ff)


#4

Einen im Oktober 2018 hinfällig werdenden Draft(!) als »Standard« vorauszusetzen, halte ich erst einmal für fragwürdig; könnt Ihr vielleicht die Entscheidungsgründe für die gewählten Einstellungen, die – wie vorher bekannt gewesen – nun zu Problemen alltäglicher legitimer Mailnutzung führen, darlegen? Normalerweise macht man ja einen Status Quo nicht leichtfertig mutwillig kaputt, und das erzeugte »Mailinglistenproblem« ist ja DKIM-/DMARC-inhärent.

Auch würde ich über die DMARC-Einstellungen reden wollen:

_dmarc.forum.freifunk.net. 86400 IN TXT "v=DMARC1\; p=quarantine\; rua=mailto:admin@forum.freifunk.net\; ruf=mailto:admin@forum.freifunk.net\; rf=afrf\; sp=none\; pct=100\; ri=86400"

Mittels rua/ruf bekommt AFAIK admin@forum.freifunk.net personenbezogene Informationen (IP- und Mailadressen), insbesondere von US-Mailserver-Anbietern, frei Haus; ist das knapp vier Wochen vor Gültigkeit von DSGVO/GDPR eine so kluge Entscheidung? Auch hier wäre interessant, was die Beweggründe waren, diese Daten extern erfassen zu lassen und empfangen zu wollen.

Edit: Da nicht jedem klar sein dürfte, was die »Feedbacks« bei DMARC ermöglichen, auch wenn @adorfer daraus ja keinen Hehl macht:

(Hervorhebung von mir.) Über die gewählten DMARC-Einstellungen kann admin@forum.freifunk.net nun von anderen DMARC nutzenden Mailservern Informationen bekommen, das z. B. die Forenmail an foobar@example.com an barfoo.ffforum@gmil.com geschickt werden sollte. Letztere Mailadresse dürfte den Forenadmins nicht bekannt sein (angemeldet wurde sich ja mit foobar@example.com), und ein legitimes Interesse an dieser, aktiv über Dritte beschafften, Information – daß nämlich foobar@example.com und barfoo.ffforum@gmil.com irgendwie zusammenhängen – fällt mir zu konstruieren schwer.

Nota bene: ich unterstelle keine unlauteren Absichten; aber nach dem »CDN-Shitstorm« und den ewigen Dezentralisierungsdebatten und dem generellen »wir speichern nicht!«-Ansatz finde ich diese kleine Konfigurationsänderung mit gravierenden Auswirkungen auf die Privacy der Nutzer doch diskussionswürdig. Zumal man die Einstellungen ja nicht so progressiv machen muß.


#5

Nein.
Zumindest solche Informationen gab es bislang nicht.
Lediglich die Info über die Absenderdomain “forum.freifunk.net” und die IP des anliefernden, aber DKIM-failenden Hosts.
Bespiel (IP-Adressen ausgeblendet)

-<record>
-<row>
<source_ip>212.xxx.xxx.xxx</source_ip>
<count>1</count>
-<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
-<identifiers>
<header_from>forum.freifunk.net</header_from>
</identifiers>
-<auth_results>
-<dkim>
<domain>forum.freifunk.net</domain>
<result>fail</result>
<selector>default</selector>
</dkim>
-<spf>
<domain>sxxx.kundenserver.de</domain>
<result>pass</result>
</spf>
</auth_results>
</record>

Diese Auswirkungen sehe ich nicht.
Es ist nicht ersichtlich, um welche Mailadressen, oder welche Mail-Domains es geht.
Es wird lediglich gemeldet, welche IP mit welchem Reverse da versucht hat, mail mit der Domain “forum.freifunk.net” einzuliefern als Absender, dabei aber gefailed hat.


#6

Danke für’s Disclosure.

Da – aus meiner Sicht – SPF → DKIM → DMARC → ARC → … kein Problem löst, ohne mit jeder Stufe weitere Änderungen von den Absendern zu erfordern, um das Mailsystem generell nicht kaputt zu machen, habe ich mit SPF aufgehört, aktiv den Weg weiterzugehen. Die Option, sich von extern Infos über die Nutzung der eigenen Domain senden zu lassen, klingt schon spannend. Und irgendwo auf dem hehren Anti-Spam-Kreuzzug gibt’s auch die Option, sich ganze, als nicht konform abgelehnte, Mails zuschicken zu lassen; sofern das nicht im DMARC-Kontext war, fein.

Trotzdem steht noch die Antwort aus, warum ausgerechnet forum.freifunk.net päpstlicher als der Papst wurde? Vor dem »DNS-Umzug« bestand das Problem ja nicht, warum ist es nun eines? Danke.


#7

Weil die Nutzung von DKIM, SPF und “möglichst gutem Scoring bei $EMAILMASSENHOSTER” immer wieder eingefordert wurde.
Teilweise öffentlich im Forum, teilweise auf anderen Kanälen. Oft mit diffusem “warum landen die Notifications aus dem Forum im Spam bei mir. Macht, dass $XY Euch hochstuft”
Strenge SPF und DMARC ist eine Möglichkeit, das zu erreichen.
(Und nein, vally.org&co waren vorher schon “grün” plus mehrere Whitelistungen. Das allein hat nicht geholfen.)

Ob man sich dem Diktat von Google, Microsoft, Yahoo, United-Internet etc beugen soll, wo die selbst doch (add you favourite insult here): Darf man sich aussuchen.
Menschen nutzen eben Gmail&Co, weil sie dort das Gefühl haben, weniger Spam zu erhalten. Daher können die Standards setzen. Durch die Größe ihres Tortenstücks.
Am Ende läuft es auf ein “Friss oder Stirb” hinaus.

Und ja, auch ich habe vorletztes Jahr meine altgedienste qmail-Installation beerdigt, nachdem auch die letzten uucp-sites eingestampft worden sind und ich kein batched/rgsmtp mehr benötigte.
Dass ich vor der Erfindung von M4 sogar mal sendmail.cf “sprechen” konnte: Sind halt Opas Geschichten aus dem EDV-Schützengraben.
Hier dreht jetzt ein Postfix, einfach weil’s der Standard ist und man da Dinge effektiv mit hinbekommt.


#8

Und das wurde wo hier diskutiert, was man wie warum macht, mit welchem Vorteil für wen und welchem Nachteil für wen sonst? (Ja, “mach’ mal DKIM an” als Ausgangsthread für “DNS-Zone forum.freifunk.net geschnitten und externalisiert” habe ich gesehen (keine Folgeabschätzung oder Diskussion allerdings).)

Man” ja. Aber ich finde schon, daß “man” hier mit mehr Augenmaß agieren muß; weil drölf Honks Foren-Mails wegen $Policy ihres Mailanbieters-of-Choice aus ihrem Spam-Folfer fischen müssen, sollte man nicht die paar hundert anderen übervorteilen (lies: benachteiligen).

ARC ist schlicht (noch immer – go figure) kein Standard, damit gibt es keine Lösung und damit verbieten sich zu proaktive SPF-, DKIM- und DMARC-Einstellungen. IMHO, YMMV, aber: Wo wurde dies diskutiert?

Warum wechseln die »drölf Honks« nicht ihren Mailanbieter (es gibt ja duchaus welche, die nicht primär eigene Standards durchpauken wollen) – oder lesen halt auch »Spam« –, warum wird deren Problem zum Problem Aller gemacht? Auf welcher Grundlage jenseits von »weil wir Admin sind«?

Ja, das geht in Richtung »›gut gewollt‹ ≠ ›gut gemacht‹«; ich denke, wir müssen reden.

Dann verschweige ich besser mal, daß meine sendmail.cf partiell noch handgeklöppelt ist wie auch, daß ich davor ein Proxmox Mail Gateway geschnallt habe, um die altersbedingten offenen Flanken mal anzugehen …

Aber Spaß beiseite: der Standard-aliases-Eintrag führt auch 2018 auf einem moderat aktuellen Postfix nicht dazu, daß Postfix die Header umschreibt. Was auch wieder kontraproduktiv wäre bei »abuse: abuse.xy@ticketsystem.example.com«. Hier will man sicher vieles, aber genau eins nicht: daß »From: “CERT-Bund Reports” <reports@reports.cert-bund.de>« in »“CERT-Bund Reports” (reports@reports.cert-bund.de via local postfix) <postmaster@doma.in>« umgeschrieben wird. Und hier liefern AFAIK DMARC/ARC noch(?) keine Lösung (ich fürchte, daß sie das prinzipbedingt nicht können), was IMHO ihren Einsatz auf’s Mindeste beschränkt, wenn generell nicht gar verbietet.

Kurzum: ich halte es für notwendig, daß derlei signifikante Änderungen »von den Nutzern« unterrichtet entschieden werden.


#9

< offTopic> Ich verstehe nicht warum so eine Sache einer Diskussion im Vorfeld bedarf. Wenn das unser Anspruch ist kommen wir zu gar nixs mehr. @adorfer und @MPW haben sich ehrenswerterweise eingesetzt den Mailversand auf vernünftige Beine zu stellen und Adorfer hat hier proaktiv Stellung bezogen das die Setups die einige wenige nutzen nicht (mehr) kompatibel sind, gab Tipps was man tun kann. Die beiden betreuen das Forum und benötigen dafür IMO auch Entscheidungskompetenz. Jetzt wird aber nach getaner Arbeit erstmal eine Grundsatzdiskussion aufgemacht? Wir sollten alle aufpassen das wir nicht ewig jene die sich Einbringen demotivieren, man kann durchaus konstruktiver formulieren als es hier in dem Thread der Fall ist :wink: </ offTopic>

Wenn ich dich richtig verstehe ist deine Annahme, das kaum jemand Anbieter nutzt die SPF mehr oder weniger stark fordern. Diese Annahme würde ich persönlich hinterfragen. Ich halte es eher für die Ausnahme, das jemand Forwarded (mir ist nicht klar warum man es nicht einfach in der Mailbox annehmen sollte?) und dazu noch nicht bereit ist an seinem Setup dann Anpassungen vorzunehmen. Das können aber nur die Admins auf Basis der Datenbank gut einschätzen.

Cheers,
Arwed


#10

Hallo,

Hui - das ist viel Arbeit wg. kaputter E-Mail-Standards.

Es gibt keine standardkonformen, SPF-kompatiblen redirects. SRS ist nunmal seit knapp 15 Jahren expired. Die Idee von SPF ist, dass $random-server mails von forum.freifunk.net senden darf - da das hier eingeschränkt ist, gehen Weiterleritungen kaputt. ARC repariert diesen Standard nicht.

Wikipedia sagt dazu ganz nett:
“Even if the SPF and DKIM validation fail, the receiving service can choose to validate the ARC”.

Hier:
"v=spf1 a mx a:forum.freifunk.net a:mail.freifunk-rheinland.net a:mail.nadeshda.org a:mail2.nadeshda.de ip4:51.255.233.210 ip4: ip6:2001:41d0:1:a31a::210 ~all"

~all sagt eben: Weiterleitungen sind nicht erlaubt (softfail: The SPF record has designated the host as NOT being allowed to send but is in transition) - Es gibt zwar die “itended” action zustellen-aber-markieren; die Markierung ist aber eben SPAM und die Mail geht unter.

Damit:

  • Mit diesem SPF-Record stellt ihr klar, dass Weiterleitungen nicht funktionieren dürfen.
  • Wer sich einen E-Mail Hoster aussucht, der SPF-auswertet, sollte keine Weiterleitungen konfigurieren
  • E-Mail ist kaputt.

Edit: Ich vergaß:
Heinlein empfiehlt ?all https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

Gruß, yanosz


#11

Doch. Weiterleitungen funktionieren, setzt aber voraus, dass der Weiterleitserver ARC nutzt.

Und die SPF-Regelung besagt: Weiterleitungen ohne ARC sollen im Spamverdacht (“quarantäne”) landen.

d.h da kann man sie per procmail&Co ja ggf. nach Kritierien (from, received-lines) wieder in die passende Inbox holen.

Sprich
a) Entweder weiterleiten von einem Host, der ARC kann
b) oder zu einem Host, der SPF/DKIM nicht kann/nicht prüft (ist ja keine Pflicht)
c) per Filterregel aus dem Spam herausholen
d) per Absender in Whitelist von der Prüfung ausnehmen (sofern der Mailbox-Anbieter das anbietet.)


#12

Hallo,

ARC ist weder Teil von SPF noch ein gültiger Standard-RFC. Es ist nur ein Draft.
Damit kann ARC gar nicht sagen, wie eine SPF-Anweisung standardkonform interpretiert werden soll.

Standardkonform sagt ~all genau das: Andere Server nicht: Soft-Fail. Es ist für Debugging / Transition gedacht.~all und Weiterleitungen ergeben imho keinen Sinn.

Wenn Du Weiterleitungen erlauben willst sag: ?all - das macht mailbox.org auch.

Gruß, yanosz


#13

Das sind alle keine echten Standards, so wie man das von “gut abgehangenen RFCs” erwartet, sondern Vorschläge von Arbeitsgruppen, die die sich die Bekämpfung von Spam (und die Erhaltung des providerunabhängigen Mediums “E-Mail”) auf die Fahnen geschrieben haben. Und dabei nicht nur Snakeoil verkaufen möchten, sondern wirklich an Lösungen interessiert sind.
Und dafür werden eben Stück für Stück “Angriffswege” zum Einschleusen von Spam zumindest erschwert, wenn nicht ganz abgedichtet.

Und: der SPF gibt eine Empfehlung heraus, was Empfangsmailserver tun können. Wenn sie denn mögen.
Das ist nicht nomativ. Es wird auch nicht vorgeschrieben “etwas zu löschen”.
Es ist lediglich eine öffentliche Bekanntmachung, die einfach abfragbar ist:
“was für E-Mails aus der Absenderdomain kommt und daher als valide angesehen werden kann. Und wo ein zweiter Blick notwendig sein sollte.”

Das problematische Szenario ist “User nutzt Weiterleitungsserver, der kein ARC kann” und “User nutzt ziel-Postfach, wo es keine Möglichkeit gibt für Whitelists, keine Sortierregeln, kein Option zur Deaktivierung eine strengen SPF-Anwendung in den individuellen Spamerkennungs-Settings. Und User hat auch keinen Zugriff mit den üblichen Imap/procmail-Tools auf seine Mailboxen.”

All anderen können @forum.freifunk.net in die whitelist eintragen oder bei Match einen Foldermove (Spam->Inbox) triggern.


#14

Und für diesen Fall wäre ?all (aka spf neutral) imho das richtige setting.

Gruß, yanosz


#15

Das bezweifle ich mal stark. Wieso sollten hunderte Nutzer hier Weiterleitungen für ihre Emails einrichten? Und wozu will man Forenemails überhaupt weiterleiten?

Ich sehe hier überhaupt keinen Anwendungsfall für Weiterleitungen. Trag halt direkt die Zieladresse im Forum ein und alles wird gut.

Oder setz den weiterleitenden Server auf die weiße Liste. Das geht auch. Problem gelöst.


#16

Hallo kurze Rückmeldung von Meiner Seite:

Weiterleitung von Foren Mails von web.de an gmail funktioniert bisher ohne Probleme.
Warum man Weiterleitungen macht evtl. weil es auch leute gibt die Ihre Emails nicht selber hosten :wink:


#17

Schön, dass es funktioniert. Das ist aber halt z. B. schon unnötig. Einfach die Gmail-Adresse als Forenadresse nutzen und das würde es auch tun.

Eben genau das erschließt sich mir überhaupt nicht. Der einzige Anwendungsfall, der mir einfällt, wäre sowas wie: Ich habe einen eigenen Emailserver, vertraue aber der Stabilität nicht, daher hänge ich einen der großen Anbieter vorweg, und leite die Emails weiter. Dann verpasse ich nichts, wenn der Server mal offline ist.

Aber genau in dem Fall kann man eben einfach auf dem eigenen Server den weiterleitenden Server auf die weiße Liste setzen.

Von $kommerziellemAnbieterA zu $kommerziellemAnbieterB weiterzuleiten hat mMn wenig Sinn.


#18

Aber genau da brauchst Du genau das nicht, da “die Großen” (mir bekannten) seit Langem ARC implementiert haben.
Fehlendes ARC gibt es idR bei irgendwelchen Home-Servern oder irgegendwelchen “Mittelstands-IT”-Buden, die Wartungsstau haben. Und wo die Mail-Server erst komplett abbrennen müssen, bevor das mal wieder jemand länger als 10 Minuten “am Stück” anfasst. Und die argumentieren dann auch gern damit, dass “es ja keine Pflicht sei”, so wie man vor 2-3 Jahren den Kunden noch eingeredet hat, dass man für Webseiten eigentlich gar kein HTTPS bräuchte. “Ist ja keine Pflicht. Und was soll schon passieren”


#19

Wobei selbst dieser Fall nur mit einiger Fantasie vorstellbar ist, da laut RFC 2821 für mindestens 4-5 Tage versucht werden sollte eine E-Mail zuzustellen.


#20

Es ist ein breaking change (etwas, was etwas vorher funktionales zerstört), diese Tatsache war vorher bekannt. Es dann nachher mit »wegen Weiterleitung ohne ARC« das auch noch als Schuld des Weiterleitenden darstellen zu wollen – entgegen der Mailversandrealität –, ist dreist. Auch einen Nicht-Standard bei den Nutzern nun vorauszusetzen, ist AFAIK beispiellos.

Fakt ist: funktionierende Weiterleitungen von Forums-Nutzern wurden mutwillig zerstört — diese Auswirkung war vorab klar und dennoch wurden die Einstellungen bewußt gewählt, ohne dies vorab zu kommunizieren.
Das kann Ede gerne auf Edes-Privat-Forum so machen; für forum.freifunk.net erwarte ich zumindest eine Vorab-Info mit Deadline, nicht ein »übrigens, das, worauf Ihr bislang vertraut habt, haben wir gerade absichtlich kaputt gemacht«. Auch die Nutzer haben ihre Zeit nicht gestohlen — genausowenig wie die Admins.

Sicher. Und wenn ab dem 25.05.18 nur noch Mails von/an europäische ccTLDs transportiert werden (wg. gTLD/ICANN/GDPR), so ist das auch nur eine kleine Änderung, die nur einen Prozentsatz der Forennutzer betrifft.

Fake News! SPF, genauer RFC 7208, ist »an Internet Standards Track document«. Dies gilt auch für DKIM aka RFC 6376.

Für DMARC, RFC 7489, hingegen gilt dies schon nicht mehr (»This document is not an Internet Standards Track specification; it is published for informational purposes.«); und ARC hat es bislang in mehreren Jahren nicht mal zum RFC geschafft, der aktuelle Draft expired wie gesagt im Oktober 2018.

Damit ist auch klar, daß man jenseits SPF & DKIM ein Minenfeld betritt und nur konservative Einstellungen vornimmt, sofern man diese Nicht-Standards überhaupt unterstützt — außer, man administriert seinen eigenen kleinen Mailserver, unter dessen obskuren Einstellungen keine Dritten leiden müssen.

Bemerkenswert, diese Arroganz. Ihr macht klammheimlich und bewußt eine Funktion des Forums gezielt für einige Nutzer kaputt – nach wie vor ohne explizite Aufstellung, warum welches gewählte Setting für welches Szenario alternativlos sei –, und dann sollen die Nutzer die Suppe auslöffeln und die Funkion umständich, jeder Betroffene für sich, irgendwie wiederherstellen. Das mag nicht die Intention gewesen sein; so kommt Dein »pfft, dann haben wir Weiterleitungen eben kaputt gemacht — sehe ich eh’ keinen Sinn drin« aber gerade hier an. Nur mal so als Feedback.

Da ich ein wenig Angst vor Deinen 08/15-Lösungen habe, möchte ich darauf eigentlich gar nicht weiter eingehen, aber vielleicht soviel: manchen Account hat man einfach zwangsweise, weil man eine Dienstleistung gekauft hat, und kundenfreundlich, wie manche Anbieter sind, nehmen sie einem die Last ab, eine Zielmailadresse anzugeben und schicken wichtige, vertragsrelevante Dinge an jene Zwangsmailbox. Da kann man dann händisch nachzugucken vergessen, eine Weiterleitung einrichten oder – weil das sicherer ist – einen Sammeldienst beauftragen.

Aber ja, im Grunde ist eMail-Weiterleitung im Forums-Mail-Fall vermeidbar; wenn man das aber nicht mehr unterstützen möchte, ist dennoch der Ablauf »Information vor Umsetzung«, das ist hier nicht erfolgt.

Steile These. Privat mache ich SPF; DKIM schon nicht mehr, weil mir das nicht hinreichend zielführend scheint (Oversigning, Subject-Änderungen z. B. durch Mailinglisten, …). ARC im Draft-Zustand, davon würde ich auch beruflich die Finger lassen — was es nicht mal zum RFC geschafft hat, hat auf professionell betriebenen Systemen nichts verloren. (Daß Google das schon implementiert hat, liegt aus meiner Sicht in der Miturheberschaft Googles; hier versucht G wieder einmal, über die normative Kraft des Faktischen, Fakten in seinen Sinne zu schaffen.)

Erm, ja; aber wenn Dein Mailserver, so wie meiner :smile:, sehr innovative Tests macht, und die Mails z. B. vom Bundestag mit 5xx ableht, weil diese von apache@bundestag.de kommen, der MX für bundestag.de aber Mails an apache@bundestag.de nicht annimmt (mit 5xx-Code; sender-adress verification ist ein sehr schöner Test mit, leider, hohem Mißbrauch­potential), dann nützt Dir die Haltezeit nix, denn bei 5xx geht die Mail direkt zurück an den Absender (oder auch nicht, denn mein Mailer hat die Annahme ja gerade verweigert, weil eine Fehlermail nicht an den angeblichen Absender geschickt werden könnte).