Mailbox.org - Neuer sicherer Maildienst

Es geht nicht um die Client zu Server Verschlüsselung (siehe #4).

Ich geb' mich geschlagen. :hum:
 
Zusammengefasst: Durchgehende Transportverschlüsselung ist gewährleistet durch RFC6698 (da sind dann keine Relays dazwischen) und wenn nicht, bekommst du bei Nichtzustellung einen Bounce und kannst wechseln.

Und genau das ist doch der Blödsinn! Wenn eine Verschlüsselung nicht gewährleistet ist, wird meine Mail nicht zugestellt und dann? Soll auf unverschlüsselt wechseln? Dann kann ich gleich auf Verschlüsselung verzichten.

Und zu DANE und DNSSEC: das garantiert bzw. schützt auch nur vor veränderten Zertifikaten. Wenn ich als Mailprovider einen Server hinstelle und den als Mailserver-Empfänger so einrichte, dass er der letzte im Knoten ist, richtigen DNSSEC eintrage, etc. pp. danach aber die Mails in meinem Netzwerk wieder unverschlüsselt weiterleite, bringt das auch nur bedingt was.

Und ja, du siehst richtig. Ich betrachte das vorrangig für meinen "Teller", wie jeder andere auch. Wir reden hier über einen Anbieter und nicht über eine grundsätzliche Struktur, dann wäre das was anderes. Aber wenn ich eine Dienstleistung in Anspruch nehmen will, die mich was kostet, dann betrachte ich das nur für meinen Anwendungsfall, weil für diesen Anwendungsfall muss ich entscheiden, ob das in Frage kommt oder nicht.

Ich fasse mal zusammen:

1. erzwungene Verschlüsselung ist kein Alleinstellungsmerkmal, andere Provider machen das auch
2. Für die veranschlagten Kosten bekomme ich bei anderen Anbietern mehr Leistung (z.B. Exchange-Postfach)
3. eine durchgehende Verschlüsselung ist nicht gewährleistet
4. Daten liegen unverschlüsselt auf den Servern von mailbox.org
5. Standardmäßig ist auch bei mailbox.org nicht der sichere Weg aktiviert (muss extra über Konfigurationsoberfläche gemacht werden)
6. Erhöhter Organisationsaufwand, da ich Mails über den sicheren Weg nochmals kontrollieren muss, ob die auch wirklich angekommen sind

Fazit: eine nette Idee mit gutem Ansatz, für mich kommt das nicht in Frage, da es a) zu teuer ist und b) die beworbenen Features keine gesonderten Alleinstellungsmerkmale sind.

Viele Grüße
Martin
 
Ich jedenfalls rede über den Anfang einer Struktur um das Internet wieder »zurückzuholen«.
Das allein technisch zu lösen, reicht sicher nicht.

Nur noch zu 1.: Nenne bitte Einen.
 
Dachte ich mir schon, kann ich aber nicht gelten lassen, denn das passiert nur bei im Mailverbund Beteiligte.

Weil (aus deinem CCC-Link): "Unklar bleibt dabei, ob auch andere Anbieter – so wie etwa der von erfahrenen Nutzern selbst betriebene Mailserver – von diesen verschlüsselten Verbindungen profitieren können."

Und (aus Heise-Link): »Kleinhoster bei United Internet müssen sich vertraglich verpflichten, den MX-Record nicht zu einem "unsicheren" Provider umzubiegen. Dafür können sie auch damit werben, "E-Mail made in Germany" einzusetzen.«

Freilich ist das eine Lachnummer.

OK und wenn ich mir den CCC-Artikel durchlese wird mir auch klar, wie die "Gegenargumente", auch hier, zustande kommen.

Und hier noch was zu DANE, falls es jemanden interessiert:
https://www.afnic.fr/medias/documents/Dossiers_pour_breves_et_CP/dossier-thematique12_VEn1.pdf
 
Zuletzt bearbeitet:
Unverschlüsselte Mails können sicher transportiert werden, weil die komplette Transportstrecke verschlüsselt wird.
Bei dem Satz musste ich erst einmal breit grinsen. Wenn du dich dabei besser fühlst: Bitte.
Aber hast du dich mal gefragt, warum wirklich sensible Daten von Firmen und Behörden, müssen sie denn per E_Mail verschickt werden, beim Absender per Hand verschlüsselt und beim Empfänger per Hand entschlüsselt werden? Und das meist per Key, der nur den beiden Beteiligten bekannt ist.
 
So, dann wird das also nach 27 Posts ein "ich wiederhole mich-Thread". :heul:

Post #14, erster Satz: »Es geht mir um das grundsätzliche Mitschneiden unberechtigter Dritter.«

Post #14, letzter Absatz: »Nämlich die Möglichkeit zu bekommen, Mails zu verschicken, die keine großartige, aber umständliche Verschlüsselung erfordern, wie z.B. Angebote.«

Der Nächste bitte... :crack:
 
Kann ich nicht gelten lassen, denn das passiert nur bei im Mailverbund Beteiligte.

Ist bei mailbox.org aber nicht anders. Der einzige Unterschied ist, dass mailbox.org die Mail nicht zustellt, wenn es nicht verschlüsselt geht. Insofern muss man aber mailbox.org zu Gute halten, dass sie zumindest versuchen Mailserver, die nicht im Verbund sind, verschlüsselt anzusprechen. Das machen die anderen nicht. Damit steigt zwar die Zahl derer, wo eine verschlüsselte Verbindung klappt, insgesamt sicherer macht es das auch nicht.

Telekom & Co geht da einen restriktiveren Weg: sie garantieren die Veschlüsselung nur im Verbund, weil sie da sicher sein können, dass es wirklich verschlüsselt abläuft. mailbox.org sieht das etwas lockerer und geht den Weg, wenn jemand Verschlüsselung anbietet, dann nutzen sie das auch.

Ich finde mailbox.org ja nicht schlecht, im Gegenteil, eigentlich ist es eine gute Sache. Aber: ich mag es überhaupt nicht, wenn man durch Marketing Kunden vermeintliche Sicherheit vorgaukelt. Mir fehlt da insgesamt noch mehr Transparenz.

Ein wirkliches Alleinstellungsmerkmal wäre, die Mails verschlüsselt abzulegen. Warum macht das eigentlich keiner?

Viele Grüße
Martin

P.S.: Ich bin schon lange weg vom selbst betriebenen Mailserver. Der Aufwand für Pflege, Wartung und Sicherheit ist zu hoch für mich und mehr Sicherheit gewinne ich dadurch auch nicht. Im Gegenteil, die Gefahr, dass ich meinen Server nicht so gut absichere wie ein großer Provider ist sogar höher.
 
So, dann wird das also nach 27 Posts ein "ich wiederhole mich-Thread".

Post #14, erster Satz: »Es geht mir um das grundsätzliche Mitschneiden unberechtigter Dritter.«

Post #14, letzter Absatz: »Nämlich die Möglichkeit zu bekommen, Mails zu verschicken, die keine großartige, aber umständliche Verschlüsselung erfordern, wie z.B. Angebote.«

Sehr schön, dann wiederhole ich auch mal was.
Du behauptest doch, dass diese Übertragung absolut sicher ist (und das ist ja nicht Anhängig vom Inhalt). Warum gerade ein Angebot eine sache sein soll, die nicht "umständlich" verschlüsselt werden soll, musst du mir mal erklären.
 
Ist bei mailbox.org aber nicht anders. Der einzige Unterschied ist, dass mailbox.org die Mail nicht zustellt, wenn es nicht verschlüsselt geht. Insofern muss man aber mailbox.org zu Gute halten, dass sie zumindest versuchen Mailserver, die nicht im Verbund sind, verschlüsselt anzusprechen. Das machen die anderen nicht.

Ein wirkliches Alleinstellungsmerkmal wäre, die Mails verschlüsselt abzulegen. Warum macht das eigentlich keiner?

Sie sind nicht in einem Verbund und das nenne ich ein Alleinstellungsmerkmal.

Verschlüsseltes Ablegen im Dateisystem, falls du das meinst, ist schon lange üblich (bei uns dm-crypt mit luks).

Sehr schön, dann wiederhole ich auch mal was.
Du behauptest doch, dass diese Übertragung absolut sicher ist (und das ist ja nicht Anhängig vom Inhalt). Warum gerade ein Angebot eine sache sein soll, die nicht "umständlich" verschlüsselt werden soll, musst du mir mal erklären.

Das sind oft z.B. Anforderungen von Firmen, die an mich gestellt werden, weil Mailver-/entschlüsselung oft fehlschlägt, gerade bei Erstkontakt oder wie gesagt zu umständlich ist.
Das jetzt genau zu begründen, halte ich ehrlich gesagt, in diesem Thread für überflüssig.

Hat Posteo nicht diese Verschlüsselung?
Ich bin allerdings nicht der Profi auf diesem Gebiet.

Sehr schön. Posteo hat eine Liste, mit welchen Gegenstellen transportverschlüsselt wird.
Aber keine Wahlmöglichkeit es bei unbekanntem Ziel zu versuchen.
 
Verschlüsseltes Ablegen im Dateisystem, falls du das meinst, ist schon lange üblich (bei uns dm-crypt mit luks).
Und, was soll das für den Kunden an Sicherheit bringen bei einem externen Dienstleister?!

Sehr schön. Posteo hat eine Liste, mit welchen Gegenstellen transportverschlüsselt wird.
Aber keine Wahlmöglichkeit es bei unbekanntem Ziel zu versuchen.

Bei der man sieht, wie schon in #2 erwähnt, dass jeder Bauern-Provider das mittlerweile kann. Ja, deine tolle Wahlmöglichkeit... Wenn du sagst, du kannst 50% der Mails nicht verschicken, weil die Gegenstelle kein TLS kann, soll das praxistauglicher sein als "richtige" Ende-zu-Ende Verschlüsslung (oder die eigene Infrastruktur die du ausschließt)?

Versteh mich nicht falsch. Ich freu mich über jeden Provider der Jahre zuspät TLS einführt, aber ich versteh nicht, was _die_ Neuerung ist, die du uns hier verkaufen willst? Wenn man richtige Verschlüsslung will, gibts nur Ende-zu-Ende Verschlüsslung, und TLS ist, anders als du in #4 behauptet seit Jahren nichts neues, auch bei Server-zu-Server-Kommunikation. Und, wie du siehst, .. wenn nicht jeder mitmacht, hast du von TLS nichts, solange es genügend Kunden gibt, denen das scheiß egal ist. Und dann kannst du auch sofort Ende-zu-Ende verschlüsseln.

Ich meine, was mich gerade "nervt" an der ganzen Diskussion seit Monaten ist, dass hier so viele kleine Startups/Firmen ankommen und nur groß von Sicherheit schreiben (und das reicht schon aus um Kunden zu bekommen), und sofort so viele Leute dahinströmen, obwohl das bei anderen seit Jahren Stand der Dinge ist. Und das ganze ist oftmals völlig intranspartent, weil Closed Source etc. Wo ist da der Gewinn?
 
Das sind oft z.B. Anforderungen von Firmen, die an mich gestellt werden, weil Mailver-/entschlüsselung oft fehlschlägt, gerade bei Erstkontakt oder wie gesagt zu umständlich ist.
Das mag in deiner Welt so sein, in meiner ist das anders.
Ich arbeite in einer großen Behörde und bei uns ist die Vor-Ort Ent- und Verschlüsselung mit einem Key vollkommen normal und sogar Vorschrift. Bestimmte Daten darf ich gar nicht anders nach aussen versenden. Da schlägt nichts fehl. Da sind eher mal Mitarbeiter, die mit der Kryptsoftware Probleme haben. Aber das kann man schnell vor Ort klären.
Wobei die Verschlüsselung auch nur nach aussen wirklich notwendig ist. Ansonsten greifen die Mechanismen des Intranets.
 
Verschlüsseltes Ablegen im Dateisystem, falls du das meinst, ist schon lange üblich (bei uns dm-crypt mit luks).

Korrigier mich, wenn ich da jetzt falsch liege, aber dm-crypt verschlüsselt "nur" das Dateisystem wie bei FileVault. Wenn der Server in Betrieb ist und sich jemand einhackt, dann kann er die Mails lesen, da diese als Klartext auf der verschlüsselten Festplatte abgelegt werden, richtig?

Das meine ich nämlich nicht, denn verschlüsselte Festplatte sind mittlerweile fast überall Standard. Ich meine, warum niemand die E-Mail selbst verschlüsselt ablegt. Technisch müsste das ja lösbar sein.

Viele Grüße
Martin

P.S.: posteo.de will genau das anscheinend einführen.
 
Wenn der Server in Betrieb ist und sich jemand einhackt, dann kann er die Mails lesen, da diese als Klartext auf der verschlüsselten Festplatte abgelegt werden, richtig?
Nö. Warum sollten die Mails nicht verschlüsselt abgelegt werden (können)?
 
Und, was soll das für den Kunden an Sicherheit bringen bei einem externen Dienstleister?!

Bei der man sieht, wie schon in #2 erwähnt, dass jeder Bauern-Provider das mittlerweile kann. Ja, deine tolle Wahlmöglichkeit... Wenn du sagst, du kannst 50% der Mails nicht verschicken, weil die Gegenstelle kein TLS kann, soll das praxistauglicher sein als "richtige" Ende-zu-Ende Verschlüsslung (oder die eigene Infrastruktur die du ausschließt)?

Versteh mich nicht falsch. Ich freu mich über jeden Provider der Jahre zuspät TLS einführt, aber ich versteh nicht, was _die_ Neuerung ist, die du uns hier verkaufen willst? Wenn man richtige Verschlüsslung will, gibts nur Ende-zu-Ende Verschlüsslung, und TLS ist, anders als du in #4 behauptet seit Jahren nichts neues, auch bei Server-zu-Server-Kommunikation. Und, wie du siehst, .. wenn nicht jeder mitmacht, hast du von TLS nichts, solange es genügend Kunden gibt, denen das scheiß egal ist. Und dann kannst du auch sofort Ende-zu-Ende verschlüsseln.

Ich meine, was mich gerade "nervt" an der ganzen Diskussion seit Monaten ist, dass hier so viele kleine Startups/Firmen ankommen und nur groß von Sicherheit schreiben (und das reicht schon aus um Kunden zu bekommen), und sofort so viele Leute dahinströmen, obwohl das bei anderen seit Jahren Stand der Dinge ist. Und das ganze ist oftmals völlig intranspartent, weil Closed Source etc. Wo ist da der Gewinn?

Wenn die Platte im Rechenzentrum abraucht, kann man schnell den Rechenzentrumshiwi schicken, um sie zu tauschen.
Der kann dann mit der losen Platte nix mehr anfangen.

Na, jeder "Bauernprovider" kann es ja leider nicht.
Ich will hier gar nichts verkaufen, das siehst du irgendwie falsch. Ich habe auch mit Heinlein nichts zu tun, falls du das denkst.

Ich behaupte doch nicht TLS wäre neu und mailbox.org hätte es als erster, wo liest du das denn alles raus. :kopfkratz:
PFS zu verwenden ist diesbezüglich neu und das btw. stellt Posteo auch falsch dar, ist kein Zusatz zu TLS.
Und deswegen verstehe ich dein "TLS Jahre zu spät einführen" nicht. Du weisst doch offensichtlich halbwegs, was TLS und PFS ist.
Und das "Neue, was ich verkaufen will" habe ich doch jetzt in den vorigen Posts genügend dargestellt.
Postfix ist nicht Closed Source und Heinlein ist kein Startup, mailbox.org ist halt eine neue Marke.
Was da jetzt intransparent sein soll, verstehe ich nicht so ganz. Vlt. sollten sie jedem die Logfiles schicken?
Wen meinst du denn bitte mit "seit Jahren", PFS bauen doch die Provider erst seit kurzem ein.

Warum bist du eigentlich hier, wenn dich alles so nervt?

Das mag in deiner Welt so sein, in meiner ist das anders.

Bei dir ist es so, woanders ist es anders. Und nun... :noplan:

Korrigier mich, wenn ich da jetzt falsch liege, aber dm-crypt verschlüsselt "nur" das Dateisystem wie bei FileVault. Wenn der Server in Betrieb ist und sich jemand einhackt, dann kann er die Mails lesen, da diese als Klartext auf der verschlüsselten Festplatte abgelegt werden, richtig?

Das meine ich nämlich nicht, denn verschlüsselte Festplatte sind mittlerweile fast überall Standard. Ich meine, warum niemand die E-Mail selbst verschlüsselt ablegt. Technisch müsste das ja lösbar sein.

P.S.: posteo.de will genau das anscheinend einführen.

Ja, solange die Kiste läuft, kann root mitlesen.

Technisch kein Problem, kostet nur Kraft (und Geld) und kommt halt erst langsam (wegen Geld :D).

Genau, nur dann haben auch die eigenen Maildienstmitarbeiter keinen Zugriff.
(Ausser die mit den Kundenpasswörtern [wenn man damit verschlüsselt])

Edit: Das hat jetzt mailbox.org optional eingeführt und verschlüsselt via Kunden-PGP-Schlüssel.
(Einen kleinen Haken wegen sent-Folder und Workaround gibt es auch)
 
Zuletzt bearbeitet:
Wenn die Platte im Rechenzentrum abraucht, kann man schnell den Rechenzentrumshiwi schicken, um sie zu tauschen.
Der kann dann mit der losen Platte nix mehr anfangen.

Na, das kann der Kunde eh nicht kontrollieren.
Na, jeder "Bauernprovider" kann es ja leider nicht.
Ich will hier gar nichts verkaufen, das siehst du irgendwie falsch. Ich habe auch mit Heinlein nichts zu tun, falls du das denkst.

Ich behaupte doch nicht TLS wäre neu und mailbox.org hätte es als erster, wo liest du das denn alles raus. :kopfkratz:
PFS zu verwenden ist diesbezüglich neu und das btw. stellt Posteo auch falsch dar, ist kein Zusatz zu TLS.
Und deswegen verstehe ich dein "TLS Jahre zu spät einführen" nicht. Du weisst doch offensichtlich halbwegs, was TLS und PFS ist.
Und das "Neue, was ich verkaufen will" habe ich doch jetzt in den vorigen Posts genügend dargestellt.
Postfix ist nicht Closed Source und Heinlein ist kein Startup, mailbox.org ist halt eine neue Marke.
Warum bist du eigentlich hier, wenn dich alles so nervt?
Ach, was machst du da son großen Unterschied? Obs jetzt 15 Jahre zu SSL sind, oder nur 4 zu D-H ..
Ich hab jetzt schon wie oft gesagt, wann Google FPS eingeführt hat? Und was genau verstehst du an SMTP nicht, dass du da zwischen Mail-Server-zu-Mail-Server und SMTP-Kommunikation unterscheidest? Und hey, mein qmail/exim nutzen ne ziemlich bekannte SSL Lib, und die hat Diffie-Hellman Key Exchange, wenn ich raten müsste seit 2009. Und was muss man da groß konfigurieren... fast nichts?

Mir ist klar was postfix ist, und mir gings ums Prinzip. Das mag jetzt auf deinen Anbieter nicht unbedingt zutreffen, aber ich denke, du hast verstanden was ich meine.
Genau so wie ich verstanden hab, dass es dir um dein "Notfalls besser keine email, anstatt unverschlüsselt" ankommt. Sehr löblich. Aber mal ehrlich, was soll das bringen, wenn du 50% der emails nicht zustellen kannst, und dann ist sie immer noch nicht verschlüsselt abgelegt auf dem Mailserver? Wenn du schon email kaputt machst und so wert auf Verschlüsslung legst, dann kannst du auch besser Ende-zu-Ende verschlüsseln, was jedenfalls theoretisch mit jedem Anbieter geht.

Gut, ich hab alles gesagt, ich bin raus hier.
 
Ach, was machst du da son großen Unterschied? Obs jetzt 15 Jahre zu SSL sind, oder nur 4 zu D-H ..

Ich hab jetzt schon wie oft gesagt, wann Google FPS eingeführt hat?

Und was genau verstehst du an SMTP nicht, dass du da zwischen Mail-Server-zu-Mail-Server und SMTP-Kommunikation unterscheidest? Und hey, mein qmail/exim nutzen ne ziemlich bekannte SSL Lib, und die hat Diffie-Hellman Key Exchange, wenn ich raten müsste seit 2009. Und was muss man da groß konfigurieren... fast nichts?

Mir ist klar was postfix ist, und mir gings ums Prinzip. Das mag jetzt auf deinen Anbieter nicht unbedingt zutreffen, aber ich denke, du hast verstanden was ich meine.
Genau so wie ich verstanden hab, dass es dir um dein "Notfalls besser keine email, anstatt unverschlüsselt" ankommt. Sehr löblich. Aber mal ehrlich, was soll das bringen, wenn du 50% der emails nicht zustellen kannst, und dann ist sie immer noch nicht verschlüsselt abgelegt auf dem Mailserver? Wenn du schon email kaputt machst und so wert auf Verschlüsslung legst, dann kannst du auch besser Ende-zu-Ende verschlüsseln, was jedenfalls theoretisch mit jedem Anbieter geht.

Gut, ich hab alles gesagt, ich bin raus hier.

Meine Güte, es geht darum es zu benutzen und nicht ob es in einer Lib rumschlummert, die du ja auch schon sooo lange eingebaut hast. Das hättest du in deinem arroganten #2 auch schon einbringen können.

Genau einmal und ich habe geantwortet.

SMTP ist SMTP, da unterscheide ich ja nicht.

Nochmal, es ist nicht mein Anbieter, ich bin auch nicht involviert und
keiner macht Email kaputt, weil er evtl. ein bisschen Druck auslöst.
"Ich" möchte unverschlüsselte Mails verschlüsselt transportieren, weil es das zukünftige "Hausmittel"
gegen "Abschnorchler" werden soll und einer muss anfangen und die anderen werden nachziehen.
Vermutlich Posteo fing an, mailbox.org hat es optional erweitert (Alleinstellungsmerkmal: ohne Mailverbund)
und bald kommen die nächsten.
Den Rest spare ich mir, dir ging's ums Prinzip und du bist ja raus.

---

Es war als Ankündigung/News im Sicherheitsforum gedacht.

Wie sich der Thread jetzt entwickelt hat, war von mir *nicht* beabsichtigt.
Deswegen werde ich das in Zukunft auch unterlassen.
 
Zuletzt bearbeitet:
Peer Heinlein hier von mailbox.org:

Ich bin auf die Diskussion gestoßen und wollte mal ein paar Sachen richtig stellen. Ich muß gestehen, das Posting ist etwas länger geworden. Ich habe mir erlaubt, die Antworten auf verschiedene Postings der Übersichtlichkeit halber zusammenzuassen.

Der Ansatz ist ja ganz nett, aber das Problem liegt in der Struktur und Arbeitsweise von E-Mails. Der "klassische" Weg einer E-Mail ist von A -> B -> C -> D.

A ist dein Recher, B ist dein Mailserver, C ist der Mailserver des Empfänger, D ist der Rechner des Empfängers. Was nützt mir also eine Verschlüsselung von A -> B, wenn danach wieder alles offen ist wie ein Scheunentor? Richtig, nichts. Verschlüsselung macht nur dann Sinn, wenn es eine End-To-End Verschlüsselung ist.

Wir bieten dem User ja gerade die Möglichkeit sicherzustellen, daß der Weg B=>C SSL-verschlüsselt ist. Für Profis auch mit verschiedenen Absicherungsstufen.

Das ist ein gehöriger Unterschied und das kann bislang kein anderer Anbieter. Die allerletzte Meile, also C=>D ist der Weg vom Empfangs-Mailserver zum Empfangs-IMAP-Server innerhalb des Netzes des Empfängers. Die Verschlüsselung dort können wir nicht garantieren, das ist richtig.

Aber in diesen Bereichen im lokalen Netz des Providers liegen die Daten zwangsläufig irgendwann klartext rum (es sein denn man nutzt bei uns das vollständig verschlüsselte Postfach, was nochmal ein ganz anderes/neues Feature ist). Darum empfehlen wir ja auch nachdrücklich den weiteren Einsatz von PGP und S/MIME.

Die komplette Transportstrecke also? Wie wollen die das kontrollieren? Das geht nicht. Zudem stellt mailbox.org eine E-Mail nicht zu, wenn der Empfänger-Mailserver keine verschlüsselte Verbindung erlaubt. Das allein ist doch ein enormer Verlust! Versuch mal deinem Geschäftspartner zu erklären, dass du ihm keine E-Mails schicken kannst, weil der seinen Mailserver nicht verschlüsselt hat.

Das Feature kann beim Absenden einer Nachricht ganz bewußt und im Einzelfall aktiviert werden. Siehe: https://mailbox.org/mails-definitiv-sicher-versenden/

Ich meine folgendes: mailbox.org preist als großes Feature an komplett verschlüsselt zu sein. Wenn man dann genauer nachliest, ist das a) nichtmal als Standard eingestellt und b) ist die Chance, wenn man verschlüsselt versendet hoch, dass die E-Mail nicht ankommt.

Wenn ich einem Nutzer per Default die PGP-Verschlüsselung aktiviere -- mit welchem Key soll ich das verschlüsseln? Das geht nicht, das liegt in der Natur der Sache.

Ich versuche es mal anders: was mailbox.org anbietet ist nur halbherzig und nicht vollständig durchdacht. Wenn ich vertrauliche Informationen versenden will und das verschlüsselt, muss sichergestellt sein, dass das von Ende zu Ende durchgehend verschlüsselt ist. Das ist bei mailbox.org nur dann der Fall, wenn a) beide über mailbox.org versenden oder b) alle Stationen dazwischen auch verschlüsseln.

Wir stecken viel Zeit und auch Geld in die Aufklärung unserer User und versuchen zu erreichen, daß möglichst viele möglichst selbstverständlich PGP nutzen. Das SSL-Feature ist ein Behelf für Situationen, wo die Gegenstelle nunmal partout kein PGP kann, man per Mail kommunizieren will/muß und man trotzdem eine gewisse Grundabsicherung sicherstellen will.

Einen Ersatz für PGP ist das nicht und wird von uns so auch nie im Leben gesagt. Wir empfehlen ausdrücklich den Einsatz von PGP.

Siehe dazu: https://mailbox.org/stiftfilm-wie-funktioniert-e-mail-verschluesselung-mit-pgp/

Mailbopx.org nimmt meine Mail verschlüsselt entgegen, die Verbindung ist also dort terminiert.
Dann später (irgendwann), leitet mailbox.org meine Mail an den Empfänger weiter, mit eigener ausgehandelter Verbindung und eigener Verifikation der Gegenstelle.

Und hier ist geanu der Punkt. Es verschiebt sich eibfach nur das "Vertrauen" um einen weiteren Knoten.
Ich als Nutzer habe keine Möglichkeit die Entscheidung von Mailbox.org zu beeinflussen und kann auch die Vertrauenswürdigkeitsentscheidungen nicht beeinflussen.

Doch, genau das kannst Du. Wir bieten den Usern exakt diese Möglichkeit: Sie können ganz genau festlegen, dass eine spezifische E-Mail nur über SSL rausgeht (Profis können auch eine CA- oder DANE-Validierung vorschreiben.).

Da ich als Nutzer keine Möglichkeit habe das zu verifizieren, kann ich genau so gut einen anderen Dienst benutzen.

Doch, genau das kannst Du verifizieren.Ein- und ausgehend kannst Du das steuern -- und ob wir das gehalten haben, steht im Mailheader.

Das ist lein besonderes Highlight. Web.de, gmx, T-Online usw. haben auch gerade genauso umgestellt. Man wird seid 3 Monaten von den Providern, Regelmäßig daran erinnert, wenn man noch ein Zugriff vergessen hat um zu Stellen. Galgenfrist ist glaube ich noch bis März. Das übrings für senden und empfangen.

Es ist schön, daß auch diese Provider ENDLICH eine SSL-Verschlüsselung für den Endnutzer (!) bei SMTP und POP3/IMAP vorschreiben. Andere Provider tun das seit über 15 Jahren (keine Polemik, ist wirklich so). Mit dem hier diskutierten Ansatz von uns, Mails auch zwischen den Providern (!) definiert verschlüsselt zu versenden, hat das rein gar nichts zu tun.

1. erzwungene Verschlüsselung ist kein Alleinstellungsmerkmal, andere Provider machen das auch
2. Für die veranschlagten Kosten bekomme ich bei anderen Anbietern mehr Leistung (z.B. Exchange-Postfach)
3. eine durchgehende Verschlüsselung ist nicht gewährleistet
4. Daten liegen unverschlüsselt auf den Servern von mailbox.org
5. Standardmäßig ist auch bei mailbox.org nicht der sichere Weg aktiviert (muss extra über Konfigurationsoberfläche gemacht werden)
6. Erhöhter Organisationsaufwand, da ich Mails über den sicheren Weg nochmals kontrollieren muss, ob die auch wirklich angekommen sind


Zu 1: Nein, das macht sonst niemand. Zumindest keinen, den ich kenne (und ich bin in Sachen Mail nicht allwissend, aber doch recht gut informiert)

Zu 2: Das kann sein, das ist Geschmacksfrage. Wir bieten ein volles Groupwareoffice inkl. Filesharing und Online-Textverarbeitung.

Zu 3: Es ist bis zum Zielprovider, also insb. durch das Internet, gewährleistet. Wenn ich sicherstellen muß, was der Zielprovider macht, müßte ich ihn aufkaufen.

Zu 4: Bei unserem vollständig verschlüsselten Postfach liegen die Daten nicht unverschlüsselt im Postfach. Wir sind der erste Provider, der das anbietet. Provider, die sagen, sie würden auf verschlüsselten Festplatten speichern, betreiben Augenwischerei. Die verschlüsselten Festplatten sind im laufendne Betrieb 24/7 lesbar geöffnet, sonst könnte der Server nicht arbeiten.

Zu 5: Richtig.

Zu 6: Du kriegst eine Fehlermeldung und zukünftig sogar eine explizite Empfangsbestätigung.

Telekom & Co geht da einen restriktiveren Weg: sie garantieren die Veschlüsselung nur im Verbund, weil sie da sicher sein können, dass es wirklich verschlüsselt abläuft.


Ach, dieses E-Mail-made-in-Germany ist Humbug. Sie machen seit kurzem SSL wie alle anderen auch auf der Welt. Sobald ein Server SSL anbietet, wird das genutzt. 15 Jahre haben sie das NICHT gemacht, nun haben sie "smtpd_use_tls=yes" aktiviert und die Marketing-Abteilung macht einen (sehr guten!) Job. Aber diese Provider verschlüsseln zu allen anderen ISPs jetzt genauso, wie die drei untereinander. Und alle anderen Provider senden zu denen jetzt verschlüsselt. E-M-i-G hatte bislang noch nicht mal ein Konzept um Sicherzustellen, daß sich nicht ein Man-in-the-Middle in deren SSL-Kommunikation reinklemmt. Führt jetzt technisch zu weit, aber wenn man sehr (!) guten informierten Kreisen glauben darf, gab's da keine Absicherung. Ich selbst wurde als Mail-Consultant gefragt, wie man sowas skalierbar realisieren könnte.

Ich hoffe, ich konnte damit zur Aufklärung beitragen.

Peer
 
Zuletzt bearbeitet:
Zurück
Oben Unten