vielleicht erklärt das dein Problem.
Die Erklärung an sich ist ohnehin ganz einfach: Die haben einen falsch aufgebauten SPF-Record in ihrer DNS-Zone, wie man leicht mit diversen "SPF checkers" auch auf verschiedenen Internet-Seiten überprüfen kann (z.B. hier:
https://mxtoolbox.com/spf.aspx). Aber zumindest "bestätigt" dieser Hinweis dann meine Vermutung, daß auch andere MTA (Mail Transfer Agents - also in erster Linie SMTP-Server) sich nicht mit den falschen Daten anfreunden können bzw. wollen.
Hast du deine Sicherheitseinstellungen in diesem Fall ungünstig gewählt?
Was heißt "ungünstig"? Solche Probleme treten ohnehin nur alle Jubeljahre mal auf, wenn jemand den zugehörigen Standard im
RFC7208 nicht korrekt umsetzt und dann kann ich (i.d.R.) auch auf den Empfang von Mails aus solchen Domains verzichten.
Denn dort sind sowohl die verfügbaren Mechanismen wie
include beschrieben (
https://datatracker.ietf.org/doc/html/rfc7208#section-5.2), also auch die Verwendung des
a-Keywords (
https://datatracker.ietf.org/doc/html/rfc7208#section-5.3), die hier wohl korrekt wäre, denn der sendende Server hat den DNS-Namen
kirk.selfhost.de und auch die passenden
A- bzw.
AAAA-Records in der DNS-Zone für seine IPv4- und IPv6-Adresse(n).
Auch die Reaktion auf mögliche Probleme ist im RFC klar festgelegt:
https://datatracker.ietf.org/doc/html/rfc7208#section-8 und bei einem
permerror (
https://datatracker.ietf.org/doc/html/rfc7208#section-8.7) sollen solche Mails eben mit einer
550-Message abgelehnt werden, was mein eigener Mail-Server auch genau so praktiziert ... und der von Google ja dann wohl ebenfalls, wenn Probleme mit GMail-Konten bestehen.
Rätselhaft ist mir hier nur die Ursache für das Fortbestehen des Problems ... entweder man versteht es bei
selfhost.de nicht, worin die Ursache des Fehlers liegt (und seit 2014 ist das ein "offizieller" Standard im o.a. RFC7208) oder man ist der Ansicht, der eigene SPF-Eintrag wäre schon korrekt, man verwende ja andere Mechanismen (DKIM, s.u.) und wer den SPF-Record als falsch ansieht, der kriegt eben keine Mails. Jedenfalls ist so ein falscher Eintrag (zumindest bei meiner Konfiguration im Postfix) eigentlich "schlimmer", als wenn gar kein Eintrag existieren würde.
Dann wäre das Ergebnis "nur"
none oder
neutral und der Absender würde beim ersten Versuch nur mit einem temporären Fehler abgewiesen (sogenanntes "Greylisting") und wenn die Nachricht (von einem korrekt konfigurierten MTA) in einem weiteren Versuch nach mind. 5 Minuten erneut ausgeliefert werden soll, wird sie akzeptiert.
Das ist eine "durchaus übliche" Konfiguration und ich denke nicht im Traum daran, die irgendwie zu schwächen. Die allererste Prüfung bei mir erfolgt anhand eines SPF-Records, denn dabei werden nur minimale Ressourcen benötigt - alles andere ist deutlich aufwändiger (Kryptographie) und auch wenn heutzutage selbst die Spam-Schleudern schon mit SPF und DKIM arbeiten, bietet das doch immer noch einen "Grundschutz" gegen Spam-Versand über "gekaperte" Rechner/Server, deren wirkliche Besitzer damit nichts zu tun haben und "mißbrauchte" Absender-Adressen, nur weil man bei irgendwelchen Leuten im Adressbuch stand/steht und "mitgeerntet" wurde, als das Konto dort kompromittiert wurde.
Bleibt noch die Frage zu klären, ob man bei
selfhost.de noch weitere Mechanismen wie DKIM (
RFC6376) und DMARC (
RFC7489 - was auf SPF und DKIM aufsetzt) verwendet.
Schaut man sich die Angaben dazu in der DNS-Zone an, so werden die Mails von dort wohl tatsächlich signiert:
Rich (BBCode):
vidar:~ $ dig @pri.selfhost.de _domainkey.selfhost.de. txt
; <<>> DiG 9.18.13 <<>> @pri.selfhost.de _domainkey.selfhost.de. txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36873
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;_domainkey.selfhost.de. IN TXT
;; ANSWER SECTION:
_domainkey.selfhost.de. 3600 IN TXT "o=-"
;; AUTHORITY SECTION:
selfhost.de. 345600 IN NS pri.selfhost.de.
selfhost.de. 345600 IN NS sec.selfhost.de.
;; ADDITIONAL SECTION:
pri.selfhost.de. 60 IN A 82.98.82.20
sec.selfhost.de. 60 IN A 185.26.156.9
;; Query time: 20 msec
;; SERVER: 82.98.82.20#53(pri.selfhost.de) (UDP)
;; WHEN: Wed May 24 12:22:35 CEST 2023
;; MSG SIZE rcvd: 124
vidar:~ $ dig @pri.selfhost.de default._domainkey.selfhost.de. txt
; <<>> DiG 9.18.13 <<>> @pri.selfhost.de default._domainkey.selfhost.de. txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42595
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;default._domainkey.selfhost.de. IN TXT
;; ANSWER SECTION:
default._domainkey.selfhost.de. 3600 IN TXT "v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRdAv8Lq83QWmJdNbtlWC/YQ779HyF8B8xz0iOAsy79VNTLrRvnijSwXQYJ9kjs/K6c7UHd4wOduWt" "3cExYo1oFZqrMA4mGJtC1aYVqdgf2z0xkImsPNLAZeIaAcZCPCkdBR4GNtEdZrGV6oXdPG90OlWe5Er4/Ip4yj+uy8V67wIDAQAB;"
;; AUTHORITY SECTION:
selfhost.de. 345600 IN NS pri.selfhost.de.
selfhost.de. 345600 IN NS sec.selfhost.de.
;; ADDITIONAL SECTION:
pri.selfhost.de. 60 IN A 82.98.82.20
sec.selfhost.de. 60 IN A 185.26.156.9
;; Query time: 19 msec
;; SERVER: 82.98.82.20#53(pri.selfhost.de) (UDP)
;; WHEN: Wed May 24 12:26:43 CEST 2023
;; MSG SIZE rcvd: 358
vidar:~ $
- nur erfolgt eine Prüfung der Signatur bei mir eben erst dann, wenn die SPF-Hürde überwunden wurde. Und das ist - wegen des fehlerhaften Aufbaus des SPF-Records - eben nie der Fall ... und wenn ich spekuliere und die GMail-Warnung dieselbe Ursache hat, wohl auch bei Google nicht.
Denn für die DKIM-Prüfung muß die Nachricht auch erst einmal komplett empfangen und "kanonisiert" (in ein definiertes Format gebracht) werden, bevor man den Hash erneut berechnen und mit dem in der Mail (der mit dem öffentlichen Schlüssel aus einem DKIM-Record in der DNS-Zone zunächst mal entschlüsselt werden muß) enthaltenen Wert vergleichen kann, um dann (einigermaßen) sicher sein zu können, daß diese Nachricht über einen Server ausgeliefert wurde, der über den zugehörigen privaten Schlüssel verfügen konnte.
Das ist alles zusätzlicher Aufwand ... und auch wenn in DMARC die SPF-Prüfung erst NACH der DKIM-Prüfung vorgesehen ist (
https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.2), verbietet einem niemand, den SPF-Eintrag auch schon VORHER zu prüfen. Und sofern der - wenn er tatsächlich existiert - ein gültiges Format hat, ändert das auch absolut nichts am Ergebnis - wenn man einen DNS-Server mit Cache befragt, braucht es nicht einmal einen weiteren (externen) DNS-Request für den SPF-Record, wenn (später im Zuge der Ziffer 4 im vorherigen Link) der SPF-Record erneut geprüft wird.
Wobei auch die Einträge in der Subdomain
_dmarc.selfhost.de (wo eine DMARC-Policy ja ihren Platz hätte) für mich sehr seltsam aussehen und damit (afaik) auch eine gültige DMARC-Konfiguration eher unwahrscheinlich ist:
Rich (BBCode):
vidar:~ $ dig @pri.selfhost.de _dmarc.selfhost.de. txt
; <<>> DiG 9.18.13 <<>> @pri.selfhost.de _dmarc.selfhost.de. txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25933
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;_dmarc.selfhost.de. IN TXT
;; AUTHORITY SECTION:
selfhost.de. 2560 IN SOA pri.selfhost.de. hostmaster.selfhost.de. 1684922610 16384 2048 1048576 2560
;; Query time: 19 msec
;; SERVER: 82.98.82.20#53(pri.selfhost.de) (UDP)
;; WHEN: Wed May 24 12:04:09 CEST 2023
;; MSG SIZE rcvd: 87
vidar:~ $ dig @pri.selfhost.de _dmarc.selfhost.de. any
; <<>> DiG 9.18.13 <<>> @pri.selfhost.de _dmarc.selfhost.de. any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47358
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;_dmarc.selfhost.de. IN ANY
;; ANSWER SECTION:
_dmarc.selfhost.de. 86400 IN MX 20 dummy-smtp.selfhost.de.
_dmarc.selfhost.de. 60 IN A 185.26.156.199
;; AUTHORITY SECTION:
selfhost.de. 345600 IN NS pri.selfhost.de.
selfhost.de. 345600 IN NS sec.selfhost.de.
;; ADDITIONAL SECTION:
dummy-smtp.selfhost.de. 86400 IN A 82.98.82.20
pri.selfhost.de. 60 IN A 82.98.82.20
sec.selfhost.de. 60 IN A 185.26.156.9
;; Query time: 15 msec
;; SERVER: 82.98.82.20#53(pri.selfhost.de) (TCP)
;; WHEN: Wed May 24 12:04:21 CEST 2023
;; MSG SIZE rcvd: 163
vidar:~ $
Es gibt also keinen nutzbaren Eintrag für eine DMARC-Policy, denn das wäre nach RFC7489 auch wieder ein
TXT-Record:
https://datatracker.ietf.org/doc/html/rfc7489#section-6.1 und was der
MX- und der
A-Eintrag in der Subdomain
_dmarc.selfhost.de bewirken sollen, weiß ich auch nicht.
Wenn ich also nicht schwer auf dem Holzweg bin (und ich wüßte nicht, wo ich dorthin abgebogen wäre - sollte das so sein, gibt mir sicherlich jemand einen Tipp), sieht das mit der gesamten Mail- und DNS-Konfiguration für die Domain
selfhost.de etwas seltsam aus - or short: it looks a bit strange to me.
Man setzt hier offenbar ausschließlich auf DKIM (was durchaus legitim wäre, wobei man dann bei mir dennoch ins Greylisting läuft), stellt aber parallel dazu auch noch einen ungültigen(!) SPF-Record bereit und der entpuppt sich hier dann als Pferdefuß.
@KunterBunter:
Kannst Du mir auch noch die Quelle dieser Nummer bzw. des Screenshots nennen? Ich bedanke mich zwar für dessen Bereitstellung, würde aber nur ungern einer kreativen Nutzung irgendeines Zeichenprogramms aufsitzen.
