Hi,
ich hatte bei der Anmeldung eben die Bestätigungsmail im Spam-Ordner und zusätzlich dem Hinweis das Gmail nicht verifizieren kann die die Mail von hier kam, was am fehlenden SPF-Eintrag(1) für die Domain discourse.voss.earth liegt.
Mein Vorschlag wäre den entsprechenden TXT-Record im DNS hinzuzufügen, was automatisch auch das „Schau mal im Spamordner nach“-Problem mindestens stark einschränken sollte.
Wenn man es gerne so gaanz richtig mag, kann man auch noch einen DKIM(2) und DMARC(3) Eintrag setzen.
Tatsächlich würde ich das mit dem SPF-Eintrag aber dringend empfehlen, da solche Mails bei bestimmten Maildiensten zum Teil nicht mal mehr angenommen werden.
Ich kann gerne auch behilflich sein bei Fragen bzw. Erstellung des TXT-Records…
~ben
Vermutlich tut es folgender TXT-Record schon:
„v=spf1 ip4:144.76.67.247 -all“
Ob man hinten das „-“ als Modifier nutzen will, darüber sollte man genau nachdenken. Gibt ja Leute, die nutzen Mail-Weiterleitungen. An der Stelle knallt es dann.
Ich persönlich tue es bei allen ca. 300 Domains, die ich hoste. Aber der möglichen Konsequenz sollte man sich bewusst sein.
Google bietet allerdings noch weitere Maßnahmen an: Meine Website-Inhaberschaft bestätigen - Search Console-Hilfe
Als Mailserver-Betreiber kann ich nur sagen: Das nervt einfach alles wie sau.
Ganz so einfach ist es glaube ich nicht.
Das Discourse läuft in einem Dockercontainer und die IP, die ihr seht ist die des Webservers. Dieser rufst sie dann quasi als Proxy auf. Der Apache läuft in einem LXC Container.
Wenn Discourse nach draussen spricht dann läuft das allerdings über IPMASQ über die Hauptadresse des Servers.
Es gibt also drei Adressen:
Host: xxx.xxx.xxx.xxx (und intern 10.10.10.1)
Webserver: yyy.yyy.yyy (und intern 10.10.10.3)
Discourse: (nur intern 10.10.10.2)
Also müsste der Eintrag dann für xxx.xxx.xxx.xxx lauten, oder?
An dieser Stelle ist nur der public-Mailserver maßgeblich, der von euch verwendet wird. Hintergrund ist ja, dass es an für sich erstmal keinen Mechanismus gibt, der einen Absender dazu zwingt, auch zu beweisen, dass er der ist, für den er sich ausgibt. Also wenn ich jetzt eine Mail abschicke mit info@discourse.voss.earth von meinem Server, dann kann ich das erstmal machen und werde nicht dran gehindert. Im Zuge der Spamabwehr hat man sich allerdings verschiedene Restriktionen überlegt, mit denen man das einschränken kann. Bei spf macht der empfangende Mailserver einen DNS-Lookup und schaut sich von der Absenderdomain den txt-Eintrag für SPF an. Dort wird festgelegt, welche Server Mails für die jeweilige Domain abschicken dürfen (das wäre bei euch mail.voss.earth => 144.76.67.247). In der SPF-Liste würde jetzt mein Server logischerweise nicht drinstehen und von daher landet das mit einer gewissen Wahrscheinlichkeit im Spam. Gewisse Wahrscheinlichkeit deswegen, weil nicht jeder Mailserver SPF-Checks macht und weiterhin auch so ein SPF-Modus wie „Ja, passt nicht. Aber egal, nimm die Mail trotzdem an.“ existiert; softfail nennt man das.
Das klingt erstmal ok. Das Doofe daran ist nur: Sagen wir mal ein Nutzer hätte eine web.de-Adresse in Benutzung und diese Adresse würde automatisch an Google weitergeleitet. Dann würde das für den Google-Mailserver so aussehen, als ob web.de Mails von discourse.voss.earth verschickt. Und ergo würde das, je nachdem, wie restriktiv man SPF konfiguriert, vom Google-Mailserver abgewiesen. Das ist der Grund, weswegen nicht wenige sagen, dass SPF „broken by design“ ist.
1 „Gefällt mir“
Der Discourse verwendet aber soweit ich weiß keinen Relay - jedefalls erinnere ich mich nicht das eingetragen zu haben. Ich schau mal in den Header von einer Mail vom Discourse welche IP da auftaucht. Alternativ schaue ich mal ob ich in Discourse was konfigurieren kann.
OK, ich sehe gerade es ist doch ein Relay eingetragen. Also stimmt, ich muss es nur für die Hauptadresse einrichten.
Genau:
Received: from tigger.m4tr1xx.de (static.247.67.76.144.clients.your-server.de [144.76.67.247])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(No client certificate requested)
Alles richtig 
Tatsächlich empfinde ich das Thema SPF allerdings eher als nützlich. Das mit den Weiterleitungen betrifft aber eigentlich keine Weiterleitungen die „im Postfach“ passieren, also vom User in den Einstellungen eingerichtet wurden (Zumindest trifft das auf GMail zu).
Ein Prefilter in GMail führt allerdings genau zu dem Verhalten -> SPF wird schwierig mit -all.
Ein ~all würde natürlich auch gehen. Ich bin da mittlerweile nur sehr restriktiv geworden
Ich sehe SPF auch „eher als nützlich“ an. Also mein Webserver blockt einiges via SPF, wobei es ggü Blacklisting ein Mückenschiss ist. Aber man muss sich der Problematik halt bewusst sein, was passieren kann, wenn man das restriktiv macht.
