da machst Du es Dir zu einfach. Natürlich werden Daten verarbeitet, auch bei Email. Sobald eine Webseite - egal ob privat oder nicht - dazukommt hast Du zumindest in Deutschland schon Impressumpflicht, manche Emailanbieter erwarten das auch damit Du ihnen was senden darfst. Und sobald Du etwas nicht privates machst (z.B. ein Blog mit nicht rein privaten Informationen) musst Du Dir Gedanken machen.
1 „Gefällt mir“
Bin nun schon fleißig am machen und tun.
E-Mail Hosting bei UD Media geholt, Account bei deSEC erstellt und bei Netcup die Nameserver + DNSSEC DS Records eingetragen.
Das sieht soweit komplett und richtig aus oder? Ich vertraue da komplett auf die grünen Häkchen 
Das nächste wäre die „Sachen“ einstellen damit ich die Domain bei UD Media nutzen kann. Aber ich stehe an. Wo und Was genau muss ich ändern? Auf Netcup finde ich nichts anderes außer DNS Einstellungen wo ich eben den Nameserver von deSEC angegeben habe und die DNSSEC Einträge.
liefert Dir UD Media keine Anleitung was Du im DNS bei deSEC eintragen sollst?
Ah bei deSEC muss ich es eintragen. Hier liegt dann der Fehler. Dachte bei Netcup… aber macht schon Sinn da Netcup ja nichts mehr zu tun hat damit sondern deSEC. Danke dir, ich mach mal weiter.
Jetzt musst du die Netcupdomain bei UD Media als externe Domain bestellen (für 2,40€/Jahr). In den UD Media FAQs steht unter „Was sind externe Domains? Wie können externe Domains bestellt werden?“ wie (gib in der FAQ Suche gegebenenfalls „extern“ ein).
In den Domain DNS Einstellungen in UD Media werden dann die entsprechenden DNS Einträge erzeugt, die du dann in die DNS bei deSEC übernehmen musst (die DNS Einträge bei UD Media kannst du dann löschen, musst du aber nicht.
Da du scheinbar nur einen Mailtarif hast, bräuchtest du, falls du MTA-STS auch haben willst, noch einen kleinen Webspace. Wenn du bei UD Media eingeloggt bist, schau, ob dir ein Flexhosting angeboten wird (bei mir im eingeloggten Account unter „Neuer Tarif“ im Reiter „WordPress-, Shop- & Flex-Hosting“). Dort könntest du dir dann noch einen 1GB Webspace dazu bestellen.
Achja das hatte ich vergessen. Mache ich gleich.
Ja das habe ich schon gesehen, das könnte ich auswählen.
Meinst du macht es schon Sinn das noch zu machen für MTA STS?
Noch was anderes: weißt du ob man pro Postfach 1GB zur Verfügung hat oder zählen die 1GB insgesamt für X Postfächer?
Insgesamt 1GB, die Postfächer müssen dann dementsprechend aufgeteilt werden. Im Flexhostingtarif könntest du den Mailspeicherplatz deinen Bedürfnissen entsprechend recht kostengünstig erweitern (bei mir 0,10€/GB).
Macht es Sinn DNSSEC und DANE zu haben? Wenn du dies bejahst, könnte auch MTA-STS prinzipiell Sinn für dich machen, zumal die Umsetzung recht simpel ist.
Im Detail ist das ganze Thema SPF, DKIM, DMARC, MTA-STS und DNSSEC/DANE dann doch recht komplex und hängt auch sehr von den Serverbetreibern ab, wie es umgesetzt wird. Einiges wurde ja auch hier schon besprochen. Da ich mich seit einiger Zeit bei völliger Ahnungslosigkeit damit beschäftige und immer wieder Fragen für mich auftauchen, habe ich mich mit ChatGPT darüber unterhalten und einige erhellende Antworten bekommen.
Ich werde den Dialog in den nächsten Tagen in einem neuen Thema veröffentlichen.
2 „Gefällt mir“
Ah sehr gut, dann schadet es nicht ein paar GB dazu zu nehmen.
Ok, das werde ich angehen sobald ich die Records hinbekomme.
Nachtrag Nr. 53:
Wieder bisschen gesucht, recherchiert, geärgert, weitergebastelt.
DeSEC sieht nun so aus:
Test von Internet.nl gefällt mir schon wesentlich besser:
Und noch ein Test bei mxtoolbox:
Mit diesen Fehlermeldungen kann ich noch nicht viel anfangen aber werde mal versuchen den MTA STS einzurichten, wenn das auch klappt erstmal eine E-Mail erstellen und diverese Tests machen wie die Zustellbarkeit klappt etc.pp.
Dennoch bei DNS Viz noch immer viele Fehler warum auch immer, keine Ahnung was es bedeuten soll.
(SMTP-)DANE braucht DNSSEC, MTA-STS wird mit DNSSEC sicherer als ohne. SMTP-DANE und MTA-STS kann man durchaus beide nutzen, denn manche Anbieter können nur das eine, andere nur das andere - und viele können es leider auch nur in einer Richtung.
Traurig ist natürlich schon, dass es zwei Standards gibt.
Mittlerweile hasse ich dieses E-Mail Thema abgrundtief.
Mir fehlt zwar jetzt nur noch MTA-STS aber bis dahin war es sehr mühselig, anstrengend und lächerlich. Jede Kleinigkeit muss man recherchieren weil man scheinbar von einer selbstverständlichkeit ausgeht das zu Wissen.
Die DNS Records für MTA-STS sind in deSEC.
Die txt file in /html/.well-known/mta-sts.txt (vorest mit testing und 1 tag max age) ordner
Die subdomain mta-sts.domain.tld besteht, SSL aktiv und als Pfad ist /html/.well-known ausgewählt, in der Auswahl bei UD Media sehe ich nicht explizit die Datei.
Dennoch bekomme ich entweder die Fehlermeldung 403 Forbidden You don’t have permission to access this resource oder Document Root doesn’t exists.
Hätte ich vorher gewusst was auf mich zu kommt… aber ihr habt es mMn so leicht aussehen lassen, leider kann ich bis dato das überhaupt nicht nachvollziehen was daran leicht ist.
Werde den armen UD Media support nochmal um Hilfe bitten damit es endlich mal „komplett“ ist aber sollte in naher Zukunft wieder was nicht funktionieren wars das für mich, wird abgestempelt als „erfahrung auf die ich gern verzichten hätten können.“
Da die Mail Sicherheitstechniken eben nicht selbstverständlich verbreitet sind, muss man sich eben um Einiges selber kümmern. Daher meine Hoffnung, je mehr Leute danach fragen, um so eher wird es eventuell auch kundenfreundlicher umgesetzt. Da du nun schon einmal grundlegendes Interesse daran hast und fast am Ziel bist, nicht aufgeben.
Die Subdomain sollte nicht mit dem well-known Ordner verknüpft ein, sondern mit dem Verzeichnis darüber, in deinem Fall also /html. Der well-known Ordner wird von alleine gefunden.
Wenn ich in der UD Media Domainübersicht auf die Subdomain mta-sts.domain.tld klicke bekomme ich auch die Fehlermeldung 403, das ist wohl normal.
Entscheidend ist aber, dass die Textdatei aufgerufen werden kann, wenn du im Browser https://mta-sts.[domain]/.well-known/mta-sts.txt eingibst und dann die Textdatei dargestellt wird. Vielleicht hilft dir auch der Mailhardener MTA-STS Test.
Immer daran denken, dass es bis zu 48 Stunden dauern kann, bis die DNS Einträge greifen.
Da kann ich dir auf den ersten Blick auch nicht weiterhelfen, würde aber vermuten, dass bei Netcup was mit den DS Einträgen nicht stimmt.
Hättest du deine at Domain bei UD Media direkt, wäre es nicht so kompliziert, dass du noch Netcup und desec unter einem Hut bringen müsstest.
Da relativiert sich auch der at Domainpreis von 16€/Jahr, zumal du bei Netcup + den Preis für die externe Domain bei UD Media auch schon auf 15€/Jahr kommst.
Lebensretter.
Habe ich nun gemacht… es funktioniert.
Gestern bestimmt 3 Stunden dran gesessen und keine Lösung gefunden. Hatte mich an diese Anleitung gehalteb: MTA-STS Guide und hier steht explizit "Der Pfad muss lauten https://mta-sts.domain.de/.well-known/mta-sts.txt
Darum habe ich es so versucht, aber eben ohne Erfolg.
Diese Fehlermeldung ist bei mir nun auch weg mit dem zuweisen nur auf „/“ was du mir empfohlen hast.
Netcup war von all dem das einzige wirklich einfache. Dort habe ich nur stumpf die DS Format Werte die mir deSEC gezeigt hat eingetragen.
Keytag, Algorithm, Digest Type und den DS Digest Key.
Stimmt schon, die 6€ mehr im Jahr für die Domain bei UDMedia hätte kaum einen Unterschied gemacht. Aber ich habe es deswegen so gemacht, weil es hieß die Domain sollte man nicht dort registrieren wo man auch hosted. Netcup Domain + Flextarif (1 ftp benutzer, 1gb webspace, 2gb mail, externe Domain 2,40€) bin ich aktuell auf ca. 28€ im Jahr aber dafür unendlich E-Mails. Das wäre mir mit zB Proton + SimpleLogin deutlich teurer gekommen.
Kannst du mir noch sagen: wenn ich bei meiner mta-sts.txt ein max_age von X monate angebe, was genau bedeutet das. Muss ich nach X Monate es selbst aktualisieren bzw. was muss ich aktualisieren?
Muss ich noch andere Dinge stets aktuell halten/ändern?
Gibt es sonst noch etwas was ich ab sofort immer warten muss oder ist nun alles „einsatzbereit“ und bleibt auch so die nächsten Jahre sofern sich nicht großartig was an den Standards ändert?
das ist Schnee von gestern. Die meisten Clients respektieren TTL (bei Cloudflare ist der Default 5 Minuten) oder verwenden wenige Minuten - schon um Speicherplatz zu sparen. Gemessen an der Frequenz mit der DNS-Anfragen erfolgen reichen schon wenige Minuten für drastische Verbesserungen…
Nein, das definiert nur wie lange maximal gecached werden darf. Musst Du nicht dauernd ändern.
1 „Gefällt mir“
Okay und welche Dauer wäre empfehlenswert? Oder besser gefragt: macht es Sinn nur zB.: 6 Monate zu wählen anstatt ein Jahr? Mir sagt das trotz deiner Erklärung nichts inwiefern das meine E-Mail beeinträchtigen o.Ä. kann.
Und gibt es sonst noch Dinge die ich immer „aktuell“ halten muss oder ist jetzt erstmal alles erledigt?
Habe nun auch schon einiges Tests gemacht, unter anderem deinen „Emailsicherheit - DerTest“ und „Email Test Authentifizierung beim Empfang“ mal sehen was dabei raus kommt.
Andere Tests wie zB MECSA, Internet.nl, checktsl ergaben 97% bzw. 100%.
Gehe also davon aus das nun grundsätzlich alles korrekt eingestellt ist.
https://www.rfc-editor.org/rfc/rfc8461#page-7 sagt mindestens Wochen. Mein Testserver sagt 3 Minuten. Die meisten Server scheinen die Zahl in der einen oder anderen Richtung zu ignorieren. Dass während einem Test (der länger dauern kann) mehrere Zugriffe erscheinen ist selten, bei Google oft nicht am Anfang wo man ihn erwarten würde oder auch mal gar nicht.
Realistisch: das Caching erhöht die Sicherheit nur bei sehr hohem Volumen und nur wenn DNSSEC nicht verwendet wird. Der extra-Roundtrip spielt eher keine Rolle.
Alles klar, dann werde ich noch eine kurze Zeit testen und wenn alles in Ordnung ist stelle ich um auf enforce und 6 monate. Sollte dann für mich erledigt sein.
Bezüglich dmarc: ich habe folgende Regeln gewählt: p=quarantine;sp=reject;np=reject;pct=100;fo=1;adkim=s;aspf=s;
Gibt es Möglichkeiten meinen E-Mail Verkehr vorher ordentlich zu testen ob eine Einstellung wirklich keine Probleme macht weil zB zu streng eingestellt, bevor man die Domain dann für wichtige Accounts nutzt?
Achja und dein Testergebniss kam retour:
Es erhielten die Mailserver Post, die das nach RFC 7672 tun sollten.
Ihr Mailserver verwendet vermutlich RFC 7672 (Postfix: dane) (sehr gut).
Die Domäne im EHLO und in der DNS Rückwärtssuche stimmen nicht überein.
Ihr Mailserver hat eine Mail (FROM/RCPT/DATA) ohne Verschlüsselung
(STARTTLS) übertragen. Selbst wenn er RFC 7672 oder RFC 8461 verwenden sollte, erzwingt er keine Verschlüsselung (nicht gut, aber leider normal).
Ich glaube das war auch 1:1 das Ergebnis welches auch @ToKu bekommen hat bei UD Media. Kann/Soll man hier noch etwas verbessern oder einfach akzeptieren?
Vielen Dank 
DMARC erlaubt auch none und damit nur Reporting. Dafür musst Du halt einen Empfänger aufsetzen und auch gelegentlich draufsehen. Wichtig ist das m.E. v.a. wenn man mehrere Ausgangsserver hat und die nicht gut/einheitlich konfiguriert sind. Bei einer neuen Domäne und Test kannst Du das m.E. auslassen.
Die Rückwärtssuche ist heute nicht mehr so relevant, weil es bessere Möglichkeiten zur Authentifizierung gibt, steht aber immer noch auf vielen Listen. Was die Server oder Dienstleister eingangsseitig wirklich prüfen ist oft ein großes Geheimnis.
Ihr könnt ja UD Media nach ihrer Meinung dazu fragen.
Ich kenne nur einen Anbieter der das adaptiv macht und dabei auch Schmerzen hat - mich selbst. Das zeigt, dass die Orientierungshilfe der DSK geschrieben wurde ohne den Markt zu untersuchen (https://blog.lindenberg.one/AufsichtEmail).
1 „Gefällt mir“
Danke dir für die Erklärung.
Ich habe gestern noch diverse Tests gemacht, unter anderem auch bei mail-tester.com, dort gabs 10/10 Punkte. Dort wird nur eine Kleinigkeit bemängelt.
"Reverse-DNS-Eintrag stimmt nicht mit der sendenden Domain überein Ihre IP-Adresse 194.117.254.66 ist mit der Domain ud26.udmedia.de assoziiert.
Dennoch scheint Ihre Nachricht von mail.ud26.udmedia.de gesendet worden zu sein. Sie sollten den Pointer (PTR-Typ) im DNS und den Hostnamen Ihres Servers gleichlautend anpassen.
Hier die kontrollierten Werte der Prüfung: IP: 194.117.254.66 HELO: mail.ud26.udmedia.de rDNS: ud26.udmedia.de
Der Support von UD Media meinte dazu:
Der Test wird hier nicht korrekt sein.
Die IP auf die man sich verbindet muss mit der IP vom EHLO passen, also hier: 194.117.254.66 == host (mail.ud26.udmedia.de ) == 194.117.254.66Bei einem Forward confirmed reverse DNS wird zu einer IP Adresse der Host ermittelt und danach von diesem Host auch wieder die IP Adresse. Wenn die Adressen dann gleich sind, gilt dies als bestätigt.
Wenn Sie z.B. diesen Checker hier nutzen passt es auch https://www.debouncer.com/reverse-dns-check?ip=mail.ud26.udmedia.de :
FCrDNS test result: 194.117.254.66 resolved to ud26.udmedia.de; ud26.udmedia.de resolved to 194.117.254.66;
rDNS is forward confirmed.
Generic PTR record test result: ud26.udmedia.de not looks like generic.
Verstehe davon zwar wie gewohnt nicht viel, aber ich weiß das ich mich damit nicht beschäftigen muss.
Was mich aber wirklich noch interessiert und auch @ToKu schon hier gefragt hat aber, glaube ich, noch keine Antwort bekommen hat:
Muss man die DS Records, in meinem Fall von deSEC zu Netcup, manuell aktualisieren falls die sich ändern sollten? Also den Digest Key oder irgendwas anderes?
So wie ich die Antwort im desec.io Forum auf die Frage „Renewal of the DS DNSKeys“ verstehe ja. Nur passiert es auf absehbare Zeit nicht und man wird benachrichtigt.
Zu deinen fehlerhaften Einträgen bei NSEC3 bei dem dnsviz Test müsste es doch auch eine Erklärung, entweder links bei den Symbolen und/oder bei den Fehlern im Schaubild geben?
Außerdem könntest du es noch mit hardenize.com, mit zonemaster.net und mit dnssec-debugger.verisignlabs.com überprüfen.
Da der max_age Wert angibt, wie lange ein Mailserver die MTA-STS Policy für eine Domain zwischenspeichern darf, bevor er die Gültigkeit erneut überprüft, heißt im Umkehrschluss, dass wenn du 6 Monate einstellst und du an der Policy etwas änderst, andere Mailserver es erstmal für einen längeren Zeitraum nicht mitbekommen. Daher die Empfehlung für zum Testen kurze und für ein Produktivsystem längere Zeiträume einzustellen. Fragst du ChatGPT wird zum Testen 10 Minuten bis 1Stunde empfohlen und für ein Produktivsystem 6 bis 24 Stunden. In der Beispielpolicy in dem von @Joachim erwähnten RFC Papier steht ein Wert von 604800, also 7 Tage.
Sollte sich, z.B wegen entdeckter Sicherheitslücken, die empfohlene Protokollversion (dein erster Eintrag in der Policy) ändern, ist ein langer Zeitraum eher hinderlich und du solltest dir überlegen mit welchen Zeitraum du leben kannst, bis eine Änderung wirksam wird. Ich persönlich würde dann auch 7 Tage bis maximal 4 Wochen einstellen.
1 „Gefällt mir“
Ok das beruhigt mich, auch zu Wissen das man sowieso benachrichtig wird. Somit ists kein Problem einmal alle paar Jahre? den DS Key zu wechseln.
Verisignlabs alles grün
Zonemaster fast alles grün außer Nameserver und SOA, siehe Screenshot.
Hardenize sieht auch gut aus.
Checktsl 100%
Internet.nl 97%
Und bezüglich DNSViz Fehler: dort heißts bei fast allen „The response had an invalid RCODE (REFUSED). See RFC 1035, Sec 4.1.1“. Ja schön, hilft mir leider nicht weiter 
Habs jetzt auch nochmal geändert nun auf 7 Tage.