Hallo zusammen,
ich bin nun seit einigen Jahren überzeugter und zufriedener Kunde bei Mailbox.org.
Vor einiger Zeit bin ich nun auf die Website von Herrn Lindenberg aufmerksam geworden und habe dort den Email-Sicherheitstest mit @mailbox.org und dem auch besonders beworbenen @secure.mailbox.org gemacht.
Das Fazit der mir zugesandten und nachstehend dargestellten Ergebnisse dieses Test entsprach dann aber nicht meiner Erwartungshaltung an die Qualität von @secure.mailbox.org.
@mailbox.org
Analyse Senden von Email
Es erhielten die Mailserver Post, die das nach RFC 7672 tun sollten. Ihr Mailserver verwendet vermutlich RFC 7672 (Postfix: dane) (sehr gut).
Ihr Mailservice sendet eine Fehlernachricht wenn STARTTLS von Servern mit RFC 7672 oder RFC 8461 nicht angeboten wird, aber garantiert keine Verschlüsselung bei anderen (könnte besser sein)
@secure.mailbox.org
Analyse Senden von Email
Ihr Mailserver verwendet kein SNI, also auch kein RFC 7672 oder RFC 8461, und akzeptiert dann vermutlich auch beliebige Zertifikate beim Senden (nicht gut).
Ihr Mailservice sendet eine Fehlernachricht wenn STARTTLS von Servern mit RFC 7672 oder RFC 8461 nicht angeboten wird, aber garantiert keine Verschlüsselung bei anderen (könnte besser sein)
Da ich weit davon entfernt bin das Ergebnis derartiger Test technisch zu bewerten habe ich mich an den Support von Mailbox.org gewandt und den Sachverhalt beschrieben. Der Support antwortete relativ schnell, freundlich und wortreich aber eben für mich auch wieder technisch unverständlich; so dass ich mich an den Betreiber der Website des Email-Sicherheitstest gewandt und um eine Bewertung der Aussagen von Mailbox.org gebeten habe.
Um es abzukürzen. Trotz zweimaligem Hin-und her konnte der Support von Mailbox.org meine Bedenken zum Testergebnis nicht ausräumen.
Denn die Kernaussage dieses Testergebnisses heisst ja: Wenns „secure“ sein soll, dann bessser nicht @secure.mailbox.org benutzen.
Deshalb wende ich mich hier an euch mit der Frage ob es hier im Forum Mitglieder gibt die bei Posteo, Tutanota oder ggf. auch andere Email-Provider gibt die diesen Email-Sicherheitstest auch schon einmal durchgeführt haben und die ein besseres, sprich sichereres Ergebnis bekommen haben ?
Gleich vorweg: Seit rund sieben Jahren bin ich mit MBO vertraut. Parallel dazu kann ich mich gut an die Worte von Peer Heinlein (CEO, mailbox.org) erinnern, die er im Rahmen eines Vortrages (Chemnitzer Linux-Tage) verlauten ließ. Demnach ist die MBO-Mailserver-Infrastruktur von außen nur bedingt auf seine Sicherheit überprüfbar (vgl. hier). Und das ist auch durchaus so gewollt, wie ich aus Peer’s Worten schließen konnte.
Man kann also davon ausgehen, dass die Ergebnisse derartiger Online-Testprozeduren nicht wirklich das tatsächliche Sicherheitsabbild widerspiegeln.
Zudem ist das Feature @secure.mailbox.orgnicht als „Allround-Heilmittel“ in Sachen „Security“ vorgesehen. Damit wird lediglich aber definitiv eine SSL/TLS-verschlüsselte Verbindung erzwungen (vgl. hier).
Zunächst einmal Danke für Deine Antwort und die Tabelle die Du verlinkt hast.
Nehme ich jetzt mal diese Tabelle (Stand 2020) und die Erklärungen der EU-Seite (Stand 29.12.2023) zur Systematik der jeweiligen Bewertungen ergibt sich für mich folgende Frage:
Auf welcher Grundlage wurde diese Tabelle erstellt?
Du schreibst ja selbst:
Das Gleiche gilt dann natürlich ja auch für alle anderen Mailprovider in dieser Liste.
Aber die Wirksamkeit der jeweils implementierten Features und deren korrektes Zusammenspiel ist damit ja nicht bewiesen, oder?
Sofern diese Tabelle dann aber „nur“ auf Basis der werblichen Aussagen der jeweiligen Mailprovider basiert, hat diese Tabelle keine Aussagekraft.Das @secure.mailbox.org kein Allheilmittel ist, hatte ich auch von Anfang an so verstanden. Der erzwungene SSL/TLS Versand im Vergleich zum normalen @mailbox.org ist/war jedoch eine zusätzliche Sicherheit die ich gern genutzt habe. Dafür habe ich auch die entsprechenden S/Mime Zertifikate.
Der Mail-Sicherheitstest sagt jetzt aber leider etwas Anderes aus; womit ich wieder bei meinem ursprünglichen Post bin…
Vielleicht finden sich ja doch noch einige Mitglieder hier im Forum die diesen Email-Sicherheitstest mit ihrem aktuellen Mailprovider machen und dann hier über das Ergebnis berichten?
Da habe ich wahrscheinlich nicht richtig formuliert. Ich meinte nicht das sehr gute Ranking von MBO in dieser Tabelle, ich meinte die Methodik zur Prüfung der Wirksamkeit sämtlicher, jeweils implementierter Systeme und deren korrektes Zusammenspiel bzw. der einfachen Übernahme werblicher Aussagen.
Eine Prüfung von außen ist ja und dies hat der CEO von MBO ja bestätigt wie Du schreibst, nur bedingt aussagefähig und spiegelt nicht das tatsächliche Sicherheitsbild wieder. Basiert die Tabelle auf einer solchen Aussenprüfung wäre sie also…mit Vorsicht zu genießen.
Basiert die Tabelle der EU auf rein werbliche Aussagen (was ich mir beim besten Willen nicht vorstellen kann), könnte man das schon Verbrauchertäuschung nennen.
Wie auch immer. MBO gehört im Hinblick auf Sicherheit sicherlich zu den TOP-Provider im Email Business. Trotzdem hat mich der Email-Sicherheitstest, in Verbindung mit den Antworten des Supports, ziemlich verunsichert. Aber damit muss ich wohl (und kann ich auch) leben.
Nein, heisst es nicht.
Danke Dir für die Zeit die Du Dir genommen hast um mir zu antworten.
Wenn Du damit auf Eigenschaften wie z.B. Festplattenverschlüsselung im Rechenzentrum u.ä. anspielst - klar, das kann man von außen nicht testen und der Auftragsverarbeitungsvertrag von MBO (mailbox.org) ist da in meinen Augen auch dürftig. Da steht „nach Möglichkeit“. Meiner Meinung nach gibt es die Möglichkeit immer, also könnte man auch schreiben „werden immer verschlüsselt“ (und ich schreibe bewusst nicht „grundsätzlich“ weil das bei Juristen und damit in Verträgen „nicht immer“ bedeutet).
Mein Test unterzieht den Emailserver auf Transportebene einem Test in beiden Richtungen. Er testet natürlich keine Festplattenverschlüsselung und er testet auch nicht, ob der Resolver DNSSEC richtig macht. Als Dreingabe schaut er sich auch SPF, DKIM und DMARC an, das können die meisten öffentlichen Anbieter aber einigermaßen, von T-Online mal abgesehen. Da patzen überwiegen private Organisationen.
Insofern ist das natürlich nur ein Ausschnitt aller Sicherheitseigenschaften, aber in meinen Augen der, der sonst nicht beleuchtet wird - auch nicht von der Europäischen Seite. Andere Tests beleuchten fast immer nur die Empfangsseite, weil man für die Sendeseite einen Mitwirkenden beim Sender braucht.
Wenn Du Anhaltspunkte hast, dass der beim getesteten Ausschnitt etwas falsch läuft, dann lass es mich bitte wissen. Das ist Software, die hat auch mal Fehler.
hat wahrscheinlich nur die Empfangsseite getestet. Sonst würde die Eingabe der Adresse/Domain nicht reichen, Du müsstest von dort eine Email senden.
Hmm … . Um den MECSA-Prozess erfolgreich zum Abschluss bringen zu können, ist die Beantwortung der von dort zugesandten E-Mail mit unverändertem Betreff (RQid=*****) zwingend erforderlich. Dient das seitens MECSA tatsächlich nur der Absicherung die Anfrage zu legitimieren?!
dient anscheinend nur der Verifikation. Ich habe für den Dienst auf meinem Server absichtlich TLS-Policy encrypt eingetragen obwohl mein Server dane (die Abkürzungen sind auf https://blog.lindenberg.one/Rfc7672MailcowPostfix erklärt) kann - trotzdem 5 Sterne. Das deutet für mich darauf hin, dass die Sendeseite nicht geprüft wird. Kein Wunder, dafür muss man schon spezielle Software schreiben…
Das sollte (müsste) dann aber auch (deutlich) Erwähnung finden.
Wer hier nicht konkret hinterfragt, läuft Gefahr im Ergebnis Äpfel mit Birnen zu vergleichen.
Das deutet für mich darauf hin, dass die Sendeseite nicht geprüft wird.
Hierzu muss bedacht werden, dass die Eingangsserver regelmäßig eben nicht auch die Ausgangsserver sind.
Beispiel, so findet man die Eingangsserver:
dig mailbox.org mx
;; ANSWER SECTION:
mailbox.org. 7200 IN MX 50 mx-n.mailbox.org.
mailbox.org. 7200 IN MX 10 mx2.mailbox.org.
mailbox.org. 7200 IN MX 10 mx1.mailbox.org.
mailbox.org. 7200 IN MX 20 mx3.mailbox.org.
Wenn ich nun die Email-Header von einer bei mir angekommenen Nachricht von mailbox.org Absender anschaue, ist da nix zu sehen von mx*.mailbox.org, also den Eingangsservern zu sehen. Es wird für den Ausgang ein anderer Server verwendet und bei großen Anbietern kann der wechseln und unterschiedlich konfiguriert sein logischerweise.
Dort steht:
Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151])
Kann man beliebig durchspielen mit andren Anbietern. Dort ists ebenso.
Darüber hinaus: Die DKIM Signatur wird auch im Email-Header gezeigt. Das kann man von aussen sonst auch nicht testen. Könnte man höchstens den DNS Eintrag prüfen, nur bedeutet das noch nicht, dass auch wirklich DKIM auf die Email gestempelt wird.
Was bedeutet dies also für einen Mail-Test?
Der MECSA Test ist der einizg mir bekannte Test, der auch diese Aspekte abprüft.
Einziger Nachteil:
Mir schwant, als würden Ergebnisse gecacht und seien deshalb nicht immer exakt.
@sambapati: Welches Angriffs- oder Bedrohungsszenario hast Du eigentlich?
Du schreibst da nichts neues. Bei mailbox.org wird zum Senden für @secure.mailbox.org ein anderer postfix als bei @mailbox.org verwendet. Zufällig ist der bei @secure.mailbox.org verwendete auch ein Empfangsserver.
Jain. Vermutlich wird hier von MECSA tatsächlich die Antwort verwendet. Ohne Antwort kann man das indirekt aus DMARC schließen, das verlangt SPF und DKIM, allerdings gibt es auch Emailanbieter die das nicht verstehen.
@Joachim/(@all) Nun wird es hier aber wirklich interessant! Das veranlasst mich, im neuen Jahr (vlt. 2./3. KW) mit Peer zu telefonieren. Vlt. lässt sich auf diesem Weg aufklären, warum und wieso es so ist wie es ist.
Ich berichte zu gegebener Zeit gerne an dieser oder anderer Stelle … .
Meine unprofessionelle Meinung:
Ich verwende ausschließlich .secure Adressen und das seit ca. 1 Jahr, ich habe es erst einmal erlebt das eine Mail von mir nicht versendet wurde, weil die Gegenseite keine Verschlüsselungen angeboten hat. Wie oft mit Spam oder Newsletter nicht erreichen, bekomme ich ja nicht mit die Mails werden ja nicht angenommen. Als ich mich mal bei einem Kundendienst erkundigen wollte, warum die zweite domain .secure nicht angenommen wurde und ich diese Verschlüsselungsoption erwähnte, meinte die IT dazu, was das bringen würde, Mailserver würden schließlich immer verschlüsseln.
Mich würde interessieren, wie oft kommt es denn jetzt vor? Meine Erfahrung liegt bei einer Mail, also nicht wirklich viel.
Was würden die Zusatzeinstellungen die man nur auf eigene Gefahr verwenden soll, genau bewirken, würde dadurch mehr Sicherheit entstehen aber auch öfters Übertragungen abgelehnt?
Dazu meine Vermutungen: die meisten Anwender verstehen (noch) nicht, dass es nicht nur Verschlüsselung sondern auch Authentifizierung braucht (jedenfalls gegen aktive Angreifer). Leider gibt es halt keine digitiale Grundausbildung. Ich schreibe das auf https://blog.lindenberg.one/DigitaleSelbstverteidigung#AV und stelle das im Video auf https://blog.lindenberg.one/EmailVideo dar.
Daher klingt eine „TLS-Garantie“ (obligatorische Verschlüsselung) für normale Anwender gut, für mich aber nicht, wenn dabei die Authentifizierung des Empfängers auf der Strecke bleibt. SMTP-DANE (RFC 7672) ist halt auch nur eine opportunistische Verschlüsselung mit Authentifizierung des Empfängers sofern der auch SMTP-DANE anbietet. Mehrwert entsteht also vor allem dann, wenn alle SMTP-DANE können.
Dass Peer / mailbox.org nicht beides gleichzeitig kann ist bestimmt Folge davon, dass Postfix das nicht kann, und niemand Geld in die Hand nehmen wollte, das zu ändern. Weil eben (bisher) zuwenige Nutzer das verstehen und danach fragen.
…und verzichtest damit halt auf die Authentifizierung des empfangenden Servers wo sie möglich wäre.
dto. Das ist heute wirklich selten. Allerdings ist das halt „opportunistisch“. Ein aktiver Angreifer würde versuchen, einen anderen MX zu benennen oder ein STARTTLS zu verhindern, um die Mail abzufangen oder wenigstens mitlesen zu können. Beides wird mit SMTP-DANE verhindert. Entscheidend ist nicht, was brave Mitspieler tun, sondern was die Bösen können.
Irrtum. Spammer senden teilweise auch verschlüsselt, mit SPF und DKIM, inzwischen auch mehrfach (Greylisting hilft also nur noch bedingt). Jedenfalls sehe ich das auf meinem Testserver, der allerdings bisher keine der üblichen Blacklisten verwendet.
Stimmt weitgehend (s.o.) aber berücksichtigt halt keinen Angreifer, aber tatsächlich hast Du eingangsseitig keinen Vorteil von @secure.mailbox.org.
Der Normalbenutzer und leider auch der normale ITler versteht nicht, was schief gehen kann oder wird.
Laut Peer Heinlein (Vortrag über Sicherheitsmechanismen im E-Mail-Verkehr bei den Chemnitzer Linux-Tagen vor einigen Jahren) tat das die SPAM-Community (jedenfalls damals) nicht. Wie es heutzutage konkret aussieht, kann ich natürlich nicht sagen. Aber: Seit ich meinen E-Mail-Account bei MBO unterhalte, bekomme ich keinen SPAM mehr zugestellt.
Die Kontoeinstellungen entsprechen weitgehend der MBO-Standardeinstellung. Ich habe lediglich festgelegt, dass erkannter SPAM nicht sofort (unzugestellt) gelöscht, sondern mit Hinweis darauf zugestellt werden soll. Aber wie schon erwähnt: Ich bekomme keinen SPAM, nunmehr schon seit über sieben Jahren nicht mehr. Ob mir da vlt. was entgeht?!
das hängt leider vom Empfänger ab. Wenn der empfangende Server SMTP-DANE (RFC 7672) kann, dann ist die Sicherheit von @secure.mailbox.org schlechter als die von @mailbox.org, weil die Authentifzierung nicht stattfindet. Kann der Empfänger kein SMTP-DANE, dann ist sie besser, weil zumindest Verschlüsselung erzwungen wird. Das ist natürlich unbefriedigend.
