Re: Viele Mail-Programme anfällig für neue Spam-Tricks

[Werner Flamme]

Bjoern Meier [07.12.2017 10:01]:
> Hi,
> 
> bisher finde ich die Argumentionen hier ziemlich traurig. Alles was ich
> lese ist ein rumgeweine darüber, dass Benutzer sich nicht den Aufwand
> machen sich mit Verschlüsselung auseinanderzusetzen und zur selben Zeit
> äußern sich die Mail-Admins hier auf der Liste, dass Sie nicht gewillt
> sind, selbst den Aufwand zu betreiben. Kein Wunder also, dass Encryption
> nicht vorrankommt und auf Heise Whatsapp als trauriges, aber positives (Es
> ist traurig, weil es ein Beispiel ist, dass mit der eigentlich Problematik
> - der Diversitität - nichts zu tun hat)  Beispiel herhalten muss.

Ich bin in dieser Firma kein Mailadmin.

> Ich finde es erschütternd, dass es hier Admins gibt, die ein Problem darin
> sehen das Ablaufdatum zu überwachen. Mal davon ab, dass das super einfach
> per Skript zu überwachen wäre, erinnert mich z. B. die PSW Group
> automatisch daran.  Ab einer gewissen Menge würde ich dann die Zertifikate
> eh 3 Jahre laufen lassen. Wenn man einen effizienten Prozess hat, kann man
> das alle 3 Jahre schon mal machen. Ich verstehe schon, wer mehr als 500
> Benutzer hat, der steht vor einem komplexen - aber lösbaren -  Problem.

Das Ablaufdatum zu überwachen ist trivial. Die darauf folgende nötige
Aktion ist es nicht.

Das Problem ist sicher technisch lösbar. Ich schrieb von einem
vertretbaren Aufwand. Wir haben einen Mailadmin, der nebebei auch
Webadmin und LDAP-Verantwortlicher ist. Und Gruppenleiter
RZ-Basisdienste. Der hat ganz sicher andere Sorgen, als den Usern den
A... abzuwischen. Das ist bei knapp 1500 Personen (= Usern) hier im Haus
ohnehin etwas aufwändiger.

Wenn die User sich Gedanken über die Problematik machen, finden sie im
Intranet Schritt-für-Schritt-Anleitungen und bei den zuständigen
Kollegen vom Endpointservice auch erfahrene und geduldige Berater und
Unterstützer. Das Zertifikat selbst ist i.d.R. in wenigen Minuten
ausgestellt. Wir haben eine CA, die über den DFN von Telekom CA2
zertifiziert ist, die Sache mit selbstsigniert und ähnlichem Kram
entfällt also.

Aber wir sind nicht dafür da, den Wissenschaftlern hier im Haus das
Denken abzunehmen. Service anbieten ja, und die Installation ist in
wenigen Minuten erledigt. Aber hinterherrennen und zwangsweise
einrichten gibt es hier nicht.

Wie soll ich denn administrativ auch herausbekommen, welcher der x
installierten Mailclients auf dem Client-Host verwendet wird? Soll ich
das Zertifikat bei jedem Client in den jeweiligen Zertifikatsspeicher
prügeln? Woher weiß ich überhaupt, an welchem Rechner der User arbeitet?
Viele haben einen Laptop mit Linux, was von der aktuellen
Arbeitsplatzerfassungssoftware mangels funktionierendem Agent ignoriert
wird. Da kann ich gar keine zentralen Befehle abschicken. Aber arbeitet
der User überhaupt mit dem Laptop oder verbindet er sich eher mit seiner
Windows-VM? Bzw. wo nutzt er überhaupt den Mailclient?

Sicher, technisch lösbar. Nur: mit vertretbarem Aufwand nicht.

> Mir ist klar, dass S/MIME alles andere als elegant ist. Das Problem ist
> nicht S/MIME, sondern der "Trust-Path". Teures Schlangenöl ohne echten
> Mehrwert für die Ende-zu-Ende Verschlüsselung.

Wer S/MIME macht, ohne eine allgemein anerkannte CA dahinter zu haben,
hat andere Probleme... Alternativ gibt es PGP. Wer einen Mailclient hat,
der beides kann, sieht keinen Unterschied. Wer nicht...

> Lediglich meine subjektive Meinung dazu.
> 
> Was die mobilen Geräte betrifft: funktioniert SCEP mit einer MDM für euch
> überhaupt nicht? Bisher hatte ich damit nur gute Erfahrung.

Das funktioniert für die eiFons. Mehr interessiert hier in der Firma nicht.

Ich bin aber kein Firmeneifonbesitzer, also hatte ich den Spaß, mir das
Zertifikat manuell auf Android zu installieren, da ich gelegentlich doch
mal unterwegs Firmenmails lesen muss. Der Spaß bestand zunächst darin,
erst mal eine Software zu finden, die überhaupt mit S/MIME umgehen kann.
Danach musste das Zertifikat in den Zertifikatsspeicher importiert
werden. Und das zu einer Zeit, als Ciphermail noch lange nicht
Ciphermail hieß... Der Aufwand ist für Otto Normaluser nicht zumutbar.



-- 


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20171207/c7549321/attachment.asc>