Wie wahrscheinlich ist das heutzutage?
Könnte man das auch voraussetzen?
Wie wahrscheinlich ist das heutzutage?
Könnte man das auch voraussetzen?
Aktuell ist das eher unwahrscheinlich, wobei ich den Begriff im Kontext unglücklich finde. Die Mehrzahl der Systeme hat das nicht, viele können es auch nicht ohne weiteres haben.
Das hierbei notwendige DNSSEC wird nicht von allen Domainprovidern unterstützt. Z.B. haben die vielen Firmenmailserver von Hetzner-Kunden kein DANE, sind damit aber in bester Gesellschaft mit vielen anderen Providern.
Aus Sicht des Anbieters ist das hinsichtlich Kosten/Nutzen auch verständlich.
Wenn man das voraussetzt, wird es einsam.
United Internet kann es (wenn auch nicht toll), damit sind ca. 50% der deutschen Bürger adressiert. Es gibt eine Absprache zwischen BfDI und Bundesnetzagentur, dass SMTP-DANE im Katalog der Sicherheitsmaßnahmen (gut zwei Jahre überfällig) sein soll, dann werden die restlichen öffentlichen Emailanbieter nachziehen müssen.
Bei Organisationen sieht es leider eher mau aus (MS ist immerhin auf dem Weg), und DNSSEC ist eine mir unverständliche Hürde. Ja, auch ich musste meine Domain von Ionos zu einem anderen Anbieter umziehen, danach war DNSSEC kein Problem.
5 Beiträge wurden in ein existierendes Thema verschoben: „E-Mail made in Germany“ = „Bullshit made in Germany“?
Hallo @Joachim , ich mutmaße mal das es, bedingt durch diesen Thread, zu einem erhöhten Aufkommen an Email-Sicherheitstests gekommen ist ?
Wenn dem so ist, wäre es nett wenn Du die Ergebnisse der verschiedenen Provider mit uns hier teilen würdest. Mir wäre jedenfalls wichtig zu wissen ob ich (normaler Mailnutzer mit überschaubarem Mailaufkommen) überhaupt eine Alternative hat.
Kann man die Problematik mit dem Setting dane-only oder verify kompensieren? https://kb.mailbox.org/en/private/e-mail-article/ensuring-e-mails-are-sent-securely
Aber nur in Bezug auf deinen eigenen Account, dein eigenes Postfach. Zudem sollte man diese Einstellung nur verändern, wenn man sich ganz sicher ist was man tut!
Könnte man so was auch als Voraussetzung mit der .secure Option ?
Weil die hat ja noch 2 Parameter, was das genau bewirkt war mir nicht klar und wollte dies deshalb auch nicht ausprobieren .
Kann man überhaupt SMTP-DANE als Voraussetzung einstellen?
Ja, aber es war kein öffentlicher Anbieter neu dabei, außer Tuta die ich getestet habe. Tests privater Server veröffentliche ich nicht (abgesehen von meinem eigenen).
Leider sehe ich da keine. Die Werbung suggeriert halt mehr als die Technik hergibt.
Mal angenommen postfix, und mehr Informationen auf https://blog.lindenberg.one/Rfc7672MailcowPostfix. Dane-Only als globale Einstellung führt dazu, dass Mails zu allen empfangenden Servern die das nicht können fehlschlagen. Aber tatsächlich wäre das eine denkbare Alternative ala @dane-only.mailbox.org statt @secure.mailbox.org. Hab ich bisher bei keinem Anbieter gesehen.
Verify und ein DNSSEC-Resolver ist tatsächlich meine Basiseinstellung und die klappt solange ganz gut wie ein übliches vertrauenswürdiges Zertifikat beim Empfänger verwendet wird. Wenn es aufrund eines nur via DANE vertrauenswürdiges Zertifikat scheitert, stellt der Automat diese Domain auf dane-only. Leider ist der Automat nicht so stabil wie ich mir das wünschen würde.
Probier doch bitte, und schick mir die Ergebnisse zusammen mit der Beschreibung und welche Einstelllung das war (also nacheinander testen). Vielleicht werden wir gemeinsam schlau daraus.
bei einem eigenen Server schon, aber s.o…
Soll ich das mal (unabhängig von @anon83163390) übernehmen?
Hinweis:
Der (ausschließlich) verschlüsselte Versand muss bei MBO explizit aktiviert werden!
Mir kommt diese ganze Diskussion in etwa so vor:
Die Tür zur Wohnung ist aus Pappmaché. Und jetzt wird darüber diskutiert, ob das Schloss sicher ist. Ob man es vielleicht mit einem Dietrich aufbekommt oder ob man noch einen Zusatzriegel einbauen sollte.
Daher auch zuvor meine Frage nach dem Bedrohungsszenario von @sambapati.
Der Elefant im Raum ist doch, das vielleicht die Übertragung der E-Mail sicher ist oder auch nicht, aber am End niemand genau weiss, was nach Übertragung los is.
Um ein Beispiel zu liefern: https://www.kuketz-forum.de/t/e-mail-kontakt-mit-gafam-server/3896
Neuerdings muss man auch beim Emailclient vorsichtig sein:
https://www.borncity.com/blog/2023/01/01/sicherheitsrisiko-microsoft-outlook-app-bertrgt-anmeldedaten-und-mails-in-die-cloud/
Das sind doch die entscheidenen Fragen! Da ist die Transportverschlüsselung normal nicht relevant.
Berechtigter Einwand, finde ich.
Trotzdem oder gerade deshalb sollten wir hier die Diskussion nicht als gegenstandslos und damit automatisch überflüssig betrachten. Schließlich hat sich auch dadurch innerhalb der letzten 10 bis 15 Jahre vieles verändert. Die positiven Effekte sind dabei mehr und mehr spürbar. Das heißt aber nicht, dass wir nun beruhigt die Hände in den Schoß legen und uns in unserem Sessel bequem zurücklehnen können.
@Joachim
Gestern habe ich den besagten Test durchgeführt.
wir haben es hier nicht von Deiner Haustür sondern davon, dass Deine Kommunikation - altmodisch Dein Telefon - nicht abgehört werden kann. Das heißt selbstverständlich nicht automatisch dass die Sicherheitsvorkehrungen Deines Anbieters im Rechnezentrum ausreichend sind, und das hatten wir schon oben. Da muss jeder selbst wissen (oder falls vorhanden den Auftragsverarbeitungsvertrag prüfen) wem er vertraut und was er selbst macht.
Das gleiche gilt natürlich auch für die Sicherheit auf dem Client. Da bist Du immer selbst verantwortlich.
Wenn Du Sicherheit willst, dann musst Du überall hinsehen. Das einzige was ich für mühsam bis müssig halte ist sich Gedanken zu machen, was der Kommunikationspartner macht. Der ist für sich selbst verantwortlich. Oder wenn es mir wichtig ist, dann mach ich ihn darauf aufmerksam oder wechsle das Medium.
ja, aber der lief nicht rund, auch für mich Neuland. Siehe Nachricht…
Mich würde das Ergebnis interessieren was da raus gekommen ist, was kann man mit den beiden Optionen nun erreichen?
Ich blicke in diesem Thread nicht wirklich durch, weil dieses Thema mir noch zu hoch ist. Finde aber die Diskussion sehr interessant. Aber so wirklich verstehe ich es nicht.
Jedenfalls sah ich gerade im Forum von mailbox.org, dass jemand dort eine Frage stellte, die auch Thema dieses Threads ist. Oder auch nicht. Jedenfalls hier der Thread:
https://userforum.mailbox.org/topic/6977-secure-kein-dane-smtp
Dort sagt Herr Heinlein, dass die Secure-Adresse DANE SMTP nutzt:
Keine Ahnung, ob das relevant ist und ob das hier zum Thema passt. Denn ich las auch hier, dass es eben um den Empfänger auch geht. Na ja. Dient als Information für euch und vielleicht hilft es euch.
PS: Ich bin nicht derjenige, der im Forum von mailbox.org fragte
Kurz erklärt:
Auf der Versenderseite (hier am Beispiel @mailbox.org, @secure.mailbox.org) ist alles in bester Ordnung. Laut @Joachim soll das hier diskutierte „Problem“ aber empfängerseitig aufgrund fehlerhaft implementierten SMTP-DANE in Erscheinung treten.
Gibt es hier eigentlich ein Update zu?
Anscheinend hat mailbox.org ja wohl eine falsche Implementierung? So etwas sollte man doch schnell korrigieren wollen, wenn das stimmt, oder?
Diese Formulierung ist falsch! MBO hat keine falsche Implementierung. Die Hintergründe für das hier diskutierte Thema sind nicht so klar und eindeutig erkennbar, deshalb läuft alles bis dato Kommunizierte auf Spekulationen hinaus. Direkte Gespräche (wie weiter oben schon erwähnt) werden Klarheit bringen.
Ok. Woher weißt Du es denn, wenn es nicht klar ist?
Schade finde ich nur, dass die seit Wochen das Thema vor sich her schieben und anscheinend nicht behandeln/angehen wollen. Entweder wissen sie es besser, oder es scheint sie aktuell nicht so zu interessieren?
Da werden erstmal Testergebnisse überprüft, weil der Anbieter bestimmt Argumente hat, dass die gelieferten Ergebnisse nicht dem entsprechen was eigentlich vorgesehen ist.
Das da Schlicht nur eine Haken einer Option vergessen wurde, kannst Du getrost vergesen.
Mich intetessiert das auch, aber ich geh deswegen nicht auf die Barrikaden. Das Thema wird nicht vergessen, braucht nur etwas länger.