Das Herstellen einer angemessenen Zahl von Kopien dieses Dokuments ist gestattet, jedoch nur für den internen Gebrauch. Zu anderen Zwecken darf dieses Dokument weder kopiert noch reproduziert werden; weder teilweise noch vollständig, nicht elektronisch, mechanisch oder auf irgendeine andere

Weise, ausser mit ausdrücklicher, schriftlicher Genehmigung der SEPPmail AG.

Der Inhalt dieses Dokuments kann möglicherweise verändert worden sein, falls Sie es nicht direkt von der SEPPmail AG erhalten haben. Auch wenn dieses Dokument mit der grössten Sorgfalt angefertigt wurde, übernimmt die SEPPmail AG keine Verantwortung für etwaige Fehler oder Unvollständigkeiten.

Das Benutzen dieses Dokuments beinhaltet die Zustimmung zu dessen Gebrauch ohne

Mangelgewähr und ohne jegliche Garantien. Jeglicher Gebrauch der hier aufgeführten Informationen erfolgt auf eigenes Risiko.

PGP und Pretty Good Privacy sind gesetzlich geschützte Warenzeichen der PGP Corporation, gültig in den USA und anderen Ländern. Java und alle Java-basierten Marken sind Warenzeichen Oracle

Corporation, gültig in den USA und anderen Ländern. UNIX ist ein eingetragenes Warenzeichen unter der Verfügung der X/Open Company, gültig in den USA und anderen Ländern. Microsoft, Internet

Explorer, Windows, Windows NT, Windows 2000, Windows XP, Windows Vista, Windows 7, Windows

8 und Windows 10 sind entweder eingetragene Warenzeichen oder gesetzlich geschützte

Warenzeichen der Microsoft Corporation, gültig in den USA und anderen Ländern. Netscape und

Netscape Navigator sind gesetzlich geschützte Warenzeichen der Netscape Communications

Corporation, gültig in den USA und anderen Ländern. Google Chrome sind gesetzlich geschützte

Warenzeichen der Google Inc., gültig in den USA und anderen Ländern. Alle etwaigen anderen hier aufgeführten Warenzeichen sind Eigentum ihrer jeweiligen Besitzer und werden hier ohne die Absicht der Markenverletzung verwendet.

OpenBSD ist ein Betriebssystem, das unter dem Berkeley Copyright vertrieben wird ( www.openbsd.

org ).

LibreSSL ist eine vom OpenBSD-Team von nicht benötigten Bestandteilen befreite Abspaltung von

OpenSSL und wird unter der OpenBSD Lizenz vertrieben ( www.libressl.org

Der Apache Webserver und Apache Tomcat werden unter dem Apache Software Foundation

OpenLDAP ist eine Implementierung des LDAP, die als freie Software unter der, BSD-Lizenz

ähnlichen, OpenLDAP Public License veröffentlicht wird ( www.openldap.org

GnuPG ist Software, die unter der GNU Public License vertrieben wird ( www.gnupg.org) .

SpamAssassin ist ein Filterprogramm, mit dem unerwünschte E-Mails (Spam) automatisch aussortiert werden können und ist als freie Software unter den Bedingungen der Version 2 der Apache-Lizenz freigegeben ( http://www.spamassasin.org

ClamAV ist ein unter der GPL stehendes von der Sourcefire Inc. ( http://www.sourcefire.com/) entwickeltes Virenschutzprogramm ( http://www.clamav.net) .

Hinweise auf kommerzielle Produkte, Verfahren oder Dienstleistungen, durch Nennung des Produktoder Herstellernamens oder auf beliebige andere Weise, kommen nicht notwendigerweise einer

Billigung, Empfehlung oder Favorisierung durch die SEPPmail AG gleich.

Einfuhr, Ausfuhr und Benutzung dieser und anderer Verschlüsselungsprodukte sind möglicherweise gesetzlich eingeschränkt.

In diesem Dokument vom Verfasser geäusserte Ansichten und Meinungen drücken nicht notwendigerweise jene der SEPPmail AG aus und dürfen nicht zum Zweck der Werbung oder der

Produktempfehlung benutzt werden. Verweise auf Internetadressen sind vor der Drucklegung gründlich geprüft worden. Aufgrund des ständigen Wandels der Internetinhalte kann die SEPPmail AG aber keine Garantie für das Vorhandensein und den Inhalt der angegebenen Quellen übernehmen.

Sollten Sie in dieser Anleitung fehlerhafte Links finden, teilen Sie uns dies bitte unter Angabe des betroffenen Links und der Versionsnummer dieser Anleitung an die Adresse [email protected] mit.

Druck: Mai 2015, CH-5432 Neuenhof

2 Einleitung

Willkommen zur Secure E-Mail Lösung SEPPmail

Das vorliegende Handbuch unterstützt bei der SEPPmail Installation und dient als Referenz der einzelnen Konfigurationsaspekte. Es ist in folgende Teile gegliedert:

Vorwort

Teil I

Teil II

Teil III

Teil IV

Teil V

Teil VI

Teil VII

Teil VIII

Einführung in das Produkt.

Allgemeine Informationen zu kryptographischen Verfahren sowie wichtige

Produktmerkmale der SEPPmail Appliance.

Beschreibung des Produkts

An dieser Stelle wird das komplette Produkt inklusive der Funktionsweise sowie aller Features detailliert beschrieben.

Inbetriebnahme des SEPPmail Secure E-Mail Gateways.

Dies beinhaltet das Integrieren der Appliance in das Netzwerk sowie das

Anpassen der vorhandenen E-Mail- und Netzwerk-Umgebung.

Administrative Aufgaben

Beschreibt die regelmässig anfallenden Aufgaben zur Wartung des

SEPPmail-Systems

Microsoft Outlook AddIn

Beschreibt Einrichtung und Bedienung des zur Steuerung der Appliance kostenfrei zur Verfügung gestellte MS Outlook AddIn

Referenz der Menüpunkte.

Hier werden die Konfigurationsmöglichkeiten innerhalb der Menü-Struktur detailliert beschrieben.

Referenz der Regelwerk Anweisungen.

Hier werden Befehle für individuelle Regelwerk Anweisungen erklärt, wie sie gegebenenfalls zur Integration in komplexe Infrastrukturen benötigt werden.

2.1 Dokumentationsvereinbarungen

Um die Dokumentation übersichtlicher zu gestalten, werden unterschiedliche Schreibweisen und

Symbole verwendet. Eine Übersicht der verwendeten Symbole und Schreibweisen für zum Beispiel

Programmiercode, Menüpunkte oder Schaltflächen ist in der folgenden Tabelle dargestellt:

Hinweis auf mögliche Fehlerquellen oder Abschnitte in denen besondere Sorgfalt bei der Konfiguration notwendig ist.

Wichtiger Hinweis

Kapitelverweis

Home

Sektion

clusertid.txt

Create ruleset

ldap_compare();

Verweis auf ein Kapitel in dieser Dokumentation

Menüpunkt

Sektion

Spezielle Eingabefelder, Eingabewerte oder Ausgabewerte/Dateien

Schaltfläche

Programmiercode

2.2 Sichere E-Mail-Kommunikation durch Verschlüsselung

Grundsätzlich unterscheidet man zwischen symmetrischer und asymmetrischer Verschlüsselung.

Dabei hat jedes Verfahren seine Vor und Nachteile.

Symmetrisch

Bei der symmetrischen Verschlüsselung wird mit einem Schlüssel verschlüsselt. Der

Kommunikationspartner muss für das Entschlüsseln im Besitz des gleichen Schlüssels sein. Das heisst jedoch, für jeden Kommunikationspartner muss ein eigener Schlüssel verwendet werden.

Problematisch dabei ist der sichere Austausch der Schlüssel, sowie das Verwalten der Schlüssel bei vielen Kommunikationspartnern. Diese Art des Verschlüsselns ist wenig rechenintensiv und somit schnell und Ressourcen schonend.

Asymetrisch

Bei der asymmetrischen Verschlüsselung werden zwei Schlüssel verwendet, ein öffentlicher Teil

(public key) und ein privater Teil (private key oder secret key). Dabei gleicht der öffentliche Schlüssel einem Vorhängeschloss, der private Schlüssel dem passenden Schlüssel zu diesem Schloss. Somit muss dem Absender eines zu verschlüsselnden Dokumentes muss nur der „public key“ des

Empfängers bekannt sein. Nur der Empfänger mit dem dazu passenden „privaten Schlüssel“ wird in der Lage sein, das Dokument wieder zu entschlüsseln.

Somit kann der „public key“ ohne weitere Sicherheitsmassnamen an jeden beliebigen

Kommunikationspartner gegeben werden und ist somit mehrfach verwendbar. Dieses Verfahren ist allerdings sehr rechenintensiv und deshalb langsam und Ressourcen raubend.

Hybrid

Mit dem hybriden Verfahren werden die Vorteile aus symmetrischer und asymmetrischer

Verschlüsselung genutzt. So wird das zu verschlüsselnde Dokument Ressourcen schonend und schnell symmetrisch verschlüsselt. Der Austausch des symmetrischen Schlüssels erfolgt mittels asymetrischer Verschlüsselung. Aus diesem Grund hat sich dieses Verfahren für die

Dokumentenverschlüsselung durchgesetzt.

Bei den nachfolgend beschriebenen Standardverfahren S/MIME und openPGP handelt es sich deshalb ebenfalls um hybride Verfahren.

SEPPmail setzt auf verschiedene standardisierte Verschlüsselungsverfahren und bietet dadurch höchste Sicherheit für unterschiedliche Kommunikationspartner. In diesem Abschnitt werden die

Verfahren erläutert, die dabei zum Einsatz kommen.

Die Secure E-Mail-Gateway Appliance SEPPmail entschlüsselt eingehende E-Mails automatisch. Der

Vorgang ist für den E-Mail-Empfänger komplett transparent. Er erhält seine E-Mails unverschlüsselt in seiner Mailbox und liest diese wie bisher, ohne Zusatzaufwand.

Eingehende E-Mails können mit einer digitalen Signatur versehen sein. Bestandteil dieser Signatur ist der öffentliche S/MIME Schlüssel (Zertifikat) des Absenders. Um den Verwaltungsaufwand zu minimieren, speichert die SEPPmail Appliance diese S/MIME Zertifikate nach erfolgreicher Prüfung automatisch, wodurch sie im Anschluss für das Verschlüsseln von E-Mails an die entsprechenden

Kommunikationspartner bereit stehen.

Für den sicheren E-Mail-Versand wählt die SEPPmail-Appliance aus folgenden 5 Methoden die für den Empfänger bestmögliche aus:

1. S/MIME Benutzerverschlüsselung

Sofern auf der SEPPmail-Appliance entsprechendes Schlüsselmaterial vorhanden ist, läuft die

Verschlüsselung mittels S/MIME vollautomatisch ab. Für das Erlangen öffentlicher Schlüssel der

Kommunikationspartner werden diese automatisch aus den S/MIME Signaturen eingehender E-

Mails eingesammelt. Schlüsselpaare für interne Benutzer können auf der SEPPmail-Appliance selbst erstellt oder durch einen öffentlichen Zertifikatsanbieter ausgestellt werden. In beiden Fällen lassen sich die Zertifikate auch automatisiert erstellen. Die SEPPmail-Appliance unterstützt zu diesem Zweck verschiedene Schnittstellen zu öffentlichen Zertifikatsanbietern (CAs).

2. openPGP Benutzerverschlüsselung

openPGP funktioniert nach dem gleichen Grundprinzip wie S/MIME. Auch die openPGP-Schlüssel werden auf der SEPPmail-Appliance verwaltet und E-Mails entsprechend automatisch verund entschlüsselt, sofern das benötigte Schlüsselmaterial vorhanden ist. Im Gegensatz zu S/MIME werden die Schlüssel bei openPGP in der Regel immer selbst erzeugt. Dies liegt in der Tatsache begründet, dass openPGP im Gegensatz zu S/MIME nicht hierarchisch aufgebaut ist. Aus diesem

Grund ist auch ein automatisiertes Einsammeln von öffentlichen Schlüsseln ist im Gegensatz zu

S/MIME nicht möglich.

3. E-Mail Domänen Verschlüsselung

Die SEPPmail-Appliance bietet Ihnen die Möglichkeit, den E-Mail-Verkehr permanent zwischen mehreren E-Mail Domänen zu verschlüsseln. Auch hierfür kommen unterschiedliche Verfahren zum Einsatz

a) S/MIME zwischen der SEPPmail Appliance und Secure E-Mail Gateways andererer

Hersteller

Dabei stellen sich die Kommunikationspartner gegenseitig jeweils Ihren öffentlichen S/

MIME Domänen Schlüssel zur Verfügung. Da hierfür lediglich jeweils ein Zertifikat benötigt wird, und eine vorab Kommunikation der beiden Administratoren notwendig ist, kann in der

Regel ein Self-Signed-Certificate verwendet werden.

b) openPGP zwischen der SEPPmail Appliance und Secure E-Mail Gateways andererer

Hersteller

Dabei stellen sich die Kommunikationspartner gegenseitig jeweils Ihren öffentlichen openPGP Domänen Schlüssel zur Verfügung.

c) per Managed Domänen Services - ohne jeglichen Konfigurationsaufwand - zwischen allen SEPPmail Appliances

Die SEPPmail-Appliances tauschen über den Managed Domain Service vollautomatisiert die jeweils eigens hierfür durch die Appliance bereit gestellten öffentlichen S/MIME

Domänen Schlüssel aus.

Somit wird grunsätzlich jeglicher E-Mail Verkehr zwischen SEPPmail-Appliances automatisch verund entschlüsselt.

Hinweis:

Bei der Verschlüsselung via Managed Domain Service werden auch die

Header einer E-Mail verschlüsselt.

Die für das Mailrouting benötigten Informationen werden ausschliesslich aus dem Envelope bezogen.

4. GINA-Technologie

Bei der GINA-Verschlüsselungstechnologie handelt es sich um ein patentiertes Verfahren. Dabei werden E-Mails nicht bis zum Abholen durch den Empfänger zwischengespeichert, wie es bei anderen Webmail Verfahren üblich ist, sondern vollständig verschlüsselt an den Empfänger ausgeliefert. E-Mails sind bei diesem Verfahren vor Phishing-Attacken geschützt, denn neben dem

Kennwort ist für den erfolgreichen Zugriff auch die verschlüsselte E-Mail selbst aus dem Postfach des Empfängers erforderlich.

Eine GINA-Nachricht enthält die komplette, ursprünglich unverschlüsselte Nachricht - inklusive

Anhänge - in verschlüsselter Form als HTML-Dateianlage. Der Empfänger ruft die Nachricht ab, indem er die verschlüsselte Dateianlage im lokalen Webbrowser öffnet. Diese wird dann über eine sichere SSL-Verbindung (HTTPS) an die SEPPmail-Appliance des Absenders übertragen und dort nach Eingabe eines Benutzerkennworts entschlüsselt und angezeigt. Durch die Kennworteingabe wird die Identität des Empfängers bei jedem Abruf geprüft. Im Gegensatz zum herkömmlichen E-

Mail-Versand können E-Mail-Zustellungen aufgrund der korrekten Authentifizierung des

Empfängers nachgewiesen werden. Die nachfolgende Abbildung zeigt ein Beispiel einer GINA-

Nachricht.

Beispiel einer GINA-Nachricht

5. TLS/SSL Transportverschlüsselung

TLS/SSL bietet eine zusätzliche Sicherheit und ergänzt die bisher beschriebenen

Verschlüsselungsmethoden. Die Kommunikation zwischen der SEPPmail-Appliance und anderen

E-Mail Servern wird in der Standardkonfiguration immer über einen TLS/SSL gesicherten Kanal aufgebaut, sofern die Gegenstelle dies unterstützt.

2.3 Digitale E-Mail-Signaturen

Beim Einsatz digitaler E-Mail-Signaturen wird die verbindliche E-Mail-Kommunikation gewährleistet, indem die Authentizität einer Nachricht verifiziert werden kann. Somit wird sichergestellt, dass eine

Nachricht unverändert beim Empfänger eintrifft und der angezeigte Absender auch dem tatsächlichen

Absender entspricht.

Das Secure E-Mail-Gateway SEPPmail kann E-Mails entweder mit Benutzer- oder mit Firmen-

Zertifikaten signieren. Die beiden Verfahren werden im Folgenden kurz erläutert:

Digitale E-Mail-Signatur mit einem Benutzerzertifikat

Das Signieren von E-Mails mit einem S/MIME-Benutzerzertifikat erlaubt dem Empfänger die

Authentizität der E-Mail mit seinem E-Mail-Client zu prüfen. Damit wird sichergestellt, dass der

Absender authentisch ist und die E-Mail während und nach dem Versand nicht verändert wurde. Bei dieser Methode wird für jeden E-Mail-Absender ein eigenes S/MIME-Zertifikat benötigt.

In der Regel können nur Zertifikate offizieller Zertifikatsanbieter (Trusted CA) automatisiert vom

Empfänger geprüft werden. Aus diesem Grund wird dringend das Verwenden solcher offiziellen

Zertifikate empfohlen. Die SEPPmail-Appliance bietet mit ihren integrierten CA-Connectoren die

Möglichkeit den Bezug von Zertifikaten einiger offizieller Zertifizierungsstellen zu automatisieren.

Alternativ ist das Signieren von E-Mails auch im E-Mail-Client des jeweiligen Absenders möglich. Das

SEPPmail Secure E-Mail-Gateway wird diese E-Mails dann nur noch verschlüsseln. Da sich viele S/

MIME-Zertifikate zum Signieren und Verschlüsseln von E-Mails eignen, kann es sinnvoll sein, solche

Zertifikate zusätzlich auf der SEPPmail-Appliance zu installieren. Dadurch können E-Mails bereits an der SEPPmail-Appliance mit den entsprechenden Zertifikaten automatisch entschlüsselt und somit zum Beispiel zentral archiviert oder auf Viren geprüft werden.

Digitale E-Mail-Signatur mit einem Firmenzertifikat

Das Signieren von E-Mails mit einem S/MIME-Firmenzertifikat erfüllt auf Unternehmensebene denselben Zweck wie das Signieren mit einem S/MIME-Benutzerzertifikat auf Personenebene. Bei dieser Variante wird nur ein einziges Zertifikat für das Unternehmen benötigt. Da S/MIME-Zertifikate grundsätzlich jedoch nur für eine E-Mail-Absenderadresse gültig sind, erhalten alle ausgehenden E-

Mails den gleichen (technischen) Absender. Das heisst alle E-Mails des Unternehmens - egal wer im

Unternehmen der Absender ist - erscheinen beim Empfänger mit derselben E-Mail-Adresse. Daraus resultieren einige Probleme:

Zwar wird beim Empfänger der korrekte Benutzername angezeigt, jedoch wird ein automatisches Erfassen von Kontakten und zugehörigen E-Mail-Adressen nicht mehr wie erwartet funktionieren.

Aufgrund der Häufigkeit, mit welcher diese eine Absenderadresse bei Einsatz dieser

Technologie verwendet wird, besteht eine hohe Wahrscheinlichkeit, dass diese fälschlicherweise als SPAM eingestuft wird.

Das hätte zur Folge, dass bei den meisten Empfängern alle E-Mails des Unternehmens abgewiesen würden.

Non Delivery Reports (NDR) also Informations-Mails welche bei Nicht-Zustellbarkeit erzeugt werden, werden nicht an den ursprünglichen, sondern an den technischen Absender gesendet

...

Fazit:

Diese Art der Signatur ist im produktiven Umfeld absolut nicht zu empfehlen, da über kurz oder lang massive Support Aufwände generiert werden!

2.4 Zentrale Firmen E-Mail Fussnote

Das SEPPmail Secure E-Mail-Gateway kann Ihre E-Mails mit Firmen E-Mail-Disclaimer ergänzen.

Disclaimer werden sowohl im Text- wie auch HTML-Format unterstützt.

Zentrale Firmendisclaimer, können verwendet werden um einheitlichen Text wie zum Beispiel Adresse und Firmeninhaber an E-Mails anzuhängen.

Beispiel im Textformat:

Firma AG - Musterstrasse 1, 1234 Musterstadt - www.meinefirma.ch

2.5 Kompatibilität zu anderen Secure E-Mail Systemen

Aufgrund des Verwendens genormter Techniken und Protokolle lässt sich SEPPmail transparent in jede E-Mail-Infrastruktur integrieren. Alle anerkannten und sicheren Standard-

Verschlüsselungstechniken sind implementiert. Die Kompatibilität zu den gängigen E-Mail-Systemen ist damit sichergestellt und die Installation zusätzlicher Softwarekomponenten entfällt.

Für Empfänger, die keine S/MIME Zertifikate oder openPGP Schlüssel besitzen, kann die GINA-

Technologie für das sichere Übertragen von E-Mails genutzt werden.

2.6 Remote-Administration mittels Web-Portal

Sämtliche Verwaltungsmöglichkeiten des SEPPmail Secure E-Mail-Gateways stehen über eine

Webbrowser basierte Konfigurationsoberfläche zur Verfügung. Die Verbindung zwischen Webbrowser und dem SEPPmail Secure E-Mail-Gateway ist zusätzlich SSL verschlüsselt (HTTPS).

3 Die SEPPmail-Appliance

3.1 SEPPmail AG (Hersteller)

Das in der Schweiz ansässige, international tätige und inhabergeführte Unternehmen SEPPmail ist

Hersteller im Bereich „Secure Messaging“. Dessen patentierte, mehrfach prämierte Technologie für den spontanen sicheren E-Mail-Verkehr (GINA) verschlüsselt elektronische Nachrichten und versieht diese auf Wunsch mit einer digitalen Signatur. Die Secure E-Mail-Lösungen sind weltweilt erhältlich und leisten einen nachhaltigen Beitrag zur sicheren Kommunikation mittels elektronischer Post.

Dadurch maximiert SEPPmail die Kommunikationssicherheit von hunderttausenden von Benutzern.

Das Unternehmen wurde 2001 gegründet und verfügt demnach über eine mehr als zehnjährige

Erfahrung im sicheren Versenden digitaler Nachrichten.

Die Produktphilosophie gründet sich auf zwei Hauptmerkmale: ein Höchstmass an Sicherheit, in

Kombination mit hohen Benutzerkomfort. Zu letzterem zählen insbesondere einen hochverfügbaren

Betrieb mit hoher Stabilität und geringen Administrationsaufwände.

SEPPmail AG hat mit seinem CEO, Herrn Stefan Klein, den „Erfinder“ dieser Lösung on board, der seit 2001 die Entwicklung dieses Produktes betreut und begleitet. Dabei stellte er sicher, dass die

Produktphilosophie über all die Jahre beibehalten wurde. So reifte das Produkt mit den

Kundenanforderungen, wobei die individuellen Anforderungen immer dem Gesamtprodukt beigefügt und somit allen Kunden zugängig wird.

SEPPmail AG

Industriestrasse 7

CH-5432 Neuenhof http://www.SEPPmail.ch

3.2 Vorstellung und Verfahren

3.2.1

Gateway-to-Gateway (Domänen-) Verschlüsselung

Eine Grundfunktionalität aller SEPPmail-Appliances ist der „Managed Domain Service“. Dieser

Service stellt sicher, dass jeder SEPPmail-Appliance jeweils die öffentlichen Domänen Schlüssel aller anderen SEPPmail-Appliances zur Verfügung stehen. Somit kann zwischen den teilnehmenden

Kunden das vollautomatische und transparente Verschlüsseln des gesamten E-Mail Verkehrs von

Gateway zu Gateway (Domänen Verschlüsselung) gewährleistet werden.

Durch den manuellen Austausch der öffentlichen Domänen Schlüssel lässt sich die Domänen

Verschlüsselung auch mit Gateways anderer Hersteller realisieren.

Die beiden Verschlüsselungstechnologien TLS und Gateway-to-Gateway sind Bestandteil der

SEPPmail-Appliance Grundlizenz und müssen nicht per User lizensiert werden.

3.2.2

Produktphilosophie

Die Produktphilosophie gründet sich auf zwei Hauptmerkmale: ein Höchstmass an Sicherheit, in

Kombination mit hohem Benutzerkomfort. Zu letzterem zählen insbesondere ein stabiler Betrieb und möglichst geringe Administrationsaufwände.

Das Produkt unterstützt alle am Markt befindlichen Standard-Technologien (siehe

S/MIME (X.509)

openPGP

TLS

) für das Absichern des E-Mail Verkehrs mittels Verschlüsselung und Signatur.

Darüber hinaus hat SEPPmail ein Verfahren entwickelt und patentiert, welches erlaubt, einem gänzlich

„unbekannten“ Empfänger spontan eine verschlüsselte E-Mail zu senden. Der Empfänger benötigt für das Entschlüsseln sowie dem sicheren Antworten ausschliesslich Standardkomponenten, wie einen beliebigen E-Mail Client (dies kann auch ein Webmail Client sein), einen beliebigen Browser und

Zugang zum Internet, unabhängig vom Endgerät. Wir nennen diese Technologie GINA (siehe

GINA

Webmail

Ein mit der Lösung ausgeliefertes Standard-Ruleset (siehe

Zentrales Regelwerk

) ermöglicht das

100%ige Verschlüsseln aller als vertraulich gekennzeichneten, zu versendenden E-Mails. Dabei wird

über das Ruleset die für den jeweiligen Empfänger beste Verschlüsselungstechnologie ausgewählt.

Beginnend mit der Prüfung, ob ein beglaubigter öffentlicher S/MIME Schlüssel des Empfängers für das

Verschlüsseln zur Verfügung steht, kaskadiert das System über openPGP, Domänen Verschlüsselung

runter bis zur „GINA“ Technologie (siehe

Verschlüsselungshierarchie

). Diese kommt nur dann zum Einsatz, falls kein geeignetes Schlüsselmaterial des Empfängers vorliegt oder vom Versender ganz bewusst - für den Erhalt einer verbindlichen Lesebestätigung - gewählt wird.

SEPPmail besteht aus nur einem Hauptprodukt, welches allen Kunden zur Verfügung gestellt wird.

Einzelne Features, welche von Kunden gewünscht werden und in das Gesamtkonzept in punkto

Sicherheit und Benutzerkomfort passen, werden kostenfrei von SEPPmail implementiert und kommen somit allen Kunden zu Gute.

Die Lösung wird als komplette, auf openBSD basierende Firmware geliefert. Damit entfällt das aufwendige Installieren und Warten von Einzelkomponenten, wie zum Beispiel Datenbanken oder

Funktionsmodulen. Das Update erfolgt auf Knopfdruck für das gesamte System.

3.2.2.1

Fünf generische Prinzipien

1. Angemessenes Absichern der Geschäftsdaten

Das Absichern wird durch den Einsatz bewährter Verschlüsselungstechnologien (S/MIME, openPGP, TLS und GINA) sowie durch eine gehärtete Appliance garantiert.

2. Kosteneffizienter Betrieb

Kosteneffizienz wird durch den Appliance – Ansatz, einen hohen Automatisierungs- und

Standardisierungsgrad und insbesondere einen sehr niedrigen Support Aufwand der GINA-

Technologie im Vergleich zu anderen Methoden (PDF oder Webmailer) erreicht.

3. Hohe Anzahl von Kunden und Geschäftspartnern erreichbar

Den besten Beweis für die „Massentauglichkeit“ der patentiertenGINA-Technologie erbringt der

Dienst „Incamail“ der Schweizerischen Post. Uns ist kein Projekt bekannt bei der mit alternativen

Methoden auch nur annähernd so viele Kunden bedient bzw. so viele E-Mails verschlüsselt werden.

Als stiller Champion stellt sich mehr und mehr die Domänen Verschlüsselung heraus (siehe

Gateway-to-Gateway (Domänen-) Verschlüsselung

). Ein nicht zu unterschätzender Anteil der

E-Mail Kommunikation zwischen Unternehmen wird mittlerweile mittels der völlig transparenten

Domänen Verschlüsselung gesichert.

4. Hoher Grad von Akzeptanz

Auch hier möchten wir wieder auf die GINA-Technologie verweisen. Damit ist eine einfache Zwei-

Weg–Kommunikation möglich. Separate Kommunikationskanäle (PDF zum Kunden – Rückweg

über ein Webportal) sind nicht nötig.

5. Erfüllen der geschäftlichen und rechtlichen Rahmenbedingungen

Bei der GINA-Technologie werden E-Mails generell vollständig verschlüsselt ausgeliefert. Damit gelangt die E-Mail in den 100%igen Einflussbereich des Empfängers. Rechtliche Probleme betreffend vollständiger Auslieferung von E-Mails (Wie dies bei einem „normalen“ sicheren Webmail der Fall wäre) bestehen somit nicht.

3.2.3

Verschlüsselungstechnologien

3.2.3.1

S/MIME (X.509)

Da die SEPPmail-Appliance in der Regel im vollen E-Mail Strom steht (siehe auch Architekturen ->

Im vollen E-Mail Strom

), lernt diese automatisch alle (gültigen!) S/MIME Public Keys (Zertifikate), die

über E-Mail-Signaturen eingeliefert werden. Das heisst die Zertifikate müssen von einer der SEPPmail bekannten CA (Certificate Authority) stammen. Ist die CA nicht bekannt, so wird deren Root Zertifikat automatisiert gesammelt und dem Administrator zur Prüfung vorgelegt (halbautomatischer Vorgang).

Nach Herstellen des Vertrauens in diese CA durch den Administrator, werden auch von dieser ausgestellte Zertifikate automatisiert aus den Signaturen eingesammelt. Erfahrungsgemäss nimmt dieser Aufwand nach einer Einschwingphase des Systems merklich ab, da die meisten Root-

Zertifikate der von den Kommunikationspartnern verwendeten CAs geprüft wurden.

Wird eine als vertraulich gekennzeichnete E-Mail an einen externen Empfänger versendet, prüft das

System erstrangig, ob ein freigegebenes Zertifikat des Empfängers existiert. Die E-Mail wird transparent verschlüsselt und versendet.

Wenn ein intelligentes E-Mail Routing – System beim Kunden vorhanden ist welches signierte und / oder verschlüsselte E-Mails erkennen kann, so können auch gezielt nur die nötigen E-Mails über die

Appliance empfangen werden. Die Appliance muss dann nicht in den vollen E-Mail Strom integriert werden.

3.2.3.1.1 Managed PKI

Die SEPPmail Appliance hat ein vollständiges PKI-System eingebaut und verwaltet User Schlüssel bzw. Zertifikate zentral im System. E-Mail Zertifikate können von beliebigen CAs eingespielt werden.

Zu den wichtigsten CAs stellt SEPPmail jedoch Konnektoren zur Verfügung: aktive Konnektoren

Swiss

CA der Schweizerisschen Post

Sign

SCEP Protokoll, durch welches CAs diverser Hersteller – auch Microsoft – angebunden werden können. Eine gute Kurzbeschreibung ist unter http://www.itwissen.info/definition/lexikon/ simple-certificate-enrollment-protocol-SCEP-SCEP-Protokoll.html zu finden. Dabei handelt es sich jedoch (noch) um keinen Standard (RFC).

legacy Konnektoren (diese Unternehmen stellen den Betrieb Ihrer CAs ein)

S-

CA des Deutschen Sparkassen Verlages (DSV)

Trust

SignTr ust

CA der Deutschen Post in Vorbereitung

A-

Trust akkreditierte Zertifizierungsdiensteanbieter für qualifizierte Zertifikate in Österreich und

Liechtenstein

D-

Trust

Bundesdruckerei (Deutschland)

Über diese Konnektoren können E-Mail- und gegebenenfalls Personen- Zertifikate automatisiert von den entsprechenden CAs bezogen werden. Das jeweils zum Tragen kommende Verfahren kann dabei unterschiedlich sein. In der Appliance werden die so bezogenen Zertifikate den Usern automatisiert zugeordnet und zur Signatur herangezogen.

Der Bezug von Zertifikaten für die E-Mail-Konten ist daher flexibel und individuell konfigurierbar.

Bei Anlage eines neuen Benutzers – dies kann wahlweise automatisch zum Beispiel durch Anfordern von Verschlüsselung oder Signatur, oder manuell erfolgen - kann gewählt werden, ob ein E-Mail

Zertifikat automatisch ausgestellt werden soll. Dieses kann dann von der internen (Sub-)CA oder über

21 die MPKI Schnittstelle bezogen werden. Bei Bedarf sind auch beide Varianten parallel möglich.

Wird das Zertifikat über die MPKI bezogen, so wird das Schlüsselpaar in der Regel auf der SEPPmail-

Appliance generiert und nur der öffentliche Schlüssel zum Signieren an die Trusted CA übermittelt.

Der sensible private Schlüssel verlässt bei diesem Verfahren zu keiner Zeit die Appliance und liegt dort – wie das gesamte Schlüsselmaterial – in einem gesicherten Bereich ab.

Auch das Erneuern der Zertifikate ist vollautomatisiert möglich. Der Zeitraum, wieviele Tage vor Ablauf des alten Zertifikates ein neues generiert werden soll ist dabei frei wählbar.

3.2.3.1.2 Güte eines Zertifikates

Um eine SEPPmail-Appliance mit Zertifikaten zu bestücken, sollte geklärt sein, in welcher Qualität diese gewünscht sind.

SSL-Zertifikat

Zunächst wird für das Absichern der SSL-Strecke, welche durch die GINA-Funktionalität etabliert wird, im Regelfall zwingend benötigt. Damit die gängigen Browser keinen Sicherheitsverstoss melden, sollte dieses Zertifikat von einer offiziellen CA kommen und den FQDN - also den Namen, unter welchem das GINA-Portal zu erreichen ist - beinhalten.

E-Mail Zertifikat

Zertifikate, welche für das Signieren (und Verschlüsseln) von E-Mails geeignet sind, werden in unterschiedlichen Güten von den Ausstellern (CAs) angeboten. Eine einheitliche Klassifizierung gibt es dabei leider nicht. Die Zertifikate unterscheiden sich dabei in Ihrer Aussagekraft.

So wird bei dem einfachsten Zertifikat lediglich die Existenz der E-Mail Adresse bestätigt. Das heisst, mit dieser Art des Zertifikates kann durch die Signatur bestätigt werden, dass die E-Mail während des Transportes nicht verändert wurde von der benannten Absenderadresse stammt

In der nächst höheren Zertifikatsgüte wird zusätzlich der Absender namentlich benannt. Das heisst für das Ausstellen dieses Zertifikates musste sich der Inhaber in irgend einer Form ausweisen. Bei

Einsatz einer MPKI (siehe

Managed PKI

) bestätigt die beantragende Organisation, dass sie nur

Zertifikate für Ihre Mitarbeiter ausstellt. Somit bestätigt dieses zusätzlich die Person des Absenders und dessen Organisation

Diese Zertifikate können für zusätzliche Zwecke verwendet werden, wie zum Beispiel für das Signieren von PDF-Dateien.

Für die Ausstellung eines qualifizierten Zertifikat (wie z.B. beim Personalausweis in D oder SuisseID in

CH) muss eine face-2-face Kontrolle (z.B. PostIdent in D) durchgeführt werden. Eine automatische

Ausstellung über eine

Managed PKI

ist somit unmöglich!

Selbst signierte Zertifikate sind für das signieren von E-Mails ungeeignet, da die Zertifikatskette beim

Kommunikationspartner in der Regel nicht bekannt ist und somit kein Vertrauen hergestellt werden kann.

3.2.3.2

OpenPGP

Zur nachteiligen Natur von openPGP Schlüsseln gehört, dass diese - bevor sie für das Verschlüsseln herangezogen werden können - zuerst validiert werden müssen. Somit ist ein automatisiertes Prüfen nicht möglich (Prinzip: web of trust). Theoretisch müsste daher bei jedem zu importierenden

öffentlichen openPGP Schlüssel über einen separaten Kanal der Fingerabdruck (Hash) des

Schlüssels geprüft werden. SEPPmail hat ein "umgedrehtes" Verfahren realisiert: Wenn der

Empfänger eine GINA-E-Mail (siehe

GINA Webmail

) erhält, so wird ihm darüber auch die

Möglichkeit gegeben, den eigenen öffentlichen Schlüssel - egal ob openPGP oder S/MIME - auf die

Appliance hochzuladen. Durch die vorangegangene Authentifizierung des Empfängers durch E-Mail und Initial-Passwort am GINA-Web-Interface ist kein zusätzliches Validieren durch die Administration oder den Sender notwendig.

3.2.3.3

LDAP Key-Lookup für S/MIME und OpenPGP

Eine LDAP Lookup Funktionalität ist in der Lösung integriert. Beim Erfassen von Key Servern ist allerdings auf die Qualität dieser zu achten. Häufig wird über "öffentliche" Key Server „totes“

Schlüsselmaterial verbreitet. Verwendet der Absender dieses Material, so kann der Empfänger die damit verschlüsselte E-Mail unter Umständen - mangels privatem Schlüssel - nicht lesen.

3.2.3.4

TLS

SEPPmail nutzt im Normalfall „opportunistisches TLS“, sprich TLS (mit der jeweils höchstmöglichen

Verschlüsselung) wird benutzt, wenn dies vom gegenüberliegenden E-Mail Server bzw. MTA (Mail

Transfer Agent) unterstützt und angeboten wird.

Zusätzlich können für einzelne E-Mail Domänen und/oder E-Mail Server spezifisch TLS – Level erfasst werden. (mit den Postfix – typischen Stufen „may“, „verify“, „secure“, „fingerprint“ und bald auch

„dane“).

TLS „gezielt“ als Ersatz für eine Verschlüsselung von E-Mails zu verwenden erscheint schwierig, und zwar primär aus folgenden Gründen:

Bei Verwenden von TLS wird maximal bis zum nächsten MTA verschlüsselt. Da immer mehr

Firmen Cloud–Dienste für das Filtern von Spam E-Mails verwenden, reicht dies normalerweise nicht

Eigentlich darf TLS nur bei Einsatz der Sicherheitsstufe „Fingerprint“ oder „DANE“ als einigermassen sicher betrachtet werden. Alle anderen Sicherheitsstufen sind - zum Beispiel durch DNS Spoofing - aushebelbar

Das Verwalten von TLS Verbindungen erzeugt hohen Administrationsaufwand

Trotz dieser Nachteile erfreut sich TLS in letzter Zeit steigender Beliebtheit – wahrscheinlich weil TLS als „kleinster gemeinsamer Nenner“ auf praktisch jedem MTA verfügbar ist. SEPPmail plant deshalb auch, den TLS – Support zu erweitern.

3.2.4

Verschlüsselungshierarchie

Das von SEPPmail initial zur Verfügung gestellte Standard-Ruleset gibt für E-Mails die folgende

Vorgehensweise vor:

Wurde eine E-Mail als zu verschlüsselnd markiert, so wird diese „best effort“ behandelt. Dabei wird nach folgender Wertigkeit vorgegangen:

1. Geprüftes S/MIME Zertifikat des Empfängers

2. Geprüfter öffentlicher openPGP Schlüssel des Empfängers

3. Geprüftes S/MIME Domänen Zertifikat des Empfängers

4. Geprüfte öffentlicher openPGP Domänen Schlüssel des Empfängers

Sollte aufgrund fehlenden Schlüsselmaterials des Empfängers keines der vorangegangenen

(Standard-)Verfahren verfügbar sein, so wird

5. GINA mit hinterlegtem Empfängerpasswort

6. GINA mit Initialpasswort

Es gilt zu beachten, dass die Verschlüsselungsverfahren der Punkte 3. und 4. auch bei nicht als zu verschlüsselnd markierten E-Mails zum Einsatz kommt, sofern diese Verfahren verfügbar sind.

Standard Verschlüsselungsmerkmale sind Betreffzeilen-Schlüsselworte, Sensitivity Parameter

(Vertraulichkeitsmarkierung) sowie spezielle x-header.

Optional können auch zum Beispiel LDAP Abfragen als Merkmale herangezogen werden, wie etwa

Microsoft Active Directory (AD) Benutzergruppen.

Sollte eine andere Reihenfolge, oder ein anderer Vorgang gewünscht werden, kann jederzeit das

Ruleset entsprechend angepasst werden. Damit können gewünschte Standardisierungen im Umgang mit E-Mails an vorbestimmte Adressen oder Domänen so voreingestellt werden, dass diese

Regelungen unabhängig von den Nutzeraktionen immer ziehen.

Darüber hinaus kann das Ruleset der Appliance bei Bedarf durch das eigens dafür bereit gestellte

AddIn (siehe

MS-Outlook AddIn

) bzw. Betreffzeilen-Schlüsselworte übersteuert werden. Wobei diese Befehlswörter in der Regel vom Kunden vorgegeben und angepasst werden können.

Folgende Befehlswörter sind in der Standardinstallation vorgegeben:

[plain] E-Mail mit diesem Kennzeichen durchlaufen nicht das Ruleset und werden somit cryptographisch unbehandelt versendet

[confiden tial]

Anfordern der Verschlüsselung

[priv] E-Mail mit diesem Kennzeichen werden mittels GINA-Technologie verschlüsselt (Stichwort

Lesebestätigung)

]

[emptypw Die Notwendigkeit der Eingabe eines Initialpasswortes bei GINA-E-Mails wird unterdrückt

(Sicherheitstechnisch bedenklich)

[SMS:

<MFN>]

Mobilfunknummer zur Übertragung des Initialpasswortes einer GINA-E-Mail*

[noenc] Verschlüsseln wird unterdrückt, sofern dies als Standard im Ruleset definiert wurde

[sign] Anfordern der Signierung

[nosign] Signieren wird unterdrückt, sofern dies als Standard im Ruleset definiert wurde

[lfm] Aktiviert das Large File Management, unabhängig der E-Mail Grösse*

[lfm: nocrypt]

Der Empfänger Einer LFM Mail muss sich für das Abholen des "Large Files" nicht authentifizieren*

(*Funktionen, welche Zusatzllizenzen erfordern)

Diese Schlüsselworte stehen natürlich nur dann zur Verfügung, wenn die zugehörigen Funktionen vom

Administrator im Ruleset auch aktiviert wurden.

3.2.5

GINA Webmail

SEPPmail verfügt über eine patentierte Technologie zur Unterstützung von Benutzern ohne Secure E-

Mail Infrastruktur. Diese Technologie benötigt lediglich einen Web-Browser und die Möglichkeit E-

Mails zu empfangen, also Internetzugang. Weitere Anforderungen an die Infrastruktur des

Benutzers bestehen nicht.

Diese Technologie bietet im Vergleich zu anderen auf dem Markt verfügbaren Lösungen für die sichere E-Mail Kommunikation mit beliebigen Partnern wichtige Vorteile:

a) Schritt 1: Sender - E-Mail verfassen

Der Sender verfasst in seinem Standard E-Mail Client eine E-Mail und klassifiziert diese als vertraulich, indem er diese entweder mit den E-Mail Client Boardmitteln (1) als „vertraulich“ markiert.

Er kann auch im Betreff ein frei definierbares, aber unternehmensweit vereinbartes Befehlswort

zum Beispiel (2) „[secure]“ einsetzen. Diese Methode greift auch für sogenannte System-User (= maschinelle Ansteuerung).

oder er verwendet das kostenlose Outlook AddIn von SEPPmail (3) [Abb.1].

Dabei kann er wählen zwischen: a) „Verschlüsseln“ (Bezeichnung kann angepasst werden): Dabei wird die E-Mail am System mit den für den/die Empfänger zur Verfügung stehenden Technologien im „Best Effort“ Verfahren verschlüsselt und versendet.

b) „Verschlüsseln mit Lesebestätigung“ (Bezeichnung kann angepasst werden): Dabei wird immer zwingend die GINA-Technologie angezogen, denn nur dadurch kann eine Rückmeldung des

Systems zum Zeitpunkt des aktiven Lesens der versendeten E-Mail sichergestellt werden. Diese

Lesebestätigung ist vom externen Empfänger nicht abzuwählen.

Sollte dieses Verfahren der Kundenanforderung nicht entsprechen, kann das AddIn auch entsprechend angepasst werden. Das AddIn ist Standardmässig in den Sprachen Deutsch und

Englisch verfügbar: Bei Bedarf können zusätzliche Sprachen realisiert werden. Danach wird die E-

Mail versendet.

b) Schritt 2: Sender - Verschlüsseln und Initialpasswort

Die als vertraulich markierte E-Mail wandert durch den E-Mail Server und passiert danach die

SEPPmail. Die Appliance erkennt, dass diese E-Mail zu verschlüsseln ist und leitet den unter A

2.2.5. beschrieben Vorgang zur Verschlüsselung ein. Sie sieht also nach, ob der oder die

Empfänger schon bekannt sind. Sollten diese schon einmal eine S/MIME signierte E-Mail an einen beliebigen Mitarbeiter geschickt haben, oder haben sich schon einmal via GINA-Portal registriert bzw. ein eigenes S/MIME Zertifikat oder einen eigenen openPGP Key hochgeladen, dann wird Die

E-Mail damit verschlüsselt.

Wenn für den/die Empfänger keine Schlüssel hinterlegt sind, oder diese gänzlich

„unbekannt“ sind, kommt die patentierte GINA Technologie von SEPPmail zum Einsatz.

Bei dieser wird zuerst ein AES256 Key erzeugt, die vertrauliche E-Mail damit symmetrisch verschlüsselt und als HTML-Anhang an eine Standard-E-Mail beigefügt. Die E-Mail wird immer

vollständig ausgeliefert. Auf der Appliance wird ausser den Empfängerdaten nichts zwischengespeichert. Beim erwähnten Anhang wird komplett auf aktiven Inhalt (wie zum Beispiel

JavaScript) verzichtet. Es wir nur „plain HTML“ verwendet.

Der Key für den Empfänger bleibt dauerhaft auf der Appliance und wird für die erste, wie für alle anderen GINA-Mails zum Ver- und Entschlüsseln für diese Empfangsadresse verwendet.

Ein Initialpasswort wird erstellt und per E-Mail dem Sender zur Übermittlung an den Empfänger (per

SMS (Abb.2), Telefon oder Fax) zugestellt.

Die für den Anschluss an einen SMS Provider oder System notwendigen Schnittstellen sind in der

Lösung eingebaut und konfigurierbar.

c) Schritt 3: Empfänger – Anmelden und einmaliges Registrieren

Der Empfänger öffnet den HTML-Anhang und wird zur Eingabe seines Initialpasswortes aufgefordert (Abb. 3). Dabei kann er auch seine gewünschte Sprache festlegen.

Anschliessend erfolgt eine einmalige Registrierung am System. Ein eigenes Passwort wird vergeben, sowie eine Sicherheitsfrage + Antwort festgelegt, um ein Zurücksetzen seines Passworts zu ermöglichen (Abb. 4) Optional kann eine Mobilfunknummer für den automatisierten SMS-

Passwort-Versand eingegeben werden.

Beim nächsten Lesen der E-Mail, oder bei einer neuen vertraulichen E-Mail, wird nur noch das eigene Passwort eingeben (Abb. 3).

d) Schritt 4: Empfänger - Lesen und sicher Antworten

Danach wird die entschlüsselte E-Mail im Webmailer (Abb. 5) angezeigt. Aus diesem kann verschlüsselt geantwortet und die E-Mail, wenn gewollt, als Klartext ins System gespeichert werden.

Der GINA-Webmailer ist bewusst möglichst einfach gehalten, um eine intuitive Anwendung zu ermöglichen.

e) Funktionen im GINA-Webmailer:

E-Mail lesen: Schaltfläche zur Darstellung der geöffneten Originalmail (Abb. 5)

E-Mail schreiben: Neue E-Mail verfassen die nur an einen Empfänger „hinter“ der SEPPmail-

Appliance versendet werden kann.

Dabei können Anhänge mit beliebigem Format beigefügt werden. Eine Kopie der eigenen

Antwort wird dem externen Beantworter GINA-verschlüsselt zurückgeliefert. (Abb. 5a)

Einstellungen: Darin können Passwort, Mobilfunknummer und Sicherheitsfrage/-antwort verändert werden. (Abb. 5b)

Untermenü: Schlüssel/Zertifikate:

Der Externe Kommunikationspartner wird über ein Zusatzmenü in die Lage versetzt, eigenes

Schlüsselmaterial dem SEPPmail Betreiber zur Verfügung zu stellen. Dabei kann durch die vorhergegangene 2-Faktor Authentifizierung (GINA-Mail + Initialpasswort per SMS) den

Schlüsseln auch sofort getraut werden. Ein Validieren durch den Administrator ist an dieser

Stelle nicht notwendig ! (Abb. 5c)

Andererseits bekommt ein externer Kommunikationspartner über die Schaltfläche "Suchen" optional auch das verfügbare Schlüsselmaterial (S/MIME; openPGP; Domänen Schlüssel) zur

Verfügung gestellt (Abb. 5d):

Nachricht-Beantworten: Über diese Funktionen kann eine sichere E-Mail-Antwort erstellt und versendet werden. Eine Kopie davon wird verschlüsselt an den externen Sender zurückgesendet (Abb. 5e)

Speichern als…: E-Mail kann im Klartext gespeichert und in beliebigen Ordner verschoben werden Entweder als eml- (Standard E-Mail Format) oder im msg-Format (Outlook)

Logout: Schaltfläche zum Verlassen des GINA Web-Mailers. Dabei wird der Cache des

Browsers und der SEPPmail Appliance geräumt. Somit verbleibt einzig die verschlüsselte

Original-GINA-Mail im System des Empfängers. Ausgenommen der Empfänger hat sich eine

Klartext-Kopie dazu abgelegt

f) Zusatzmodul SSPM: Self Service Passwort Management

Sollte der GINA-Mail Empfänger sein eigenes Passwort vergessen, besteht die Möglichkeit dieses zurückzusetzen (Abb. 6). In der Grundversion bewirkt dieses einen Call beim Administrator oder

Helpdesk, der den Empfänger kontaktiert und nachdem dieser sich authentifiziert hat, wird ihm sein neues Passwort mitgeteilt.

Ist das SSPM Modul aktiv, dann hinterlegt der GINA-Mail Empfänger beim Registrieren eine

Sicherheitsfrage und –antwort (Abb. 6a). Beim Passwort Reset wird Ihm dann, nachdem der GINA-

Mail Empfänger seine selbst vergebene Sicherheitsfrage positiv beantwortet hat, das neue Passwort per SMS auf die hinterlegte Mobilnummer zugesendet. Durch diesen automatisierten Vorgang wird der Administrator oder Helpdesk entlastet und der GINA-Mail Empfänger zeitnah mit einem neuen

Zugangspasswort versorgt. Bei der nun folgenden Anmeldung, wird der Empfänger zur Neuvergabe eines eigenen Passwortes aufgefordert.

g) Der Entschlüsselungsvorgang

Wie Eingangs schon erwähnt, benötigt der GINA-Mail Empfänger, ausser einem Client zum

Empfangen von E-Mails und somit Internetzugang, sowie einen Browser keine weiteren

Komponenten. Beim Öffnen des HTML-Attachments und während der Eingabe des

Zugangspasswortes, wird im Hintergrund über eine https-Strecke das Passwort geprüft und die E-

Mail an die SEPPmail Appliance temporär zur Entschlüsselung eingeliefert und danach über den

GINA-Webmailer im Klatext dargestellt.

(Abb. 7).

Die verschlüsselte E-Mail bleibt zu jeder Zeit im E-Mail System des Empfängers. Damit obliegt das

Backup bzw. das Archivieren der E-Mail beim Empfänger. Ohne diese E-Mail hat er auch keine

Möglichkeit diese über einen anderen Weg zu öffnen. Ein potentieller Angreifer benötigt daher beide

Komponenten: E-Mail und Passwort. Eine „brute force“ Attacke ist nicht möglich, da die SEPPmail

Appliance standardmässig nach 5 fehlerhaften Passworteingaben den Zugang sperrt.

h) Zusammenfassung und Vorteile der patentierten GINA-Technologie

Keine zusätzlichen Technologie-Layer bzw. Konvertieren in PDF, zip oder exe notwendig, da diese nur zusätzliche Komplexität und Fehlermöglichkeiten verursachen.

Empfänger benötigt nur E-Mail Client, Browser und Internetzugang. Keinen PDF-Reader oder sonstige Verschlüsselungsclients am Empfängersystem.

Wird vom Sender eine Lesebestätigung gewünscht, wird diese von der Appliance in dem

Augenblick versendet, wenn die E-Mail zum Entschlüsseln eingeliefert wird. Diese kann vom

Empfänger nicht unterbunden werden. Die Leseaktion wird immer im Log mit protokolliert.

Das Zugriffspasswort kann jederzeit vom Empfänger geändert werden.

Spontane sichere Kommunikation in beide Richtungen möglich

Die E-Mails werden vollständig an Empfänger ausgeliefert, somit werden auf der SEPPmail nur

Anmeldedaten und Keys gespeichert. (Für den Betreiber des sicheren E-Mail Gateways entfällt die Pflicht des Housekeepings (Archivierung) für E-Mails an Dritte).

Alle Texte in der GINA Oberfläche können angepasst und das Aussehen per CSS-Stylesheet verändert werden. Im Auslieferungszustand sind die Sprachen Englisch, Deutsch, Französisch,

Italienisch, Spanisch, Niederländisch und Polnisch integriert: Diese können beliebig erweitert

(oder deaktiviert) werden

Empfänger können sich auch am Portal vorgängig anmelden und so Ihre bevorzugte

Verschlüsselungsform (Passwort oder Zertifikats-Key) wählen.

i) Unterschiedliche Registrierungsprozesse für externe Kommunikationspartner

1. Spontaner Kommunikationsbeginn: Der Sender verfasst eine E-Mail, klassifiziert dieses als

„Vertraulich“ und versendet diese. Hat er die Mobilnummer des Empfängers, könnte er diese im

Betreff schon als Tag [zum Beispiel SMS:00491511234567] mitgeben. Die Appliance würde dann mit dem Versenden der GINA-Mail auch gleichzeitig das SMS auslösen.

Ansonsten wird der Sender aufgefordert dem neuen Empfänger sein Initialpasswort auf parallelem Wege (SMS, Telefon, Fax) zu übermitteln.

2. Vorbereitete Kommunikation: a) Der Sender versendet eine Einladungsmail ohne Initialpasswort an den zukünftigen

Kommunikationspartner. Diese sollte OHNE vertraulichen Inhalt sein. Der Empfänger öffnet

das HTML-Attachment und der unter Schritt 3 / Abb. 4 beschriebene

Registrierungsprozess startet. Danach kann gesichert Kommuniziert werden. Der Externe hat sein eigenes Passwort festgelegt oder schon sein Schlüsselmaterial hochgeladen.

b) Der Externe meldet sich über die Webseite des SEPPmail Betreibers zur sicheren

Kommunikation an. Ein Link bringt den externen Kommunikationspartner auf das

Registrierungsportal der SEPPmail Appliance. Dort hinterlegt er sein Passwort (oder

Schlüsselmaterial). Ein E-Mail Ping bestätigt seine Anmeldung:

Die „harte“ Tour: Jede vertrauliche E-Mail wird per GINA und mit einem SMS-Passwort versendet.

3.2.5.1

Mobile Computing Support

3.2.5.1.1 Interne Nutzer von mobilen Endgeräten

Grundsätzlich gilt, dass SEPPmail dem internen Netzwerk vertraut. Somit sind alle E-Mails im Intranet und am E-Mail Server im Klartext verfügbar. Da die internen mobilen Endgeräte sich die E-Mails vom

E-Mail Server ziehen und dort abliefern, ist von dieser Seite KEIN Problem zu erwarten.

Wie klassifiziert ein interner Nutzer auf seinem mobilen Endgerät (herstellerunabhängig) eine E-Mail als VERTRAULICH? Dies ist generell mit der Befehlsfunktion in der Betreffzeile möglich. Der

Verfasser fügt ein festgelegtes Kommando - zum Beispiel [confidential] oder [sign] beziehungsweise ein vom Kunden individuell festgelegtes Befehlswort wie <c> - in die Betreffzeile ein. Die E-Mail wird am E-Mail Server angenommen, ausgeliefert und die danach folgende SEPPmail Gateway Appliance reagiert auf diesen Befehl und führt das entsprechende Kommando für Verschlüsseln oder Signieren aus.

Blackberry hat mit der Version 10.3.1 (erwartet für Februar/März 2015) eine E-Mail

Klassifizierungsfunktion in seinem E-Mail-Client angekündigt. Genauere Details dazu sind SEPPmail noch nicht bekannt. (Stand Jan 2015).

Für die Standard E-Mail-Clients von iOS, Android und Windows Phone sind keine integralen

Funktionen für das Klassifizieren von E-Mails bekannt. Sollten solche in zukünftigen Versionen implementiert werden, wird SEPPmail auch diese für das Ansteuern der eigenen Lösung nutzen.

Werden Klassifizierungs-Plugins vom Kunden gewünscht, kann SEPPmail Machbarkeitserhebungen dazu anstellen, Nutzen und Aufwand abschätzen und eine Realisierung anstossen.

3.2.5.1.2 Externe Empfänger von verschlüsselten E-Mails auf mobilen Endgeräten

Hersteller /

Betriebssystem

Android

Windows Phone

Zertifikats-

Unterstützung durch Vendor gegeben

Bemerkung

Eine Beispiel-Anleitung zum Import bzw. Installation auf iOS

Geräten finden Sie hier: https://blog.globalsignblog.com/de-de/zertifikate-auf-androidger%C3%A4ten-installieren

Keine Dokumentation im Netz vorhanden

Blackberry

10 und höher iOS (Apple)

ja / nein ja

Blackberry hat nach Auskunft des Supports bei signierten und verschlüsselten ein grundsätzliches Problem, welches so schnell auch nicht behoben werden kann. Das Fehlerverhalten von zum Beispiel signierten E-Mails auf BB Endgeräten ist unterschiedlich und nicht vorhersehbar. zum Beispiel bei einem

Reply auf eine signierte E-Mail vom BB Client, verschwindet der

Antworttext beim Empfänger. Das Problem kann nicht gefixt werden.

Eine Beispiel-Anleitung zum Import bzw. Installation auf iOS

Geräten finden Sie hier: http://wiki.fernuni-hagen.de/helpdesk/index.php/

Zertifikat_in_iOS_einbinden

3.2.5.1.3 Kompatibiolitätsmatrix für Empfänger von GINA Web-Mails

Hersteller /

Betriebssystem

Android

Unterstützung Bemerkung

nativ mit vollwertigem Browser zum Beispiel Firefox oder Chrome

Windows Phone

Blackberry

10 und höher iOS (Apple)

nativ nativ Für frühere Betriebssystem Versionen kann eine App zur

Verfügung gestellt werden kostenlose

SEPPmail App im iTunes

Store verfügbar

Das iOS Sicherheitskonzept (Sandbox) erfordert eine einfach zu handhabende App zum Übergeben der verschlüsselten

Daten aus dem E-Mail an den Browser.

3.2.5.2

Administration und Management

Eine komplette Managementoberfläche für die Administration und das Management der GINA-User ist integraler Bestandteil der Lösung. Auf diese Oberfläche ist ein rollenbasierter (Helpdesk) Zugriff möglich.

3.2.5.3

MS-Outlook AddIn

Das Outlook AddIn ist absichtlich möglichst einfach gehalten. Im Standard werden lediglich im E-Mail x-header für das Steuern der Appliance gesetzt. Eine direkte Kommunikation zwischen AddIn und

SEPPmail ist nicht notwendig.

Das von SEPPmail kostenfrei gelieferte Outlook AddIn unterstützt Microsoft Outlook 2007, 2010 und

2013 jeweils in der 32 und 64 Bit Version auf den Plattformen Microsoft Windows7, 8 und 8.1 sowie

Terminal Server jeweils in der 32 und 64 Bit Version.

Das AddIn, kommt als MSI Installationspaket und kann somit mit den üblichen Software Verteil- und

Installationsmechanismen customized problemlos in grossen Umgebungen ausgerollt werden.

Weiterhin ist ein ADM-Template für die Konfiguration des AddIns per Group-Policies (GPOs) vorhanden.

Eine detailierte Beschreibung der Konfigurationsmöglichkeiten ist im Kapitel

Microsoft Outlook AddIn

103

zu finden.

3.2.6

Elektronische Signaturen

Die SEPPmail Appliance beherrscht neben der Verschlüsselung von E-Mails auch die RFC konforme

Signatur. Eine Authentizität und Integrität der Daten bzw. der versendeten E-Mail ist durch das

Anbringen einer elektronischer Signatur zu erreichen und möglich. Zusätzlich wird mit der Signatur der

öffentliche Schlüssel des Absenders verbreitet, welcher für das Verschlüsseln von an den Absender gerichteten E-Mails benötigt wird.

Das für die Signatur erforderliche Benutzerzertifikat (siehe auch

S/MIME (X.509)

) kann bei Bedarf

über eine MPKI (siehe

Managed PKI

) automatisch durch die Appliance bezogen oder manuell für den jeweiligen Benutzer importiert werden. Das bedeutet: Die dazu erforderlichen zentralen

Funktionalitäten (eingebaute PKI, Konnektoren zu offiziellen CA’s, automatische Zuweisungsfunktion der Zertifikate zu den Usern) sind in der SEPPmail standardmässig vorhanden und werden mit der

Verschlüsselungslizenz dem Betreiber und Nutzer zur Verfügung gestellt.

Automatische Signatur

Die ausgehenden E-Mails werden am Gateway automatisch im Namen des Senders signiert. Der

Benutzerkreis, für welchen dies gegebenfalls erfolgen soll, kann bei Bedarf über das Ruleset gesteuert.

Manuelle Signatur

Die Signatur am Gateway kann auch über das Outlook AddIn (siehe

MS-Outlook AddIn

) oder via

Kommando in der Betreffzeile manuell forciert werden.

Digitale E-Mail-Signatur mit einem Firmenzertifikat

Mails den gleichen (technischen) Absender. Das heisst alle E-Mails des Unternehmens - egal wer im

Unternehmen der Absender ist - erscheinen beim Empfänger mit derselben E-Mail-Adresse.

Daraus resultieren einige Probleme:

Zwar wird beim Empfänger der korrekte (Absender-) Benutzername angezeigt, jedoch wird ein automatisches Erfassen von Kontakten und zugehörigen E-Mail-Adressen nicht mehr wie erwartet funktionieren.

Aufgrund der Häufigkeit des Verwendens dieser einen Absenderadresse besteht eine hohe

Wahrscheinlichkeit, dass diese fälschlicherweise als SPAM eingestuft wird. Das hätte zur Folge, dass bei den meisten Empfängern alle E-Mails des Unternehmens abgewiesen würden.

Non Delivery Reports (NDR) also Informations-Mails welche bei Nicht-Zustellbarkeit erzeugt werden, werden nicht an den ursprünglichen, sondern an den technischen Absender gesendet

Fazit:

Diese Art der Signatur ist im produktiven Umfeld absolut nicht zu empfehlen, da über kurz oder lang massive Support Aufwände generiert werden!

Anzeigen einer Signaturprüfung

Die Information ob eine E-Mail signiert wurde und zu welchem Ergebnis die Prüfung kam, erfolgt bei

SEPPmail durch das Hinzufügen von Tags im Betreff, im Standard:

[signed OK] beziehungsweise [signed INVALID]

Bei Betreffzeilen, die solche Tags schon mitliefern (vielleicht zum Vortäuschen falscher Tatsachen) werden diese Tags bereits vor dem eigentlichen Prüfen gelöscht. Somit ist sichergestellt, dass beim

Empfänger das tatsächliche Ergebnis der Prüfung angezeigt wird.

Der Betreiber der Appliance kann entscheiden, ob Signaturen am Gateway abgehängt und nur der

Indikator in der Betreffzeile ausgeliefert wird, oder die Signatur an den Empfänger weitergereicht wird.

Das Abhängen von Signaturen ist mitunter durchaus sinnvoll, da manche Endgeräte mit diesen

Signaturen nur bedingt umgehen können. So erzeugen zum Beispiel Blackberry wie auch Android

Geräte Fehler, wenn auf eine signierte Mail geantwortet wird.

Wie kritisch der Umgang mit Signaturnachrichten an den Empfänger betrachtet werden sollte, zeigt folgendes Beispiel. Eine sichere E-Mail Gateway Appliance erzeugt folgenden Mail Footer bei Prüfung der Signatur:

Das sieht vordergründig gut aus und zeigt dem Nutzer die gesamte Information einer Signatur:

E-Mail ist originär

E-Mail ist unverfälscht

Zertifikat ist gültig

Aber

ein Angreifer könnte diesen Footer ebenso an seine unsignierte Mail anfügen und so eine gefälschte Mail von außen einschleusen. Das Gateway, welches dieses Verfahren für das

Markieren signierter E-Mails verwendet, könnte diese Fälschung nicht erkennen. Dem Empfänger dieser E-Mail würde somit eine gültige Signatur vorgegaukelt.

3.3 Aufbau und Architektur

3.3.1

Appliance

SEPPmail stellt Appliances sowohl in Form von hochstabiler Industrie-Hardware, als auch für virtualisierte Umgebungen zur Verfügung.

3.3.1.1

Hardwaremodelle

Empfohlen bis 100 Postfächer beziehungsweise 50 Verschlüsselungs-User (Encrypt Lizenzen)

SEPPmail 500B Dimensionen (HxBxT) Desktop Gerät (90 x 330 x 203 mm)

Prozessoren

Speicher (RAM)

Festplatte (HDD

Intel Atom D510 1.66 Ghz Dual Core

1 GB SO-DIMM DDR2 PC-667

SATADOM 8GB Flash Modul SLC

Netzwerk Karte (NIC) 2x Intel 82574L Gigabit LAN

Stromversorgung 250W flexATX 80+ low noise PSU

Empfohlen bis 1000 Postfächer beziehungsweise 500 Verschlüsselungs-User (Encrypt Lizenzen)

SEPPmail 1000B

Dimensionen (HxBxT) 19" 1U short rack form factor (43 x 426 x 356 mm)

Prozessoren Intel Core i3-530 2.93 Ghz Dual Core

Speicher (RAM) 2 GB DDR3 ECC PC-1333

Festplatte (HDD 250 GB enterprise class SATA HDD

Netzwerk Karte (NIC) 2x Intel 82574L Gigabit LAN

Stromversorgung 260W PFC PSU

Empfohlen bis 7500 Postfächer beziehungsweise 5000 Verschlüsselungs-User (Encrypt Lizenzen)

SEPPmail 3500B

Dimensionen (HxBxT) 19" 1U short rack form factor (43 x 435 x 699 mm)

Prozessoren Intel Xeon E5-2603 1.80 Ghz Quad Core

Speicher (RAM)

Festplatte (HDD

4 GB DDR3 ECC PC-1333

2x 146 GB SAS HDD 15k (RAID 1)

Netzwerk Karte (NIC) 4 Port Intel 82571EB Gigabit LAN

Stromversorgung 2x 460W hot plug PSU

Empfohlen bis 20000 Postfächer, die maximale Anzahl von Verschlüsselungs-Usern ist im Einzelfall zu prüfen

SEPPmail 5000B Dimensionen (HxBxT) 19" 2U rack form factor (87 x 446 x 699 mm)

Prozessoren 2x Intel Xeon E5-2630 2.30 Ghz Six Core

Speicher (RAM) 12 GB DDR3 ECC PC-1333

Festplatte (HDD 3x 300 SAS HDD 15k (RAID 1 + HSP))

Netzwerk Karte (NIC) 4 Port Intel 82571EB Gigabit LAN

Stromversorgung 2x 460W hot plug PSU

Durch die Kaskadierbarkeit der Systeme über Cluster und eingebautem Load Balancing ist die Anzahl der User frei skalierbar.

Die angegebene Empfehlung basiert auf Durchschnittswerten für E-Mail-Durchsatz und -Grössen im

Verhältnis zur Anzahl der Postfächer und kann daher im Einzelfall stark abweichen.

3.3.1.2

Virtualisierte Versionen

Verfügbar für die Virtualisierungsumgebungen:

ESX (VMware)

Hyper-V (Microsoft)

HyperVisor (RedHat)

Systemanforderungen für Virtualisierung:

SEPPmail VM500 (Empfohlen bis 100 Postfächer beziehungsweise 50 Verschlüsselungs-User

(Encrypt Lizenzen)

Anzahl vCPUs: 1

Arbeitsspeicher: 1 GB

Festplatte: 2 GB

SEPPmail VM1000 (Empfohlen bis 1000 Postfächer beziehungsweise 500 Verschlüsselungs-

User (Encrypt Lizenzen)

Anzahl vCPUs: 2

Arbeitsspeicher: 2 GB

Festplatte: 5 GB

SEPPmail VM3500 (Empfohlen bis 7500 Postfächer beziehungsweise 5000 Verschlüsselungs-

User (Encrypt Lizenzen)

Anzahl vCPUs: 4

Arbeitsspeicher: 4 GB

Festplatte: 10 GB

SEPPmail VM5000 (Empfohlen bis 20000 Postfächer, die maximale Anzahl von

Verschlüsselungs-Usern ist im Einzelfall zu prüfen)

Anzahl vCPUs: 12 empfohlen

Arbeitsspeicher: 4 GB

Festplatte: 20 GB

3.3.2

Sizing

Unverbindliche Erfahrungswerte für das Festlegen von System-Ressourcen (VM) und

Dimensionierung einer Lösung sind der folgenden Tabelle zu entnehmen.

Speicher (RAM) in GB

Anzahl Prozessoren

Festplatte(n) in GB

Anzahl Netzwerkkarten verfügbarer interner LFM Speicher in

Bei Plattengrössen unter 20 GB wird jeweils die Hälfte für das Erweitern der

"/tmp" Partition verwendet. Bei grösseren Platten werden hierfür statisch 10 GB verwendet.

Maximalgrösse LFM bei Einlieferung per SMTP (begrenzt durch Mailqueue)

Bei Einlieferung per GINA begrenzt lediglich der verfügbare interne LFM

Speicher

Maildurchsatz pro Stunde

(bei durchschnittlichen E-Mail-Grösse von bis zu 200 kByte)

Maximalanzahl Verschlüsselungs-User

(Encrypt Lizenzen)

Virtual Appliance

500 1000 3500

5000

1 abhängig von der Grösse der zugewiesenen Partition (mind.

100

2500

200

5GB)

500

10000 30000

500

90000

50 500 5000 im

Einzelfall zu prüfen

Empfohlene Maximalanzahl Postfächer

(basiert auf dem "Maildurchsatz pro

Stunde" und dem Erfahrungswert des durchschnittlichen E-Mail Aufkommens pro User bei entsprechenden

Unternehmensgrößen)

100 1000 7500 20000

Da einige Ressourcen in virtuellen

Umgebungen nicht mit physikalischen vergleichbar sind

(Speicher/Prozessoren), können diese im Bedarfsfall entsprechend angepasst werden

Hardware Appliance

500B 1000B 3500B 5000B

2x6

250 2x146 3x300

2 4 4

100

2500

100

200

10000

500

1000

100

500

30000

5000

7500

250

500

90000 im

Einzelfall zu prüfen

20000

3.3.3

Software

Die Software basiert auf dem Betriebssystem openBSD, welches sich über die Jahre als extrem zuverlässig und widerstandsfähig gegen Angriffe erwiesen hat. Darüber hinaus wurde das

Betriebssystem durch SEPPmail zusätzlich gehärtet. Die nicht benötigten Libraries wurden entfernt und nur die Module eingebaut, die für die Lösung erforderlich waren. Die Firmware hat in der komprimierten Version (Betriebssystem und Applikation) eine Grösse von ca. 60MB. Als MTA wird

Postfix verwendet.

Das System ist so konzipiert, dass damit auch PCI – konforme Infrastrukturen aufgebaut werden können (Passwortregeln, SIEM, Samhain – Integration, verschlüsseltes Dateisystem etc.)

3.3.4

Zentrales Regelwerk (Rule Engine)

SEPPmail hat mit seiner Rule-Engine ein kleines Workflow-System eingebaut. Das Regelwerk kontrolliert den Fluss jeder einzelnen E-Mail durch die Applikation und definiert, welche E-Mail wie behandelt wird (signiert, verschlüsselt, entschlüsselt, zurückgewiesen,…).

Darüber hinaus können hier Prüfungen und Datenbankabfragen (LDAP-Lookups zum Beispiel an ein

Microsoft Active Directory) durchgeführt und die retournierten Ergebnisse oder Parameter zur E-Mail

Steuerung und/oder Verschlüsselungssteuerung herangezogen werden.

Dieses einfache und doch effektive Werkzeug ermöglicht die Definition eines Regelwerks, welches eine genaue Abbildung der gewünschten Security Policy eines Unternehmens darstellt. Die Rule-

Engine ist als einfache if/else Skriptsprache aufgebaut. Eine umfassende Dokumentation des

Aufbaus, der Befehle und der Parameter ist im Handbuch hinterlegt. Die Lösung wird mit einem

Standardregelwerk ausgeliefert, welches in 90% der Fälle unverändert bei den Unternehmen zum

Einsatz kommt und jederzeit den speziellen Bedürfnissen eines Unternehmens angepasst werden kann.

3.3.5

Architekturen

3.3.5.1

Im vollen Mailstrom

In den beiden folgenden Szenarien kann die Entscheidung, ob und wie E-Mails beim Versand verschlüsselt/signiert werden, zentral über das Ruleset der SEPPmail Appliance oder individuell am E-

Mail Client via Schlüsselwörter, Outlook AddIn beziehungsweise IBM Notes Schablone oder

Groupwise Vorlage getroffen werden.

Eingehende E-Mails werden gegebenenfalls entschlüsselt, beziehungsweise die Signatur geprüft und entsprechend für den internen E-Mail Empfänger gekennzeichnet (zum Beispiel [secure], [signed ok],

[signed invalid])

Öffentliche Schlüssel von eingehenden, signierten E-Mails werden gesammelt, so dass diese zur

Verschlüsselung an die absendenden Kommunikationspartner automatisch genutzt werden können.

Eine Liste der zu gewährleistenden Kommunikationswege, über welche die SEPPmail Appliances kommunizieren ist sowohl im Quick-Install Guide als auch im Handbuch (http://dl.seppmail.ch) zu finden.

3.3.5.1.1 Kleine Umgebungen

Für gewöhnlich wird die Appliance in kleineren Umgebungen als zusätzliche Stufe zwischen E-Mail

Server und Internetzugang (Router) in den E-Mail Strom gesetzt. In dieser Konstellation wird für die

Appliance optional ein „Protection Pack“ (Virus, Spam and Phishign Protection VSPP) für Spam

Erkennung und Virenschutz angeboten.

3.3.5.1.2 Grössere beziehungsweise komplexere Umgebungen

In grösseren Umgebungen trifft man häufig auf eine separate AntiSpam-/Antiviren- Lösung, welche im

Normalfall auch E-Mail Routing Funktionen zur Verfügung stellt.

Dabei werden ausgehende E-Mails am Spam-Filter auf Viren geprüft, bevor sie gegebenenfalls an der

Appliance verschlüsselt/signiert werden.

Eingehende verschlüsselte E-Mails werden zunächst zum Entschlüsseln an die SEPPmail Appliance geleitet und anschliessend zur Virenprüfung zurück an den Spam-Filter geliefert. Somit können auch verschlüsselte E-Mails an zentraler Stelle auf Viren geprüft werden.

3.3.5.2

Über spezielles Routing angesteuert

Im folgenden Szenario fällt die Möglichkeit des zentralen Entscheidens, ob und wie E-Mails beim

Versand verschlüsselt/signiert werden, an der SEPPmail Appliance weg. Dieses Steuern wird von der vorgeschalteten AntiSpam- Komponente übernommen.

Hierfür muss diese ebenfalls die individuell am E-Mail Client via Schlüsselwörter, Outlook AddIn, IBM

Notes Schablone oder Groupwise Vorlage getroffene Entscheidung interpretieren können.

3.3.5.3

Schnittstellen

Eine Liste der zu gewährleistenden Kommunikationswege, über welche die SEPPmail Appliances kommunizieren ist sowohl im Quick-Install Guide als auch im Handbuch (http://dl.seppmail.ch) zu finden.

3.3.6

Hochverfügbarkeit, Loadbalancing

Die Cluster- und Loadbalancing-Funktionalität ist im Grundsystem der SEPPmail-Appliance integriert.

Mit wenigen Schritten kann ein Cluster zwischen zwei und mehr Geräten aufgebaut werden, bei Bedarf auch über verschiedene Standorte hinweg. Dabei werden alle betriebsrelevanten Daten

(Systemparameter, Nutzerdaten und Schlüsselmaterial) über alle Systeme synchronisiert. Die

Systeme sind so ausgelegt, dass bei einem Totalausfall eines Standortes, der oder die verbleibenden

Standorte den Betrieb reibungslos aufrechterhalten können. Sobald der Regelbetrieb wieder hergestellt ist, werden wieder alle Systeme automatisch abgeglichen.

3.3.6.1

Multi Master LDAP

Ein SEPPmail Cluster besteht aus zwei oder mehr SEPPmail-Appliances. Jeder Member des Clusters oder jede Instanz ist Teil des Multi-Master LDAP Verbundes. Im LDAP sind alle für den Betrieb einer

Instanz notwendigen Daten abgelegt.

Der Einsatz von Multi-Master LDAP ermöglicht deshalb auf einfache und elegante Art allen Instanzen, mit minimaler Verzögerung, die gleiche Datenbasis zur Verfügung stellen.

Des Weiteren erlaubt das Verwenden von LDAP als Clusterprotokoll, einen Cluster auch über reine IP

Netzwerke zwischen den Rechenzentren zu betreiben. Layer 2 Netzwerke oder Spezialprotokolle zwischen den Netzwerken sind in aller Regel nicht notwendig.

3.3.6.2

Queue-Less-Betrieb

SEPPmail hat eine einzigartige Funktionsweise, bei der E-Mails nie in einer Queue und nie auf der

Appliance zwischengespeichert werden. Eine E-Mail wird erst dann als empfangen quittiert, wenn sie an den nächsten Server weitergereicht wurde.

Dadurch muss auf den Appliances kein Platz für grosse Queues vorgehalten und überwacht werden.

Ein Backup der Queue ist ebenfalls nicht notwendig, da keine Nutz-Mails in Queues gelagert werden.

Dieses Verfahren führt zu einer erheblichen Erleichterung bei der Fehlersuche im E-Mail System.

Hauptsächlich aber kann damit eine Appliance bei Hardware Ausfall garantiert ohne Datenverlust ausgewechselt werden.

3.3.6.3

Cluster: Multimaster LDAP & Queue-Less Betrieb

Durch das Verwenden des Queue-Less Modus und den Einsatz GINA-Technologie, werden keinerlei

E-Mails in den Appliances gelagert und müssen deshalb auch nicht zwischen den Geräten zur

Ausfallsicherheit synchronisiert werden. Die Datenmenge, die zwischen den Instanzen ausgetauscht werden muss, ist deshalb sehr klein: Es müssen nur Konfiguration und Schlüssel Material synchronisiert werden.

3.3.6.4

Fail-Over und Loadbalancing

Mit wenigen Schritten kann ein Cluster zwischen zwei und mehr Geräten aufgebaut werden, dies auch verteilt über verschiedene Standorte. Der Multimastercluster benötigt dabei einzig eine TCP–

Verbindung zwischen den Geräten.

Fail-Over kann in mehreren Stufen realisiert werden:

Durch das Verwenden von MX – Records für das Ansprechen der Systeme

Durch das Definieren von (lokalen oder allgemein verfügbaren) DNS – Einträgen mit MX –

Records für den nächsten Hop

Durch Definition von virtuellen IPs, wobei die IPs eines ausfallenden Systems automatisch von einem der verbleibenden Geräte übernommen wird

Load-Balancing kann in mehreren Stufen realisiert werden:

Durch Aufteilen des E-Mail Stroms auf verschiedene virtuelle IPs (zum Beispiel ein – und ausgehender E-Mail Verkehr getrennt)

Durch Definition von MX–Records mit gleicher Priorität auf virtuelle IP–Adressen oder DNS

Round Robin

Zusätzlich hat jede SEPPmail einen integrierten Loadbalancer: Wenn eine Maschine überlastet ist, werden Aufgaben automatisch an vordefinierte andere Maschinen weitergegeben. Dies funktioniert auch über verteilte Standorte

Für den Zugriff auf das Webportal (GINA) wird das Verwenden von virtuellen IPs und eventuell eine

Web Application Firewall (WAF) empfohlen.

Da praktisch alle Installationen von SEPPmail mit einem Cluster arbeiten (insbesondere bei

Verwenden von Hardware–Appliances) ist die eingesetzte Technik praxiserprobt und extrem zuverlässig.

3.3.7

System Management

3.3.7.1

Administration

Der administrative Zugriff erfolgt in der Regel über eine SSL gesicherte Verbindung auf einen separaten Web Server.

3.3.7.2

Rollenrechte

Die SEPPmail Appliance hat ein integriertes Rollen-Rechtesystem. Dieses ist in der folgenden Tabelle abgebildet:

Rolle Zugriff

admin administrationadmin backup caadmin

Vollzugriff

Systemrelevante Konfigurationseinstellungen (Lizenz, Update, Backup,

Importfunktionen, Boot)

Das Backup der Appliance wird täglich verschlüsselt an die E-Mail-

Adressen aller Backup Benutzer gesendet

Interne Certificate Authority (CA) und Managed Public Key Infrastructure

(MPKI)-Einstellungen

Cluster Einstellungen clusteradmin domainkeysadmin groupsadmin

Domänen Schlüssel Verwaltung

Gruppenverwaltung (diese beinhaltet sowohl die hier beschriebenen

Rollen, wie auf optional selbst erstellte Gruppen zur Verwendung im

RuleSet)

Übersicht des Systemstatus homeadmin logsadmin mailprocessingadmin mailsystemadmin

Logs

Rule Engine

Anbindungseinstellungen und einfache AntiSpam Einstellungen multiplecustomersadmin Mandanteneinstellungen in multitenant Systemen openpgpkeysadmin readonlyadmin openPGP Schlüsselverwaltung lesender Zugriff auf alle Menüs ssladmin statisticsadmin systemadmin usersadmin webmailaccountsadmin webmaillogsadmin

SSL Einstellungen

Statistik Graphiken

Systemeinstellungen (Netzwerkinterfaces)

Interne Benutzerverwaltung

GINA Benutzerverwaltung

GINA Webmail Logs x509certificatesadmin X.509 Zertifikatsverwaltung x509rootcertificatesadmin X.509 Root Zertifikatsverwaltung

3.3.7.3

Backup / Restore

Das System wird täglich automatisch gesichert. Inhalt der Sicherung ist ausschliesslich Konfiguration und Schlüsselmaterial, weshalb die Grösse der Sicherung selbst nach jahrelangem Betrieb der

Appliance minimal bleibt. Die Sicherungsdatei wird automatisch verschlüsselt an den oder die

BackupOperator gesendet. Da auf den Appliances dank der GINA-Technologie nie Nutzdaten gespeichert werden müssen, kann im Disasterfall trotz der geringen Grösse des Backups die volle

Funktionalität des Systems innerhalb kürzester Zeit wiederhergestellt werden.

Der Restore einer einzelnen Maschine erfolgt durch das alleinige Einspielen der Backupdatei nach dem Neustart.

Der Restore einer Clustermaschine erfolgt automatisch per Replikation nach Aufnahme der neuen

Maschine in den bestehenden Cluster.

3.3.7.4

Systemupdate

Das System sucht regelmässig nach anstehenden Versionsupdates und Patches und zeigt anstehende Updates dem Administrator an. Dieser entscheidet, ob er das Update „prefetchen“ oder sofort durchführen möchte. Dabei wird immer das gesamte Core-System (Firmware) ausgetauscht, d.

h. keine Einzelkomponenten. Erhalten bleiben hingegen alle Systemeinstellungen, kundenspezifische

Anpassungen und das Schlüsselmaterial.

Bei einem Clusterbetrieb, können im Wartungsfall die Komponenten einzeln und im laufenden Betrieb einem Systemupdate unterworfen werden Ein Aufbrechen des Clusters ist möglich, aber nicht notwendig. Da die Software als echte Firmware ausgeliefert wird, sind Systemupdates sehr gut planbar, da nicht einzelne Komponenten (zum Beispiel Datenbanken und Module) auf voneinander abhängige Release-Stände gezogen werden müssen. Auch ist die Lösung dadurch im Voraus zu testen.

3.3.7.5

SysLog

Die SEPPmail-Appliance bietet die Möglichkeit ihre gesamten Logs an SysLog Server zur zentralen

Überwachung/Archivierung zu liefern. Die RFC 3164 Konformität ist gegeben.

Neben dem Mail Log können bei Bedarf alle Admininistrationsoberflächen- wie auch GINA- Ereignisse in einem PCI konformen Format eingerichtet werden (CEF – Format zum Beispiel für ArcSight).

3.3.7.6

Report

Ein Statusreport wird einmal täglich von der Appliance per E-Mail sowohl an den Administrator wie auch dem Statistik-Verantwortlichen versendet. Dabei werden Notifications und Warnings angezeigt, wieviele Root Certificate zur Prüfung anstehen und je eine graphische Statistik zu Durchsatz

(Reseived-Sent-Encrypted-Decrypted), Technologie (Webmail-S/MIME-openPGP-Domain), optional

Spam (incoming-Spam-Blacklisted-Greylisted), Prozessor- und Speicherauslastung ausgeworfen.

Darüber hinaus stellt das System auch noch Reports im csv-Format zur Anzahl der versendeten oder empfangenen E-Mails und den verwendeten Technologien pro Benutzer und Domäne zur Verfügung.

3.3.8

Mandantenfähigkeit - Public-/Private Cloud Implementierung

SEPPmail-Appliances sind grundsätzlich mandantenfähig.

Somit wird Unternehmensrechenzentren und Managed Service Providern ermöglicht den Service

„Sichere E-Mail“ auch für eigenständige Unternehmenseinheiten und/oder unterschiedliche kleinere oder grössere Kunden (Mandanten) anzubieten. Dabei unterliegt der Betrieb der Appliance dem

Provider.

Durch eine ebenfalls nach Mandanten getrennte Konfigurationsoberfläche, kann über optional jeweils einzurichtende Mandanten-Admins, der jeweilige Mandant spezifische Aufgaben selbst übernehmen, wie zum Beispiel

Vornehmen von GINA-Einstellungen und Layouts

Prüfen von Log-Dateien

Verwalten von SEPPmail-Benutzern (für die Signierung/Verschlüsselung)

Verwalten von GINA--Benutzern

Verwalten von LFM-Benutzern (optional)

Die Art und Weise der E-Mail Verarbeitung wird jedoch grundsätzlich zentral verwaltet und ist somit für jeden Mandanten identisch.

Das bedeutet der MSP macht seinen Kunden Vorgaben bezüglich der E-Mail Verarbeitung !

Diese ist im Ruleset definiert und enthält zum Beispiel:

Merkmale für das Steuern der Appliance o

Tags (zum Beispiel [confidential], [sign] usw.) o

E-Mail Header (Sensitivity-Parameter welcher zum Beispiel aus dem Outlook

Vertraulichkeitsflag resultiert) o

X-Header (zum Beispiel aus dem kostenfreien SEPPmail Outlook AddIn)

Tags für das Rückmelden durchgeführter Aktionen o

Tags (zum Beispiel [secure], [signed ok] usw.) o

Header (Setzen des Sensitivity-Parameter (Vertraulichkeits-Flag))

Automatisches Erzeugen von SEPPmail-Benutzern

MPKI von welcher CA Zertifikate automatisiert bezogen werden.

Ist jedoch das zur Verfügungstellen von unterschiedlichen Verfahrensweisen der E-Mail Verarbeitung

(Ruleset Einstellungen, unterschiedliche MPKI) pro Mandant unumgänglich, so kann dies durch 2

Arten gelöst werden:

Installieren von mehreren Instanzen mit unterschiedlichen Rulesets.

Das Standard-Ruleset so anzupassen, dass die unterschiedlichen Regelbedürfnisse pro

Mandant in diesem abgebildet werden (siehe auch

Zentrales Regelwerk (Rule Engine)

)

3.4 Sicherheit

Sicherheitkonzept des Betriebssystems openBSD

SEPPmail hat das, an sich als gut gesichert bekanntes Betriebssystem, zusätzlich im „Bottom-up“

Verfahren gehärtet. Dabei wurden alle nicht notwendigen Libaries entfernt und nur unbedingt notwendigen Funktionen behalten.

Bei der Lösung handelt es sich um eine “echte” Firmware: Bei einem Update wird das Gesamtsystem aktualisiert. Damit ist dieses auch test- und reproduzierbar.

Sicherheitskonzept Core Application

Bei der Appliance handelt sich um eine gekapselte Applikation. Alle Schnittstellen gegen aussen sind möglichst einfach gehalten und nur die absolut notwendigen wurden implementiert. Die Firmware ist gepackt mit allen zugehörigen Applikationen rund 60 MB gross.

Sicherheitskonzept GINA

Das Webinterface wurde absichtlich sehr einfach gehalten und nur mit den absolut notwendigen, aber ausreichenden Funktionen versehen. Dabei wurden alle Boardmittel zur Absicherung des Web

Servers - etwa zur Abwehr von "Denial of Service" (DoS) Attacken - ausgeschöpft. Weiterhin werden zur Eingabe nur genau vordefinierte Datenfelder akzeptiert. Jedes Datenfeld wird beim Einliefern auf

Gültigkeit geprüft. Somit ist ein Einschleusen schädlichen Codes unmöglich. Der gehärtete, gekapselte

Web Server läuft als unprivilegierter User.

Schutz der Daten

CA-Schlüssel, Private Schlüssel, Session Schlüssel, GINA Benutzer Schlüssel o

Die Hauptmaschinen sind so gekapselt in der DMZ platziert, dass keinerlei direkter Zugriff von aussen möglich ist.

Sollte der Wunsch/Forderung bestehen, dass die PKI-Daten ausschliesslich im Intranet abgelegt werden, kann die Lösung aufgetrennt werden. Dabei werden für den Web-Zugriff

(GINA) eigene Maschinen (Satelliten) ohne eigene Datenhaltung in der Internet DMZ verwendet.

In der Regel macht das Sicherheitskonzept der Appliance in Kombination mit den vorhandenen

Überwachungsmöglichkeiten (SamHain, Audit Log, SNMP etc.) ein HSM unnötig. Sollte dennoch ein zusätzliches Sicherung von privaten Schlüsseln gewünscht sein, ist das Anbinden einer HSM (zum Beispiel durch Thales oder Safenet) möglich.

Pin/Passwörter o

Passwörter dienen dem Zugriff eines externen Empfängers auf seine GINA-E-Mail bzw.

nachgelagert dem AES256 Schlüssel auf der Appliance zum Entschlüsseln seiner E-Mail.

Letzterer verlässt die gut geschützte SEPPmail-Appliance niemals.

Zertifizierungen

Die Appliance kann auch für den Betrieb in PCI (Payment Card Industry Data Security Standard) – konformen Umgebungen konfiguriert werden. Zum Beispiel hat die Lufthansa Systems ein PCI – konformes Gesamtsystem mit einer SEPPmail-Appliance als Kernsystem aufgebaut. Im Oktober 2014 wurde das System mit positivem Abschluss geprüft.

Aus unserer Sicht ist es derzeit aus unterschiedlichen Gründen fraglich, ob und welche

„standardisierten“ Zertifizierungen sinnvoll sind. Der Markt der „Sicherheitszertifizier“ wächst schnell und ist unübersichtlich. Einige ausländische Unternehmen verlangen zudem Einblicke in den

Sourcecode. Dies können wir aus sicherheitsrelevanten Gründen nicht zulassen.

Die von der Lufthansa Systems durchgeführte Prüfung auf PCI-Compliancy ist unseres Erachtens deutlich strenger und daher höher zu bewerten, da diese neben einem normalen PenTest sehr harte

Vorgaben bezüglich Zugangsrechte und Protokoll der Administrationstätigkeit verlangt und prüft.

Aktuelle Sicherheitslücken oder Exploits

SEPPmail reagiert – falls betroffen - auf bekannt werdende Sicherheitslücken oder Exploits innerhalb kürzester Zeit mit einem Sicherheitsupdate, welcher allen Kunden über den normalen Update-

Mechanismus zur Verfügung gestellt wird.

Die kürzlich bekannt gewordenen Sicherheitslücken wie „Heartbleed“ oder „Poodle“ betrafen die

Lösung nicht.

3.5 Zusätzliche Features

Die SEPPmail-Appliance bietet zusätzlche Features, welche auf Wunsch beziehungsweise bei Bedarf lizensiert und verwendet werden können.

3.5.1

Large File Management (LFM)

Einführung

Das Problem der übergrossen E-Mail Anhänge ist den Meisten bekannt. Sobald eine bestimmte E-Mail

Grösse überschritten wird, wird die E-Mail entweder schon vom eigenen oder aber vom E-Mail Server des Empfängers abgewiesen. Danach beginnt die Suche nach einem geeigneten

Übermittlungsverfahren. Zur Verfügung stehen dann: FTP-Server, diverse Web-Angebote wie zum

Beispiel Dropbox oder der Postweg für die selbst gebrannte DVD.

SEPPmail nutzt die Basisfunktionalität der Appliance und den Einladungsprozess der GINA-

Technologie, um dieses Problem elegant und für den User transparent zu lösen.

Dabei gibt zwei Möglichkeiten übergrosse E-Mails bei der SEPPmail-Appliance einzuliefern:

Standard E-Mail Client

GINA Web-Mail Client

Auf der Appliance selbst sind nur vier Parameter einzustellen:

Grösse der E-Mail (in kiB) ab welcher die LFM Funktionalität aktiv wird.

Maximalgrösse einer LFM Mail

Verweildauer (in Tagen) nach welcher die E-Mail von der SEPPmail-Appliance gelöscht wird.

Versenden von übergrossen Files via Standard E-Mail Client

Wenn vom Betreiber des E-Mail Systems für den Sender keine Limitation der E-Mail Grössen vorgegeben ist, oder es keine sensiblen Daten sind, die PCI-compliant übermittelt werden müssen, steht der Nutzung des Standard E-Mail Clients zum Versenden von übergrossen Daten nichts im Weg.

Der Anwender verfasst in seinem gewohnten E-Mail-Client eine E-Mail und fügt seine zu

übermittelnden Daten und Files als Anhang bei (1). Danach versendet er diese, ohne weitere

Markierung oder Aktion. Sobald die gesamte E-Mail das auf der SEPPmail eingestellte Volumen

übersteigt, wird diese verschlüsselt und auf der Appliance in einem gesonderten Datenbereich abgelegt. Gleichzeitig wird eine Einladung (2) zum Download der übergrossen E-Mail mittels GINA-

Technologie versendet. Siehe Kapitel

GINA Webmail

Der Unterschied zu einer verschlüsselten E-Mail liegt darin, dass die Einladungsmail mit einem

Ablaufdatum versehen ist und die Datei als solches nur wenige kByte gross ist.

Sobald der Empfänger den GINA Anmeldeprozess - dieser kann optional und im Einzelfall ausgesetzt werden - durchlaufen hat, steht die E-Mail samt Anhang auf der SEPPmail-Appliance entschlüsselt zur

Verfügung. Der Anhang beziehungsweise die komplette E-Mail steht - gemäss den vom Betreiber eingestellten Optionen - zum Download über die etablierte https-Strecke bereit (3).

Die E-Mail wird nach Erreichen der Verweildauer von der SEPPmail-Appliance gelöscht, auch wenn der Download noch nicht stattgefunden hat.

Versenden von Daten via internem GINA Web-Mail Portal

Da Storage teuer ist, tendieren manche IT-Abteilungen dazu, auch den ausgehenden E-Mail Verkehr von der Grösse her zu limitieren. Aber auch sensible Daten, wie zum Beispiel

Kreditkarteninformationen, müssen über einen PCI konformen Übermittlungsweg übertragen werden.

Fast alle E-Mail Systeme sind dafür nicht ausgelegt. SEPPmail kann in einem System beide Szenarien abbilden.

Der Anwender öffnet dafür den internen <%OEM-WEBMAIL-GINA> Webmail Client über seinen

Browser und verfasst darin seine Nachricht und fügt die zu übermittelnden sensiblen Daten bei (1).

Danach versendet er die Nachricht, wobei diese über den gesicherten https-Kanal auf die SEPPmail eingeliefert wird. Der restliche Vorgang ist mit dem unter Kapitel „Versenden von übergrossen Files via

Standard E-Mail Client“ identisch. Die E-Mail samt Anhang wird verschlüsselt in einem gesonderten

Datenbereich der Appliance abgelegt und es ergeht eine Aufforderung zur Abholung (2) an den oder die Empfänger. Dieser meldet sich mit seinem Initialpasswort oder eigenem Passwort an und lädt die

Dateien auf sein System. (3)

Optional kann bei Bedarf für LFM die Passwortabfrage individuell abgeschaltet werden

LFM – Antwort

Dem Empfänger steht für eine Rückantwort der gleiche Kanal zur Verfügung. Er kann somit eine gesicherte E-Mail bzw. auch grosse vertrauliche Daten via dem GINA-Webmail Client übermitteln.

Dazu bedient er sich der Antwortfunktion innerhalb des GINA-Clients.

Der Prozess ist exakt invers zu der Versendung.

3.5.2

Internal Mail Encryption (IME)

Die SEPPmail-Appliance bietet optional die Möglichkeit der internen E-Mail Verschlüsselung. Um jedem Kundenbedarf gerecht zu werden stehen hierfür zwei Konzepte zur Verfügung.

Das erste Konzept

basiert auf der GINA-Technologie in Verbindung mit dem Outlook AddIn. Die folgende Graphik zeigt den funktionalen Ablauf: a) Am E-Mail Client (1) wird eine neue E-Mail – an einen oder mehrere interne und gegebenenfalls externe Empfänger - erzeugt.

b) Diese wird über das Outlook AddIn (2) als „zu verschlüsselnd“ und „intern zu verschlüsselnd“ markiert und modifiziert.

c) Die modifizierte E-Mail (3) wird an den E-Mail Server (4) geleitet.

d) Durch die vorgenommene Modifikation behandelt der E-Mail Server (4) die E-Mail an die internen

Empfänger wie eine Internet E-Mail (5) und leitet diese somit an die SEPPmail-Appliance (6) weiter.

e) Die SEPPmail-Appliance (6) leitet die E-Mails an die externen Empfänger (7) „best effort“ verschlüsselt in das Internet.

f) Für die internen Empfänger generiert die SEPPmail-Appliance – sofern nicht bereits vorhanden neue, interne GINA-Benutzer und versendet an diese sowie an den Absender die bekannte

GINA-Mail (8) über den internen E-Mail Server (4).

Wurde vom Absender die interne E-Mail Verschlüsselung gewählt, jedoch nur externe

Empfänger adressiert, so erhält an dieser Stelle natürlich nur er seine ausgehende E-Mail als

GINA-Mail.

g) Der interne E-Mail Server stellt die GINA-Mail(s) (9)/(10) für den Absender (1) und den/die

Empfänger (11) bereit.

h) Das AddIn (2) entfernt die noch unverschlüsselte E-Mail aus dem „Gesendet“ Ordner des

Absenders (1). Dieser erhält an deren statt die GINA verschlüsselte E-Mail (9).

i) Der Absender (1) sowie die Empfänger (11) verbinden sich durch Öffnen des in der GINA-Mail befindlichen html-Anhangs mit dem GINA-Portal (12) der SEPPmail-Appliance (6), wo die E-Mail nach Anmelden mit den persönlichen Zugangsdaten gelesen werden kann.

Der Vorteil dieser Lösung liegt zum Einen in der Outlook-Integration, zum Anderen erleichtert Sie das

Realisieren von Vertreterregelungen, da die intern verschlüsselten E-Mails auch verschlüsselt im

Outlook abgelegt bleiben und somit nur vom originären Empfänger mit dessen Passwort entschlüsselt

und somit gelesen werden können.

Das zweite Konzept

basiert allein auf der GINA-Technologie, wobei sich der Versender bereits für den Versand der E-Mail am GINA-Portal anmeldet.

57 a) Am E-Mail Client (1) wird eine SSL Verbindung (2) zum GINA-Webinterface der SEPPmail-

Appliance (3) aufgebaut.

b) Nach Anmelden am GINA-Webinterface wird im Webmailer direkt eine E-Mail an interne (und gegebenenfalls externe) Benutzer adressiert und versendet.

c) Die SEPPmail leitet die so erzeugten, bekannten GINA-Mails (5) an den internen E-Mail Server

(6) (sowie für eventuell adressierte externe Benutzer (4) in das Internet).

d) Der Interne E-Mail Server (6) leitet die GINA-Mails an den/die Empfänger (8) sowie den

Absender (7).

e) Die Empfänger (9) sowie der Absender (1) können die E-Mail im E-Mail Client öffnen und gelangen durch Öffnen des verschlüsselten HTML-Anhanges über die SSL-verschlüsselte

Strecke [(10) beziehungsweise (2)] zum bekannten GINA-Webmailer (3) mit dessen Hilfe die ursprüngliche E-Mail aus dem HTML-Anhang entschlüsselt und gelesen werden kann.

Vorteil dieser Lösung ist die absolute Unabhängigkeit von den dazwischen eingesetzten Komponenten wie E-Mail Client oder E-Mail Server.

3.5.3

Self Service Password Management (SSPM)

Das Self Service Passwort Management (kurz SSPM) ermöglicht es GINA-Benutzern selbständig Ihr

Passwort zurückzusetzen. Damit werden ressourcen- und somit kostenintensive Hotline Anfragen grösstenteils vermieden.

Dabei stehen zwei Varianten zur Verfügung, um die zwei Faktoren Authentifizierung zu gewährleisten: a) Passwortreset per SMS

Steht ein SMS-Dienst zur Verfügung, so kann sich der GINA-Benutzer nach dem Beantworten seiner persönlichen Sicherheitfrage (siehe

GINA Webmail

) ein Einmalpasswort bequem per

SMS zusenden lassen.

b) Passwortreset per E-Mail Verifikation

Steht kein SMS-Dienst zur Verfügung oder verfügt der Benutzer über keine Gelegenheit SMS zu empfangen, so kann er sich nach dem Beantworten seiner persönlichen Sicherheitfrage und

Vergabe eines neuen Passwortes von der Appliance eine E-Mail mit einem Verifikations-Link an seine hinterlegte E-Mail Adresse zusenden lassen. Nach dem Bestätigen des Links aus der E-

Mail ist das Anmelden am GINA-Portal mit seinem neuen Passwort wieder möglich.

3.5.4

Protection Pack

Ein weiteres optionales Feature der SEPPmail-Appliance ist das Protection Pack, welches Virus,

Spam und Phishing Schutz bietet.

Ist die Appliance aus dem Internet direkt, ohne vorgelagerte Schutzkomponenten per MX-Record zu erreichen, so empfiehlt sich der Einsatz dieser Komponente dringend, um ein Überlasten des

SEPPmail- sowie der nachgelagerten Systeme aufgrund von Spam-Attacken zu vermeiden. Selbst bei vorgelagerten Schutzkomponenten ist das Scannen von verschlüsselten E-Mails auf Viren nicht möglich. Nachdem an der SEPPmail-Appliance E-Mails entschlüsselt werden, können Sie dort auch auf Viren geprüft werden. Weiterhin kann durch Aktivieren des Virenschutzes gegebenenfalls die

Zweistufigkeit des selbigen gewährleistet werden.

Realisiert wird der Schutz mittels Black-, White- und Greylisting sowie der integrierten Komponenten

SpamAssassin und ClamAV.

3.6 Lizenzen

3.6.1

Basissysteme und Lizenz

SEPPmail bietet die Basissysteme entweder als Hardware Appliance (siehe

Hardwaremodelle

) oder als virtuelle Appliance an (siehe

Virtualisierte Versionen

Die eingesetzte Firmware ist auf beiden Systemen identisch. Somit sind auch gemischte (Cluster-)

Systeme aus physikalischen und virtuellen Appliances möglich.

Mit dem Basissystem wird auch die Basislizenz erworben, welche bereits die Domänen

Verschlüsselung für das gesamte Unternehmen beinhaltet.

Weiterhin zwingend erforderlich für den Betrieb der SEPPmail-Appliance ist ein jährlicher

Wartungsvertrag für das Basissystem / Lizenz.

3.6.1.1

Protection Pack

Optional kann für jede Instanz (SEPPmail-Appliance) das Protection-Pack (VSPP) gewählt werden.

Der jährliche Betrag beinhaltet das Freischalten der integrierten AntiSpam sowie AntiVirus

Funktionalität.

Diese Funktionalitäten werden durch verschiedene Filtermechanismen sowie dem Einsatz der

Produkte SpamAssassin und ClamAV realisiert, deren Integration in den jeweils aktuellen Versionen gewährleistet wird.

Hinweis:

Für Systeme welche ohne vorgelagerte Schutzkomponenten direkt mit dem

Internet kommunizieren, wird das Protection Pack dringend empfohlen.

Andernfalls gilt es den gegebenenfalls durch Spam E-Mails zusätzlichen

Ressourcenverbrauch beim Dimensionieren des SEPPmail-Systems zu beachten!

Schritt 1 zur passenden Lizenz:

Auswahl der gewünschten Appliance(s) für das Basissystem und die dazugehörige jährliche

Wartung. Optional kann pro Basissystem das jährlich fällig werdende Protection-Pack (VSPP) erworben werden.

3.6.2

Signatur und Verschlüsselung

Soll das kryptographische Behandeln von E-Mails an der SEPPmail-Appliance auf Benutzerebene stattfinden, so ist für jede SENDENDE E-MAIL ADRESSE - unabhängig vom kryptographischen

Verfahren - eine User-Lizenz zu erwerben.

Das impliziert natürlich, dass auch nur diese Nutzer verschlüsselte E-Mails über die SEPPmail-

Appliance entschlüsseln können. Denn nur für diese Benutzer wird auf der Appliance das benötigte, benutzerbezogene Schlüsselmaterial gespeichert.

Diese benutzerbezogenen Lizenzen sind fest an die E-Mail Adresse des Benutzers gebunden und werden nur dann wieder freigestellt, wenn die E-Mail Adresse stillgelegt wird, zum Beispiel wenn der

Mitarbeiter das Unternehmen verlässt. Werden E-Mails von einer auf der Appliance stillgelegten E-

Mail Adresse versendet, so werden diese weder signiert noch verschlüsselt (auch nicht über die

Domänen Verschlüsselung!). Sollte aber diese E-Mail Adresse und damit auch die allgemein gültige

Domänen Verschlüsselung (ohne S/MIME, openPGP und GINA), weiter aktiv bleiben, ist das nur durch das vollständige Löschen des Users auf der SEPPmail-Appliance möglich. Wurde diesem User eigenes Schlüsselmaterial (self-signed oder offizielle Zertifikate) zugewiesen, so werden diese zunächst revoziert und anschliessend gelöscht. Über das Revozieren der Zertifikate wird den externen

Kommunikationspartnern in der Regel automatisiert, das ein Verschlüsseln an die entsprechende E-

Mail Adresse - anders als beim blossen Stillegen - nicht mehr möglich ist.

Schritt 2 zur passenden Lizenz:

Auswahl der Anzahl benötigter Signatur- und Verschlüsselungslizenzen (pro sendender E-Mail

Adresse), zuzüglich dem zwingend erforderlichen, jährlichen SW Care Pack.

3.6.3

Large File Management (LFM)

LFM Lizenzen können in unterschiedlichen Mengen zu den Signatur- und Verschlüsselungslizenzen bezogen werden. Somit ist auch ein Betrieb der SEPPmail-Appliance als alleinstehende Lösung für den sicheren Austausch von grossen Dateien möglich.

Bei LFM handelt es sich um concurrent Lizenzen. Das heisst mit dem versenden eine übergrossen E-

Mail wird der Absender E-Mail Adresse eine LFM-Lizenz zugeteilt. Versendet dieser Absender innerhalb 30 Tagen keine weitere LFM E-Mail, so wird die Lizenz automatisch wieder freigestellt.

Schritt 3 zur passenden Lizenz:

Auswahl der Anzahl gewünschter LFM-Lizenzen, zuzüglich dem zwingend erforderlichen, jährlichen LFM Care Pack.

3.6.4

Self Service Password Management (SSPM)

Die unter

Self Service Password Management (SSPM)

erläuterte Funktion des SSPM, ist als einmalige, optionale Erweiterung der Signatur- und Verschlüsselungslizenz zu erwerben. Dieses

Modul erhöht nicht den jährlichen Wartungsbeitrag der Care Packs.

Schritt 4 zur passenden Lizenz:

Auswahl von SSPM Lizenzen in der selben Anzahl wie Signatur- und Verschlüsselungslizenzen, sofern dieses Modul gewünscht wird.

3.6.5

Internal Mail Encryption (IME)

Die unter

Internal Mail Encryption (IME)

erläuterte Lösungserweiterung zur internen Mail

Verschlüsselung (IME), ist wie dasSSPM Modul ebenfalls ohne jährliche Wartung einmalig pro

Signatur- und

Verschlüsselungslizenz zu erwerben.

Schritt 5 zur passenden Lizenz:

Auswahl von IME Lizenzen in der selben Anzahl wie Signatur- und Verschlüsselungslizenzen, sofern dieses Modul gewünscht wird.

4 Inbetriebnahme der Secure E-Mail-Gateway-Appliance

4.1 Bevor Sie beginnen

Bitte überprüfen Sie den Verpackungsinhalt auf Vollständigkeit. Der Lieferumfang besteht aus:

Anzahl Beschreibung

SEPPmail-Hardware-Appliance bzw. SEPPmail-Virtual-Appliance für VMware ESX oder

Microsoft Hyper-V Server

Quick Install Guide

Kaltgerätekabel (240V)

Sollte der Lieferumfang bei Ihnen unvollständig sein oder sollten bei der Installation der SEPPmail-

Appliance Probleme oder Fragen auftauchen, kontaktieren Sie bitte SEPPmail oder Ihren SEPPmail

Fachhändler.

Eine Liste mit den Kontaktangaben der jeweiligen Fachhändler auf der Webseite der SEPPmail AG http://www.seppmail.ch zu finden.

4.2 Integration der SEPPmail-Appliance in Ihre E-Mail-Umgebung

(Standard Konfiguration)

In diesem Abschnitt wird ein einfaches Szenario beschrieben, in dem die SEPPmail-Appliance externe

E-Mails aus dem Internet direkt entgegennimmt und interne E-Mails nach extern ins Internet versendet. Je nach Aufbau Ihrer E-Mail-Infrastruktur können weitere E-Mail-Server oder Gateways im

E-Mail-Datenfluss vorkommen.

In diesem Szenario wird SEPPmail als SMTP-Gateway zwischen dem Internet und dem internen E-

Mail-Server installiert. Dadurch ändert sich der E-Mail-Datenfluss in den folgenden zwei wesentlichen

Punkten:

1. E-Mails aus dem Internet werden nicht mehr direkt an internen Ihren E-Mail-Server, sondern (neu) an die SEPPmail-Appliance gesendet.

2. Der E-Mail-Server schickt seine E-Mails nicht mehr direkt ins Internet, sondern (neu) an die SEPPmail-Appliance. Die SEPPmail-Appliance übernimmt somit eine Smarthost-

Funktion.

Die E-Mail-Infrastruktur für den beschriebenen Aufbau ist in nachfolgender Abbildung zu sehen.

Typischer Aufbau einer E-Mail-Infrastruktur mit einer SEPPmail Appliance

4.3 Benötigte Informationen zur Inbetriebnahme

Es wird empfohlen, folgende Informationen Ihrer E-Mail-Umgebung vor dem Inbetriebnehmen der

SEPPmail-Appliance bereitzustellen:

Benötigte Information Ihre Angabe

Öffentlicher DNS-Eintrag oder öffentliche IP-Adresse der Appliance*:

Name oder die IP-Adresse, unter welchem Ihre SEPPmail-Appliance aus dem

Internet erreichbar sein wird.

Interne IP-Adresse der Appliance:

Interne IP-Adresse und Subnetzmaske, unter welcher die SEPPmail-Appliance im internen Netzwerk erreichbar sein wird.

Hostname der Appliance:

Frei wählbarer Hostname Ihrer SEPPmail-Appliance, zum Beispiel secureemailgateway. Dieser ist normalerweise im DNS Server aufgeführt.

Diese Einstellung entspricht der internen Sicht. Sie muss also nicht den

Daten, wie sie vom Internet her Gültigkeit haben, entsprechen.

Interne Domäne:

Beispiele sind: ihrefirma.local oder ihredomain.de usw.

Diese Einstellung entspricht der internen Sicht. Sie muss also nicht den

Daten, wie sie vom Internet her Gültigkeit haben, entsprechen.

Standard Gateway IP-Adresse:

Standard-Gateway IP-Adresse Ihrer Firewall oder Ihres Routers, über welche die SEPPmail-Appliance die Verbindung mit dem Internet herstellen kann.

DNS Server:

Die Eingabe von bis zu drei IP-Adressen von DNS-Servern ist möglich. Dabei kann es sich sowohl um externe, als auch interne DNS-Server handeln. Werden interne DNS-Server verwendet, so müssen diese Anfragen für externe

Adressen entsprechend weiterleiten.

Hostname oder IP-Adresse des bestehenden internen E-Mail-Servers:

Hostname oder IP-Adresse, unter der Ihr bestehender interner E-Mail-Server im internen Netzwerk angesprochen werden kann.

E-Mail-Domänen:

Domänen der E-Mail-Adressen Ihrer Organisation an, zum Beispiel firma.ch, firma.com

Postmaster Adresse

An diese Adresse werden Systembenachrichtungen gesendet (zum Beispiel

Watchdog Meldungen)

Admin E-Mail Adresse(n)

Wird für den Empfang von Passwort Rücksetzungsanfragen von GINA-

Benutzern benötigt.

Werden mehrere GINA Interfaces verwendet, so ist unter Umständen das

Einrichten mehrerer Admins sinnvoll.

Benötigte Informationen zum Einrichten der SEPPmail Appliance

* Die SEPPmail-Appliance muss aus Internet als Webserver erreichbar sein und benötigt deshalb eine von extern erreichbare IP-Adresse. Oft ist dies die Adresse der Firewall oder eines Reverse-Proxies /

Web-Application-Firewall. In einfachen Installationen kann dazu die IP-Adresse verwendet werden, unter der Ihr Internet-Router von extern erreichbar ist.

Diese Information sind wie folgt herauszufinden:

1. Öffnen der Eingabeaufforderung auf einem Windows-PC

2. Eingabe des Befehls "nslookup" und mit "Enter" bestätigen

3. Es erscheint ">" Zeichen (Prompt)

4. Eingabe des Befehls "set querytype=mx" und mit "Enter" bestätigen

5. Eingabe der E-Mail-Domäne der eigenen Organisation (zum Beispiel ihredomain.com) und mit

"Enter" bestätigen

6. Alle verfügbaren E-Mail Server werden als "mail exchanger =" angezeigt

Servernamen hinter dem Begriff "mail exchanger" mit der geringsten MX-Preference-Nummer haben die höchste Priorität bei der Namensauflösung.

4.4 Firewall / Router einrichten

Für eine korrekte Funktion der SEPPmail-Appliance sind folgende Kommunikationswege zu gewährleisten:

Port Quelle Ziel Beschreibung

TCP

(SSH)

TCP

(SMTP)

TCP/

UDP

(DNS)

Appliance

E-Mail-

Server update.seppmail.ch

support.seppmail.ch

Wird für Updates und Lizenzänderungen der

Appliance sowie dem Managed Domain Service benötigt. Weiterhin das benutzerinitiierte Öffnen von Support Sitzungen ermöglicht.

Sollte der Zugriff über Port 22 nicht möglich sein, so besteht die Möglichkeit die Verbindung über einen Proxy Server herzustellen (siehe auch

System

126

Proxy Settings

)

Appliance

Wird für die Synchronisation von Appliances im

Clusterverbund benötigt.

Wird für den Versand ausgehender E-Mails vom internen E-Mail-Server an die SEPPmail-

Appliance benötigt

Appliance

Internet

Smarthost

Appliance

E-Mail-Server

Appliance

Internet

Smarthost

Wird für den Versand eingehender E-Mails von der SEPPmail-Appliance an den internen E-Mail-

Server benötigt

Wird für den direkten Empfang von E-Mails aus dem Internet benötigt

Wird für den Empfang von E-Mails über einen

Smarthost benötigt

Wird für den direkten Versand von E-Mails aus dem Internet benötigt

Wird für den Versand von E-Mails über einen

Smarthost benötigt

Nameserver (intern)

Ermöglicht die Namensauflösung über einen/ mehrere interne DNS-Server

Appliance Nameserver (extern)

Ermöglicht die Namensauflösung über einen/ mehrere externe DNS-Server

Internet

Ermöglicht die Namensauflösung für die

Einstellung built-in DNS Resolver

TCP

80/2703

UDP

24441

Appliance Internet

Wird für Updates des Protection Packs (Virus,

SPAM and Phishing Protection )benötigt.

TCP/

UDP

123

(NTP)

Appliance

Internet

Timeserver (intern)

Wird für die Zeitsynchronisation mit Zeitservern im

Internet benötigt

Wird für die Zeitsynchronisation mit internen

Zeitservern benötigt

TCP/

UDP

389

(LDAP)

Appliance Internet

Ermöglicht LDAP Abfragen an LDAP-Server im

Internet welche zum Beispiel von vielen CAs zur

Bereitstellung von öffentlichen Schlüsseln betrieben werden.

Port Quelle Ziel Beschreibung

und/oder

TCP/

UDP

636

(LDAPS)

LDAP-Server

(intern)

Ermöglicht LDAP Abfragen an interne LDAP-

Server zur Abfrage von öffentlichen Schlüsseln interner Benutzer zum Beispiel für Interne Mail

Verschlüsselung (IME).

TCP/

UDP

388,387

(LDAP) und/oder

TCP/

UDP

635

(LDAPS) internes

Netz

Appliance

Ermöglicht LDAP Abfragen an den in die

Appliance integrierten Keyserver zur Abfrage von

öffentlichen Schlüsseln interner Benutzer zum

Beispiel für Interne Mail Verschlüsselung (IME)

oder zur Abfrage von auf der Appliance gespeicherten öffentlicher Schlüssel von externen

Kommunikationspartnern zum Beispiel für eine

End-to-End Verschlüsselung.

Ermöglicht LDAP Abfragen an den in die

Appliance integrierten Keyserver zur Abfrage von

öffentlichen Schlüsseln interner Benutzer.

Internet

Hinweis

TCP

443

(HTTPS)

Internet Appliance

Diese Freischaltung sollte aus

Sicherheitsgründen nicht vorgenommen werden, da sie ein

Address-Harvesting ermöglicht

Wird für das Herstellen der SSL verschlüsselten

Kommunikation über HTTPS zur SEPPmail-

Appliance benötigt, welche für die Nutzung der

GINA-Technologie verwendet wird.

TCP

443

(HTTPS)

TCP

8080

(HTTP) und/oder

TCP

8443

(HTTPS)

Appliance

Admin PC

Internet

Appliance

Wird ein Managed Public Key Infrastructure

(MPKI) Connector verwendet, so wird der Zugang zur Certification Authorothy (CA) über eine HTTPS

Strecke hergestellt.

Wird für den Zugriff auf die web-basierte

Administrationsoberfläche benötigt.

Es wird empfohlen, nur die SSL-verschlüsselte

Verbindung (HTTPS) über Port TCP/8443 zuzulassen.

TCP

5061

Appliance Internet

Wird von vielen SMS-Gateways für den SMS-

Versand via Internet verwendet. Im Bedarfsfall ist der korrekte Port direkt beim Anbieter zu erfragen.

Regeln zur Gewährleistung der Netzwerkkommunikation der SEPPmail Appliance

* optional, je nach Konfiguration der SEPPmail-Appliance

** In einfachen Installationen wird keine Firewall zwischen der SEPPmail-Appliance und dem internen

Netz verwendet. Die mit ** markierten Regeln entfallen dann.

4.5 SEPPmail-Appliance anschliessen

Falls eine virtuelle SEPPmail-Appliance erworben wurde, so ist das Image in das Host-System zu integrieren und anschliessend zu starten.

Virtuelle Abbilder stehen als OVF-Image für die Hostsysteme ESX, VMware, und RedHat HyperVisor, sowie als VHD-Image für Microsoft Hyper-V zur Verfügung.

Wurde eine Hardware Appliance erworben, so sind folgende Schritte erforderlich:

1. Verbinden der mit LAN1 oder eth0 gekennzeichnete Ethernet-Schnittstelle der SEPPmail-

Appliance mit der Ethernet-Schnittstelle eines Computers. Je nach Hardwareausstattung und

Einstellung der Schnittstellen beider Geräte, muss für diese Art der Verbindung gegebenenfalls ein gekreuztes RJ45 Patchkabel (auch bekannt als Crossover-Kabel) verwendet werden.

Alternativ kann die Verbindung über einen Ethernet-Hub oder Switch mit "normalen" RJ45

Patchkabeln hergestellt werden.

2. Anschliessen der Appliance mittels beiliegendem Stromkabel an das Stromnetz.

4.6 Basiskonfiguration in wenigen Schritten

Dieses Kapitel beschreibt, wie in wenigen Schritten die Basis-Konfiguration des SEPPmail-Systems vorgenommen wird.

4.6.1

Netzwerkeinstellungen und Systemregistrierung

Nachfolgend wird das Integrieren der SEPPmail Appliance in die vorhandene Infrastruktur beschrieben.

Hierfür werden die in

Benötigte Informationen zur Inbetriebnahme

gesammelten Informationen benötigt.

4.6.1.1

Initialer Verbindugsaufbau

In den kommenden Abschnitten wird sowohl der initiale Zugang zu einer

Hardware Appliance

wie auch

Virtuellen Appliance

beschrieben. Ziel ist das initiale erreichen der Webbrowser basierten

Administrationsoberfläche, über welche ausnahmslos die weitere Konfiguration erfolgt.

4.6.1.1.1 Hardware Appliance

Zur erstmaligen Konfiguration der Netzwerkparameter der SEPPmail-Hardware-Appliance besteht die

Möglichkeit einen Bildschirm und Tastatur anzuschliessen und die IP-Adresse temporär an der

Console auf den gewünschten Wert zu ändern. Das weitere Vorgehen für dies Methode ist im Punkt

Consolen Login

beschrieben.

Alternativ kann die SEPPmail-Hardware-Appliance über ein Crossover-Kabel oder über einen Hub direkt mit einem Computer verbunden werden.

Hierfür müssen sich beide Geräte im gleichen IP Subnetz befinden. Gegebenefall muss hierfür die IP-

Adresse des Computers auf eine IP-Adresse zwischen 192.168.1.1/24 - 192.168.1.254/24,

Netwerkmaske 255.255.255.0 geändert werden.

Hinweis:

Die Adresse 192.168.1.60 ist bereits für die SEPPmail-Appliance reserviert. Dies ist die Standard IP-Adresse im Auslieferungszustand.

Beispiel einer entsprechenden Netzwerkeinstellung anhand der Windows Oberfläche

Das weitere Vorgehen ist im Punkt

Login als Administrator

beschrieben.

4.6.1.1.2 Virtuelle Appliance

Bei einer virtuellen Appliance ist das Consolen Fenster des erstmalig gestarteten SEPPmail-Images auf dem Host-System zu öffnen.

Im Anschluss ist wie in Punkt

Consolen Login

beschrieben vorzugehen.

4.6.1.1.3 Consolen Login

Ist die SEPPmail-Appliance fertig hochgefahren, so erscheint ein Login Prompt:

Nach der Anmeldung mit

Standard-Benutzername: admin

Standard-Kennwort: admin wird zur Eingabe der IP-Adresse ( in diesem Beispiel 172.16.161.50 ) aufgefordert

Weiterhin ist das Subnetz ( in diesem Beispiel 255.255.255.0 ) und Gateway Adresse ( in diesem

Beispiel 172.16.161.1 ) einzugeben

Abschliessend wird die URL für das Administrator Login angezeigt:

Nun ist das Web-Administrationsportal der SEPPmail-Appliance - bis zum Reboot - über die

angezeigte URL im Browser zu erreichen ( siehe

Login als Administrator

)

4.6.1.2

Login als Administrator

Sämtliche Verwaltungsmöglichkeiten der SEPPmail-Appliance stehen über eine Webbrowser basierte

Konfigurationsoberfläche zur Verfügung.

Im Auslieferungszustand kann die Konfigurationsoberfläche wie folgt erreicht werden:

Hardware Appliance über CrossOver Kabel oder Hub:

LAN1 - https://192.168.1.60:8443

LAN2 - https://192.168.2.60:8443 virtuelle und Hardware Appliances, bei welchen die IP-Adresse über die Console geändert wurde:

LAN1 - https://<Ihre temporär vergebene IP>:8443

(siehe

Login als Administrator

)

Der Standard-Benutzername lautet:

Das Standard-Kennwort lautet: admin admin

Hinweis:

Erst durch die Registrierung der SEPPmail-Appliance wird eine temporäre, 30tägeige Testlizenz bezogen beziehungsweise eine bereits vorhandene Kauflizenz aktiviert. (siehe

Das System registrieren

Nach erfolgreichem Registrierungsprozess verschwindet die Meldung No valid

license found - Please obtain a valid license.

Bei Aufruf der Konfigurationsoberfläche im Webbrowser erschenit eine Warnung, dass die Webseite unsicher sei. Der Aufruf der Seite muss trotz dieser Meldung fortgesetzt werden.

Hinweis:

Die Meldung erscheint in der Regel nur bis ein gültiges SSL-Zertifikat installiert wurde

(siehe Menüpunkt

SSL

187

4.6.1.3

Netzwerkeinstellungen der SEPPmail-Appliance

Um die Netzwerkparameter der SEPPmail Appliance permanent zu konfigurieren, müssen diese in der

Konfigurationsoberfläche unter dem Menüpunkt

System

eingetragen und gesichert werden.

In der Sektion

IP Addresses

ist für das

Interface 1

die IP-Adresse und die zugehörige Subnetzmaske gemäss des vorhanden

Netzwerkes einzugeben

Hnweis:

Die Definition der Netzmaske wird nach der Classless Inter-Domain Routing (CIDR)

Notation festgelegt.

Die Netzmaske 255.255.255.255 entspricht "/32" (einzelne IP-Adresse)

Die Netzmaske 255.255.255.0 entspricht "/24" (Klasse-C Netzwerk)

Die Netzmaske 255.255.0.0 entspricht "/16" (Klasse-B Netzwerk)

Die Netzmaske 255.0.0.0 entspricht "/8" (Klasse-A Netzwerk)

Siehe auch

System

IP Addresses

119

In der Sektion

Name

sind die Felder

Hostname

und

Domain

zu füllen.

Dabei ist der Hostname ist frei wählbar, zum Beispiel securemailgateway. Der Domain-Name entspricht der DNS-Domain, in welcher sich die Appliance befindet (zum Beispiel ihrefirma.local oder ihredomain.com).

Diese Einstellungen sind die interne Sicht, sie müssen also nicht den Daten, wie sie vom

Internet her Gültigkeit hätten, entsprechen.

Siehe auch

System

Name

121

In der Sektion

DNS

kann zwischen der Verwendung der Root-DNS-Server im Internet (Use built-in DNS Resolver) oder eines explizit anzugebenden DNS-Server gewählt werden (Use the following DNS Servers)

Wird die Einstellung Use built-in DNS Resolver verwendet, kann das Auflösen von Namen unter

Umständen etwas länger dauern, wodurch die Performanz des Systems beeinträchtigt werden kann.

Bei Angabe eines DNS-Servers (

Primary

) ist darauf zu achten, dass dieser auch Domänen Namen im

Internet auflösen kann. Falsche Einträge können zu einem sehr langsamen Antwortverhalten der

Konfigurationsoberfläche sowie Problemen bei der Kommunikation mit Drittsystemen führen. Über die

Eingabefelder

Alternate1

und

Alternate 2

können bei Bedarf weitere, alternative DNS Server eingegeben werden. Dadurch würde bei Ausfall des "Primary" Servers würde der "Alternate 1" übernehmen, sollte auch dieser ausfallen der "Alternate 2".

Siehe auch

System

DNS

122

In der Sektion

Routing

73 wird das zum Subnetz passende

Default Gateway

eingetragen. Diese Eingabe wird benötigt um Netze ausserhalb des Eigenen zu erreichen.

Siehe auch

System

Routing

122

4.6.1.4

Netzwerkkonfiguration prüfen

Um sicherzustellen, dass die vorgenommenen Netzwerkeinstellungen der SEPPmail-Appliance korrekt sind, ist in der Konfigurationsoberfläche unter dem Menüpunkt

Administration

in der Sektion

Update

209

auf die Schaltfläche

Check for update

zu klicken.

Falls eine der beiden folgenden Meldungen erscheint,

You already have the latest version installed

There is a new version available: Installed version is alteVersionsnummer, latest version is neueVersionsnummer

war die Netzwerkkonfiguration erfolgreich.

Erscheint die Meldung

ERROR: unable to connect to update server. Make sure that the device can make

connections to the internet on port 22. ist eine Verbindung in das Internet über Port TCP/22 (SSH) nicht möglich. Die Netzwerkeinstellungen der SEPPmail-Appliance sowie die Firewall- bzw. Router-Einstellungen sind erneut zu prüfen (siehe

Firewall / Router einrichten

4.6.1.5

Das System registrieren

Das Registrieren des SEPPmail-Systems erfolgt im Web-Administrationsportal unter dem Menüpunkt

Administration Sektion

License and registration

209 durch wählen der Schaltfläche

Register this device...

Mit dem Registrieren der Appliance bezieht das System eine 30-tägige Testlizenz wird bei Eingabe des

Activation code

am Ende der Registrierungsseite eine Kauflizenz aktiviert.

Der Activation Code entspricht der Device ID (xxxx-xxxx-xxxx) auf dem "SEPPmail License

Certificate".

Erscheint die Meldung

Registration successful

, so wurde der Registrierungsvorgang erfolgreich abgeschlossen.

4.6.2

Das System auf den neusten Stand bringen

In der Sektion

Update

209

des Menüpunktes

Administration

sind die verschiedenen Update

Optionen zu finden.

Ist die SEPPmail-Appliance bereits auf dem aktuellen Stand, so ist die Meldung

You already have the latest version installed zu sehen. Andernfalls wird die aktuell auf der SEPPmail-Appliance installierte, sowie die auf dem

Update-Server bereitgestellte Version angezeigt

There is a new version available: Installed version is alteVersionsnummer, latest version is

neueVersionsnummer

In diesem Fall ist die Appliance so oft über die Schaltfläche

Fetch update

zu aktualisieren, bis die

Meldung "You already have the latest version installed" erscheint. Durch erneutes Klicken auf die

Schaltfläche

Fetch update

wird gegebenenfalls der Update-Fortschritt in % angezeigt.

Nach jedem Update erfolgt ein Neustart der SEPPmail-Appliance.

4.6.3

Wichtige Sicherheitsmassnahmen

In den kommenden Abschnitten werden folgende Sicherheitsmassnahmen beschrieben:

Ändern des Administrator-Passworts

Festlegen des HTTPS-Protokolls für den sicheren Zugriff auf die Appliance

Erstellen eines Backup Users zur regelmässigen Sicherung der Appliance

Eingabe der Postmaster Adresse für den Empfang von Systemmeldungen

4.6.3.1

Administrator-Kennwort ändern

Aus Sicherheitsgründen sollte das Kennwort des Benutzers admin unbedingt geändert und auf einen entsprechend komplexen Wert gesetzt werden.

Das Ändern des Passwortes kann sowohl über das Menü

Login

in der Sektion

Change Password

114

als auch den Benutzerdetails des Benutzers "admin" im Menü

Users

(siehe

User Data

224

Password

) erfolgen.

4.6.3.2

Festlegen des HTTPS-Protokolls für den sicheren Zugriff zum System

Im Menüpunkt

System

sind nach dem Klicken der Schaltfläche

Advanced view

weitere

Konfigurationsoptionen sichtbar. In den Sektionen

GUI Protocol

123

und

GINA https protocol

werden die Zugriffsoptionen auf die Appliance (HTTP oder HTTPS) eingestellt.

124

Aus Sicherheitsgründen wird empfohlen, die Option

HTTP

zu deaktivieren und sowohl für die

Konfigurationsoberfläche wie auch für das GINA-Interface nur

HTTPS

zuzulassen. Das ungesicherte

HTTP-Protokoll sollte nur dann Verwendung finden, wenn bereits eine vorgelagerte Komponente den

SSL-Tunnel terminiert und die Verbindung zwischen dieser Komponente und der SEPPmail-Appliance

über ein gesichertes Netzwerk stattfindet.

4.6.3.3

Backup Benutzer erstellen

Der Backup Prozess der SEPPmail-Appliance erstellt täglich automatisiert eine Sicherung. Für die

Funktion dieses Prozesses sind zwei Schritte notwendig:

1. Backup Kennwort setzen

Da die Backups der Appliance grundsätzlich verschlüsselt werden, ist die Eingabe eines

Backup Kennwortes zwingend. Das Setzen erfolgt unter dem Menüpunkt

Administration

, in

der Sektion

Backup

210

mittels der Schaltfläche

Change password

2. Zuordnung eines Users zur Gruppe Backup

Nach dem automatischen Erstellen des Backups wird dieses an alle Mitglieder der Gruppe

Backup gesendet. Das Zuordnen von Benutzern erfolgt über den Menüpunkt

Groups

in der

Gruppe

backup

233

über die Schaltfläche

Edit...

Soll für diesen Zweck ein eigener Benutzer angelegt werden, so ist darauf zu achten, dass dieser eine gültige E-Mail-Adresse in der beziehungsweise einer der interne E-Mail Domänen besitzt. Das ziehen einer Verschlüsselungslizenz für diesen Benutzer kann gegebenenfalls durch aktivieren der Optionen "May not encrypt mails" und "May not sign mails" unterbunden werden (sieheBenutzerdetails

User Data

224

Da aufgrund des Aufbaus der Appliance lediglich die Maschinenkonfiguration sowie das

Schlüsselmaterial gesichert werden muss, fallen die Backups extrem klein aus (< 1 MB). Dies macht den Versand per E-Mail unproblematisch.

4.6.3.4

Eingabe der Postmaster Adresse für den Empfang von Systemmeldungen

Damit Benachrichtigungen des SEPPmail-Systems über eventuelle Probleme (Watchdog Meldungen) versendet werden können, ist die Eingabe einer entsprechenden E-Mail Adresse für den Empfang dieser Meldungen im Menü

Mail System

unter der Sektion

SMTP settings

134

in das Feld

Postmaster address

erforderlich.

4.7 Vorbereiten der GINA-Technologie

Um auch mit Kommunikationspartnern, welche selbst über kein Schlüsselmaterial verfügen sicher kommunizieren zu können, kommt die GINA-Technologie zum Einsatz.

Für das initiale Einrichten dieses Verfahrens ist zunächst die Erreichbarkeit der SEPPmail-Appliance aus dem Internet - in der Regel per SSL Port 443 (siehe

Firewall / Router einrichten

) - zu gewährleisten.

Weiterhin sollte auf der Appliance ein gültiges SSL-Zertifikat einer vertrauenswürdigen Certification

Authorothy (CA) eingebunden sein (siehe

SSL

187

Letztendlich sind die GINA-Einstellung über

Edit GINA Settings

169

vorzunehmen.

4.8 Integration in die bestehende E-Mail Infrastruktur

Die Basis-Einrichtung der SEPPmail-Appliance ist mit dem Abarbeiten der vorangegangenen Punkte abgeschlossen.

Für eine Minimalkonfiguration zum Austausch sicherer E-Mails sind die in den folgenden Punkten beschriebenen weiteren Schritte notwendig.

4.8.1

Zu verwaltende E-Mail-Domänen einrichten

Die E-Mail Domänen auf welche das neue SEPPmail-System reagieren soll, sind Menü

Mail

System

Sektion

Managed Domain

130

über die Schaltfläche

Add Domain...

einzugeben.

Dabei wird unter

Domain Name

der Name der E-Mail Domäne eingegeben.

Als

Forwarding Server IP or MX name

wird in der Regel der Groupware Server angegeben, an welchen

die E-Mails intern weitergeleitet werden (siehe auch Kapitel "Add/Edit Managed Domain"

Settings

139

4.8.2

Ausgehenden E-Mail-Verkehr steuern

Das Abgeben der ausgehenden E-mails in das Internet wird im Menü

Mail System

Sektion

Outgoing Server

132

gesteuert. Soll die SEPPmail-Appliance E-Mails direkt an externe E-Mail-

Empfänger im Internet abgeben, so ist die Option Use built-in mail transport agent zu wählen. Sollte an ein vorgelagertes System weitergeleiten werden, so ist die Option Use the following SMTP

server: zu wählen. Dann ist unter

Server name

der entsprechde Name oder die IP-Adresse dieses

Systems einzutragen. Erfordert dieses System eine Authentifizierung, so ist der erforderlich

Benutzername unter

User ID

und das Kennwort unter

Password

einzugeben.

Hinweis:

Bei Verwenden der Einstellung Use built-in mail transport agent wird dringend empfohlen das optionale Protection Pack (VSPP) zu lizensieren und aktivieren, sofern für den eingehenden E-Mail Verkehr nicht etwa ein externer AntiSpam-Dienst vorgeschaltet ist. Andernfalls ist mit erheblichen Beeinträchtigungen, bis hin zum

Erliegen des Mailflusses durch SPAM-Attacken zu rechnen.

4.8.3

Mail Relaying

Damit das interne Groupware System in der Lage ist, ausgehende E-Mails an das SEPPmail-System abzugeben, ist es notwendig, die IP-Adresse des, beziehungsweise unter Umständen auch das Netz in dem die Groupware Server stehen zu berechtigen.

Dies erfolgt durch den Eintrag der IP(s) beziehungsweise des oder der Netze in die dafür vorgesehenen Felder des Menüs

Mail System

in der Sektion

Relaying

135

4.8.4

SSL-Zertifikat einbinden

Eine detaillierte Beschreibung ist im Kapitel des Menüpunktes

SSL

187

zu finden.

Die folgenden Seiten liefern lediglich eine Kurzbeschreibung zur Inbetriebnahme.

4.8.4.1

SSL-Device-Zertifikat selbst erstellen

SEPPmail ermöglicht es, ein eigenes SSL-Device-Certificate über die Konfigurationsoberfläche zu erstellen. Für eine Testinstallation ist es nicht zwingend erforderlich ein kostenpflichtiges SSL-Device-

Certificate zu beschaffen. Das Zertifikat kann auf der SEPPmail-Appliance automatisch generiert und signiert werden.

Hierfür ist in das Menü

SSL

187

zu wechseln und die Schaltfläche

Request an new Certificate...

zu klicken.

Im erscheinenden Menü sind die hier aufgeführten Felder zwingend auszufüllen:

Sektion

Issue To

Parameter Beschreibung

Name or IP (CN)

IP-Adresse oder Hostname unter der SEPPmail aus dem

Internet erreichbar ist. Bei einem selbstsignierten Zertifikat muss der hier angegebene Werte dem Namen in der URL entsprechen unter der SEPPmail angesprochen wird.

Beispiel:

Soll SEPPmail unter der URL

https://securewebmail.

example.tld angesprochen werden, so lautet der im

Feld Name or IP (CN) anzugebende Hostname

securewebmail.example.tld.

E-Mail

Country (C)

Eine gültige E-Mail-Adresse innerhalb der Firma, unter der eine zuständige Person erreicht werden kann.

Land, in dem die Organisation ihren Sitz hat.

Sektion

Attributes

Parameter Beschreibung

Key size (bits)

Signature

In der Regel ist die maximale Schlüssellänge zu wählen um den aktuellen Sicherheitsstandards zu entsprechen.

Für das Erstellen eines selbs signierten Zertifikates ist Create

self-signed certificate auszuwählen.

Um die Erstellung des SSL-Zertifikats auszuführen, ist auf die Schaltfläche

Create Request

zu klicken. Durch die Bestätigung mit folgenden Zertifikatsdetails die Seriennummer des Zertifikats (Serial No.)

79 die Gültigkeitsdauer (Validity) den Fingerprint (SHA1 Fingerprint) ist der Vorgang abgeschlossen.

Hinweis:

Auch das Erstellen eines Wildcard SSL-Zertifikats ist möglich. Wildcard Zertifikate gelten nicht nur für einen dedizierten Host sondern können für mehrere Hosts einer

Domäne verwendet werden.

Beispiel:

Ein SSL-Zertifikat mit dem Namen ginatest.testdomain.net kann nur für diesen einen

Host verwendet werden. Anderenfalls wird eine Zertifikatsfehlermeldung im

Webbrowser angezeigt. Ein Wildcard SSL-Zertifikat können Sie auf beliebigen Hosts einer Domäne verwenden, zum Beispiel ginatest.testdomain.net, webmail.

testdomain.net oder secmail.testdomain.net.

Um ein Wildcard SSL-Zertifikat zu erzeugen, geben Sie den Hostnamen mit einem führenden Stern "*" ein, zum Beispiel *.testdomain.net .

Zur Aktivierung des neuen SSL-Device-Certifikate ist ein Neustart der SEPPmail-Appliance - zum

Beispiel über die Schaltfläche

Reboot

, welche unter

Administration

System

210

Reboot System zu finden ist - notwendig.

Detaillierte Informationen sind unter

Request a new Certificate

190

zu finden.

4.8.4.2

SSL-Device-Zertifikat von einer öffentlichen Zertifizierungsstelle anfordern

Für den produktiven Betrieb der SEPPmail inklusive GINA-Technologie empfiehlt sich dringend das

Verwenden eines Trusted-SSL-Device-Certificate für den SSL-gesicherten Zugriff auf das GINA-

Webmail-System.

Für das Anfordern und anschliessende Einbinden eines gekauften Trusted-SSL-Device-Certificate ist in das Menü

SSL

187

zu wechseln und die Schaltfläche

Request an new Certificate...

zu klicken.

Im erscheinenden Menü sind die hier aufgeführten Felder zwingend auszufüllen:

Sektion

Issue To

Parameter Beschreibung

Name or IP (CN)

IP-Adresse oder Hostname unter der SEPPmail aus dem

Internet erreichbar ist. Bei einem selbstsignierten Zertifikat muss der hier angegebene Werte dem Namen in der URL entsprechen unter der SEPPmail angesprochen wird.

Beispiel:

Soll SEPPmail unter der URL

https://securewebmail.

example.tld angesprochen werden, so lautet der im

Feld Name or IP (CN) anzugebende Hostname

securewebmail.example.tld.

Parameter

E-Mail

Country (C)

Beschreibung

Eine gültige E-Mail-Adresse innerhalb der Firma, unter der eine zuständige Person erreicht werden kann.

Land, in dem die Organisation ihren Sitz hat.

Sektion

Attributes

Parameter Beschreibung

Key size (bits)

Signature

In der Regel ist die maximale Schlüssellänge zu wählen um den aktuellen Sicherheitsstandards zu entsprechen.

Für das Anfordern eines Trusted-SSL-Device-Certificate ist

Create certificate signing request auszuwählen.

Um ein Schlüsselpaar zu erzeugen und den Antrag zur Signierung des öffentlichen Schlüssels

(certificte signing request, kurz CSR) zu erstellen, ist auf die Schaltfläche

Create Request

zu klicken. In der Grünen Statusleiste oben im Menü erscheint danach Certificate request created.

Ganz unten im Menü erscheint die Schaltfläche

Download and Import signed Certificate...

über welche zunächst der CSR zu finden ist. Nach dem Hochladen des CSR zur Trusted CA und dem anschliessenden Erhalt des Zertifikates, kann dieses - gegebenenfalls durch erneutes Klicken auf die

Schaltfläche

Download and Import signed Certificate...

, sofern das Menü zwischenzeitlich gewechselt wurde - unter Import Certificate eingefügt und per Schaltfläche

Import Certificate

importiert werden.

Hinweis:

Falls im oberen Bereich des Menüs die gelb hinterlegte Information Remember to

import the signed certificate angezeigt wird, so wurde zuvor bereits ein

Zertifikatsantrag erstellt.

Das neu erstellte SSL-Device-Zertificate sollte zusammen mit den gegebenenfalls zusätzlich benötigten Intermediate CA-Zertifikate(n) und dem Zertifikat der Root-CA selbst in der Reinhenfolge

1. Public Key des eigenen SSL-Device-Zertifikats

2. Public Key von einer oder mehreren Intermediate CA-Zertifikaten

3. Public Key der Root-CA eingefügt werden

Im Fehlerfall ist das SSL-Device-Zertifikat nicht zu nutzen. Ebenfalls kann dies zu

Problemen beim Zugriff auf die Konfigurationsoberfläche führen. Für diesen Fall sollte sicherheitshalber vor dieser Aktion temporär der HTTP-Port über

System

Advanced View

GUI Protocol

123

HTTP Port

für den Zugriff auf die

Administrationsoberfläche (http://<Appliance>:8080) freigegeben werden.

Zur Aktivierung des neuen SSL-Device-Certifikate ist ein Neustart der SEPPmail-Appliance - zum

Beispiel über die Schaltfläche

Reboot

, welche unter

Administration

System

210

Reboot System zu finden ist - notwendig.

Detaillierte Informationen sind unter

Request a new Certificate

190

zu finden.

4.8.4.3

Bestehendes SSL-Device-Zertifikat verwenden

Für den produktiven Betrieb der SEPPmail inklusive GINA-Technologie empfiehlt sich dringend das

Verwenden eines Trusted-SSL-Device-Certificate für den SSL-gesicherten Zugriff auf das GINA-

Webmail-System.

Für das Einbinden eines gekauften Trusted-SSL-Device-Certificate ist in das Menü

SSL

zu wechseln und die Schaltfläche

Request an new Certificate...

zu klicken.

Im erscheinenden Menü ist in der Sektion

Upload existing key

191

das Einbinden auf zwei Arten abhängig vom vorliegenden Zertifikats-Format (pem oder PKCS#12 also p12 oder pfx) - möglich.

Dabei werden die ersten beiden Parameter ausschliesslich für die Integration des pem-Formats, die beiden letzteren Parameter für die Integration des PKCS#12-Formates benötigt.

Parameter

X.509 Key

Note: Remove password before uploading a key

X.509 Certificate

(and optional intermediate certificates)

Key and certificate in

PKCS12 format

Beschreibung

In dieses Feld wird der Private Schlüssel aus der pem-Datei eingefügt.

Hierfür wird die pem-Datei mit einem Editor geöffnet- Falls der private

Schlüssel durch ein Kennwort geschützt ist, muss dieses zuvor entfernt werden. Im Anschluss wird der Private Schlüssel (dieser beginnt mit -----

BEGIN PRIVATE KEY----- und endet mit -----END PRIVATE KEY-----) in das Eingabefeld kopiert.

Die Eingabe muss unbedingt mit einer Leerzeile abgeschlossen werden!

In dieses Feld wird der Öffentliche Schlüssel aus der pem-Datei eingefügt. Dieser ist unterhalb des Privaten Schlüssel in der pem-Datei zu finden und beginnt mit -----BEGIN CERTIFICATE----- und endet mit

-----END CERTIFICATE-----.

Unter Umständen sind in der pem-Datei weitere Zertifikate enthalten.

Dabei handelt es sich um Zwischen- oder auch Intermediate- Zertifikate, welche unterhalb des Öffentlichen Schlüssels in dieses Feld kopiert werden müssen. Zuletzt wird das Zertifikat der Root CA eingefügt.

Die Eingabe muss unbedingt mit einer Leerzeile abgeschlossen werden!

Hinweis:

In dieses Eingabefeld sollten alle notwendigen

Zwischenzertifikate für eine vollständige

Zertifikatskette eingefügt werden. Eine unvollständige Zertifikatskette führt bei der

Zertifikatsprüfung immer dann zu Problemen, wenn der Gegenstelle diese nicht bereits bekannt ist. Internet-Tools - wie zum Beispiel CheckTLS zeigen dann einen falschen TLS-Status an.

Nicht jede pem-Datei enthält die komplette

Zertifikatskette. In diesem Fall müssen die benötigten Zwischenzertifikate gegebenenfalls anderweitig besorgt werden.

Über die Internet-Browser Schaltfläche "Datei auswählen" wird die

PKCS#12-Datei (diese hat die Endung .p12 oder .pfx) ausgewählt.

Parameter

PKCS12 password

Beschreibung

Hinweis:

Auch hier muss darauf geachtet werden, dass diese Datei die komplette Zertifikatskette, also auch die Zwischenzertifikate enthält.

Gegebenenfalls kann nach dem Import der

PKCS#12 Datei ein Backup des Zertifikates (siehe

SSL

187

) vorgenommen werden. Die dadurch zur

Verfügung stehende pem-Datei kann mit einem

Editor geöffnet und anschliessend wie oben beschrieben wieder inklusive Zwischenzertifikate importiert werden.

Nachdem eine PKCS#12-Datei den Privaten Schlüssel enthält, ist diese

Passwort geschützt. Das Passwort muss vor dem Import der oben ausgewählten PKCS#12-Datei in dieses Eingabefeld eingegeben werden.

Über die Schaltfläche

Upload Key and Certificate

wird das SSL-Zertifikat in die Appliance hochgeladen.

Zur Aktivierung des neuen SSL-Device-Certifikate ist ein Neustart der SEPPmail-Appliance - zum

Beispiel über die Schaltfläche

Reboot

, welche unter

Administration

System

210

Reboot System zu finden ist - notwendig.

Detaillierte Informationen sind unter

Request a new Certificate

190

zu finden.

4.8.5

E-Mail-Datenfluss umstellen

Um den sicheren E-Mail-Verkehr mit der SEPPmail-Appliance zu ermöglichen, müssen folgende

Änderungen am bestehenden E-Mail-Server vorgenommen werden:

In das Internet:

1. SEPPmail-Appliance als Smarthost definieren

Die SEPPmail Appliance wird nach der Integration in die bestehende E-Mail-Umgebung die

Rolle eines SMTP-Gateways übernehmen. Der E-Mail-Server übermittelt somit E-Mails nicht mehr direkt nach extern, beziehungsweise an das gegebenenfalls bereits vorhandene SMTP-

Gateway (zum Beispiel Spam-Filter), sondern (neu) nun an die SEPPmail-Appliance.

Um diese Änderung vorzunehmen, muss auf dem bestehenden E-Mail-Server der interne

Hostname beziehungsweise IP-Adresse der SEPPmail-Appliance als Smarthost definiert werden.

Auf der Appliance sind die Relaying Einstellungen zu beachten (siehe Abschnitt

Mail Relaying

2. Autorisieren der SEPPmail-Appliance für den E-Mail-Versand

a) Ist die SEPPmail-Appliance direkt mit dem Internet verbunden, so sind die korrekten

Firewall- beziehungsweise Router-Einstellungen zu gewährleisten (siehe Abschnitt

Firewall / Router einrichten

b) Ist der SEPPmail-Appliance zum Internet hin noch ein weiterer Smarthost (zum Beispiel ein

Spam-Filter) vorgeschaltet, so ist der interne Hostname beziehungsweise die IP-Adresse der SEPPmail-Appliance auf diesem Smarthost in die Liste der autorisierten E-Mail-Relay

Systeme einzutragen.

Die Appliance ist entsprechend einzustellen (siehe

Ausgehenden E-Mail Verkehr steuern

Aus dem Internet:

1. Umstellung des MX-Eintrages

War der E-Mail-Server bislang direkt mit dem Internet verbunden, so muss der vorhandene MX-

Eintrag zukünftig nicht mehr auf den Hostnamen beziehungsweise die IP-Adresse des E-Mail-

Servers, sondern (neu) auf die SEPPmail-Appliance zeigen.

2. Umstellung des Smarthost

Nimmt ein Smarthost die E-Mails aus dem Internet entgegen und leitete diese bislang direkt an den E-Mail-Server weiter, so muss dieser die E-Mails zukünftig an die SEPPmail-Appliance abgeben.

ACHTUNG

Mit dieser Anpassung wird die SEPPmail-Appliance in den E-Mail-Datenfluss integriert. Alle E-Mails werden nach der Umstellung an die SEPPmail-

Appliance gesendet.

Das Umstellen des E-Mail-Datenflusses darf erst dann erfolgen, wenn alle anderen Konfigurationsschritte der SEPPmail-Appliance abgeschlossen sind.

Andernfalls ist eine Beeinträchtigung des E-Mail-Verkehrs nicht ausgeschlossen.

4.8.6

Steuern der Appliance

Die von der Appliance durchzuführenden gewünschten Aktionen - zum Beispiel Signieren und/oder

Verschlüsseln - können als globale Aktion an der Appliance oder über vordefinierte Merkmale individuell am Client (siehe

Betreffzeilen Schlüsselworte

Microsoft Outlook Vertraulichkeit

Microsoft Outlook AddIn

) ausgelöst werden.

Automatisierte Steuerungsmöglichkeiten sind zum Beispiel über LDAP-Abfragen oder dem definieren von Gruppen (siehe

Groups

233

) möglich. Diese Optionen stehen über sogenannte

Custom

Commands

164

des Menüs

Mail Processing

der Sektion

Ruleset Generator

zur Verfügung.

Diese Basis Steuerungsmöglichkeiten sind bereits vordefiniert. Eine genaue Beschreibung der

Konfigurationsmöglichkeiten zur Steuerung der Appliance ist unter

Mail Processing

Ruleset

Generator

157

zu finden.

Für eine Korrekte Funktion der Appliance muss initial ein Ruleset generiert werden

(siehe

Mail Processing

Sektion

Ruleset Generator

157

Schaltfläche

Save and

Create Ruleset

ganz unten).

4.8.6.1

Betreffzeilen Schlüsselworte / X-Header

Das Verwenden von Betreffzeilen Schlüsselworte (siehe Tabelle 1) - welche bei Bedarf verändert werden können - für das Steuern der Appliance durch den Client gewährleistet die Unabhängigkeit vom eingesetzten E-Mail Client.

Ebenso können (X)-Header für das Ansteuern der kryptographischen Aktionen ausgewertet werden

(ebenfalls Tabelle 1) welche zum Beispiel in

IBM Notes mittels angepasster Mailschablonen oder Novell Groupwise über Vorlagen gesetzt werden können.

Betreffzeilen

Schlüsselwort

[plain]

(x-)header / Wert x-smplain / yes

[confidential] sensitivity / companyconfidential x-smenc / yes

[priv] sensitivity / private x-smwebmail / yes

E-Mail mit diesem Kennzeichen durchlaufen nicht das Ruleset und werden somit kryptographisch unbehandelt versendet

Anfordern der Verschlüsselung (best effort)

[emptypw]

[SMS:<Mobil funknummer>]

[zip]

[noenc]

[sign]

[nosign] x-smplain / yes x-smsign / yes x-smnosign / yes

E-Mail mit diesem Kennzeichen werden mittels

GINA-Technologie verschlüsselt (Stichwort

Lesebestätigung)

Die Notwendigkeit der Eingabe eines

Initialpasswortes bei GINA-E-Mails wird unterdrückt

(Sicherheitstechnisch bedenklich)

Mobilfunknummer zur Übertragung des

Initialpasswortes einer GINA-E-Mail* versendet den verschlüsselten E-Mail-Teil einer

GINA-Nachricht grundsätzlich im ZIP- anstatt im

HTML-Format. Dies wird zum Beispiel benötigt, wenn der Empfänger Outlook Web Access (OWA)

2003 verwendet, da GINA-Nachrichten im HTML-

Format aus OWA 2003 nicht entschlüsselt werden können.

Verschlüsseln wird unterdrückt, sofern dies als

Standard im Ruleset definiert wurde

Anfordern der Signierung

Signieren wird unterdrückt, sofern dies als Standard

Betreffzeilen

Schlüsselwort

(x-)header / Wert

[lfm]

[lfm:nocrypt]

Tabelle 1

(*Funktionen, welche Zusatzllizenzen erfordern)

im Ruleset definiert wurde

Aktiviert das Large File Management, unabhängig der E-Mail Grösse*

Der Empfänger Einer LFM Mail muss sich für das

Abholen des "Large Files" nicht authentifizieren*

4.8.6.2

Microsoft Outlook Vertraulichkeit

Eine weitere Möglichkeit die SEPPmail-Appliance zu steuern ist über die Vertraulichkeitseinstellung bei

Microsoft Outlook.

Dabei wird die eingestellte Vertraulichkeit der E-Mail (siehe Abbildung) ausgewertet. Steht diese auf

"Vertraulich" so wird das Verschlüsseln der E-Mail angefordert. Wird hingegen "Privat" verwendet, so wird die GINA-Technologie erzwungen (siehe

Betreffzeilen Schlüsselworte / X-Header

Tabelle 1, sensitivity header)

Nachrichtenoption »Vertraulich« in Outlook

4.8.6.3

Microsoft Outlook AddIn

Um den Benutzerkomfort zu steigern steht für Microsoft Outlook ein

AddIn

103

zum kostenfreien

Download (http://dl.seppmail.ch) zur Verfügung.

4.9 Clustern mehrer Systeme

Dieses Kapitel beschreibt die grundsätzliche Funktionsweise von Clustern und zeigt die Möglichkeiten des Einbindens von SEPPmail-Appliances auf.

Die SEPPmail-Appliance verfügt über alle notwendigen Funktionen für ein eigenständiges Clustering und Loadbalancing. Natürlich ist das Einbinden in Infrastrukturen mit bereits vorhandenen externen

Loadbalancern beziehungsweise Loadbalancing Verfahren ebenso möglich.

4.9.1

Allgemein

Ein Cluster bezeichnet einen Rechnerverbund aus mehreren vernetzten Computersystemen. Diese miteinander vernetzten Computersysteme sind zwar physisch getrennt werden aber logisch als eine

Einheit betrachtet. So ist es möglich, dass ein Cluster als ein einziges logisches System angesprochen werden kann, tatsächlich aber aus mehreren physikalischen Systemen besteht.

Das Einrichten beziehungsweise das Hinzufügen von Maschinen zu einem Cluster erfolgt - wie in

"Abbildung 1" dargestellt - im Menü

Cluster

(siehe auch

Cluster

215

Abbildung 1 - Einrichten eines Clusters

Bei einem bestehenden Cluster synchronisieren alle Cluster Members ihre Konfigurationsdatenbanken ohne merklichen Zeitverlust. Das heisst alle Cluster Members sind gleichberechtigt.

Konfigurationsänderungen werden somit sofort übernommen, egal an welchem Cluster Member sie vorgenommen werden ("siehe Abbildung 1.1")

Abbildung 1.1 - Replikation im Cluster

Für das Einrichten beziehungsweise den Betrieb eines Clusters gibt es mehrere Beweggründe. Je nach Zielsetzung unterstützt die SEPPmail-Appliance verschiedene Betriebsarten, welche wie folgt unterschieden werden:

Hochverfügbarkeits Cluster

Diese Art des Clusters dient dem Gewährleisten der Ausfallsicherheit

Loadbalancing Cluster

Ein Loadbalancing Cluster dient der Lastverteilung auf mehrere Maschinen. Dabei können unterschiedliche Verfahren zum Einsatz kommen.

Geo Cluster

Repliziert Konfigurationsdatenbanken auf geographisch voneinander getrennten Sytemen.

Frontend/Backend Cluster

Bei Frontend-Backend Clustern verfügt das Frontend System über keine eigene Datenbank, sondern wird bei Bedarf vom Backend-System mit Daten gespeist. Somit kann die Frontend

Maschine in einer Demilitarisierten Zone (DMZ) betrieben werden, in welcher keine

Datenhaltung erlaubt ist.

Secure Webmail Satellite

Trennung der GINA-Technologie vom E-Mail verarbeitenden System (Stichwort DMZ-Struktur).

Unterstützen externer redundanter Systeme

Dabei sind auch Kombinationen aus den verschiedenen Betriebsarten möglich.

Die zumeist benötigten virtuellen IP Adressen (IP Alias Adressen) für das Ansprechen eines Clusters als logische Einheit ist im Menü

System

Advanced View

IP ALIAS Addresses

120

vorzunehmen.

Hinweis:

Virtuelle IP Adressen dienen ausschliesslich dem Ansprechen eines Clusters von aussen.

Wird eine E-Mail von einer Cluster-Maschine versandt, so geschieht dies immer mit der physikalischen IP Adresse der jeweiligen Maschine.

Hinweis:

Bei der Dimensionierung der Anzahl und Leistungsfähigkeit der Systeme in einem

Cluster ist immer darauf zu achten, dass bei Ausfall eines Systems das oder die verbleibende(n) System(e) die dadurch entstehende Mehrlast verarbeiten kann/ können.

4.9.2

Hochverfügbarkeits Cluster

Die Ausfallsicherheit des SEPPmail Systems kann durch die Bildung eines Clusters erhöht werden.

Das SEPPmail System besitzt eine integrierte Clusterfunktionalität auf Basis des CARP Protokolls

(siehe auch http://de.wikipedia.org/wiki/Common_Address_Redundancy_Protocol ).

Um einen Cluster zu bilden sind mindestens zwei SEPPmail-Systeme erforderlich die sich gegenseitig

überwachen. Fällt ein System aus bzw. antwortet dieses nicht mehr auf Überwachungsanfragen, so

übernimmt das zweite System dessen Funktion. Ist das ausgefallene System wieder verfügbar bzw. es antwortet wieder auf Überwachungsanfragen, so übernimmt es wieder seine ursprüngliche Aufgabe.

Diese Funktion kann mit bis zu neun SEPPmail-Systemen abgebildet werden, wodurch eine sehr hohe

Ausfallsicherheit erreicht werden kann.

Das Hochverfügbarkeitscluster kann sowohl mit SEPPmail-Systemen auf Hardware Basis wie auch auf Basis von virtualisierten Appliances abgebildet werden. Ein Mischbetrieb beider Systeme ist ebenso möglich.

Funktion eines Hochverfügbarkeits Clusters

Bei diesem Verfahren werden einem Cluster eine oder mehrere virtuelle IP Adresse(n) mit verschiedenen Prioritäten zugeordnet. Jedes Cluster Member System hat unabhängig von der zugewiesenen virtuellen Cluster IP-Adresse eine jeweils eigene eindeutige IP-Adresse. Über diese eigene eindeutige IP-Adresse kann jedes Cluster Member System explizit angesprochen werden.

Beispiel:

In der folgenden Abbildung ist die virtuelle Cluster IP-Adresse des Clusters 10.10.0.1. Die Cluster

Member Systeme haben in unserem Beispiel die IP Adressen 10.10.0.9 und 10.10.0.10.

Abbildung 2 - Schematische Darstellung eines Hochverfügbarkeitsclusters

Das Cluster selbst wird von anderen Systemen, zum Beispiel einem internen E-Mail Server oder einem vorgelagerten E-Mail Relay Server (Gateway) über die eingerichtete(n) virtuelle(n) IP-Adresse

(n) angesprochen. Im Beispiel oben ist das die IP-Adresse 10.10.0.1.

Wird das Cluster selbst über seine Cluster IP-Adresse angesprochen, so reagiert immer das Cluster

Member System mit der höchsten Priorität auf die angesprochene virtuelle Cluster IP-Adresse. Alle anderen Cluster Member Systeme mit niedrigerer Priorität reagieren nicht auf die virtuelle Cluster IP-

Adresse, solange ein Cluster Member System mit einer höheren Priorität verfügbar ist.

Fällt das Cluster Member System mit der höchsten Priorität aus, so übernimmt automatisch ein

Cluster Member System mit der nächst niedrigeren Priorität die virtuelle Cluster IP Adresse inclusive der Funktion des ausgefallenen Cluster Member Systems.

Die Prioritäten sind in der folgenden Reihenfolge geordnet:

1. Primary

2. Secondary

3. Backup

Das Einrichten der Priorität des jeweiligen Cluster Member Systems ist im Menü

System

Advanced View

IP ALIAS Addresses

120

Priority

) vorzunehmen.

4.9.3

Loadbalancing Cluster

Ein Loadbalancing innerhalb eines Clusters kann durch mehrere Verfahren erreicht werden. Dabei bietet SEPPmail ein in die Appliance integriertes Verfahren an. Ebenso kann eine Lastverteilung auf die einzelnen Cluster Member eines SEPPmail-Clusters durch externe Loadbalancer oder

Loadbalancing Verfahren erfolgen. Die gängigsten werden an dieser Stelle aufgeführt:

Aufteilen des Ein- und Ausgehenden Verkehrs

90 auf je ein Cluster Member System. Das Abgeben von E-Mails an den Cluster Partner tritt dabei erst bei Erreichen eines entsprechenden Lastzustandes in Kraft.

Nutzen des DNS Round Robin Verfahrens

Nutzen eines externen Loadbalancers

Das Failover-Verhalten des Clusters wird durch diese Konfigurationen nicht verändert.

4.9.3.1

Aufteilen des Ein- und Ausgehenden Verkehrs

Das Aufteilen des ein- und ausgehenden E-Mail Datenflusses erfolgt - wie in "Abbildung 3" dargestellt durch eine statische Konfiguration, in welcher neben den physikalischen IP-Adressen der Appliances mit zwei weiteren, virtuellen IP Adressen (IP Alias Adresses) gearbeitet wird. Dabei existieren zwei

SEPPmail-Systeme die mit entgegengesetzter Priorität auf die zwei virtuellen IP-Adressen reagieren.

Dadurch erhält jeweils das eine System alle eingehenden und das andere alle ausgehenden E-Mails.

Im Detail

Ausfallsicherheit

Jedes SEPPmail System hat eine eigene, physikalische IP-Adresse über welche nur dieses System angesprochen werden kann. Diese Adresse wird in der Regel für die individuelle Konfiguration der

Appliance und für das Synchronisieren der Appliances untereinander ( blaue Pfeile "Abbildung1") verwendet. in "Abbildung 3" sind dies die IP-Adressen 10.10.0.9 und 10.10.0.10.

Zusätzlich werden zwei virtuelle IP-Adressen eingerichtet, um die beiden SEPPmail-Systeme logisch zu jeweils einer Gruppe zusammenzufassen. In "Abbildung 3" sind diese virtuellen IP-Adressen

(Gruppen) farblich getrennt dargestellt.

Dabei wird die

virtuelle IP-Adresse 10.10.0.1 (grün)

vom internen E-Mail Server für das Versenden

ausgehender E-Mails

angesprochen. Da diese

virtuelle IP-Adresse

von der Maschine mit der physikalischen

IP 10.10.0.9

primär

bedient wird, fliesst der gesamte ausgehende E-Mail Verkehr im

Normalbetrieb über dieses System.

Die

virtuelle IP-Adresse 10.10.0.2 (orange)

wird vom externen E-Mail Server oder auch einem vorgelagerten E-Mail Relay (zum Beispiel Firewall) für das Empfangen

eingehender E-Mails

angesprochen. Da diese

virtuelle IP-Adresse

von der Maschine mit der physikalischen

IP 10.10.0.10

primär

bedient wird, fliesst der gesamte eingehende E-Mail Verkehr im Normalbetrieb über dieses

System.

In "Abbildung 3",

grün dargestellt

, ist die

virtuelle IP-Adresse 10.10.0.1

für alle ausgehenden E-

Mails zuständig. Hier ist das Cluster Member System mit der IP-Adresse 10.10.0.9 als

Primary

eingerichtet und reagiert immer als erstes System, wenn die

virtuelle IP-Adresse 10.10.0.1

angesprochen wird. Das Cluster Member System mit der IP-Adresse 10.10.0.10 ist als

Secondary

eingerichtet und reagiert nur dann, wenn der Cluster Member

Primary

- also das System mit der IP

10.10.0.9 - nicht verfügbar ist.

In "Abbildung 3",

orange dargestellt

, ist die

virtuelle IP-Adresse 10.10.0.2

für alle eingehenden E-

Mails zuständig. Hier ist das Cluster Member System mit der IP-Adresse 10.10.0.10 als

Primary

eingerichtet (entgegengesetzt der vorherigen Darstellung) und reagiert somit immer als erstes System,

91 wenn die virtuelle IP-Adresse 10.10.0.2

angesprochen wird. Das Cluster Member System mit der IP-

Adresse 10.10.0.9 ist als

Secondary

eingerichtet und reagiert nur dann, wenn der Cluster Member

Primary

- also das System mit der IP 10.10.0.10 - nicht verfügbar ist.

Das heisst, fällt in diesem Konstrukt eine Maschine aus, so übernimmt die jeweils andere Maschine deren Aufgabe. Am Beispiel der "Abbildung 3" würde also bei Ausfall des Systems mit der physikalischen IP 10.10.0.9 - welches primär den ausgehenden E-Mail Verkehr über die

virtuelle IP-

Adresse 10.10.0.1

annimmt - ausfallen, so würde das

secundär

für die

virtuelle IP-Adresse

10.10.0.1

konfigurierte System - also das mir der IP 10.10.0.10 - den ausgehenden E-Mail Verkehr zusätzlich übernehmen.

Loadbalancing

Um gegebenenfalls Lastspitzen abfangen zu können, bietet die SEPPmail-Appliance in einer solchen

Umgebung weiterhin die Möglichkeit, bei erreichen eines definierten Lastzustandes am Primary

System Last an das Secondary System abzugeben (siehe auch

System

Advanced View

SMTP

Loadbalancing

121

)

Zusammenfassung

Jedes einzelne SEPPmail System kann über zwei verschiedene virtuelle IP-Adressen angesprochen werden und reagiert mit jeweils unterschiedlichen Prioritäten einmal als Primary und einmal als

Secondary. Dadurch ist der Betrieb beim Ausfall eines Cluster Member Systems weiterhin möglich.

Das verbliebene Cluster Member System übernimmt dann zusätzlich die Arbeit des nicht mehr verfügbaren Systems und wird alle ein- und ausgehenden E-Mails verarbeiten.

Für die Nutzung von Enhanced Secure Webmail kann eine virtuelle Cluster IP-Adresse 10.10.0.1

angesprochen werden. In Abhängigkeit der Cluster Member Prioritäten wird im Beispiel in Abbildung 3 das Cluster Member System mit der IP-Adresse 10.10.0.9 antworten, da dies mit der Priorität

"Primary" eingerichtet ist. Ist dieses System nicht verfügbar, so wird das Cluster Member System mit der IP-Adresse 10.10.0.10 antworten, da dies mit der Priorität "Secondary" eingerichtet ist.

Das Einrichten der virtuellen IP-Adressen und das Zuweisen den Prioritäten des jeweiligen Cluster

Member Systems ist im Menü

SystemSystem

Advanced View

IP ALIAS Addresses

vorzunehmen.

120

Abbildung 3 - Schematische Darstellung der statischen Aufteilung für ein- und ausgehenden E-Mails

4.9.3.2

Nutzen des DNS Round Robin Verfahrens

In der Konfiguration des internen und externen E-Mail Servers wird nicht mehr eine virtuelle Cluster IP-

Adresse für den E-Mail Versand angegeben sondern jeweils ein Hostname, zum Beispiel "SEPPmail.

meinefirma.ch" der bei ein- und ausgehenden E-Mails angesprochen wird. Im DNS ist es möglich zu jedem Hostnamen mehrere IP-Adressen anzugeben. Dadurch kann eine einfache Lastverteilung erreicht werden.

Fragt nun zum Beispiel der interne E-Mail Server den für den E-Mail Versand angegebenen

Hostnamen (SEPPmail.meinefirma.ch) des SEPPmail Clusters beim DNS Server an, so werden immer alle - diesem Hostnamen zugeordneten - IP-Adressen, also

10.10.0.1

und

10.10.0.2

zurückgeliefert, dies aber jedes Mal in unterschiedlicher Reihenfolge. Der interne E-Mail Server wird im Normalfall die erste vom DNS Server gelieferte IP-Adresse für den Versand der E-Mail verwenden.

Durch das verwenden virtueller IP-Adressen in diesem Aufbau, wird die Ausfallsicherheit gewährleistet, da in diesem Fall bei ausfall einer Maschine die verbleibende Maschine beide (virtuelle)

IP-Adressen bedienen wird. "Abbildung 3" zeigt eine logische Darstellung des Szenarios.

Im Detail

Jedes SEPPmail System hat eine eigene, physikalische IP-Adresse über welche nur dieses System angesprochen werden kann. Diese Adresse wird in der Regel für die individuelle Konfiguration der

Appliance und für das Synchronisieren der Appliances untereinander ( blaue Pfeile "Abbildung 4") verwendet. In "Abbildung 4" sind dies die IP-Adressen 10.10.0.9 und 10.10.0.10.

Zusätzlich werden zwei virtuelle IP-Adressen eingerichtet, um die beiden SEPPmail-Systeme logisch zu jeweils einer Gruppe zusammenzufassen. In "Abbildung 4" sind diese virtuellen IP-Adressen

(Gruppen) farblich getrennt dargestellt.

Der interne und der externe E-Mail Server sprechen für den Versand von ein- und ausgehenden E-

Mails an das SEPPmail Cluster System einen Hostnamen (SEPPmail.meinefirma.ch)statt virtueller IP-

Adressen an. Wird eine Anfrage für diesen Hostnamen an den DNS-Server gestellt, so wird der

Hostname in alle eingerichteten IP-Adressen aufgelöst.

Im Beispiel entsprechen die aufgelösten IP-Adressen den virtuellen Cluster IP-Adressen wie in

"Abbildung 4" dargestellt.

Dabei sind die Rollen Primary und Secondary, für das Verarbeiten dieser virtuellen IP-Adressen auf den beiden Systemen entgegengesetzt konfiguriert (Stichwort Ausfallsicherheit).

Die

virtuelle IP-Adresse 10.10.0.1 (grün)

und die

virtuelle IP-Adresse 10.10.0.2 (orange)

dargestellt, werden dem Hostnamen (SEPPmail.meinefirma.ch) zugeordnet.

Wird dieser Hostname am DNS Server abgefragt, so gibt dieser bei jeder ersten Anfrage

SEPPmail.meinefirma.ch 1800 IN A 10.10.0.1

SEPPmail.meinefirma.ch 1800 IN A 10.10.0.2

zurück. Bei jeder zweiten Anfrage wird der DNS Server die zugeordneten IP-Adressen in umgekehrter

Reihenfolge

SEPPmail.meinefirma.ch 1800 IN A 10.10.0.2

SEPPmail.meinefirma.ch 1800 IN A 10.10.0.1

zurückgeben. Da das Anfragende System in der Regel die jeweils zuerst gelieferte IP-Adresse verwendet entsteht so eine zahlenmässige Aufteilung der Anfragen und dadurch eine Lastverteilung.

Zusammenfassung

Beim Versand von ein- und ausgehenden E-Mails über das SEPPmail Cluster wird statt einer virtuellen

Cluster IP-Adresse ein Hostname im jeweiligen E-Mail Server angegeben. Dieser wird dann zur

Laufzeit in die zugehörigen IP-Adressen aufgelöst. So können der interne und der externe E-Mail

Server ein- und ausgehende E-Mails wahlweise an eine dieser aufgelösten IP-Adressen senden.

Durch den Einsatz virtueller Cluster IP-Adressen reagieren die Cluster Member Systeme je nach

Priorität, wodurch die Ausfallsicherheit gewährleistet wird.

Durch die DNS Round-Robin-Funktion kann für den ein- und ausgehenden E-Mail Datenfluss eine

Lastverteilung erreicht werden.

Quelle: Wikipedia,

http://de.wikipedia.org/wiki/Lastverteilung_per_DNS

Das Einrichten der virtuellen IP-Adressen und das Zuweisen den Prioritäten des jeweiligen Cluster

Member Systems ist im Menü

System

Advanced View

IP ALIAS Addresses

120

vorzunehmen.

Abbildung 4 - Schematische Darstellung der Lastverteilung durch das DNS Round-Robin-Verfahren für ein- und ausgehende E-Mails

4.9.3.3

Nutzen eines externen Loadbalancers

Bei Einsatz externer Loadbalancer sind diese für das gleichmässige Verteilen der Last an die

SEPPmail Cluster Member Systeme verantwortlich (siehe "Abbildung 5"). Ebenso müssen diese externen Loadbalancing Systeme den Ausfall eines Cluster Member Systems erkennen und somit für die Ausfallsicherheit des Gesamtsystems sorgen.

Im Detail

Die Cluster-Funktionalität von SEPPmail wird in diesem Szenario lediglich für die Synchronisation der

Konfiguration zwischen den Cluster Member Systemen verwendet. Das Entscheiden, welches

System auf ein- und ausgehende E-Mails reagiert wird durch vorgelagerte Loadbalancer getroffen.

Diese verteilen je nach Konfiguration und Lastsituation die E-Mails wahlweise an ein bestimmtes

Cluster Member System. Hierbei wird jedes Cluster Member System - im Gegensatz zu den anderen

Cluster Varianten - über seine eigene, physikalische IP-Adresse angesprochen. In "Abbildung 5.1" sind dies die IP-Adressen 10.10.0.9 und 10.10.0.10.

Zu beachten ist an dieser Stelle das Realisieren des SSL Zugriffs für Enhanced Secure Webmail (

grün

dargestellt). Kann dieser nicht wie in "Abbildung 5.1 dargestellt von einem externen

Loadbalancer mit verarbeitet werden, so besteht bei Bedarf die Möglichkeit, diesen Zugriff über eine virtuelle Cluster IP-Adresse (siehe "Abbildung 5.2") - im Beispiel

10.10.0.1

- zu realisieren. In

Abhängigkeit der Cluster Member Prioritäten wird im Beispiel der "Abbildung 5.2" das Cluster Member

System mit der IP-Adresse 10.10.0.9 antworten, da dies mit der Priorität "Primary" eingerichtet ist. Ist dieses System nicht verfügbar, so wird das Cluster Member System mit der IP-Adresse 10.10.0.10

und der Priorität "Secondary" die Funktion übernehmen.

Abbildung 5.1 - Schematische Darstellung der dynamischen Aufteilung für ein- und ausgehende E-Mails durch einen externen Loadbalancer

Abbildung 5.2 - Schematische Darstellung der dynamischen Aufteilung für ein- und ausgehende E-Mails durch einen externen Loadbalancer unter Verwendung einer virtuellen IP-Adresse für Enhanced Secure Webmail

4.9.4

Geo Cluster

Ein Geo-Cluster (auch "Multisite System" genannt) dient dem Replizieren von

Konfigurationsdatenbanken zwischen geographisch voneinander getrennten SEPPmail-Systemen, zum Beispiel zwischen verschiedenen Standorten eines Unternehmens.

Beispiel

Ein Unternehmen ist weltweit tätig und betreibt aus diesem Grund mehrere Rechenzentren auf verschiedenen Kontinenten. Die Unternehmensstandorte selbst sind alle durch ein VPN verbunden und haben in jedem Rechenzentrum einen Zugang zum Internet. Innerhalb dieses internen

Unternehmensnetzwerks besteht ein E-Mail Transportsystem, zum Beispiel auf Basis von Microsoft

Exchange oder IBM Domino. Die nach extern gesendeten E-Mails können je nach intern abgebildeter

Richtlinie an verschiedenen Internetzugängen des Unternehmens ins Internet versendet werden. So können beispielsweise bei Ausfall eines Internetzugangs an einem Standort die E-Mails dieses

Standortes über den Internet Zugang eines Anderen Standortes versendet werden, sofern die VPN-

Verbindung zwischen den Standorten von diesem Ausfall nicht betroffen ist.

In einem derartigen Konstrukt muss die notwendige kryptographische E-Mail Verarbeitung an allen

Internetzugängen gleichermassen funktionieren. Um dies zu gewährleisten, müssen die

Konfigurationsdatenbanken sowie das Schlüsselmaterial an allen Kryptographie-Gateways -

SEPPmail-Appliances - identisch gehalten werden.

Dies wird durch die Geo-Cluster Funktion des SEPPmail-Systems realisiert, so dass stets die konsistente Konfiguration aller Systeme gewährleistet ist.

Abbildung 6 - Schematische Darstellung einer Geo-Cluster Struktur

4.9.5

Frontend/Backend Cluster

Ist aufgrund einer DMZ (DeMilitarisierte Zone) Struktur die Datenhaltung - insbesondere die

Schlüsselverwaltung - innerhalb des Netzwerk-Standortes des E-Mail verarbeitenden Systems nicht erlaubt, so ermöglicht der Frontend/Backend Cluster das Trennen der Datenbank vom E-Mail verarbeitenden System.

Das heisst bei dieser speziellen Form eines SEPPmail-Clusters existiert auf dem als Frontend konfigurierten System keine Konfigurationsdatenbank. Die zur Laufzeit benötigten Konfigurationsdaten werden ausschliesslich auf dem Backend System - welches die Konfigurationsdatenbank und somit auch das Schlüsselmaterial beherbergt - vorgehalten und auf Anfrage vom Frontend System auf dieses im Push-Verfahren geschoben ( lila Pfeile in "Abbildung 7").

Durch Abschluss der am Frontend System angeforderte Aktion - zum Beispiel Ver- oder Entschlüsseln

- werden die hierfür angeforderten Konfigurationsdaten automatisch verworfen/gelöscht.

Abbildung 7 - Schematische Darstellung einer Frontend/Backend Cluster Struktur

4.9.6

Secure Webmail Satellite

Da E-Mail Systeme üblicherweise nur über SMTP Port 25 kommunizieren, ist unter Umständen aufgrund einer vorhandenen DMZ (DeMilitarisierte Zone) Struktur die für die GINA-Technologie benötigte Kommunikation über SSL Port 443 nicht möglich. Um dennoch die GINA-Technologie

Nutzen zu können, ohne die Sicherheits-Infrastruktur aufweichen zu müssen, ist ein Abspalten dieser

Technologie über das GINA Satelliten System und somit das Platzieren ausserhalb der DMZ möglich.

Die Kommunikation zwischen dem Basis System und dem Satelliten System erfolgt dabei via SMTP

Port 25 ( lila Pfeil in "Abbildung 8"). Zum Internet hin wird das GINA-Web Interface - meist getrennt durch eine Web Application Firewall (WAF) - über SSL Port 443 bereit gestellt.

Das Einrichten dieser speziellen Funktion erfolgt im Menü

Mail Processing

in der Sektion

Ruleset Generator

im Abschnitt

Advanced Settings

165

Abbildung 8 - Schematische Darstellung einer Secure Webmail Satellite Struktur

4.9.7

Unterstützen externer redundanter Systeme

Einsatz mit redundanten internen und externen MTAs (Mail Transport Agent)

In der SEPPmail Konfiguration kann sowohl als externer MTA (E-Mail Relay) (siehe

Mail System

Outgoing Server

132

Server name) wie auch pro interner E-Mail Domäne (E-Mail Server) (siehe

Kapitel "Add/Edit Managed Domains"

Settings

139

Forwarding Server IP or MX name) jeweils nur ein Host angegeben werden. Sollen mehrere Systeme angesprochen werden können, so muss dies

über DNS MX-Einträge geschehen.

Steht lokal kein DNS-Server zur Verfügung, welcher MX-Einträge für die anzubindenden Server bereit stellt, so können hierfür im Menü

System

unter

Advanced View

DNS

122

local zone lokale

(pseudo) Einträge definiert und verwendet werden.

Abbildung 9 - Schematische Darstellung für den Einsatz von redundanten internen und externen MTAs

100

4.10 Einrichten zusätzlicher Features

Die SEPPmail-Appliance bietet neben der Hauptfunktion des kryptographischen Behandelns von E-

Mails zusätzliche Features an, um die Sicherheit zu erhöhen

Protection Pack

100

Internal Mail Encryption (IME)

100

den Verwaltungsaufwand zu minimieren

Self Service Password Management (SSPM)

101 den Funktionsumfang zu erweitern

Large File Management (LFM)

101

Diese optionalen Features müssen separat lizensiert werden.

4.10.1 Protection Pack (VSPP)

Das Protection Pack (VSPP) bietet zusätzlichen Schutz vor Spam E-Mails und Viren.

Die für das Einrichten erforderlichen Einstellungen sind in den Sektionen

Antispam

136

Blacklists

und

Manual Blacklisting / Whitelisting

138

des Menüs

Mail System

sowie im Menü

Mail

Processing

in der Sektion

Ruleset Generator

im Punkt

Protection Pack (Anti-Spam / Anti-

Virus)

162

zu finden.

138

4.10.2 Internal Mail Encryption (IME)

Die Internal Mail Encryption dient dem Verschlüsseln von E-Mails innerhalb des eigenen

Unternehmens (E-Mail Domänen).

Diese Funktion wird in zwei verschiedenen Ausprägungen angeboten.

Die erste Variante wird dabei über das

Microsoft Outlook AddIn

103

realisiert.

Dabei muss gegebenenfalls die Schaltfläche "intern verschlüsseln" über die entsprechenden AddIn

Einstellungen (siehe

Registry

109

Tabelle 1) angezeigt werden. Der Absender aktiviert dann im Ribbon von Microsoft Outlook den vom AddIn bereit gestellten Schalter "intern verschlüsseln" vor Versand der der E-Mail. Bei dieser Methode wird die E-Mail zwar unverschlüsselt bis zur SEPPmail-Appliance

übertragen, jedoch GINA verschlüsselt dem Empfänger zugestellt.

Für Variante zwei kommt ausschliesslich die GINA-Technologie zum Einsatz.

Das heisst der Absender einer intern zu verschlüsselnden E-Mail meldet sich bereits für den Versand dieser vertraulichen E-Mail am GINA-Web-Portal an.

Damit sich der interne Benutzer als GINA-Benutzer registrieren kann, ist das Aktivieren der Optionen

Allow account self-registration in GINA portal without initial mail

Allow GINA users to write new mails (not reply)

aus dem Untermenü

Edit GINA Setting

171

- welches über

Mail Processing

GINA Domains

149

Edit

zu erreichen ist - in der Sektion

Extended Settings

171

notwendig.

Sollten diese Optionen für den Zugriff von extern nicht gewünscht sein, so muss gegebenenfalls für den Zugriff von intern ein eigenes GINA-Interface (siehe

Mail Processing

GINA Domains

Create new GINA Domain

169

) eingerichtet werden.

4.10.3 Self Service Password Management (SSPM)

Das Self Service Passwort Management erlaubt es GINA-Benutzern selbständig Ihr Passwort zurückzusetzen, wenn dieses verloren ging. Ein Eingreifen des Administrators ist somit nicht notwendig.

Für das Konfigurieren des eigenständigen Zurücksetzens stehen in den Details einer GINA-Domain, welche jeweils über

Mail Processing

GINA Domains

Edit

zu erreichen ist - in der Sektion

Security

177

die Möglichkeiten zur Rücksetzung bereit.

über eine Bestätigungs E-Mail (Reset by Email verification) per SMS (Reset by SMS)

über eine Auswahl durch den Benutzer (Let user choose between hotline and SMS)

Wird die Möglichkeit des Zurücksetzens per SMS angeboten, so ist über das Menü

Mail

Processing

in der Sektion

GINA password via SMS

151

die Konfiguration des SMS Versandes vorzunehmen.

101

4.10.4 Large File Management (LFM)

Das Large File Management ermöglicht mittels GINA-Technologie die Übertragung grosser Dateien,

über das übliche E-Mail Limit hinaus.

Diese zusätzliche Funktion steht in den Details jeder einzelnen GINA-Domain, welche jeweils über

Mail Processing

GINA Domains

Edit

zu erreichen ist - in der Sektion

Large File Management

174

zur Verfügung.

102

5 Administrative Aufgaben

Administrative Aufgaben wurden durch das effektive Design der SEPPmail-Appliance auf ein Minimum reduziert. Sollten dennoch Aufgaben anfallen, so werden die Mitglieder der Gruppen admin und

statisticsadmin (siehe

Groups

233

) darüber benachrichtigt. Weiterhin werden Benachrichtigungen

über Probleme des Systems per Watchdog Meldung an die Postmaster address (siehe

Mail

System

SMTP settings

168

) gesendet.

Je nach Konfiguration des Systems lassen sich so die administrativen Aufgaben auf folgende

Tätigkeiten beschränken:

Eingreifen bei Problemen (Watchdog Meldung)

Aktualisieren der Appliance (siehe

Administration

Update

209

)

Erneuern des SSL Zertifikats bei Ablauf (siehe

SSL

187

)

Einstufen der Vertrauesnwürdigkeit von

X.509 Root Certificates

238

Sollte die Anlage von Benutzern (siehe

Mail Processing

Ruleset generator

User creation

158

) sowie der Bezug von Zertifikaten (siehe

Mail Processing

Ruleset generator

Key Generation

162

) nicht automatisiert sein, so fallen hierfür natürlich weitere Aufgaben an.

103

6 Microsoft Outlook AddIn

6.1 Einleitung

Das SEPPmail-AddIn für Microsoft Outlook kann auf PC-Systemen mit Microsoft Outlook installiert werden. Das Installieren kann sowohl interaktiv, als auch im Silent-Mode erfolgen. Je nach gewählter

Installation stehen unterschiedliche Einstellungen (Parameter) zur Verfügung, um die Funktionalität des AddIns zu beeinflussen.

Das AddIn stellt im jedem Outlook Fenster zum Verfassen einer E-Mail (Neu, Weiterleiten, Antworten)

Schaltflächen für das Steuern der kryptographischen Aktionen der SEPPmail-Appliance zur

Verfügung. Abhängig von den bei der Installation gewählten Einstellungen erscheinen unterschiedlich viele Schaltflächen, mit unterschiedlichen Standard-Einstellungen (gedrückt / nicht gedrückt).

Die Zustände der Schaltflächen beim späteren Versenden einer E-Mail werden entweder als Steuer-Informationen in x-header geschrieben.

optional bei Verwendung des "Subject-Mode" als Schlüsselwort in die Betreffzeile der E-Mail integriert.

Da es E-Mail Server gibt, welche x-header abschneiden, bietet der "Subject-Mode hierfür eine

Alternative.

Die durch das AddIn im "Subject-Mode" hinzugefügten Schlüsselworte sind auch im "Gesendet"

Ordner des Absenders zu sehen. Das versetzt diesen in die Lage, auch später nachzuvollziehen, ob er eine E-Mail kryptographisch behandelt oder unbehandelt versendet hat.

Hinweis:

Bei Verwenden des "Subject-Mode" werden eventuell manuell der Betreffzeile hinzugefügte Steuerbefehle (siehe "subject-mod Schlüsselworte" in Tabelle

Registry

109

) entfernt, um eventuell entgegengesetzte Anweisungen zu vermeiden.

Das zentrale SEPPmail-System ist bei Eingang der E-Mail in der Lage beide Informationen auszuwerten.

Weiterhin steht eine (optionale) Schaltfläche für den Aufruf einer Hilfe-Seite im Standard-Webbrowser zur Verfügung.

Ebenso kann bei Bedarf eine Warnung beim Versenden von unverschlüsselten und unsignierten E-

Mails ausgegeben werden.

Die Anwendung ist mehrsprachig und passt sich der jeweiligen Sprache der Microsoft Outlook-

Oberfläche an. Ist diese nicht verfügbar, wird Englisch als Standardsprache für das AddIn verwendet.

Derzeit sind die Sprachen

Deutsch

Englisch

Französisch

Italienisch verfügbar.

Im Folgenden werden technische Details zu den System-Anforderungen, zur Installation und zu den

Abläufen in der Registry beschrieben.

104

6.2 Download

Das SEPPmail-Add-In für Microsoft Outlook können Sie auf der folgenden Webseite in der jeweils aktuellen Version herunterladen: http://dl.seppmail.ch

6.3 Systemanforderungen

Das SEPPmail-Add-In für Microsoft Outlook kann unter verschiedenen Betriebssystemen und

Microsoft Outlook Versionen installiert werden:

Microsoft Windows Betriebssysteme

Windows Vista

Windows 7 (32/64 bit)

Windows 8 (32/64 bit)

Windows Terminal Server

Microsoft Outlook Versionen

Outlook 2003

Outlook 2007

Outlook 2010 (32/64 bit)

Outlook 2013 (32/64 bit)

.NET Framework

Das .NET Framework muss in der Version 4.0 Client Profile oder neuer vorhanden sein. Fehlt dieses, versucht die Installationsroutine diese Komponente automatisch aus dem Internet zu beziehen und zu installieren.

6.4 Installation

Die Installation besteht aus zwei Dateien:

Setup.exe

ist erforderlich um auf Windows Vista, Windows 7 und Windows 8, bei eingeschaltetem UAC (

User Account Control = Benutzerkontensteuerung), per Rechtsklick „Als Administrator“ auswählen zu können.

Prüft vor dem Ausführen der .msi-Datei ob die Voraussetzungen für die Installation (zum

Beispiel NET Framework) vorhanden sind.

SEPPmailOutlookAddInSetup.msi

führt die eigentliche Installation durch und kann auch direkt gestartet werden, wenn entsprechende Rechte vorhanden sind (zum Beispiel inaktives UAC und Admin-Rechte) beziehungsweise am Terminalserver bereits in den Install-Mode gewechselt wurde.

6.4.1

Interaktive Installation

Beispiel:

Rechtsklick auf setup.exe und „Als Administrator ausführen“ bzw. „Run as administrator“ auswählen.

105

Abb. 1

Die Sicherheitsabfrage von Windows mit „Ja“ beantworten, um die Installation zu starten.

Im folgenden erscheinen die folgenden Bildschirme auf denen der Benutzer

Wahlmöglichkeiten a.

zu den später angezeigten Buttons

Abb. 2

zu den Standard Button-Zuständen bei Öffnen eines E-Mail Fensters

106

Abb. 3

zum Ein/Ausschalten einer Warnung beim Versand von unverschlüsselten und unsignierten E-Mails

Abb. 4

6.4.2

Silent Installation

Alternativ kann die Installation über die Kommandozeile mit diversen Parametern gestartet werden.

Hinweis:

Die Kommandozeile muss als Administrator gestartet werden!

107

Beispiel

msiexec /q /i "SEPPmailOutlookAddInSetup.msi" SMWarning=false

SMEncrypt=true SMSign=true SMWebmail=true SMHelp=true

SMEncryptSelected=false MSignSelected=false SMWebmailSelected=false / li .\log.txt

Msiexec-Parameter:

Parameter

/li .\log.txt

Beschreibung

Installation ohne User Interface

Installation eines MSI Paketes log.txt mit Basis Informationen im aktuellen Verzeichnis erzeugen

MSI-Parameter von SEPPmailOutlookAddInSetup.msi

SMEncrypt

SMSign

SMWebmail

SMNoEncryption

SMHelp

SMEncryptSelected

SMSignSelected

SMWebmailSelected

Tooltips

LMonly

Parameter

SMWarning

SMNoEncryptionSelected

Standard Beschreibung

False

Warnung falls die Schaltfläche verschlüsseln nicht ausgewählt wurde ein-/ausschalten

True Schaltfläche „Verschlüsseln“ ein-/ausblenden

True Schaltfläche „Signieren” ein-/ausblenden

Schaltfläche „Verschlüsseln mit Lesebestätigung” ein-/

True ausblenden

False Schaltfläche „Unverschlüsselt” ein-/ausblenden

False Schaltfläche „Hilfe” ein-/ausblenden

False

Schaltfläche „Verschlüsseln” im Standard aktiv/inaktiv setzen

False Schaltfläche „Signieren” im Standard aktiv/inaktiv setzen

False

Schaltfläche „Verschlüsseln mit Lesebestätigung” im

Standard aktiv/inaktiv setzen

Schaltfläche „Unverschlüsselt” im Standard aktiv/inaktiv setzen

False Tooltips für Buttons ein-/ausschalten

False Registry-Werte nur in „HKLM“, nicht in „HCU“ speichern

108

6.4.3

Deinstallation

Die Deinstallation des SEPPmail-Add-In für Microsoft Outlook erfolgt interaktiv über die

Systemsteuerung im Menü Programme und Funktionen.

Interaktiv am Beispiel Windows 7/8

Rechtsklick auf den Eintrag SEPPmail Outlook Add-In -> Deinstallieren.

Deinstallation - Outlook Add-In

Weiterhin ist die Deinstallation auch Silent per MSI über den Befehl

MsiExec.exe /x {A5B1FA06-7E16-4645-AFC1-0A7CDAFA77E3} /qn oder über das AddIn Setup setup /s /v" /x {A5B1FA06-7E16-4645-AFC1-0A7CDAFA77E3} /qn" möglich.

Dabei ist zu beachten, dass diese Befehle mit Administrator-Rechten ausgeführt werden müssen.

109

6.5 Registry

Das AddIn macht im Standard sowohl maschinenbezogene Eintragungen in den Registry Hive

HKEY_LOCAL_MACHINE (HKLM) wie auch in die benutzerbezogenen Hives

HKEY_CURRENT_USER (HCU).

Um zum Beispiel unternehmensweit Standard Vorgaben der Schaltflächen Einstellungen zu erzwingen, lässt sich das Speichern Benutzer bezogener Einstellungen (HCU) optional abschalten.

Die Schaltflächen Einstellungen werden bei neuen Benutzern aus den Maschineneinstellungen

(HKLM) in die Benutzereinstellungen (HCU) übernommen. Ebenso werden Änderungen der

Maschineneinstellungen bei bestehenden Benutzern übernommen.

Folgend werden die Registry-Werte für das AddIn im Bereich

HKEY_LOCAL_MACHINE\Software\SEPPmail\OutlookAddIn

bei 32 bit Maschinen beziehungsweise

HKEY_LOCAL_MACHINE\Software\Wow6432Node\SEPPmail\OutlookAddIn

bei 64 bit Maschinen und Ihre jeweilige Funktion beschrieben:

Schaltfläche verschlüsseln verschlüsseln mit

Lesebestätigung intern verschlüsseln unverschlüsselt signieren

Hilfe

Name

Registry

Typ

REG_

Data

Beschreibung

SMEncrypt

Selected s-smenc

SMWebmail DWORD

SMWebmail

Selected s-smwebmail

Internal

Encryption

Internal

Recipient

SMNoEncryption DWORD

SMNoEncryption

Selected s-smnoenc

SMSign

Selected s-smsign

SMHelp

DWORD

DWORD subject-mod DWORD

0/1

0/1 blendet die Schaltfläche aus bzw.

ein setzt die Schaltfläche im Standard auf inaktiv/aktiv

[confidential] subject-mod Schlüsselwort

0/1

[priv]

0/1 ime@imepseudo domain.local

0/1

0/1 blendet die Schaltfläche aus bzw.

ein setzt die Schaltfläche im Standard auf inaktiv/aktiv subject-mod Schlüsselwort blendet die Schaltfläche aus bzw.

ein gibt die Pseudo Empfängeradresse für IME an blendet die Schaltfläche aus bzw.

ein setzt die Schaltfläche im Standard auf inaktiv/aktiv

[noenc]

0/1

[sign]

0/1

0/1 subject-mod Schlüsselwort blendet die Schaltfläche aus bzw.

ein setzt die Schaltfläche im Standard auf inaktiv/aktiv subject-mod Schlüsselwort blendet die Schaltfläche aus bzw.

ein durch Aktivieren des subject-mod werden Betreffzeilen

Schlüsselworte statt x-header zur

Steuerung der Appliance verwendet.

LMOnly DWORD 0/1 das Aktivieren von LMOnly deaktiviert das benutzerbezogene

110

Tooltips

UsageTimeStamp SZ 2014,4,8,16,51,27

Web Site

DWORD

0/1 http://www.

seppmail.ch

Speichern von Einstellungen in

HCU de- bzw. aktiviert die Tooltips für die Schaltflächen

Zeitstempel für den Vergleich

HKLM/HCU

Webseite welche bei Anklicken der

Hilfe Schaltfläche aufgerufen werden soll

Tabelle 1

Davon werden folgende Werte gegebenenfalls in den Bereich

HKEY_CURRENT_USER\Software\SEPPmail\OutlookAddIn

übernommen:

Schaltfläche

Name verschlüsseln verschlüsseln mit

Lesebestätigung intern verschlüsseln unverschlüsselt signieren

Hilfe

SMEncrypt

SMEncryptSelected

SMWebmail

SMWebmailSelected

InternalEncryption

InternalRecipient

SMNoEncryption

SMNoEncryptionSelected

SMSign

SMSignSelected

SMHelp

UsageTimeStamp

Tabelle 2

Registry

Typ

REG_

DWORD

Data

0/1

0/1 [email protected]

0/1

2014,4,8,16,51,27

Werden durch Aktivieren des

subject-mod

statt der x-header Betreffzeilen Schlüsselworte verwendet, so ist darauf zu achten, dass die Schlüsselworte der in der Appliance im Punkt

Mail Processing

Ruleset generator

konfigurierten gleichen.

x-header x-smenc x-smsign s-smsign x-smwebmail s-smwebmail x-smplain

Name s-smenc

Registry

Schlüsselwort

(Standard)

[confidential] s-smnoenc

[sign]

[priv]

[noenc]

Tabelle 3

111

6.6 AddIn Verwaltung

Für das zentrale Verwalten der AddIn Einstellungen in Microsoft Netzwerken, bieten wir zusätzlich ein

ADM-Template an. Somit können die Einstellungen bequem per per Group Policies (GPO) ausgebraucht werden.

Die Vorlage steht ebenfalls zum

Download

104

zur Verfügung.

112

7 Referenz der Menüpunkte

7.1 Übersicht der Menüpunkte

Die Konfigurationsoberfläche der SEPPmail-Appliance ist in die, in der folgenden Tabelle kurz beschriebenen Menüs aufgeteilt. Die Gliederung dieses Teils des Handbuchs folgt dieser Tabelle.

Menü Beschreibung

Login/Logout

Home

System

Mail System

Anmeldung an der Konfigurationsoberfäche, ändern des persönlichen

Kennworts für die Konfigurationsoberfläche

Anzeige administrativer Daten wie zum Beispiel Systemstatus, System- und

Benutzerlizenz, aktuelle Softwareversion, statistische Daten zur

Systemauslastung

Durchführen grundlegender Netzwerkeinstellungen wie zum Beispiel IP-

Adresse, Host- und Domainname, Routing, System Datum- und Uhrzeit

Einrichtung des SEPPmail E-Mail-Systems, E-Mail Domänen und E-Mail-

Routing, E-Mail-Relay-Server, Access Control, TLS, AntiSPAM, Blacklists/

Whitelists

Mail Processing

Regeln zur Verarbeitung von E-Mails, Verwaltung von GINA-Domänen, SMS-

Kennwortversand, Disclaimer, E-Mail-Templates, Virenscanner und SPAM-

Protection-Regeln und Schwellwerte, Regelwerk für E-Mail-Signierung, Verund Entschlüsselung verwalten/anzeigen/laden

SSL

SSL-Device-Zertifikat für den SEPPmail Secure Webmail Webserver einrichten und sichern

Eigene Zertifizierungsstelle (CA) einrichten, Connector zur SwissSign CA

(MPKI) einrichten, CA-Zertifikat anfordern und sichern, eventuell Sub-CA oder Registrierungsstelle (RA) einrichten.

Administration

SEPPmail registrieren, Software-Updates installieren, Datensicherung erstellen und zurücksichern, SEPPmail neu starten oder herunterfahren,

SEPPmail auf Werkseinstellungen zurücksetzen, bestehende Benutzer oder

Schlüssel importieren, ausgehende Supportverbindung aktivieren

Cluster

Cluster-Verbund mit mehreren SEPPmail-Systemen einrichten

E-Mail-Logdateien einsehen und verwalten

Logs

Statistics

Grafische Anzeige des verarbeiteten E-Mail-Verkehrs und der

Systemauslastung

SEPPmail-Benutzerkonten erstellen und verwalten

Users

Groups

SEPPmail-Gruppen erstellen und verwalten

GINA accounts

Verwalten von automatisch erzeugten GINA--Konten. GINA bezeichnet die frühere Secure-Webmail-Schnittstelle.

openPGP public keys

Öffentliche openPGP-Schlüssel von Kommunikationspartnern importieren und verwalten

113

X.509

Certificates

Öffentliche S/MIME X.509-Zertifikate von Kommunikationspartnern importieren und verwalten

X.509 Root

Certificates

S/MIME X.509-Root-CA-Zertifikate importieren und verwalten

Domain keys

openPGP und S/MIME Domänen Schlüssel importieren, synchronisieren und verwalten

Customers

Aktivieren und Einrichten einer Multi-Kunden-Konfiguration (Multitenancy).

Hierbei können zum Beispiel E-Mail Domänen, Benutzerkonten oder GINA-

Benutzerkonten dediziert einem zuvor definierten Kunden zugewiesen werden.

Referenz der Menüpunkte in der SEPPmail Konfigurationsoberfläche

114

7.2 Login/Logout

Der Menüpunkt

Login

ermöglicht das Abmelden von der SEPPmail-Konfigurationsoberfläche beziehungsweise den Kennwortwechsel des angemeldeten Benutzers. In der folgenden Tabelle werden die einzelnen Parameter beschrieben.

Sektion

Login

Parameter

User ID

Password

Beschreibung

Eingabe der User ID zur Anmeldung an der Administrationsoberfläche.

Die Anmeldung an der AdminGUI ist prinzipiell für jeden, auf SEPPmail-

Appliance angelegten Benutzer möglich, welchem ein Passwort zugewiesen

wurde (siehe Menü

Users

223

Ob und welche Menüs für den jeweiligen Benutzer sichtbar sind hängt von dessen Gruppenzugehörigkeit ab (siehe Menü

Groups

233

Dient der Passwort Eingabe.

Sektion

Change Password

Parameter Beschreibung

The password must:

New Password

Gibt die Passwort Stärke der vorgegebenen Konfiguration (siehe Menü

Users

223

Password Policy

Zum Anmelden an der Konfigurationsoberfläche wählen Sie die Schaltfläche

Log in

Dient dem Passwort Wechsel des angemeldeten Bunutzers. Das Passwort muss zwei mal angegeben werden um eine fehlerhafte Eingabe zu vermeiden und den Vorgaben von "The password must:" entsprechen.

Log out

Abmelden von der Konfigurationsoberfläche.

Change Password

Ändert das Passwort wie unter

Change Password

eingegeben.

115

7.3 Home

Das Menü Home öffnet nach Anmeldung an der Konfigurationsoberfläche. Es zeigt grundlegende

Informationen zum SEPPmail-System an.

Sektion

System Status

Diese Sektion zeigt den aktuellen Systemstatus der SEPPmail-Appliance an.

Dieser sollte

"All systems are stable and running."

lauten. Sollten Probleme auf dem System existieren, so werden diese hier ebenso in rot angezeigt, wie eventuell wichtige, aber fehlende Konfigurationseinträge.

Sektion

License

In dieser Sektion wird der Lizenzstatus, wie lizensierte Komponenten, deren Anzahll und Laufzeit angezeigt.

Parameter Beschreibung

Wurde das System erfolgreich registriert und ist eine gültige Lizenz vorhanden, so wird hier der Status

"Valid License detected" angezeigt.

Hier werden Informationen zur System- und Benutzerlizenz angezeigt.

License Type

License ID

Lizenznummer für das SEPPmail System.

Eigentümer der SEPPmail Lizenz.

License Holder

Issue date

Ausstellungsdatum der Lizenz.

Zusätzliche Informationen zur Lizenz.

Comment

Encryption/Signature

Licenses

Large File Management

(LFM) Licenses

Anzahl der erworbenen Benutzerlizenzen. In Klammern wird die Anzahl bereits verwendeter Benutzerlizenzen angezeigt.

Anzahl der erworbenen Benutzerlizenzen für die Funktion Large File

Management. In Klammern wird die Anzahl bereits verwendeter

Benutzerlizenzen angezeigt.

Auf den Hardware Appliances ab 1000B steht für LFM interner Speicher zur Verfügung.

Die 500B benötigt eine externe USB-Platte. Bei virtuellen Appliances muss für das Verwenden von

LFM auf dem Hostsystem eine weitere Hard Disk von midestens 5GB zugeordnet, und das System neu gestartet werden. Andernfalls erscheint die Meldung

Note: You have LFM licenses, however your device has no disk to store Files. Please add an USB (or virtual) disk.

(siehe auch

Sizing

)

116

Parameter

Multitenancy

Software Care Pack

Beschreibung

Anzahl der erworbenen Mandantenlizenzen

Anzeige des Ablaufdatums der Lizenz für Software Updates.

Device Care Pack

Anzeige des Ablaufdatums des Device Care Packs.

Protection Pack

(Anti-spam/Anti-virus)

Anzeige des Ablaufdatums der Lizenz für AntiVirus und AntiSPAM.

Internal Mail Encryption

Lizenz für interne Verschlüsselung (Active / Inactive).

Self-Service password management

Lizenz für Self-Service passwort management (Active / Inactive).

Sektion

System

Zeigt die Systemdaten der Appliance an.

Parameter

Device ID

Appliance Type

Firmware Version

Uptime

Beschreibung

Gerätelizenznummer

Typ der aktuellen Appliance, zum Beispiel SEPPmail 5000 (VMware

Virtual Appliance).

Aktuell auf dem System installierte Softwareversion.

Laufzeit des Systems nach dem letzen Neustart.

Sektion

Anti-Virus

Zeigt den Status des integrierten Virenscanners an

Parameter

Inactive

ClamAV Engine

Beschreibung

Falls das Protection Pack (VSPP) nicht lizensiert wurde ist dies die einzige Anzeige der Sektion.

Anzeige der ClamAV Scan Engine Version

Anzeige der ClamAV Virensignatur Version

Signature Version

Signature Date

Anzeige des ClamAV Virensignatur Datums

Sektion

Mail statistics

117

Zeigt eine Kurzübersicht der verarbeiteten E-Mail an.

Parameter Beschreibung

Mails Processed

(S/MIME)

Anzahl aller insgesamt vom System übertragenen E-Mails (empfangen, gesendet).

Anzahl aller insgesamt via S/MIME verarbeiteten E-Mails (entschlüsselt, verschlüsselt).

Mails Processed

(openPGP)

Anzahl aller insgesamt via openPGP verarbeiteten E-Mails

(entschlüsselt, verschlüsselt).

Mails Processed

(DOMAIN)

Anzahl aller insgesamt via Domänen Verschlüsselung verarbeitenten E-

Mails (entschlüsselt, verschlüsselt).

GINA Mails

Anzahl aller insgesamt versendeten Secure Webmails über das GINA-

Subsystem.

Mails currently in queue

Anzahl aller E-Mails in der Warteschlange.

Sektion

Disk statistics

Zeigt die Auslastung der einzelnen Systempartitionen an.

Parameter Beschreibung

Zeigt die Auslastung des Datenbank Volumes im System

Database

Mail queue

Zeigt die Auslastung des E-Mail Warteschlangen Volumes im System

Zeigt die Auslastung des Volumes für die Log-Dateien im System

Log temp

LFM store

Zeigt die Auslastung des Volumes für temporäre Dateien im System

Zeigt die Auslastung des Volumes für die Large File Management

Volume im System sofern dieses Feature lizensiert wurde

118

7.4 System

Das Menü

System

kann in zwei Ansichten betrachtet werden. Die grundlegenden Basiseinstellungen sind in der Ansicht Normal View zu sehen. Diese Ansicht ist die Standardansicht bei Aufruf des

Menüs. Eine vollständige Übersicht aller Einstellungen ist in der Ansicht Advanced View zu sehen.

Advanced View

Durch betätigen der Schaltfläche

Advanced View

werden die erweiterten Parameter angezeigt.

Um die erweiterte Darstellung des Menüpunkts

System

wieder zusammenzufassen ist in der

Erweiteren Darstellung die Schaltfläche

Normal View

zu betätigen.

Normal View

In diesem Menü werden die wichtigsten Parameter der LAN-Anbindung des SEPPmail-Systems eingerichtet. Die hier eingetragenen Daten dienen auch als Grundeinstellung für viele weitere

Einstellungen des SEPPmail-Systems.

Die folgenden Tabellen beschreiben den Advanced View, da dieser alle Einstellungen des Normal

View beinhaltet.

Sektion

Comment

(optional)

Eingabefelder zur Beschreibung beziehungsweise zur Identifikation des SEPPmail-Systems. Diese

Parameter werden zum Beispiel als Betreff in der automatischen Datensicherung sowie von SNMP verwendet. Ansonsten dienen Sie lediglich der Beschreibung. Die Einträge sind frei wählbar und jeweils optional.

Parameter Beschreibung

System Description

System Location

System Object ID

System Contact

System Name

Kurzbeschreibung des Systems. Diese wird auch als Titel im Browser beziehungsweise Browser-Tab der Administrationsoberfläche angezeigt.

Standort des Systems

Eigene ID des Systems

Ansprechperson für das System

Name des Systems

119

Sektion

IP Addresses

Parameter Beschreibung

Interface 1

Eingabemaske für IP-Adresse mit Subnetzmaske und den Medientyp der physischen Netzwerk Schnittstelle LAN1 bzw. eth0. In den meisten

Umgebungen sollte der Medientyp auf dem Standardwert autoselect belassen bleiben.

Für jede physisch vorhandene Netzwerk-Schnittstelle wird jeweils eine

Schnittstellen-Konfiguration angezeigt. Die hier angezeigte Schnittstellen-

Nummer entspricht der folgenden Netzwerk-Schnittstelle:

Interface 2 - 4

(optional)

Team / bond interfaces

(optional)

Custom hosts file entries:

(optional)

Interface 1 - LAN1 bzw. eth0 oder auch vic0 bei virtuellen Appliances

Wie bei Interface 1 jedoch jeweils für

Interface 2 - LAN2 bzw. eth1 oder auch vic1

Interface 3 - LAN3 bzw. eth2 oder auch vic2

Interface 4 - LAN4 bzw. eth3 oder auch vic3

Durch Verwendung dieser Einstellung können mehrere Interfaces gebündelt und logisch wie eines verwendet werden. Dabei gibt es unterschiedliche Verfahren: broadcast (Ausfallsicherheit)

Nutzung meherer Switches gleichzeitig möglich.

failover (Ausfallsicherheit)

Nur ein Interface ist aktiv, bei Ausfall wird auf das nächste

übergegangen. Nutzung meherer Switches möglich.

lacp / 802.3ad (Lastverteilung, Ausfallsicherheit)

Bündelung mehrerer Schnittstellen zur Erreichung höherer

Bandbreiten. Anbindung an nur einen Switch mit entsprechender

Protokollunterstützung möglich.

loadbalance (Lastverteilung)

Jeder Gegenstelle im Netzwerk ein zu nutzendes Interface zugewiesen.

roundrobin (Lastverteilung, Ausfallsicherheit)

Verfügbare Interfaces werden in Senderichtung wechselweise genutzt, in Empfangsrichtung kann max. die Geschwindigkeit einer einzelnen Interface genutzt werden.

Zum Durchführen einer lokalen Namensauflösung muss in diesem Feld eine Kombination von IP-Adressen und Hostname/n eintragen werden.

Format:

62.2.145.228 update seppmail.ch support.seppmail.ch

193.239.220.29 pool.ntp.org

120

Sektion

IP ALIAS Addresses

(optional)

Werden mehrere SEPPmail-Appliances in einem Clusterverbund betrieben, so können diese gemeinsam über eine oder auch mehrere virtuelle IP-Adressen angesprochen werden. Die Stellung der einzelnen Maschine innerhalb dieses Verbundes wird über die Priorität (Priority:) definiert.

Hinweis:

Um die Funktion des CARP-Protokolls - welches die Basis für das Bereitstellen virtueller IP-Ardressen bildet - zu gewährleisten, müssen bei virtuellen Appliances gegebenenfalls folgende Einstellungen vorgenommen werden:

Microsoft Hyper-V

Option "Spoofing von MAC-Adressen aktivieren" in der Konfiguration der virtuellen Netzwerkkarte aktivieren.

Diese Option ist in den Hyper-V Einstellungen der virtuellen Maschine unter

"Ältere Netzwerkkarte -> Erweiterte Features" zu finden.

ESX

"promiscous mode" in der Konfiguration der virtuellen Netzwerkkarte aktivieren.

Diese Option ist in den ESX Einstellungen wie folgt vorzunehmen:

1. Im "vSphere Web Client" zum entsprechenden "Host" navigieren

2. Anwählen der Registerkarte "Verwalten"

3. Anwählen "Virtuelle Switches" in der Auswahl rechts der Registerkarte

4. Anwählen des umzustellenden "Switches"

5. Anwählen der Option "Einstellungen bearbeiten" durch Klick auf das

Bleistift-Symbol

6. Anwählen "Sicherheit" in der Auswahl rechts des Fensters

7. Option "Promiscuous-Modus" über das Auswahlmenü auf "Aktzeptieren" stellen und mit "OK" bestätigen

Je nach ESX Version kann es sein, dass die Sicherheitseinstellungen gesplittet wurden. Für diesen Fall sollten auf dem vSwitch die Optionen o

Promiscous Mode o

Gefälschte Übertragung o

MAC Adressänderung aktiv sein, damit CARP / VRRP korrekt arbeitet.

Parameter Beschreibung

IP Alias 0 - 3

An dieser Stelle können virtuelle IP-Adressen definiert werden, welche in der Regel bei Clusterconfigurationen zum Einsatz kommen (siehe Menü

Cluster

215

Hierzu ist es erforderlich für jeden Alias

1. eine IP-Adresse

2. die Netzwerkmaske

3. die VHID (Virtual Host Identification)

4. das Interface an welches der Alias gebunden werden soll

5. die Priorität der Schnittstelle im Verbund (Primary, Secondary,

Backup) anzugeben.

IP-Adresse Subnetz VHID

Angabe der virtuellen

IP-Adresse auf welche die zum

Beispiel

/24 für

C-

Klasse

Die VHID

(Virtual Host

Identification) muss bei allen

Interface Priority

Angabe der

Netzwerk

Schnittstelle

(siehe Sektion

IP Addresses

Stellung der einzelnen

Maschine innerhalb dieses

Parameter Beschreibung

Systeme gemeinsam reagieren sollen

Maschinen, welche ebenfalls auf die eingetragene virtuelle IP reagieren sollen gleich sein.

an welche die virtuelle IP gebunden werden soll.

Verbundes.

121

Hinweis:

Virtuelle IP Adressen dienen ausschliesslich dem Ansprechen eines Clusters von aussen.

Wird eine E-Mail von einer Cluster-Maschine versandt, so geschieht dies immer mit der physikalischen IP Adresse der jeweiligen Maschine.

Sektion

SMTP Loadbalancer

(optional)

Dient der Lastverteilung bei Betrieb eines Clusters.

Parameter Beschreibung

Enable Load balancer

Aktiviert die SMTP Loadbalancer Funktion.

Das SMTP Loadbalancing reicht erst nach erreichen eines hohen

Auslastungsgrades - Auslöser ist die Anzahl (10) der gleichzeitigen

Verbindungen - E-Mails an die eingetragenen Clusterpartner weiter.

Hierdurch wird die Fehleranalyse erleichtert, da eine Sichtung der Logs im Regelfall auf der Hauptmaschine ausreiichend ist.

Distribute load to the following cluster members

An dieser Stelle werden die IP-Adressen der Clusterpartner für das

Loadbalancing eingegeben. Die IP-Adressen werden im Eingabefeld durch ein Leerzeichen getrennt.

Sektion

Name

Der Name des Systems setzt sich aus dem Hostnamen und der Domäne zusammen. zum Beispiel securemail.seppmail.ch

Diese Einstellungen sind die interne Sicht, sie müssen also nicht den Daten, wie sie vom

Internet her Gültigkeit hätten, entsprechen.

Parameter Beschreibung

Hostname

Domain

Eingabe des Hostnamens des SEPPmail Systems ein. zum Beispiel securemail

Eingabe der Domäne des SEPPmail Systems ein. zum Beispiel seppmail.

122

Sektion

Routing

Parameter

Default Gateway

Static Routes

(optional)

Beschreibung

Angabe der Gateway-Adresse passend zum Netzwerksegment (IP und

Netzmaske wie sie unter

IP Addresses

eingegeben wurden). An dieses

Gateway werden alle Datenpakete weitergeleitet, welche an Zieladressen ausserhalb des lokalen Netzwerksegments gesendet werden sollen.

Sollten Verbindungen zu Netzen hergestellt werden müssen, welche nicht

über das Default Gateway erreichbar sind, so können an dieser Stelle die entsprechenden Netze mit ihrem Subnetz jeweils unter "Destination" und das jeweils dort hin führende "Gateway" angegeben werden. Diese statischen IP-Routen haben Priorität vor der Verwendung des Standard-

Routers (Default Gateway).

Nach dem Speichern einer statischen Route wird jeweils ein weiteres

Eingabefeld eingeblendet.

Sektion

DNS

Parameter Beschreibung

Use built-in DNS

Resolver

Prefer IPv6 addresses in replies

Bei diesem Parameter versucht das System die DNS-Namensauflösung immer mit Hilfe der DNS-Root-Nameserver im Internet. Ist dieser

Parameter ausgewählt, so kann die Auflösung von DNS-Namen ggf. sehr lange dauern und die Reaktion des SEPPmail Systems dadurch verzögert werden.

Use the following DNS

Servers

DNS-Anfragen für Adressen, für welche die SEPPmail nicht selbst zuständig ist, werden an übergeordnete DNS-Name-Server weitergeleitet.

Dazu sollte SEPPmail die DNS-Anfrage zunächst an einen internen DNS-

Server im eigenen Netzwerk oder die DNS-Server Ihres Internet Providers weitergeben, die Sie hier spezifizieren können.

Durch diese Einstellung werden IPv6 Antworten des DNS Servers bevorzugt verwendet.

Primary

Alternate 1

(optional)

Alternate 2

(optional)

Search Domain(s)

add local zone

(optional)

Gehen Sie hier den ersten DNS-Name-Server ein an den SEPPmail DNS-

Anfragen weiterleiten soll.

Ist der primäre DNS-Name-Server nicht verfügbar oder antwortet nicht wird die DNS-Anfrage an den hier eingetragenen, alternativen DNS-

Name-Server weitergeleitet.

Sind weder der primäre noch der erste alternative DNS-Name-Server verfügbar, so wird die DNS-Anfrage an den hier eingetragenen, zweiten alternativen DNS-Name-Server weitergeleitet.

Geben Sie hier eine Suchliste mit Domänen Namen an, welche bei einer

DNS-Anfrage nacheinander abgefragt werden.

Lokale Zonen werden verwendet, wenn jeweils mehrere Forwarding- und/ oder SMTP-Server angesprochen werden sollen, für das Auflösen der hierfür benötigten MX-Records jedoch kein lokaler DNS-Server zur

Verfügung steht.

123

Nach dem Speichern werden jeweils ein weitere Eingabefelder eingeblendet.

In den unten dargestellten Beispiel Eintragungen würde für die Domäne

pseudo.local vorrangig in mail1.pseudo.local mit der IP-Adresse

10.0.0.11 aufgelöst da dieser die Präferenz 10 aufweist. Sollte der Server

mail1.pseudo.local nicht erreichbar sein, wird der Eintrag mit der

Präferenz 20, also mail2.pseudo.local mit der IP-Adresse 10.0.0.12 verwendet.

Domain name: host: host:

Pseudo Domänen Name, welcher intern in der SEPPmail-

Appliance als MX-Record aufgelöst werden soll, zum Beispiel

pseudo.local.

Hostname, zum

Beispiel

mail1

mx:

Präferenz, zum

Beispiel

ip:

IP-Adresse des ersten E-

Mail-Servers, zum Beispiel

10.0.0.11

Hostname, zum

Beispiel

mail2

mx:

Präferenz, zum

Beispiel

ip:

IP-Adresse des zweiten E-

Mail-Servers, zum

Beispiel 10.0.0.12

Sektion

GUI Protocol

Definiert die Einstellungen für den Zugriff auf die Adminoberfläche.

Parameter Beschreibung

HTTP Port

HTTPS Port

Admin GUI Session timeout:

Aktivieren Sie diesen Parameter, um den unverschlüsselten Zugriff via

HTTP Protokoll auf die Konfigurationsoberfläche zu ermöglichen. Geben

Sie dazu einen entsprechenden TCP/Port (im Standard 8080) an.

Um Sicherheitsrisiken zu minimieren ist diese Option im Standard deaktiviert.

Aktiviert den verschlüsselten Zugriff via HTTPS Protokoll auf die

Konfigurationsoberfläche zu ermöglichen. Geben Sie dazu einen entsprechenden TCP/Port (im Standard 8443) an.

Dies ist der Standard Zugriff auf die SEPPmail Konfigurationsoberfläche.

Zeit in Sekunden bis zum automatischen Logout aus der

Konfigurationsoberfläche bei Inaktivität.

124

Sektion

GINA-https Protocol

Definiert die Einstellungen für den Zugriff auf das GINA-Webinterface.

Parameter Beschreibung

HTTP Port

Aktivieren Sie diesen Parameter, um den unverschlüsselten Zugriff via

HTTP Protokoll auf die Webmail-Schnittstelle des SEPPmail Systems zu ermöglichen. Geben Sie dazu einen entsprechenden TCP/Port (im

Standard 80) an.

Hinweis:

Verwenden Sie das HTTP-Protokoll nicht für einen

Zugriff auf die Webmail-Schnittstelle aus dem Internet oder aus einem anderen unsicheren Netzwerk.

Hierdurch würde das Protokollieren von

Webbrowserverbindungen zur Webmail-Schnittstelles des SEPPmail durch unbefugte Dritte ermöglicht.

Diese Einstellung wird in der Regel nur dann benötigt, wenn bereits eine vorgeschaltete Komponente den SSL-Tunnel zum GINA-Webinterface terminiert.

HTTPS Port

Enable local https proxy, redirect unknown requests to

(optional)

Aktivieren Sie diesen Parameter, um den verschlüsselten Zugriff via

HTTPS Protokoll auf die Webmail-Schnittstelle des SEPPmail Systems zu ermöglichen. Geben Sie dazu einen entsprechenden TCP/Port (im

Standard 443) an.

Aktivieren Sie diesen Parameter, um den Zugang zum Webmail

Subsystem (GINA Webinterface) nicht mehr direkt sondern über den lokalen SEPPmail Reverse-Proxy zu aktivieren. Alle nicht für das

Webmail bestimmten Anfragen werden dadurch an die eingetragene URL weitergeleiten.

Hierdurch kann zum Beispiel der Zugang zu einem internen OWA-Server

(Outlook Web Access) gewährleistet werden. Ebenfalls können

ActiveSync Verbindungen zum internen MS-Exchange Server durch den

Reverse-Proxy weitergeleitet werden.

Sektion

Console Login

(optional)

Definiert die Einstellungen für den Zugriff auf die Console der Appliance.

Parameter Beschreibung

Disable console root login

Aktivieren Sie diesen Parameter, so wird der Konsolenzugang am

SEPPmail System gesperrt.

Hinweis:

Bitte beachten Sie beim Aktivieren dieses Parameters, dass in diesem

Fall ein gewollter Zugang zum System im Fehlerfall ebenfalls nicht mehr möglich ist.

125

Sektion

Syslog Settings

(optional)

Ermöglicht die Weiterleitung von Log-Einträgen an einen Syslog Server.

Parameter Beschreibung

Forward maillog and authlog to this syslog server

Forward GUI audit log to this syslog server

Hostname oder IP-Adresse eines Syslog-Servers im LAN an welchen die

SEPPmail die Mail- und Auzuthentifizierungs- Log-Protokolle zusätzlich senden soll. Als Zielport wird UDP/514 verwendet.

Hostname oder IP-Adresse eines Syslog-Servers im LAN an welchen die

SEPPmail die Log-Protokolle der Aktionen aus der AdminGUI zusätzlich senden soll. Als Zielport wird UDP/514 verwendet.

Sektion

Log Cleanup

(optional)

Parameter Beschreibung

Automatically delete log archives older than

days

Löscht automatisch Log-Archive-Dateien, welche älter als die eingestellte

Anzahl von Tagen sind. Minimum sind 30 Tage, Maximum 3640 Tage (10

Jahre)

Durch das automatische löschen der Log-Archive kann ein "Vollaufen" der

Log-Partition vermieden werden.

Hinweis:

In mandantenfahigen Systemen ist zu beachten, dass diese Logs somit auch nicht mehr für den Mandanten

Admin auf der Appliance zur Verfügung stehen.

126

Sektion

Proxy Settings

(optional)

Hier müssen nur dann entsprechende Einstellungen vorgenommen werden, wenn ein direkter Zugriff der Appliance per SSH (TCP Port 22) in das Internet nicht möglich ist.

Parameter Beschreibung

Proxy Server

Proxy Port

Hostname oder IP-Adresse des Proxy-Servers, über welchen die SSH

Kommunikation geleitet werden soll.

Ziel-Port des Proxy-Servers, zum Beispiel 8080 oder 8081

Proxy User

(optional)

Benutzername für die Anmeldung am Proxy-Server sofern diese notwendig ist.

Kennwort für die Anmeldung am Proxy-Server

Proxy Password

(optional)

Use direct connection on port 22 outgoing

(preferred)

Diese Option muss aktiviert werden, wenn eine SSH-Verbindung direkt und ohne Umweg über einen Proxy-Server ins Internet möglich ist.

Connect through

SOCKS 4 proxy

Connect through

SOCKS 5 proxy

Connect through

HTTP proxy

Connect through

Telnet proxy

Diese Option muss aktiviert werden, um SSH-Verbindungen durch einen generischen SOCKS-Proxy zu tunneln. Diese Option kann verwendet werden, wenn der direkte Zugang via SSH ins Internet reglementiert ist, für dass SEPPmail System aber die Verbindung über einen SOCKS-Proxy

(Version 4) ins Internet möglich ist.

(Version 5) ins Internet möglich ist.

Diese Option muss aktiviert werden, um SSH-Verbindungen durch einen

HTTP-Proxy zu tunneln. Diese Option kann verwendet werden, wenn der direkte Zugang via SSH ins Internet reglementiert ist, für dass SEPPmail

System aber die Verbindung über einen HTTP-Proxy ins Internet möglich ist.

Diese Option muss aktiviert werden, um SSH-Verbindungen durch einen

Telnet-Proxy zu tunneln. Diese Option kann verwendet werden, wenn der direkte Zugang via SSH ins Internet reglementiert ist, für dass SEPPmail

System aber die Verbindung über einen Telnet-Proxy ins Internet möglich ist.

Use port 80 instead of

Diese Option muss aktiviert werden, wenn eine HTTP-Verbindung direkt ins Internet möglich ist. Die SSH-Verbindung verwendet dann den Port

TCP 80 (HTTP) statt TCP 22 (SSH).

Sektion

OCSP / CRL check Settings

(optional)

Über diese Sektion kann das Prüfen der Zertifikatsgültigkeit über Sperrlisten ("certificate revocation list" kurz "CRL") und / oder das Online Certificate Status Protocol (OCSP) aktiviert werden. Für den

Abruf dieser Informationen wird jeweils Zugriff zur ausstellenden Certification Authorothy (CA) benötigt. Hat die Appliance keine direkten Zugriff in das Internet, so kann an dieser Stelle zusätzlich die Verbindung über einen Proxy Server Konfiguriert werden.

Parameter Beschreibung

Enable OCSP / CRL checks for S/MIME certificates.

Proxy Server

Diese Option muss aktiviert werden, sofern eine OCSP / CRL Prüfung erwünscht ist.

Proxy Port

Proxy User

(optional)

Proxy Password

(optional)

Use direct connection

Hostname oder IP-Adresse des Proxy-Servers, über welchen die HTTP /

HTTPS Kommunikation zur CA hin hergestellt werden soll.

Ziel-Port des Proxy-Servers, zum Beispiel 8080 oder 8081

Benutzername für die Anmeldung am Proxy-Server sofern diese notwendig ist.

Kennwort für die Anmeldung am Proxy-Server

Connect through

SOCKS 4 proxy

Connect through

SOCKS 5 proxy

Connect through

HTTP proxy

Diese Option muss aktiviert werden, wenn eine HTTP- / HTTPS-

Verbindung direkt und ohne Umweg über einen Proxy-Server ins Internet möglich ist.

Diese Option muss aktiviert werden, um HTTP- / HTTPS-Verbindungen durch einen generischen SOCKS-Proxy zu tunneln. Diese Option kann verwendet werden, wenn der direkte Zugang via HTTP / HTTPS ins

Internet reglementiert ist, für dass SEPPmail System aber die Verbindung

über einen SOCKS-Proxy (Version 4) ins Internet möglich ist.

Diese Option muss aktiviert werden, um HTTP- / HTTPS-Verbindungen durch einen generischen SOCKS-Proxy zu tunneln. Diese Option kann verwendet werden, wenn der direkte Zugang via HTTP / HTTPS ins

Internet reglementiert ist, für dass SEPPmail System aber die Verbindung

über einen SOCKS-Proxy (Version 5) ins Internet möglich ist.

Diese Option muss aktiviert werden, um HTTP- / HTTPS-Verbindungen durch einen HTTP-Proxy zu tunneln. Diese Option kann verwendet werden, wenn der direkte Zugang via HTTP / HTTPS ins Internet reglementiert ist, für dass SEPPmail System aber die Verbindung über einen HTTP-Proxy ins Internet möglich ist.

Sektion

Time zone

Parameter Beschreibung

Auswahl der Zeitzone

Auswahl der für den Standort des SEPPmail Systems gültigen Zeitzone.

Der Wechsel zwischen Sommer- und Winterzeit wird automatisch durchgeführt.

127

128

Sektion

Time and Date

Parameter Beschreibung

No time sync

Automatically synchronize with an

NTP server

Mit dieser Einstellung wird ausschliesslich die interne Systemzeit verwendet. Diese kann über Set date and time manually entsprechend eingestellt werden. Ein automatische Abgleich mit anderen Systemen findet nicht statt!

Bei dieser Option werden Datum und Uhrzeit gegen den unter

"Server"

angegebenen Zeitserver über das Protokoll NTP, Zielport UCP 123, synchronisiert.

Server

Set date and time manually

Date

Time

Hinweis:

Diese Option ist für die Einrichtung eines Clusters auf allen

Cluster Membern zwingend erforderlich.

Die ausgewählte Zeitzone (siehe Sektion "Time Zone") spielt für die Synchronisation im Cluster keine Rolle.

Hostname oder IP-Adresse eines Zeitservers. Dieser kann sich in Ihrem

Firmennetzwerk oder im Internet befinden.

Gegebenenfalls ist die Angabe eines Hostnamens, der in mehrere

Zeitserver aufgelöst wird, bezüglich des Gewährleistens der Verfügbarkeit von Vorteil.

Steht kein NTP-Zugang zur Verfügung, so kann an dieser Stelle das aktuelle Datum und die aktuelle Uhrzeit manuell eingeben werden.

aktuelles Datum im Format: dd.mm.yyyy

aktuelle Uhrzeit im Format: hh:mm:ss

129

Sektion

SNMP Daemon

(optional)

Die hier vorgenommenen Änderungen werden erst nach einem Neustart der SEPPmail-Appliance aktiv.

Wird weder bei "snmp v1/2 Read-only Community" noch bei "snmp v1/2 Read-write Community"

eine Eingabe gemacht, so wird SNMP v1/2 deaktiviert.

Für die SNMP v3 Verschlüsselung wird AES, für die Authentifikation SHA als Algorithmus verwendet

Parameter Beschreibung

Enable SNMP

Aktivieren und deaktivieren des SNMP Deamon auf dem SEPPmail

System. Nach Aktivierung des SNMP Protokols können Sie mit SNMP-

Tools wie zum Beispiel snmpwalk Informationen Ihres SEPPmail Systems abrufen.

IP-Adresse zu der sich das SNMP-Monitoring verbindet. Dies ist in der

Regel die IP-Adresse der SEPPmail-Appliance.

Passwort für den Nur-Lese Zugriff auf die SNMP-Daten.

Listen Address snmp v1/2 Read-only

Community snmp v1/2 Read-write

Community snmp v3 user snmp v3 password

Download MIBs

Passwort für den Schreib-Lese Zugriff auf die SNMP-Daten.

Benutzername für den SNMP v3 Zugriff

Passwort für den SNMP v3 Zugriff. Dieses muss mindestens acht Zeichen lang sein.

Über diesen Link können Sie Management Information Bases (MIB) des

SEPPmail Systems als ZIP-Datei herunterladen.

Sektion

VMware Tools

(optional)

Parameter Beschreibung

Enable VMware tools

(restart to activate setting)

Im Standard wird ein OS-Kernel mit aktivierten VMware Tools verwendet.

Da diese Tools in einigen wenigen Konstellationen mit ESX, sowie mit einigen Backup Tools, welche "quiescing" verwenden, zu Problemen führen können, besteht die Möglichkeit diese zu deaktivieren.

Eine hier vorgenommene Änderung wird erst nach einem Neustart der

SEPPmail-Appliance aktiv.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

130

7.5 Mail System

Im Menüpunkt

Mail System

werden grundlegende Einstellungen des SEPPmail E-Mail-Systems vorgenommen.

Sektion

Managed Domains

Definiert die E-Mail-Domänen welche verwaltet werden sollen.

Spalte Beschreibung

Domain Name

Liste aller auf dem SEPPmail-System angelegten E-Mail Domänen. Für diese

Domänen werden E-Mails angenommen und entsprechend verarbeitet.

Server IP Address

Zeigt die IP-Adresse, den Hostnamen oder den MX-Eintrag des internen

Groupware Systems an, an welches eingehende E-Mails für den jeweils oben genannten Domain Name weitergeleitet werden.

Server Port

TLS level

GINA Settings

Disclaimer

Settings

(optional)

Customer

(optional)

Add Domain...

Zeigt den Port an, auf welchem die jeweils oben genannten Server IP

Address E-Mails für den zugehörigen Domain Name annimmt.

Zeigt an, welche Art der TLS-Transportverschlüsselung für die jeweilige E-

Mail Domäne verwendet wird.

Zeigt das GINA-Profil an, welches für jeweilige E-Mail Domäne festgelegt wurde (siehe auch

Edit GINA Settings

169

Zeigt an, welcher Disclaimer an ausgehende E-Mails der jeweiligen E-Mail

Domäne angefügt werden soll (siehe auch

Mail Processing

Edit

Disclaimer

154

Name des Kunden, dem diese E-Mail Domäne zugeordnet wurde (siehe auch

Customers

243

Wählen Sie diese Schaltfläche, um weitere E-Mail Domänen hinzuzufügen.

Diese E-Mail Domänen müssen passend sein zu den E-Mail- Adressen Ihres

Unternehmens. Weitere Informationen zur Verwaltung von E-MailDomänen erhalten Sie im Kapitel

Add/Edit Managed Domain

139

Automatically create and publish

S/MIME domain keys for all domains

Dieser Parameter bewirkt, dass für alle über die Schaltfläche

Add

Domain...

neu hinzugefügten E-Mail Domänen automatisch ein selbst signiertes X.509 S/MIME Domänen Zertifikat erzeugt und an einen zentralen

Updateservice übertragen wird. Dieses neu erzeugte S/MIME Domänen

Zertifikat (also ausschliesslich der öffentliche Schlüssel !!!) für Ihre E-Mail

Domänen wird danach automatisch an alle SEPPmail-Systeme verteilt, so dass alle Unternehmen die ein SEPPmail-System betreiben ohne weiteren

Aufwand E-Mails ausschliesslich verschlüsselt untereinander austauschen.

Dieser Service ist bereits in der Basis-Lizenz enthalten und erfordert keine zusätzlichen Encryption-Lizenzen.

Hinweis:

Die Genehmigung der Veröffentlichung des S/MIME-

Domainzertifikats muss bei SEPPmail nach Erstellung der

Managed Domain nochmals explizit erteilt werden.

Soll nicht am Managed Domain Service teilgenommen werden, so ist diese Option zu deaktivieren bevor die erste

E-Mail Domäne angelegt wird. Das S/MIME-Domain-

131

Spalte

Fetch Mail from remote POP3 server

Verify recipient addresses using

SMTP-Lookups

Beschreibung

Zertifikat wird dann nicht automatisch erzeugt.

Dieser Parameter bewirkt, dass das im Benutzerkonto eingerichtete POP3-

Konto durch SEPPmail jeweils in einem Zeitintervall von drei Minuten abgeholt wird. Die so abgeholten E-Mails werden im Anschluss durch das

SEPPmail System verarbeitet und an den entsprechenden "Forwarding

Server" (Server IP Address) weitergeleitet.

Siehe auch Kapitel Benutzerdetails

Remote POP3

227

Dieser Parameter bewirkt, dass die E-Mail-Adresse des Empfängers vorab bei dem für die E-Mail Domäne eingerichteten E-Mail-Server an den die E-

Mails weitergeleitet werden überprüft wird. Verläuft die Prüfung der

Empfänger E-Mail-Adresse nicht erfolgreich, wird die Annahme der E-Mail vom SEPPmail System verweigert.

Hinweis:

Damit diese Einstellung problemlos funktioniert, ist darauf zu achten, dass der als "Forwarding Server" (Server IP

Address) angezeigte Server keinen Spam Schutz aktiviert hat und nur E-Mails derjenigen Adressen annimmt, welche tatsächlich existent sind.

Daher ist insbesondere dann mit Problemen bei Aktivieren dieser Einstellung zu rechnen, wenn der nachgelagerte

(Forwarding-)Server nicht der E-Mail Server sondern ein weiteres, zwischengeschaltetes E-Mail Relay ist.

132

Sektion

Outgoing Server

Definiert die Art der Weiterleitung ausgehender E-Mails.

Parameter Beschreibung

Use built-in mail transport agent

Use the following

SMTP server

Server name

User ID

Server requires authentication

Dieser Parameter bewirkt, dass ausgehende E-Mails in Richtung Internet direkt durch das SEPPmail System an den Ziel E-Mail-Server des E-Mail-

Empfängers zugestellt wird. Die Appliance muss für diese Einstellung direkt aus dem Internet per MX-Record erreichbar sein.

Hinweis:

Bei Verwenden dieser Einstellung wird dringend empfohlen das optionale Protection Pack (VSPP) zu lizensieren und aktivieren, sofern für den eingehenden E-Mail Verkehr nicht etwa ein externer AntiSpam-Dienst vorgeschaltet ist.

Andernfalls ist mit erheblichen Beeinträchtigungen, bis hin zum Erliegen des Mailflusses durch SPAM-Attacken zu rechnen.

Möchten Sie ausgehende E-Mails in Richtung Internet nicht direkt zustellen empfielt sich das Verwenden eines E-Mail-Relay-Servers (Smart Host). Alle ausgehenden E-Mails werden an diesen E-Mail-Relay-Server übertragen, welcher dann Ihre E-Mails in Richtung Empfänger weiterleitet. Der E-Mail-

Relay-Server kann ein Interner Server aber auch ein Server bei Ihrem E-Mail

Provider sein.

Als Eingabe wird folgendes aktzeptiert:

IP-Adresse

Hostname

MX-Name einzelne IP-Adresse (in eckige Klammern [ ] zu setzen).

wird ein Hostname verwendet, so ist dieser in eckige

Klammern [ ] zu setzen. Namen ohne Klammern werden als MX-Eintrag behandelt!

MX-lookup wird ausgeführt

Optional ist bei Angabe einer IP-Adresse oder eines Hostnamens zusätzlich die Angabe eines individuellen Ports möglich. Dieser wird direkt im Anschluss mit einem Doppelpunkt ":" getrennt angegeben, also "[IP-Adresse]:Port" oder

"[Hostname]:Port".

Wird kein Port angegeben, so wird der Standard SMTP-Port TCP25 verwendet.

E-Mail-Relay-Server bei einem Provider benötigen vor dem Übertragen von E-

Mails meist eine Anmeldung. Verwenden Sie hierzu die entsprechenden

Anmeldedaten.

Geben Sie hier bitte den Benutzernamen zur Anmeldung ein.

Password

Geben Sie hier bitte das Kennwort zur Anmeldung ein.

133

Sektion

TLS settings

(optional)

An dieser Stelle werden TLS-Verbindungen nach aussen aufgelistet beziehungsweise eingerichtet.

Wurde in der Sektion

Outgoing Server

die Option Use the following SMTP server gewählt, so kann hier zu dem oder den unter

Server name

eingetragenen Server(n) TLS-Verschlüsselung eingerichtet werden. Wurde die Option Use built-in mail transport agent gewählt, so kann hier bei

Bedarf zu beliebigen E-Mail Servern im Internet ein TLS-Verbindung konfiguriert werden, sofern diese

TLS unterstützen.

Hinweis:

Wird hier keine Konfiguration vorgenommen, so gilt die Einstellung "may", das heisst die SEPPmail-Appliance wird zu allen Kommunikationspartnern eine TLSverschlüsselte Verbindung aufbauen, sofenr die Gegenstelle dies unterstützt.

Für die TLS Verschlüsselung wird das unter

SSL

187

eingebundene Zertifikat

verwendet.

Parameter Beschreibung

Domain Name

Liste aller auf dem SEPPmail-System angelegten E-Mail Domänen, für welche eine TLS-Verbindung konfiguriert wurde auf.

Server IP Address

Zeigt die IP-Adresse, den Hostnamen oder den MX-Eintrag für den jeweils oben genannten Domain Name an.

Server Port

TLS level

Fingerprint

Zeigt den Port an, welcher für die TLS-verschlüsselte Verbindung zur oben genannten Server IP Address verwendet wird. Im Standard ist das 25.

Zeigt an, welche Art der TLS-Transportverschlüsselung von der SEPPmail

Appliance zum angegebenen E-Mail-Server für die jeweilige E-Mail Domäne verwendet wird.

Wurde als TLS level Fingerprint gewählt, so werden hier die eingetragenen

Fingerprints der Zertifikate angezeigt..

Um bestehende TLS-Verbindungen zu verwalten ist auf den jeweiligen "Domain Name" zu klicken.

Neue TLS-Verbindungen werden über die Schaltfläche

Add TLS Domain...

eingerichtet.

Weitere Informationen zur Verwaltung von TLS E-Mail Domänen erhalten Sie im Kapitel

Add TLS

Domain

145

134

Sektion

SMTP settings

Definiert spezifische Einstellungen für das SMTP-Protokoll.

Parameter Beschreibung

max. message size

(KiB)

(optional)

In diesem Feld wird die maximale Grösse einer E-Mail in Kibibyte definiert, die durch das SEPPmail-System übertragen werden darf. E-Mails, welche diese

Grösse überschreiten werden abgelehnt. Wird hier eine Beschränkung festgelegt, so ist darauf zu achten, wie diese gegebenenfalls mit dem

Groupware Server beziehungsweise des optional zum Internet hin vorgeschalteten Systems zusammenpasst. Sollte die SEPPmail-Appliance

über den MX-Record im Internet direkt angesprochen werden ist der Eintrag eines Limits zwingend. Dieses darf die angezeigte Grosse (siehe Note:

cannot exceed xxxxx KiB) nicht überschreiten.

Achtung:

Wird ein Anhang via SMTP versendet, so kann dieser bei base64 Kodierung auf 4/3 seiner ursprünglichen Grösse anwachsen!

Weiterhin erfolgt die Angabe in Kibibyte (siehe auch http://de.

wikipedia.org/wiki/Byte )!

Postmaster address

Eingabe der E-Mail Adresse des lokalen Administrators des SEPPmail-

Systems. Alle vom SEPPmail erzeugten Statusmeldungen wie zum Beispiel

Watchdog Meldungen, aber auch die Daily Reports (siehe auch

Groups

admin

233

und

statisticsadmin

234

) werden an diese E-Mail-Adresse gesendet.

Hinweis:

Die

Postmaster address

muss gesetzt werden um

Systembenachrichtigungen empfangen zu können.

SMTP server banner string

(optional)

SMTP server HELO string

(optional)

SMTP bind address

(use with care!)

(optional)

Festlegen des Namens, mit welchem sich die SEPPmail Appliance beim

Aufbau einer SMTP-Verbindung von aussen meldet.

Bleibt der Eintrag leer, so wird der unter

System

Name

121

eingegebene

Name verwendet.

Festlegen, mit welchen Namen sich die SEPPmail Appliance, beim Versand von E-Mails beim gegenüberliegenden SMTP Server melden Soll (HELO/

EHLO-Befehl).

Die Appliance wird sich im Normalfall mit dem unter

System

Name

121 eingegebenen Namen melden. Handelt es sich hierbei zum Beispiel um einen aus dem internet nicht erreichbaren Namen (zum Beispiel Domäne ".local") so kann es erforderlich sein, hier den aus dem Internet erreichbaren Namen

(FQDN) einzutragen. Somit wird gewährleistet, dass E-Mail Server welche mit der Einstellung "Require fully qualified domain name in HELO command" arbeiten E-Mails von der SEPPmail-Appliance auch annehmen. Das heisst die Einstellung ist meist nur dann relevant, wenn in der Sektion

Outgoing

Server

132

dieses Menüs die Einstellung Use built-in mail transport agent aktiv ist.

Festlegen der IP-Adresse einer Netzwerk-Schnittstelle, über die alle E-Mails empfangen werden (normalerweise nicht notwendig).

Die SEPPmail-Appliance bindet im Normalfall alle vorhandenen Netzwerk

Parameter

135

Beschreibung

Interfaces. Sind mehrere Interfaces aktiv, jedoch nur eines davon soll für

SMTP Verbindungen zur Verfügung stehen, so kann dessen IP-Adresse hier eingetragen werden.

Hinweis:

Fällt das Interface der hier eingetragenen IP-Adresse aus, so ist die Appliance per SMTP nicht mehr erreichbar. Somit würde auch der E-Mail Verkehr unterbrochen.

Sektion

Relaying

Definition der für den Versand von E-Mails in das Internet berechtigten Systeme.

Parameter Beschreibung

Relaying allowed:

Add Relaying for

Geben Sie hier die IP-Adresse oder das Subnetz an, von welcher/m das

SEPPmail System annehmen soll.

Nach dem Speichern werden jeweils ein weitere Eingabefelder eingeblendet.

Hinweis:

In der Regel sind hier die IP-Adressen der Forwarding Server

(siehe

Managed Domains

130

beziehungsweise Kapitel

Add/

Edit Managed Domain

139

) zu berechtigen.

Um ein sogenanntes "open relay" zu verhindern, sollte hier im Normalfall keinesfalls der

Outgoing Server

132

mit aufgelistet sein.

Dieses Feld dient der Eingabe weiterer Relay Adressen beziehungsweise

Subnetzen.

Nach dem Speichern werden jeweils weitere Eingabefelder eingeblendet.

136

Sektion

Antispam

Hinweis:

Die Antispam Optionen sind erst nach Erwerb des optionalen Protection Packs

(VSPP) verfügbar.

Parameter Beschreibung

Recommended Settings

Use Greylisting

Aktiviert das Greylisting auf dem SEPPmail-System.

Durch diese Funktion werden eingehende externe E-Mails - d.h. E-Mails welche von keiner unter

Relaying

135

eingetragener IP oder Subnetz kommen

- nicht mehr unmittelbar sondern zeitlich verzögert angenommen. Dies bewirkt, dass von SPAM-Versendern verwendete Methoden zur direkten

Übertragung von E-Mails erfolglos bleiben.

Der Empfang von gewünschten E-Mails wird durch diese Funktion nicht verhindert, sondern lediglich zeitlich verzögert. Der E-Mail-Server des

Absenders wird nach einer kurzen Zeit einen erneuten Zustellversuch unternehmen. Die E-Mail wird dann angenommen.

Hinweis:

Diese Funktion ist nur wirksam, wenn das SEPPmail-System eingehende E-Mails direkt dem Internet direkt empfängt

(Einstellung

Outgoing Server

132

Use built-in mail

transport agent). Bereits von einem anderen E-Mail-Server empfangene und weitergeleitete SPAM E-Mails können durch diese Funktion nicht vermieden werden

Use Antispam

Engine (Note: remember to activate in ruleset)

Hinweis zum Greylisting

Greylisting ist eine Methode zur Bekämpfung von SPAM E-Mails. Bei dieser

Funktion wird davon ausgegangen, dass E-Mail-Server und E-Mail-Clients sich an den RFC-Standard für SMTP halten. SPAM-Versender halten sich meist nicht an den RFC-Standard. Sie werten in der Regel das temporäre

Abweisen nicht aus, wodurch eine weiterer Zustellversuch unterbleibt.

Da sich selbst per E-Mail verbreitende Viren - sogenannte Würmer - nach dem Gleichen Prinzip arbeiten, bietet Greylisting auch hier entsprechenden

Schutz.

Um eventuelle Einschränkungen durch übermässiges, einmaliges Abweisen gewünschter E-Mails zu vermeiden, wird empfohlen die Option Greylist

learning only (no mail rejection) aus den "optional Settings" für zwei bis vier Wochen zu aktivieren. Hierdurch wird die SEPPmail Appliance bezüglich des Greylistings in einem Lernmodus und weist keine E-Mails temporär zurück.

Dieser Parameter aktiviert den SPAM-Filter auf dem SEPPmail-System. Die

Konfiguration des SPAM-Filters wird im Abschnitt

Protection Pack

162

der

Sektion

Ruleset Generator

des Menüs

Mail Processing

durchgeführt.

137

Parameter Beschreibung

Use Antivirus

Engine (Note: remember to activate in ruleset)

Require HELO command

Dieser Parameter aktiviert den Virenscanner auf dem SEPPmail System. Die

Konfiguration des Virenscanners wird im Abschnitt

Protection Pack

162

der

Sektion

Ruleset Generator

des Menüs

Mail Processing

durchgeführt.

PTR check

(reverse DNS lookup)

Check if sender domain is valid

Nach Aktivieren dieses Parameters prüft die SEPPmail, ob das HELO

Kommando vom absendenden E-Mail-Server gesendet wurde. Wird das

Kommando nicht gesendet, so wird die Entgegennahme der E-Mails verweigert.

SPAM-Versender benutzen häufig E-Mail-Server ohne gültigen DNS-Eintrag.

Wird diese Option aktiviert, so werden E-Mails von Servern zu deren IP-

Adresse keinen gültiger DNS-Eintrag vorhanden ist abgewiesen.

Mit dieser Option wird das Überprüfen der Absender Domäne (der Teil hinter dem @ der absendenden E-Mail-Adresse) eingehender E-Mails aktiviert.

Kann diese nicht per DNS aufgelöst werden, so wird die E-Mail abgewiesen.

Hinweis:

Diese Einstellung bleibt von einem eventuellen Whitelisting

(siehe Sektion

Manual Blacklisting / Whitelisting

138

) unberührt!

Require valid hostname in

HELO command

Require fully qualified hostname in

HELO command

Limit incoming connections for

SMTP per IP optional Settings

Ist diese Option aktiviert, so werden nur E-Mails von Servern angenommen, welche sich im HELO Kommando mit einem gültigen - das heisst im DNS auflösbaren - Hostnamen melden. Dies könnte auch ein NetBIOS Name sein.

Durch Aktivieren dieser Option werden nur E-Mails von Servern angenommen, welche sich im HELO Kommando mit ihrem vollständigen, im

DNS auflösbaren FQDN (Fully qualified domain name) identifizieren. Der

FQDN erforder midestens eine Punkt ".", also zum Beispiel "SEPPmail.ch".

Mit dieser Einstellung werden die parallelen Verbindungen über den TCP Port

25 auf maximal zehn pro IP-Adresse limitiert. Hierdurch kann das Überlasten der SEPPmail-Appliance durch einzelne Server vermieden werden.

Greylist learning only (no mail rejection)

Dieser Parameter aktiviert den Greylisting-Lernmodus. Dabei wird die

Datenbank mit den für den Greylisting-Betrieb benötigten Informationen aufgebaut. Bei Neuinstallationen wird empfohlen diese Option zwei bis vier

Wochen zu verwenden, um in der Statrphase keine Engpässe durch das

Greylisting zu verursachen.

Strict PTR check

(reserse DNS lookup)

Diese Option aktiviert eine doppelte DNS Prüfung. Zunächst wird geprüft, ob zur IP-Adresse ein gültiger DNS Eintrag vorhanden ist um im Anschluss zu prüfen, ob die DNS-Abfrage die ursprüngliche IP ausgibt.

138

Sektion

Blacklists

Parameter Beschreibung

Add Blacklist

(RBL)

E-Mail-Server werden aufgrund von SPAM-Aktivitäten in sogenannte

Blacklists aufgenommen. Diese Listen werden durch verschiedene Anbieter im Internet gepflegt. Um E-Mails von Servern welche in diesen Listen aufgeführt sind abzuweisen, müssen die URLs der gewünschten Realtime

Blackhole Lists (RBL) eingetragen werden.

Nach dem Speichern wird jeweils ein weiteres Eingabefeld eingeblendet.

Sektion

Manual Blacklisting / Whitelisting

In diesem Menüpunkt kann der Empfang von externen E-Mails von bestimmten IP-Adressen beziehungsweise -Netzwerken blockiert oder explizit zugelassen werden.

Parameter Beschreibung add acccess entry

Für das Blockieren oder Zulassen wird das IP-Netzwerk, die Aktion und einen

Kommentar in die entsprechende Eingabefelder eingetragen.

network: action:

IP-Adresse oder

Netzwerk in der angegebenen

Form

accept

aktzeptiert die

Annahme

(Whitelist)

reject

verweigert die

Annahme

(Blacklist)

comment:

Aussagekräftiger Kommentar, weshalb die Regel eingetragen wurden und wen diese betrifft.

Beispiel:

Um alle E-Mails die aus dem IP-Netzwerk Bereich 186.56.148.x gesendet werden zu verwerfen, geben Sie den IP-Netzwerk Teil 186.56.148 ein und definieren Sie die Aktion reject.

network:

186.56.148

action: comment:

reject

Diese Testregel weist alle E-Mails ab, welche aus dem IP-Adressbereich 186.56.148.0 /24 kommen.

Hinweis:

Externe Adressen, an welche E-Mails von intern verschickt wurden, werden automatisch whitelisted, also aus dem Greylisting und ggf. anderen Spam-Checks ausgenommen.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

139

7.5.1

Untermenü Add/Edit Managed Domain

Sektion

Settings

Bei der Anlage einer neuen Managed Domain über die Schaltfläche

Add Managed Domain...

ist nur diese Sektion zu sehen.

Parameter Beschreibung

Domain

Name

Forwarding

Server

IP or MX name

Assigned to

Customer

(nur bei

Mandantenfähigen

Systemen)

Name der E-Mail Domäne, für welche durch das SEPPmail-System E-Mails angenommen und verarbeitet werden sollen. Es können mehrere E-Mail-Domänen gleichzeitig eingetragen werden. Diese müssen durch Leerzeichen getrennt werden.

Die Appliance wird dadurch pro E-Mail-Domäne eine "Managed Domain" mit identischen Einstellungen anlegen.

Diese Einstellung ist nur beim Anlegen einer neuen "Managed Domain" - das heisst wenn das Menü über die Schalttfläche

Add Managed Domain...

aufgerufen wurde - editierbar.

Hinweis:

Werden Subdomänen verwendet, so müssen dies separat aufgeführt werden, damit E-Mail für diese angenommen werden.

So werden beispielsweise durch den Eintrag "meinefirma.ch" keine

E-Mails für die Subdomäne "tochter.meinefirma.ch" angenommen.

Angabe des E-Mail Servers, an welchen die für den oben genannten Domain Name eingehenden E-Mails nach Verarbeitung durch das SEPPmail-System weitergeleitet werden sollen.

Als Eingabe wird folgendes aktzeptiert:

IP-Adresse einzelne IP-Adresse (in eckige Klammern [ ] zu setzen).

Hostname wird ein Hostname verwendet, so ist dieser in eckige

Klammern [ ] zu setzen. Namen ohne Klammern werden als MX-Eintrag behandelt!

MX-lookup wird ausgeführt MX-Name

Optional ist bei Angabe einer IP-Adresse oder eines Hostnamens zusätzlich die

Angabe eines individuellen Ports möglich. Dieser wird direkt im Anschluss mit einem

Doppelpunkt ":" getrennt angegeben, also "[IP-Adresse]:Port" oder "[Hostname]:

Port".

Wird kein Port angegeben, so wird der Standard SMTP-Port TCP25 verwendet.

Zuordnung zu einem unter

Customers

243

bereits angelegten Kunden in einem mandantenfähigem System.

Die Zuordnung zu einem Kunden ist nur beim Anlegen einer neuen Managed

Domain - das heisst wenn das Menü über die Schalttfläche

Add Managed

Domain...

aufgerufen wurde - möglich.

140

Hinweis:

Alle folgenden Einstellungen sind nur zu sehen, wenn das Menü durch Klicken auf eine "Managed Domain" aus dem übergeordneten Menü aufgerufen wurde.

Sektion

External Authentication

Wird die GINA-Technologie auch intern eingesetzt, zum Beispiel für das Large File Management

(LFM) oder Internal Mail Encryption (IME), so ermöglicht diese Option die Authentisierung der

Benutzer der "jeweiligen Managed Domain" gegen einen "externen" LDAP-Server (zum Beispiel Active

Directory).

Parameter Beschreibung

Authenticate

GINA users from this domain to external LDAP server (eg. Active

Directory)

Server

Mit Anwahl dieser Option wird die "externe" LDAP Authentisierung" aktiviert.

Port

TLS required

Bind DN

Bind Password

Angabe des LDAP Servers, gegen welchen authentisiert werden soll. Als

Eingabe wird der Hostname oder die IP-Adresse aktzeptiert.

Gibt den Port an, auf welchem der externe LDAP-Server Anfragen entgegen nimmt. Standard LDAP-Port ist 389, beziehungsweise 636 für LDAPS (siehe auch

TLS required

Wird diese Option aktiviert, so wird das Verschlüsseln der Verbindung zum

LDAP-Server mittels TLSv1 oder höher erzwungen (LDAPS oder

LDAPS+STARTTLS).

Eingabe des vollständigen Distinguished Name (DN) des read-only Accounts, welcher zur Suche des unter "External User Attributes

Search Base E-Mail

Attribute

" in der LDAP Datenbank berechtigt ist.

Passwort für das authentisieren des unter

Bind DN

einegebenen Accounts.

External User

Attributes

LDAP ObjectClass

Eingabe der LDAP-Klasse der Benutzerobjekte am externen LDAP-Server. Standard ist "*"

Search Base

E-Mail Attribute

(Default: "mail")

Suchpfad: Gibt den Zweig der LDAP Datenbank an, in welchem die zu authentisierenden Benutzer gesucht werden sollen.

Angabe des Attributes der LDAP Datenbank, unter welchem die E-Mail-Adresse des zu authentisierenden Benutzers in der angegebenen

Search Base

gespeichert ist. Standard ist "mail".

Funktionsweise:

Wird aufgrund oben genannter Konfiguration die E-Mail Adresse des sich anmeldenden Benutzers

(GINA-Accounts) und somit dessen DN in der LDAP Datenbank gefunden, so wird mit dieser DN und dem vom Benutzer im GINA-Interface eingegebenen Passwort ein neuerlicher Bind versucht. Ist

141 dieser Bind erfolgreich, so gilt die Authentifizierung am GINA-Interface ebenfalls als erfolgreich.

Interaktion mit lokalen GINA-Accounts:

Die Accounts müssen weiterhin auf der SEPPmail-Appliance angelegt werden. Ebenso muss ein lokales Passwort gesetzt werden. Dieses Passwort wird jedoch nicht für die Authentisierung verwendet, solange die externe Authentisierung aktiviert ist.

Während der Erstregistrierung des Accounts wird ein entsprechender Hinweis angezeigt.

Wird bei der Anmeldung am GINA-Interface das lokal - statt dem im LDAP - hinterlegte Passwort verwendet, dann - und nur dann! - erhält der Benutzer einen entsprechenden Hinweis (siehe

Mail

Processing GINA

Domains

GINA

Edit

Language Settings

Edit Translations

Edit

Translation File

Advanced View

Edit Translation File

185

msgid "ext_auth_enabled").

Die SEPPmail-Appliance führt einen eigenen Zähler für falsche Passwort-Eingaben. Schlägt eine externe Authentisierung öfter fehl als maximal zugelassen, wird der Account lokal temporär deaktiviert.

Dabei findet keine Interaktion mehr mit dem externen Server statt, die Deaktivierung ist also ausschliesslich lokal. Somit kann ein SEPPmail-Administrator einen deaktivierten GINA-Account in der SEPPmail-Administrationsoberfläche jederzeit wieder aktiveren oder dauerhaft deaktivieren.

Weiterhin besteht die Möglichkeit einzelne GINA-Accounts von der externen Authentisierung auszunehmen. In diesem Fall wird jeweils wieder das lokale Passwort für das Login verwendet. (siehe auch GINA-Benutzer-Details

User Data

231

External Authentication)

Hinweis:

Um einen eventuellen, externen Angreifer die Art der Authentisierung nicht Preis zu geben, bleibt der Link "Passwort vergessen?" auch bei aktivierter, externer

Authentisierung in der GINA-Anmeldemaske erhalten.

Sektion openPGP Domain Encryption

In dieser Sektion werden die openPGP Domänen-Schlüssel angezeigt, sofern vorhanden.

Key ID User ID Issued on Expires on

Zeigt die Key ID des/der openPGP-

Domänen-Key(s) an

Zeigt die zur Key ID zugehörige User ID an.

Wurde der Key durch die Appliance generiert, so lautet er in der Regel openPGP Domain Encryption <domainconfidentiality-authority@ihredomain.ch>

Ausstelldatu m des Keys

TT-MM-JJJJ

Ablaufdatum des Keys

TT-MM-JJJJ

Durch Klicken der Key ID wird ein Untermenü mit Details zum Key geöffnet. Dieses bietet die

Möglichkeit den öffentlichen Schlüssel herunterzuladen beziehungsweise das Schlüsselpaar zu löschen.

Über die Schaltfläche

Import openPGP key...

kann ein bereits vorhandenes Schlüsselpaar importiert werden (siehe Untermenü

Import openPGP Key

144

Über die Schaltfläche

Generate new openPGP key

wird ein neues Schlüsselpaar auf der

Appliance generiert (siehe Untermenü

Import S/MIME Key

144

). Die Laufzeit sowie das automatische

Aktualisieren des so erzeugten Schlüssels entspricht der unter

internal CA Settings

197

Validity in days

eingegebenen.

142

Sektion

S/MIME Domain Encryption

In dieser Sektion werden die S/MIME Domänen-Schlüssel angezeigt, sofern vorhanden.

Fingerprint Issued on Expires on

Zeigt den/die Fingerprint/s des/der S/MIME-Domänen-Keys an.

Ist im übergeordneten Menü

Mail System

Managed Domains

130 die Option Automatically create and publish S/MIME domain keys

for all domains aktiviert, so ist hier mindestens ein Zertifikat zu sehen.

Ausstelldatu m des Keys

TT-MM-JJJJ

Ablaufdatum des Keys

TT-MM-JJJJ

Durch Klicken des Fingerprints wird ein Untermenü mit Details zum Key geöffnet. Dieses bietet die

Möglichkeit den öffentlichen Schlüssel (Zertifikat) herunterzuladen beziehungsweise das

Schlüsselpaar zu löschen.

Über die Schaltfläche

Import S/MIME key...

kann ein bereits vorhandenes Schlüsselpaar importiert werden.

Der Schlüsselaustausch zwischen SEPPmail-Systemen erfolgt bei aktivierter Option Automatically

create and publish S/MIME domain keys for all domains über den "Managed Domain Service" automatisch. Somit wird sichergestellt, dass alle SEPPmail-System untereinander Domänen verschlüsselt kommunizieren.

Über die Schaltfläche

Generate S/MIME key

wird durch die integrierte CA ein neues Schlüsselpaar auf der Appliance generiert. Die Laufzeit für die so generierten Zertifikate beträgt immer zehn Jahre.

Sektion

GINA and Disclaimer Settings

Über die Auswahl

Use GINA Settings

können die für die angegebenen E-Mail-Domäne zu verwendenden GINA-Einstellungen ausgewählt werden. Diese können über das Menü

Mail

Processing

GINA Domains

149

erzeugt und editiert werden.

Bei mandantenfähigen Systemen muss hier zwingend die für den Kunden dediziert eingerichtete GINA ausgewählt werden.

Durch die Auswahl

Use Disclaimer

lässt sich eine Fussnote für ausgehende E-Mails wählen. Fussnoten können über das Menü

Mail Processing

Edit Disclaimer

154

erzeugt und editiert werden.

Diese Einstellungen kommen nur dann zum Tragen, wenn die Funktionen in den

General Settings

157 des

Ruleset Generator

des Menüs

Mail Processing

aktiviert wurden.

Sektion

TLS settings

(optional)

Soll zum nachgelagerten Groupware System (siehe Forwarding Server) eine TLS verschlüsselte

Verbindung aufgebaut werden, so kann die TLS Verschlüsselung an dieser Stelle konfiguriert werden.

Das Einrichten von TLS-Verbindungen ist im folgenden Kapitel

Add TLS Domain

146

in der Sektion

TLS Settings

beschrieben.

143

Sektion

Domain Statistics

In dieser Statistik werden nur diejenigen Kryptographie-Technologieen angezeigt, welche auf der

SEPPmail-Appliance bereits zum Einsatz kamen.

Parameter Beschreibung

Number of accounts in this domain

Anzahl der auf der SEPPmail-Appliance angelegten Benutzer (entspricht

User-Lizenzen)

GINA encrypted mails sent

Anzahl der versendeten E-Mails, welche mittels GINA-Technologie verschlüsselt wurden

openPGP encrypted mails sent

Anzahl der versendeten E-Mails, welche mittels openPGP-Technologie verschlüsselt wurden

openPGP encrypted mails received

Anzahl der empfangenen E-Mails, welche mittels -Technologie verschlüsselt waren

S/MIME encrypted mails sent

S/MIME encrypted mails received

Anzahl der versendeten E-Mails, welche mittels S/MIME-Technologie verschlüsselt wurden

Anzahl der empfangenen E-Mails, welche mittels S/MIME-Technologie verschlüsselt waren

Anzahl der versendeten E-Mails, welche mittels S/MIME-Technologie signiert wurden

S/MIME signed mails sent

S/MIME signed mails received openPGP

Domain encrypted mails sent

Anzahl der empfangenen E-Mails, welche mittels S/MIME-Technologie signiert waren

Anzahl der versendeten E-Mails, welche mittels openPGP-Technologie domänenverschlüsselt wurden

openPGP

Domain encrypted mails received

Anzahl der empfangenen E-Mails, welche mittels openPGP-Technologie domänenverschlüsselt waren

S/MIME Domain encrypted mails sent

Anzahl der versendeten E-Mails, welche mittels S/MIME-Technologie domänenverschlüsselt wurden

S/MIME

Domain encrypted mails received

Anzahl der empfangenen E-Mails, welche mittels S/MIME-Technologie domänenverschlüsselt waren

Alle vorgenommenen Änderungen werden über die Schaltfläche

Save changes

gespeichert.

Das Löschen einer Domain erfolgt über

Delete Domain

Hinweis:

Ist einer Domäne gültiges Schlüsselmaterial zugeordnet, so muss dieses vor dem

Löschen der Domäne zurückgewiesen (revoked) werden. Andernfalls erscheinen zunächst entsprechende Warnmeldungen.

144

7.5.1.1

Untermenü Import openPGP Key

Sektion

Key Data

Parameter Beschreibung

Passphrase

Key File

Eingabe für die Passphrase mit welcher der private openPGP Schlüssel bei Export verschlüsselt wurde.

Über die Schaltfläche "Datei auswählen" wird die openPGP Schlüsseldatei ausgewählt, welche importiert werden soll. Diese muss das komplette

Schlüsselpaar, also privaten und öffentlichen Schlüssel enthalten.

or Key as string

Alternativ zur Auswahl einer Schlüssel Datei kann der Schlüssel als Text in dieses

Feld kopiert werden

Über die Schaltfläche

Import

wird der Vorgang abgeschlossen.

7.5.1.2

Untermenü Import S/MIME Key

Sektion

Certificate Data

Parameter Beschreibung

Passphrase

Eingabe für die Passphrase mit welcher der private S/MIME Schlüssel bei Export in eine PKCS#12 Datei verschlüsselt wurde.

PKCS#12 File Über die Schaltfläche "Datei auswählen" wird die S/MIME Schlüsseldatei ausgewählt, welche importiert werden soll. Diese muss das komplette

Schlüsselpaar, also privaten und öffentlichen Schlüssel enthalten.

PKCS#12 Dateien haben die Dateiendung .p12 oder auch .pfx.

Über die Schaltfläche

Import

wird der Vorgang abgeschlossen.

145

7.5.2

Untermenü Add TLS Domain

Sektion

Domain Info

Parameter Beschreibung

Domain

Name

Optional

Forwarding

Server

Address

In der Regel wird hier der Name der E-Mail Domäne des Kommunikationspartners eingetragen.

Diese Einstellung ist nur beim Anlegen einer neuen TLS-Verbindung - das heisst wenn das Menü über die Schalttfläche

Add TLS Domain...

aufgerufen wurde editierbar.

Wird an dieser Stelle kein Eintrag vorgenommen, so wird der unter "Domain Name" angegebene Name per MX aufgelöst.

Als Eingabe wird folgendes aktzeptiert:

IP-Adresse

Hostname einzelne IP-Adresse wird ein Hostname verwendet, so ist dieser in eckige

Klammern [ ] zu setzen. Namen ohne Klammern werden als MX-Eintrag behandelt

MX-lookup wird ausgeführt MX-Name

Optional ist bei Angabe einer IP-Adresse oder eines Hostnamens zusätzlich die

Angabe eines individuellen Ports möglich. Dieser wird direkt im Anschluss mit einem

Doppelpunkt ":" getrennt angegeben, also "IP-Adresse:Port" oder "Hostname:Port".

Wird kein Port angegeben, so wird der Standard SMTP-Port TCP25 verwendet.

146

Sektion

TLS Settings

An dieser Stelle wird der Grad der Prüfungen für eine TLS-Verbindung eingestellt:

TLS-

Einstellung

None

May

Encrypt

Verify

Secure

Fingerprint

Beschreibung

Keine TLS-Verschlüsselung.

E-Mails werden über einen TLS-verschlüsselten Kanal versendet, falls der empfangende E-Mail-Server TLS-Verschlüsselung unterstützt.

E-Mails werden nur versendet, falls der Versand mittels TLS-Verschlüsselung möglich ist.

E-Mails werden nur versendet, falls der Versand via TLS-Verschlüsselung möglich, und das SSL-Zertifikat des empfangenden E-Mail-Servers gültig ist.

E-Mails werden nur versendet, falls der Versand via TLS-Verschlüsselung möglich, das SSL-Zertifikat des empfangenden E-Mail-Servers gültig, der FQDN des E-Mail-

Servers identisch mit dem im Zertifikat eingetragenen Namen (CN) und der Name der E-Mail Domäne identisch mit dem Domänen Namen des E-Mail Servers ist.

Diese Prüfung kann kann nicht bei der Verwendung von Wildcard-

SSL-Zertifikaten eingesetzt werden. Hier sollte alternativ die TLS-

Einstellung Fingerprint verwendet werden.

Wird beim Versenden einer E-Mail via TLS-

Transportverschlüsselung die Logmeldung ...status=deferred

(Server certificate not verified) ausgegeben, so ist das SSL-

Zertifikat des empfangenden E-Mail-Servers auf die Verwendung eines Wildcard-Zertifikats zu überprüfen.

E-Mails werden nur versendet, falls der Versand via TLS-Verschlüsselung möglich ist und das SSL-Zertifikat des empfangenden E-Mail-Servers dem eingetragenen

Fingerprint entspricht.

Stehen für die Ziel-Domäne mehrere E-Mail Server zur Verfügung, so können deren

Fingerprints getrennt durch Pipe "|" eingetragen werden,

Hinweis:

Wird hier keine Konfiguration vorgenommen, so gilt die Einstellung "may", das heisst unterstützt das nachgelagerten Groupware System TLS, so wird die SEPPmail-

Appliance eine TLS-verschlüsselte Verbindung dort hin aufbauen.

Für die TLS Verschlüsselung wird das unter

SSL

eingebundene Zertifikat

verwendet.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save changes

gespeichert.

Erklärende Anmerkungen:

Überprüfen des empfangenden E-Mail-Servers auf die Verwendung eines

Wildcard-SSL-Zertifikats

Ob ein E-Mail-Server ein Wildcard-SSL-Zertifikat verwendet kann sehr einfach mit dem

147

Kommandozeilentool OpenSSL durchgeführt werden.

Beispiel:

# openssl s_client -starttls smtp -crlf -connect xxx.xxx.xxx.xxx:25

Im Beispiel steht xxx.xxx.xxx.xxx für die tatsächliche IP-Adresse des Zielservers. Alternativ kann der

Hostname des Zielservers verwendet werden.

# openssl s_client -starttls smtp -crlf -connect postini.com.s8a1.psmtp.com:25

Das Ergebnis der Abfrage wird wie unten dargestellt aussehen. Anhand des Zertifikats-Subject im

Parameter CN kann festgestellt werden, ob es sich um ein Wildcard-SSL-Zertifikat handelt. Im

Beispiel wurde in der Antwort der Wert CN=*.psmtp.com zurückgegeben. Somit handelt es sich um ein Wildcard-Zertifikat "*", welches für alle Hosts der Domain psmtp.com verwendet werden kann.

Ebenfalls interessant ist der Parameter X509v3 Subject Alternative Name:. Als Wert wird hier DNS:

*.psmtp.com zurückgegeben. In diesem Feld können noch weitere Domains enthalten sein.

# openssl s_client -starttls smtp -crlf -connect postini.com.s8a1.psmtp.com:25

| openssl x509 -text -noout

depth=1 C = US, O = Google Inc, CN = Google Internet Authority

Certificate:

Subject: C=US, ST=California, L=Mountain View, O=Google Inc,

CN=*.

psmtp.com

X509v3 Subject Alternative Name:

DNS:

*.psmtp.com

Die Darstellung der Ausgabe wurde auf die wesentlichen Informationen reduziert.

Auslesen des SHA1-Fingerprint aus dem SSL-Zertifikat des empfangenden E-

Mail-Servers

Einen Schritt zuvor wurde beschrieben, wie das vom empfangenden E-Mail-Server verwendete SSL-

Zertifikat ausgelesen werden kann. Dabei ist es nicht relevant, ob es sich hierbei um ein Wildcard-

Zertifikat handelt oder nicht.

Der Fingerprint eines SSL-Zertifikats kann relativ einfach mir dem Kommandozeilentool OpenSSL ausgelesen werden.

Beispiel:

# openssl s_client -starttls smtp -crlf -connect xxx.xxx.xxx.xxx:25 | openssl x509 -noout -fingerprint

Auch in diesem Beispiel steht xxx.xxx.xxx.xxx für die tatsächliche IP-Adresse des Zielservers, welche alternativ durch den Hostnamen des Zielservers ersetzt werden kann.

148

# openssl s_client -starttls smtp -crlf -connect postini.com.s8a1.psmtp.com:25

| openssl x509 -noout -fingerprint

Die daraus resultierende Ausgabe sollte wie folgt aussehen:

# openssl s_client -starttls smtp -crlf -connect postini.com.s8a1.psmtp.com:25

| openssl x509 -noout -fingerprint depth=1 C = US, O = Google Inc, CN = Google Internet Authority verify error:num=20:unable to get local issuer certificate verify return:0

250 HELP

SHA1 Fingerprint=DD:9A:EC:66:E2:43:81:B9:20:2B:75:DB:30:C8:67:CC:9B:B0:D1:99

read:errno=0

In der Ausgabe wird der benötigte SHA1 Fingerprint angezeigt. Dieser Wert kann nun in die

Konfiguration übernommen werden.

149

7.6 Mail Processing

Im Menüpunkt

Mail Processing

wird das Regelwerk des SEPPmail-Systems konfiguriert.

Dieses Regelwerk ist mit einem Workflow System vergleichbar und stellt das zentrale Element der

SEPPmail-Appliance dar.

Sektion

GINA Domains

Indiviuduelle Einstellungen zu den einzelnen GINA-Interfaces.

Parameter Beschreibung

Auswahl der zu bearbeitenden

GINA Domain

Im Standard ist an dieser Stelle eine "[default]" GINA vorhanden. Sollte nur ein

GINA Webinterface benötigt werden, so ist es ausreichend diese "[default]"

Einstellungen individuell anzupassen.

Sollten mehrere "Managed Domains" auf dem System eingerichtet sein, so können über die Schaltfläche

Create new GINA domain

weitere GINA

Webinterfaces eingerichtet werden (siehe Untermenü

Create new GINA

Domain

169

). Bei einer mandantenfähigen Installation ist es zwingend

erforderlich, für jeden Kunden wenigstens eine GINA Webinterface zu erstellen.

Das Einrichten erfolgt jeweils durch Auswahl der zu konfigurierenden GINA

über das Drop-Down-Menü und klicken der Schaltfläche

Edit

. (siehe

Untermenü

Untermenü GINA Settings

169

Die Zuordung des jeweiligen GINA Webinterfaces zur jeweiligen "Managed

Domain" erfolgt in der Sektion

GINA and Disclaimer Settings

des

Untermenüs

Add/Edit Managed Domain

142

aus

Mail System

Managed

Domains

Soll ein GINA Webinterface über die Schaltfläche

Delete

gelöscht werden, so ist vorher unbedingt zu überprüfen, dass dieses keiner Managed Domain zugeordnet ist.

Hinweis:

Die "[default]" GINA muss in jedem Fall konfiguriert werden, da Sie als Basis für gegebenenfalls weitere

GINA Interfaces dient.

Unterbleibt dies, so ist mit sporadischen Fehlern der

Appliance zu rechnen!

150

Sektion

GINA Settings

Allgemeine Einstellungen der GINA-Interfaces.

Parameter Beschreibung

Password Length

Die hier angebenene Passwort-Länge bezieht sich auf das Initial-GINA-

Passwort, welches von der Appliance generiert wird. Standard ist acht "8"

Zeichen.

Wird die Passwort-Länge auf null "0" gesetzt, so ist für die initiale GINA-

Anmeldung kein Passwort erforderlich.

Hinweis:

Von der Einstellung null "0" wird aus

Sicherheitsgründen dringend abgeraten.

Auch ist ein Wert kleiner acht"8" Zeichen nicht zu empfehlen.

Use virtual hosting Werden mehrere GINA Webinterfaces verwendet, so wird im Standard nur ein FQDN für den Zugriff verwendet. Für jedes GINA-Webinterface wird ein eigener Ordner unterhalb dieses FQDNs angelegt. Dadurch wird auch bei der

Verwendung von mehereren GINA Interfaces nur ein SSL Zertifikat (siehe

Menüpunkt

SSL

187

) für den Zugriff aus dem Internet auf die jeweiligen GINA

Webinterfaces benötigt.

Wird die Option "Use virtual hosting" verwendet, so muss für jedes GINA

Webinterface ein eigener FQDN verwendet werden. Dies hat zur Folge, dass auch für jedes GINA Webinterface ein eigenes Zertifikat benötigt wird. Das entsprechende Eingabefeld für das individuelle Zertifikat wird in diesem Fall

im Untermenü

Edit GINA Settings

169

angezeigt.

Secure GINA track access

Disallow insecure ciphers

Mit dieser Option werden über den eingetragenen Link erweiterte

Informationen in einer GINA-Lesebestätigung bereitgestellt. Aktiviert wird diese Funktion durch eintragen der URL für den Zugriff auf die

Administrationsoberfläche der Appliance. Dabei muss sichergestellt werden, dass diese URL von jedem internen E-Mail Client erreichbar ist.

Diese Option ist im Standard deaktiviert, wodurch der Zugriff auf das GINA

Webinterface auch mit älteren Clients / Browsern möglich ist (RC4 aktiv). Um das Sicherheitpotential der Appliance auszuschöpfen, sollte die Aktion aktiviert werden.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

151

Sektion

GINA password via SMS

Einstellungen für den automatisierten Passwort Versand via SMS

Parameter

Disable

Beschreibung

Der GINA-Passwort-Versand via SMS ist deaktiviert

Use cell phone /

GSM modem attached to appliance

Use Mail to SMS service

(configuration below)

Ist eine Hardware Appliance im Einsatz, so kann an einen USB-Anschluss der

Appliance ein Mobiltelefon oder GSM-Modem angeschlossen werden, über welches SMS versendet werden können. Auf ausreichenden Empfang des

Mobiltelefons / GSM-Modems ist zu achten.

An dieser Stelle werden die Zugangsdaten für den SMS Versand über einen

Mail to SMS Dienst eingetragen. Dies kann sowohl ein interner Dienst im

Netz des Kunden als auch ein externer Dienst im Internet sein. Der Zugang zu diesem Dienst ist zu gewährleisten (siehe

Firewall / Router einrichten

Mail to SMS settings

Mail from:

Mail address prefix:

<PREFIXMobile#>@

Angabe des gewünschten Absenders, der in der SMS erscheinen soll, zum Beispiel "Ihre Firma"

Mobilfunknummer, über welche die SMS versendet werden soll.

Diese Daten stellt der Betreiber des Dienstes zur

Verfügung.

Gateway Domain:

<Mobile#>@

Bei der deutschen Telekom wäre das zum Beispiel

"017187654321"

Gateway-Domäne für den SMS-Versand.

Diese Daten stellt der Betreiber des Dienstes zur

Verfügung.

Use xml service

(configuration below)

Bei der deutschen Telekom wäre das zum Beispiel "td1.sms.de"

An dieser Stelle werden die Zugangsdaten für den SMS Versand über einen

XML Dienst eingetragen. Dies kann sowohl ein interner Dienst im Netz des

Kunden als auch ein externer Dienst im Internet sein. Der Zugang zu diesem

Dienst ist zu gewährleisten (siehe

Firewall / Router einrichten

Server address: xml template

Server Adresse des Dienstanbieters.

Diese Daten stellt der Betreiber des Dienstes zur

Verfügung.

Diese Daten stellt der Betreiber des Dienstes zur

Verfügung. EinBeispiel hierfür findet dich unten in diesem Abschnitt

Weiterhin werden die zur Verfügung stehenden Variablen angezeigt

152

Parameter Beschreibung

Use HTTP GET service

(configuration below)

Placeholders:

$sms: Text message

$number: cell number including country code (+xx...)

$countrycode: country code, e.

g. "49"

$localnumber: cell number without country code zu übermittelnder Nachrichtentext.

Mobilfunkrufnummer incl. Landesvorwahl

(+xx...)

Landesvorwahl, zum Beispiel "49" für

Deutschland

Mobilfunkrufnummer OHNE

Landesvorwahl sowie eine Beispielkonfiguration:

XML Example:

Server:

String: https://xml1.aspsms.com

<?xml version="1.0" encoding="UTF-8"?>

<Originator>Secmail</Originator>

<PhoneNumber>$number</PhoneNumber>

</Recipient>

<MessageData><![CDATA[$sms]]></

MessageData>

<Action>SendTextSMS</Action>

</aspsms>

An dieser Stelle werden die Zugangsdaten für den SMS Versand Dienst per

HTTP Get eingetragen. Dies kann sowohl ein interner Dienst im Netz des

Kunden als auch ein externer Dienst im Internet sein. Der Zugang zu diesem

Dienst ist zu gewährleisten (siehe

Firewall / Router einrichten

Server address:

HTTP Get String

Den Server für den Zugang zum HTTP Get Service stellt SMS-Provider zur Verfügung.

Den String für den Zugang zum HTTP Get Service stellt SMS-Provider zur Verfügung.

Es stehen die aus der XML-Konfiguration bekannten Variablen zur Verfügung.

Weiterhin wird die Beispielkonfiguration für den schweizer Dienst "chrus" angezeigt.

HTTP GET Example:

Server: https://www.chrus.ch

String: /mysms/http/send.php?

user=xyz&pwd=xyz&from=Secmail&to=$number&msg

Parameter Beschreibung

Über diese Option wird der Zugriff auf den Passwort-Versand-Link der

Appliance gesteuert.

=$sms

Access to GINA send password form:

Disabled

Available via public GINA GUI

Damit wird der Passwort-Versand-Link deaktiviert. Somit erscheint dieser auch nicht in der Passwort-Mail, welche beim initialen Versand einer GINA-

Mail an den Absender der E-Mail gesendet wird.

Aktiviert das Einfügen des Links für den SMS-Passwortversand in der GINA-

Passwort-Benachrichtigungs-E-Mail an den Absender.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

153

154

Sektion

Edit Disclaimer

Fussnoten Einstellungen.

Parameter Beschreibung

Auswahl der zu bearbeitenden

Fussnote

(Disclaimer)

Die Verwendung eines Disclaimers ist optional. Sollen Disclaimer verwendet werden, so können vorhandene Disclaimer - nach entsprechender Auswahl

über das Drop-Down-Menü - über die Schaltfläche

Edit

(siehe Untermenü

Edit Disclaimer

186

) angepasst oder auch weitere Disclaimer über die

Schaltfläche

Create new disclaimer

angelegt werden.

Disclaimer stehen immer sowohl im Text- als auch im HTML-Format zur

Verfügung. Beim E-Mail-Versand wird das passende Format anhand des E-

Mail-Formats automatisch ausgewählt.

Die Zuordung des jeweiligen Disclaimers zur jeweiligen "Managed Domain" erfolgt in der Sektion

GINA and Disclaimer Settings

des Untermenüs

Add/Edit Managed Domain

142

aus

Mail System

Managed Domains

Soll ein Disclaimer über die Schaltfläche

Delete

gelöscht werden, so ist vorher unbedingt zu überprüfen, dass dieser keiner Managed Domain zugeordnet ist, beziehungsweise gegebenenfalls in

Custom Commands

164 der Sektion

Ruleset Generator

dieses Menüs verwendet wird.

Hinweis:

Sollen Disclaimer verwendet werden, so ist unbedingt darauf zu achten, dass diese noch auf dem Groupware

System oder durch die SEPPmail-Appliance gesetzt werden. Werden Disclaimer bei ausgehenden E-Mails durch ein nachgelagertes System angehäntgt, so wird bei durch die Appliance S/MIME signierten E-Mails diese

Signatur zerstört.

155

Sektion

Edit Mail Templates

E-Mail-Vorlagen Einstellungen.

Parameter Beschreibung

Auswahl der zu bearbeitenden

E-Mail Vorlage

(Templates) für

Bounce-Mails

E-Mail-Templates sind vordefinierte Nachrichten, welche in definierten Fällen automatisiert versendet werden. Diese Templates können innerhalb eines

Custom Commands

164

der Sektion

Ruleset Generator

dieses Menüs verwendet werden.

Im Standard ist lediglich das Template "bounce_noenc" vorhanden. Dieses sowie gegebenenfalls selbst erzeugte Templates können - nach entsprechender Auswahl über das Drop-Down-Menü - über die Schaltfläche

Edit

angepasst werden. Das Anlegen neuer Templates erfolgt über die

Schaltfläche

Create new template

Abhängig von spezifischen Einstellungen des Rulests (siehe

Ruleset

Generator

) werden weitere Standard Templates verwendet

("bounce_noseckey", "bounce_noauth") verwendet. Diese sind in der Auswahl nicht zu sehen, können jedoch durch Erstellen mittels

Create new template

ebenfalls angepasst werden.

Hinweis:

Bei der Anlage neuer Templates kann über den Template

Namen gesteuert werden, ob die Original-E-Mail als

Anhang angefügt wird oder nicht.

Wird im Template Namen "attachmail" gefunden, so wird die ursprüngliche E-Mail angefügt.

Soll ein Template über die Schaltfläche

Delete

gelöscht werden, so ist vorher unbedingt zu überprüfen, dass dieses in

Custom Commands

164

der Sektion

Ruleset Generator

dieses Menüs verwendet wird.

156

Sektion

Miscellaneous Options

Sonstige Einstellungen.

Parameter Beschreibung automatically send new openPGP public keys to users when a key is created

Ist der Sektion

Ruleset Generator

dieses Menüs unter

Key Generation

162 die Option "automatically create openPGP keys for new users" aktiv, so wird durch Aktivieren dieser Option der öffentliche Schlüssel des automatisch generierten Schlüsselpares an den neu erzeugte Benutzer gesendet.

Dadurch wird dieser Benutzer in die Lage versetzt, seinen öffentliche

Schlüssel selbst an Kommunikationspartner weiterzugeben. Diese werden dadurch wiederum in die Lage versetzt, openPGP verschlüsselt mit diesem

Benutzer zu kommunizieren.

Hinweis:

Dieser Parameter wird nicht im Cluster synchronisiert. Das heisst in einem

Cluster Umfeld muss der Parameter auf jedem Cluster Teilnehmer einzeln konfiguriert werden

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

157

Sektion

Ruleset Generator

Mit dem

Ruleset Generator

wird quasi ein "Workflow System" für eingehende und ausgehende E-

Mails definiert.

Die in dieser Sektion vorhandenen Eingabefelder für Betreffzeilen-Schlüsselworte (text in subject) sind mit "Regular Expressions" zu befüllen. Das heisst Sonderzeichen müssen mit einem Backslash "\" als solche gekennzeichnet werden. Gruppierungen sind durch Eingrenzen mit runden Klammern "()" vorzunehmen. Eine Aneinanderreihung mehrerer Schlüsselwort ist durch das Trennen mit dem Pipe-

Zeichen "|" möglich.

Beispiel:

Soll als Betreffzeilen-Schlüsselwort <abc> verwendet werden so ist diese wie folgt einzugeben:

\<abc\>

Soll sowohl das Betreffzeilen-Schlüsselwort <abc> als auch [def] verwendet werden so ist diese wie folgt einzugeben: (\<abc\>)|([def])

Gross-/Kleinschreibung wird bei der Eingabe des Schlüsselwortes in der Betreffzeile ignoriert.

Bei Verwenden des SEPPmail-Outlook-AddIns im Betreffzeilen-Modus ist darauf zu achten, dass bei

Änderungen der Schlüsselworte in der Appliance, diese entweder als zusätzliche Werte hinzugefügt werden, oder die Werte im AddIn an die Werte der Appliance angepasst werden müssen.

Beschreibung

General Settings

Do not touch mails with the following text in subject:

Add disclaimer to all outgoing emails

Also add disclaimer to replies (in-reply-to header set)

Reprocess mails sent to reprocess@decrypt.

reprocess

Ist diese Option aktiv und das angegebene Schlüsselwort wird im

Betreff einer ausgehenden E-Mail gefunden, so wird diese kryptographisch unbehandelt weitergeleitet. Das Ruleset wird nicht weiter durchlaufen.

Im Standard lautet das Schlüsselwort \[plain\].

Dies ergibt unter Umständen Sinn, wenn all diese Voraussetzungen gegeben sind:

Einstellung "Always use S/MIME or openPGP if keys are available" an der SEPPmail-Appliance aktiv

Absender weiss, dass der Empfänger temporär nur auf einem

Mobilen Endgerät empfangen kann

Inhalt der E-Mail ist nicht vertraulich

Mit dem Aktivieren dieser Funktion wird jeder ausgehenden, initialen

E-Mail die Fussnote angehängt, welche der jeweiligen Managed

Domain (siehe Menü

Add/Edit Managed Domain

Disclaimer Settings

) zugeordnet ist.

142

GINA and

Durch das Aktivieren dieses Punktes wird nicht nur initialen E-Mails, sondern auch Antwort-E-Mails die jeweils zugeordnete Fussnote angehängt.

Diese Funktion ermöglicht es einem Empfänger eine verschlüsselte

E-Mail aus seinem Postfach erneut an die SEPPmail-Appliance zur

Entschlüsselung zu senden. Hierfür ist die Verschlüsselte E-Mail als

Anhang in eine neue E-Mail zu packen und an die Adresse " [email protected]" zu senden. Die ursprünglich verschlüsselte Nachricht wird dadurch entschlüsselt - natürlich vorausgesetzt der entsprechende Schlüssel ist der SEPPmail-

Appliance bekannt - und zurück gesendet.

Anwendungsbeispiele könnten sein:

Direktes Weiterleiten verschlüsselter E-Mails an den internen

E-Mail Server bei Ausfall der Appliance

Migration von lokalem Schlüsselmaterial auf den Clients hin

158

Beschreibung

Show message subject in logs

User Creation

Manual user creation: Only process outgoing mails from users with an account

Mit dieser Option können Benutzer auf der Appliance nur manuell angelegt werden.

Hinweis:

Wird diese Einstellung gewählt, so ist sicherzustellen, dass kein Absender, welcher in der SEPPmail-Appliance nicht bereits als

Benutzer angelegt ist, Merkmale zur kryptographischen Behandlung (Schlüsselwort,

AddIn, Header) verwendet.

In dieser Konstellation würde die Anforderung ignoriert und somit die E-Mail ohne die gewünschte kryprtographische Aktion versendet.

Dieses Verhalten kann bei Bedarf durch einen

Custom Command dahingehend geändert werden, dass E-Mails in dieser Konstellation abgewiesen

werden (siehe

Bounce von E-Mails nicht authentifizierter Benutzern

331

automatically create accounts for new users if user tries to sign / encrypt zur SEPPmail-Lösung bei gleichzeitigen zurückbleiben von verschlüsselten E-Mails in den Postfächern der Empfänger

Ebenso ermöglicht dieser Befehl openPGP verschlüsselte Dateien aus dem Datei System durch Senden als E-Mail Anlage an diese

Adresse zu entschlüsseln.

Zeigt die Betreffzeilen von E-Mails im E-Mail-Log der Appliance an.

Dies erleichtert oft die Fehleranalyse. Sollte diese Anzeige jedoch aus revisionstechnischen Gründen untersagt sein, so ist das

Ausblenden durch Deaktivieren dieser Option möglich. automatically create accounts for all users

Durch Aktivieren dieser Option wird ein Absender, der über ein entsprechendes Merkmal eine E-Mail als zu verschlüsselnd oder zu signierend markiert automatisch als Benutzer auf der SEPPmail-

Appliance angelegt werden, sofern er nicht bereits vorhanden ist.

Bei Verwenden dieser Option ist darauf zu achten, dass genügend freie Benutzerlizenen vorhanden sind (siehe

Home

Licenses

Encryption/Signature Licenses)

115

Kreiert für jeden Absender der über die SEPPmail-Appliance eine E-

Mail sendet einen Benutzer, egal, ob Verschlüsseln/Signieren angefordert wurde oder nicht.

Diese Einstellung ist geeignet, wenn die SEPPmail-Appliance nicht direkt im E-Mail Strom steht, sondern bereits über eine vorgelagerte

Komponente entschieden wird, welche E-Mails kryptographisch zu behandelnd sind und nur diese an die SEPPmail-Appliance übergibt.

Ein weiterer Anwendungsfall wäre, wenn alle E-Mails eines

Unternehmens grundsätzlich signiert oder gegebenenfalls verschlüsselt werden sollen.

Encryption/Decryption

Incoming e-mails

Add this text to message

Ist diese Option aktiv, werden eingehende, durch die SEPPmail-

Appliance entschlüsselte E-Mails im Betreff mit diesem Schlüsselwort

159

Beschreibung

subject after decryption

gekennzeichnet.

Im Standard lautet das Schlüsselwort \[secure\].

Set confidential flag after decryption:

Durch Aktivieren dieser Option wird bei eingehenden, durch die

SEPPmail-Appliance entschlüsselten E-Mails den Header

"Sensitivity: Confidential" .

Reject mails if S/MIME decryption fails

Bei aktiver Option werden eingehende, verschlüsselte E-Mails abgewiesen (bounced), sofern sie durch die SEPPmail-Appliance nicht entschlüsselt werden konnten.

Da die SEPPmail-Appliance eine E-Mail einem eventuell vorgelagerten System erst dann als angenommen meldet, wenn die

E-Mail ausgeliefert werden kann, ist diese Funktion auch zum

Beispiel nach einem externen SPAM-Filter problemlos verfügbar.

Hinweis:

Durch Aktivieren dieser Aktion wird auch eine eventuell teilweise Ende-zu-Ende

Verschlüsselung (zum Beispiel mittels Smart-

Card) unterbunden.

Outgoing e-mails

Always encrypt mails with the following text in subject:

Always encrypt mails with Outlook

"confidential" flag set

Ist diese Option aktiv und das angegebene Schlüsselwort wird im

Betreff einer ausgehenden E-Mail gefunden, so wird diese verschlüsselt.

Im Standard lautet das Schlüsselwort \[confidential\].

Bei aktiver Option wir der "Sensitivity" Parameter aus dem E-Mail

Header der ausgehenden E-Mail ausgewertet. Hat dieser den Wert

"confidential", so wird die E-Mail verschlüsselt.

Always use GINA technology for mails with the following text in subject:

Ist diese Option aktiv und das angegebene Schlüsselwort wird im

Betreff einer ausgehenden E-Mail gefunden, so wird das

Verschlüsseln mittels GINA-Technologie erzwungen.

Im Standard lautet das Schlüsselwort \[priv\].

Das Erzwingen der GINA-Technologie ist immer dann sinnvoll, wenn eine verlässliche Lesebestätigung benötigt wird.

Always use GINA technology for mails with

Outlook "private" flag set

Bei aktiver Option wir der "Sensitivity" Parameter aus dem E-Mail

Header der ausgehenden E-Mail ausgewertet. Hat dieser den Wert

"private", so wird ebenfalls das Verschlüsseln mittels GINA-

Technologie erzwungen.

Hinweis:

Diese Option kann zu Problemen führen, wenn als privat markierte Kalendereinträge versendet

werden, da diese dann automatisch GINA--

verschlüsselt würden.

Create GINA users with empty password if the following text is in the subject:

Mit Aktivieren dieses Punktes wird bei Auffinden des angegebenen

Schlüsselwortes im Betreff einer ausgehenden, initialen GINA-E-Mail kein Initial-Password benötigt.

Im Standard lautet das Schlüsselwort \[emptypw\].

160

Beschreibung

Always use S/MIME or openPGP if keys are available

Bei aktiver Option werden ausgehende E-Mails immer verschlüsselt, sofern der SEPPmail-Appliance ein öffentlicher Schlüssel - egal ob S/

MIME oder openPGP - des Kommunikationspartners (Empfängers) vorliegt.

Hinweis:

Es gilt zu beachten, dass der Versender der E-

Mail auf der SEPPmail-Appliance jeweils als

Benutzer angelegt sein oder werden muss, wenn er an einen entsprechenden

Kommunikationspartner sendet.

Always use GINA encryption if account exists and no S/MIME or openPGP key is known

Ist diese Option aktiv, so werden ausgehende E-Mails immer mittels

GINA-Technologie verschlüsselt, sofern der SEPPmail-Appliance kein öffentlicher Schlüssel - weder S/MIME noch openPGP - bekannt ist, jedoch ein SEPPmail-Account für den Kommunikationspartner

(Empfängers) vorliegt.

Do not encrypt outgoing mails with the following text in subject:

Ist diese Option aktiv und das angegebene Schlüsselwort wird im

Betreff einer ausgehenden E-Mail gefunden, so wird ein eventuelles

Verschlüsseln in jedem Fall unterdrückt. Andere kryptographische

Aktionen (Signieren) sind davon nicht betroffen.

Im Standard lautet das Schlüsselwort \[noenc\].

Use AES256 for S/MIME encryption

Durch das Aktivieren dieser Option wird für das S/MIME

Verschlüsseln von E-Mail der AES256 Algorithmus verwendet.

Dieser Algorithmus wird von WindowsXP Maschinen sowie in

Outlook Versionen vor 2007 nicht unterstützt.

Hinweis:

Für openPGP wird automatisch die maximal mögliche Schlüssellänge aus dem öffentlichen

Schlüssel des Kommunikationspartners ermittelt und verwendet.

Signing

Incoming e-mails

Add this text to message subject if S/MIME signature check succeeds:

Ist diese Option aktiv, werden eingehende, signierte E-Mails, deren

Signaturen durch die SEPPmail-Appliance geprüft und als in Ordnung befunden wurden mit dem angegebenen Schlüsselwort im Betreff gekennzeichnet.

Im Standard lautet das Schlüsselwort \[signed\sok\].

Hinweis:

Damit eine S/MIME E-Mail-Signatur als "in

Ordnung" befunden wird, a) darf diese E-Mail auf dem Weg vom

Absender bis zum Empfang und Prüfung durch die SEPPmail-Appliance nicht verändert worden sein.

b) muss das Signatur-Zertifikat des

Absenders von einem vertrauenswürdigen

161

Beschreibung

Aussteller stammen (siehe

X.509 Root

Certificates

238

)

remove signature if S/

MIME signature check succeeds

Add this text to message subject if S/MIME signature fails:

Entfernt die S/MIME E-Mail-Signatur nach erfolgreicher Prüfung.

Das Entfernen der E-Mail-Signatur kann beim Einsatz Mobiler

Endgeräte als E-Mail-Clients von Vorteil sein, da diese häufig nicht mit diesen Signaturen umgehen können.

Ist diese Option aktiv, werden eingehende, signierte E-Mails, deren

Signaturen durch die SEPPmail-Appliance geprüft und als defekt befunden wurden mit dem angegebenen Schlüsselwort im Betreff gekennzeichnet.

Im Standard lautet das Schlüsselwort \[signed\sINVALID\].

remove signature if S/

MIME signature check fails

Entfernt die S/MIME E-Mail-Signatur nach fehlgeschlagener Prüfung.

Das Entfernen der E-Mail-Signatur kann beim Einsatz Mobiler

Endgeräte als E-Mail-Clients von Vorteil sein, da diese häufig nicht mit diesen Signaturen umgehen können. Allerdings ist dann auch keine weitere Prüfung durch den E-Mail-Client und somit eine

Analyse, weshalb die Signatur als ungültig eingestuft wurde, möglich.

Outgoing e-mails

Hinweis:

Sofern die Zertifikatskette nicht bereits in den Zertifikaten, welche für das

Signieren verwendet werden vorhanden ist, wird diese während des

Signierens durch die Aplliance ergänzt. Dies setzt voraus, dass der

Appliance die eigene Zertifikatskette bekannt - das heisst unter

X.509 Root

Certificates

238

als vertrauenswürdig eingestuft ist.

S/MIME sign outgoing mails with the following text in subject:

Sign all outgoing e-mails if S/MIME certificate available

Do not S/MIME sign outgoing mails with the following text in subject:

Ist diese Option aktiv und das angegebene Schlüsselwort wird im

Betreff einer ausgehenden E-Mail gefunden, so wird diese S/MIME signiert.

Im Standard lautet das Schlüsselwort \[sign\].

Signiert alle ausgehenden E-Mails von SEPPmail-Benutzern mit gültigem S/MIME Zertifikat.

Da mit der S/MIME Signatur das öffentliche Zertifikat mitgesendet wird, wird diese durch das Aktivieren dieser Aktion möglichst vielen

Kommunikationspartnern zur Verfügung gestellt. Dadurch werden diese widerum in de Lage versetzt S/MIME verschlüsselt mit dem

Absender zu kommunizieren.

Weiterhin wird hierdurch die Herkunft der E-Mails bestätigt.

Ist diese Option aktiv und das angegebene Schlüsselwort wird im

Betreff einer ausgehenden E-Mail gefunden, so wird ein eventuelles

Signieren in jedem Fall unterdrückt. Andere kryptographische

Aktionen (Verschlüsseln) sind davon nicht betroffen.

Im Standard lautet das Schlüsselwort \[nosign\].

S/MIME sign outgoing mails with domain key with the following text in subject:

Ist diese Option aktiv und das angegebene Schlüsselwort wird im

Betreff einer ausgehenden E-Mail gefunden, so werden alle ausgehenden E-Mail - egal von welchem Absender - mit dem S/

MIME-Zertifikat und im Namen der angegebenen E-Mail-Adresse

(siehe "Using Certificate") S/MIME signiert.

Im Standard lautet das Schlüsselwort \[domainsign\].

162

Beschreibung

Using Certificate:

Achtung:

Vom Verwenden dieser Option wird dringendst abgeraten!

Durch die für diese Funktion notwendige

Manipulation des Absenders aller ausgehenden

E-Mails resultieren zahlreiche Probleme.

So werden sogenannte Non-Delivery-Reports immer an diese Adresse und nicht an den ursprünglichen Absender gesendet. Das heisst kommt eine E-Mail nicht wie erwartet bei

Empfänger an, so wird der ursprüngliche

Absender darüber keine Information erhalten.

Trägt der Empfänger den Absender der E-Mail in sein Adressbuch ein, so ist auch hier zu erwarten, dass er zukünftig nicht den eigentlich gewünschten, sondern den manipulierten

Empfänger adressiert.

Angabe der E-Mail-Adresse wie sie im S/MIME Zertifikat für die

Domänensignatur enthalten ist.

Text before new FROM:

Einzufügender Text vor dem manipulierten Absender.

Text after new FROM:

Einzufügender Text nach dem manipulierten Absender.

Key Generation

automatically create openPGP keys for new users automatically create S/

MIME keys for new users

Durch Auswählen dieser Option wird für jeden neu generierten

Benutzer automatisch ein openPGP-Schlüsselpaar erzeugt.

automatically buy <CA> S/

MIME keys for new users

Durch Auswählen dieser Option wird für jeden neu generierten

Benutzer automatisch ein S/MIME-Schlüsselpaar über die interne CA erzeugt.

Durch Auswählen dieser Option wird für jeden neu generierten

Benutzer automatisch ein S/MIME-Zertifikat von der angegebenen

CA bezogen.

Hinweis:

Das Schlüsselpaar wird auf der Appliance generiert. Nur der öffentliche Schlüssel wird zum Signieren bei der CA eingereicht. Der private Schlüssel verlässt die SEPPmail-

Appliance nicht!

Diese Option erscheint nur dann, wenn unter

External CA

199

eine entsprechende MPKI

ausgewählt wurde.

Protection Pack (Anti-Spam / Anti-Virus)

(nur mit entsprechender Lizenz "Anti-spam / Anti-virus" (siehe

Home

Licenses

115

) verfügbar)

Check mails for viruses and send infected mails to (leave

Mit Auswahl dieser Option wird der Virenscanner aktiviert. Infizierte

E-Mails werden an die optional einzugebende E-Mail-Adresse gesendet (Quarantäne). Bleibt das Eingabefeld für die E-Mail-

163

Beschreibung

empty to reject infected mails):

Check incoming mails for spam and add the following text to the subject to identify spam:

Tag level:

Check incoming mails for spam and redirect spam to

(leave empty to reject spam):

Spam level:

Adresse leer, so werden infizierte E-Mails abgewiesen (bounced).

Send notification to this email address if a virus was found:

Wird an dieser Stelle eine E-Mail-Adresse angegeben, so werden an diese Benachrichtigungen über Virenfunde gesendet.

Mit Auswahl dieser Option werden als SPAM klassifizierte E-Mails dem angegebenen Text in der Betreffzeile versehen und an den

Empfänger weitergeleitet. Basis der Klassifizierung ist der angegebene "Tag level" (siehe nächste Option).

Der Standartext für diese Markierung lautet [SPAM]

(Achtung: reine Texteingabe, keine "Regular Expression")

Auswahl, des Schwellwertes für die SPAM-Erkennung. Je niedriger dieser Wert gesetzt wird, desto strenger sind die Kriterien für die

SPAM-Erkennung.

Im Standard ist der Wert "5" gewählt.

Bei niedrigen Werten erhöht sich das Risiko von Falscherkennungen, so dass legitime E-Mails als SPAM erkannt und markiert werden.

Mit Auswahl dieser Option werden als SPAM klassifizierte E-Mails an die angegebene Adresse umgeleitet, beziehungsweise bei freilassen des Eingabefeldes abgelehnt (bounced). Basis für die SPAM

Erkennung ist der angegebene "Spam level" (siehe nächste Option).

Auswahl, des Schwellwertes für die SPAM-Erkennung. Je niedriger dieser Wert gesetzt wird, desto strenger sind die Kriterien für die

SPAM-Erkennung.

Im Standard ist der Wert "8" gewählt.

Bei niedrigen Werten erhöht sich das Risiko von Falscherkennungen, so dass legitime E-Mails als SPAM erkannt und umgeleitet beziehungsweise abgelehnt (bounced) werden.

Header tagging

Durch das "Header tagging" wird das Setzen eines erweiterten, sogenannten X-Headers und einen zugehörigen Wert für unterschiedliche Situationen (siehe folgende Optionen) durch die SEPPmail-

Appliance ermöglicht. Diese erweiterten Informationen können durch nachgelagerte Komponenten ausgewertet werden.

Ein Beispiel für so eine zusätzliche, nachgelagerte, E-Mail verarbeitende Komponente könnte ein

Data Loss Prevention (DLP) System sein.

Set header to value For all incoming mails

Setzt den angegebenen X-Header mit dem zugeordneten Wert für alle eingehenden E-Mails

Set header to value For all outgoing mails

Setzt den angegebenen X-Header mit dem zugeordneten Wert für alle ausgehenden E-Mails

Set header to value For all mails that have been encrypted

Setzt den angegebenen X-Header mit dem zugeordneten Wert für alle E-Mails, welche durch die SEPPmail-Appliance verschlüsselt wurden.

Set header to value For all mails that have been decrypted

Setzt den angegebenen X-Header mit dem zugeordneten Wert für alle E-Mails, welche durch die SEPPmail-Appliance entschlüsselt wurden.

164

Beschreibung

Archiving

Send a copy of ALL emails to the following Address:

Durch Aktivieren dieser Option wird eine Kopie aller über die

SEPPmail-Appliance transportierten E-Mails an die angegebene E-

Mail-Adresse gesendet.

Custom Commands

Über Custom Commands können über den in den

Regelwerk-Anweisungen

248

definierten

Befehlssatz spezifische Anforderungen an entsprechender Stelle im Ruleset eingefügt werden.

Custom commands for incoming e-mails BEFORE decryption:

Fügt bei Aktivierter Option den im Eingabefeld vorhandenen Code an der Stelle im Ruleset für eingehende E-Mails VOR der

Entschlüsselung ein.

Custom commands for incoming e-mails AFTER decryption:

Fügt bei Aktivierter Option den im Eingabefeld vorhandenen Code an der Stelle im Ruleset für eingehende E-Mails NACH der

Entschlüsselung ein.

Custom commands for outgoing e-mails BEFORE encryption:

Fügt bei Aktivierter Option den im Eingabefeld vorhandenen Code an der Stelle im Ruleset für ausgehende E-Mails VOR der

Verschlüsselung ein.

Custom commands for e-mails from GINA:

Custom commands for User

Creation:

Fügt bei Aktivierter Option den im Eingabefeld vorhandenen Code an der Stelle im Ruleset für eingehende GINA E-Mails ein.

Fügt bei Aktivierter Option den im Eingabefeld vorhandenen Code an der Stelle im Ruleset für das Generieren neuer Benutzer ein.

Key Server

Über Key Server wird das zusätzliche Abfragen öffentlicher Schlüssel von Kommunikationspartnern für die Verschlüsselung ermöglicht.

Nach dem Speichern eines Key Server Eintrags wird jeweils ein weiteres Eingabefeld eingeblendet.

Hinweis:

Öffentliche Key Server beherbergen häufig "totes" Schlüsselmaterial. Das heisst für die über den Key Server bereitgestellten öffentlichen Schlüssel besitzen die Empfänger oft nicht mehr den privaten Schlüssel. Somit sind diese nicht in der Lage die verschlüsselten E-Mails zu lesen.

Aus diesem Grund wird dringend von der Abfrage solcher Server abgeraten.

openPGP Key Server An dieser Stelle werden Einträge für openPGP Key Server vorgenommen.

Hinweis:

Wird bei der Abfrage eines öffentlichen openPGP Schlüssels ein Schlüssel gefunden, dessen Key ID idenisch mit einem bereits vorhandenen Eintrag auf der SEPPmail-

Appliance ist, so wird dieser Schlüssel auf der

Appliance durch das Ergebnis der LDAP-Abfrage

überschrieben.

S/MIME Key Server An dieser Stelle werden Einträge für S/MIME Key Server vorgenommen.

Beispiel Key Server Eintrag:

165

Beschreibung

recipient mask

(regexp):

@firma\.ch

URI:

LDAP://ldap.firma.local/

Bind dn:

CN=MaxMuster,

OU=Users,

OU=Firma

Bind pw:

password

Base DN:

DC=ihredomain,DC=local

Advanced Options

Re-inject mails to sending mailserver

Run in queueless mode

Mit dem Aktivieren dieser Option werden bereits verarbeitete E-Mails an den einliefernden E-Mail-Server zurück gesendet.

Forwarding und Outgoing Server werden bei aktivierter Option ignoriert beziehungsweise als Fallback Einstellung verwendet

Achtung:

Durch das Aktivieren dieser Option kann unter

Umständen eine E-Mail Schleife (Loop) erzeugt werden, wenn das einliefernde E-Mail System diese Funktion nicht unterstützt oder falsch konfiguriert wurde.

Schaltet die Warteschlangen (Queue) Funktion ab. Das heisst E-

Mails werden vom <OEM-PRODUCTNAME%>-System im Normalfall erst dann an das abgebende System als angenommen gemeldet, wenn die E-Mail bereits vom nachfolgenden System als angenommen gemeldet wurde (Rückmelde Code "250 Requested mail action okay, completed").

Wird diese Option verwendet, so kann bei einem Austausch der

Appliance (zum Beispiel bei einem Hardware-Defekt) annähernd sichergestellt werden, dass keine E-Mails verloren gehen.

Achtung:

Aufgrund dieser Einstellung können - vor allem wenn die E-Mail verarbeitenden Maschinen in unterschiedlichen Netzen stehen -Verzögerungen auftreten. Eine Folge davon können vermehrt auftretende Timeouts sein.

Weiterhin kann das vorläufige Zwischenspeichern einer E-Mail in der E-Mail Warteschlange durch diese Einstellung nicht 100%ig verhindert werden:

Werden beispielsweise bei ausgehenden E-

Mails mehrere E-Mail Domänen adressiert, von denen eine nicht den Empfang mit dem

Rückmelde Code 250 quittiert, so würde die E-

Mail an diese eine E-Mail Domäne dennoch in der E-Mail Queue zwischengespeichert werden.

Bei Komplettausfall des nächsten E-Mail HOPs würde die Appliance ebenfalls die E-Mails in der

Warteschlange speichern und somit dem abgebenden System den Empfang quittieren.

Ebenso werden LFM-Benachrichtigungs-E-Mails in der Warteschlange zwischengespeichert, wenn der Empfänger temporär nicht erreichbar ist.

166

Beschreibung

Completely disable GINA technology

Completely disable userbased S/MIME and openPGP

Deaktiviert die GINA-Technologie.

Als Folge würden als "zu verschlüsselnd" gekennzeichnete E-Mails abgewiesen werden, wenn keine andere Verschlüsselungsmethode

(S/MIME, openPGP, Domain) verfügbar ist.

Hinweis:

Wird die GINA-Technologie über diese Option abgeschaltet, so ist darauf zu achten, dass alle

Optionen aus "Encryption/Decryption", welche diese Technologie ansteuern deaktiviert sind.

Ebenso darf kein Ansteuern dieser Technologie

über "Custom Commands" erfolgen.

Deaktiviert sowohl die Benutzer bezogene S/MIME als auch die openPGP Technologie.

Diese Aktion wird meist in Verbindung mit "Completely disable GINA technology" verwendet, um ausschliesslich Domänen

Verschlüsselung anzuwenden.

Use remote GINA server, reachable under the following email address:

Muss aus revisionstechnischen Gründen der GINA-Teil in einer anderen Demilitarisierten Zone (DMZ) als der SMTP verarbeitende

Teil stehen, so ist die Trennung über diese Option möglich. Selbst eine Trennung auf unterschiedliche Standorte ist möglich.

Alle GINA zu verschlüsselnden E-Mails werden dann über die hier angegebene Pseudo-E-Mail-Adresse (zum Beispiel [email protected]) S/MIME verschlüsselt per SMTP an den GINA-Satelliten geleitet.

This is a remote GINA server

Hinweis:

Wird diese Option gewählt, so ist darauf zu achten, dass alle Optionen aus "Encryption/

Decryption", welche diese Technologie ansteuern deaktiviert sind. Ebenso darf kein

Ansteuern dieser Technologien über "Custom

Commands" erfolgen.

Definiert den Gegenpart zur Option "Use remote GINA server, reachable under the following email address:", also den GINA-

Satelliten.

An der Satelliten-Appliance muss die Pseudo-Mail-Domäne (im

Beispiel oben "ginapseudodomain.local") als zusätzliche Managed

Domain eingetragen werden (siehe

Mail System

Managed

Domains

130

). Ebenso müssen die Managed Domains des Basis-

Systems erfasst werden. Die GINA-Konfiguration und deren

Zuordnung zu den Managed Domains erfolgt auf dem Satelliten-

System (siehe

Mail Processing

GINA domains

149

Relay for domain:

Hier sind die "Managed Domains" des "Basis"-Systems einzutragen

(siehe

Mail System

Managed Domains

130

Die Trennung der Domains erfolgt durch ein Pipe-Zeichen "|" als

Regulärer Ausdruck, also (domain1.tld)|(domain2.tld)|(domainn.tld) einzugeben.

167

Beschreibung

Hinweis:

Theoretisch kann somit auch ein GINA-Satellit, für mehrere Appliances, welche unterschiedliche

Managed Domains beherbergen, konfiguriert werden.

Relay email address:

Relay domain key fingerprint:

Enable internal encryption with user keys (also enables ldap server on ports 388, 387 and 635.

User keys must be installed on appliance for proper function)

Enable ldap server on ports 388, 387 and 635 to distribute collected S/

MIME certificates to internal users

Use Incamail instead of local GINA interface

Hier ist die gleiche Pseudo-E-Mail-Adresse einzutragen wie auf dem

"Basis"-System unter "Use remote GINA Server, reachable under the following email address:".

Hier sind die Fingerprints der Domänen Zertifikate der unter "Relay for Domain" angegebenen Managed Domains jeweils durch ein Pipe-

Zeichen "|" getrennt als Regulärer Ausdruck, also (Fingerprint1)|

(Fingerprint2)|(Fingerprintn) anzugeben.

(siehe

Add/Edit Managed Domain

142

S/MIME Domain

Encryption

)

Mit dieser Option wird die zertifikatsbasierte interne E-Mail

Verschlüsselung aktiviert.

Im Anschluss müssen die privaten Schlüssel - der vorhandenen unternehmensinternen CA - für die Benutzer, denen das

Verschlüsseln zu externen Kommunikationspartnern gestattet ist, auf der SEPPmail-Appliance importiert werden (siehe

Administration

Import

211

Import S/MIME keys).

Am E-Mail Client müssen in der Regel zwei LDAP Adressbücher erzeugt werden:

1. zur Abfrage der unternehmensinternen CA, welche das

Schlüsselmaterial für die interne E-Mail Verschlüsselung bereit stellt

2. zur Abfrage des über diese Option aktivierten Key Servers der

SEPPmail-Appliance

Hierzu ist es ausreichend die IP-Adresse beziehungsweise den

Hostnamen der SEPPmail-Appliance sowie einen der Ports 387 oder 388, beziehungsweise 635 für eine verschlüsselte

Verbindung anzugeben. Eine Authentifizierung ist nicht notwendig

Weiterhin wichtig ist, dass dem X.509 Root Zertifikat der internen CA

der SEPPmail-Appliance (siehe

194

Download certificate

) an den Clients vertraut wird.

(diese Option schliesst die folgende Option aus)

Durch Aktivieren dieser Option wird die SEPPmail-Appliance und stellt somit die öffentlichen S/MIME Schlüssel per LDAP zur

Verfügung.

(diese Option schliesst die vorhergehende Option aus)

Diese Option ist nur für Teilnehmer des schweizer Dienstes Incamail relevant.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save and Create ruleset

gespeichert. Das Ruleset wird mit den vorgenommen Einstellungen generiert.

168

Für eine korrekte Funktion der Appliance muss initial ein Ruleset durch Klicken der

Schaltfläche

Save and Create Ruleset

generiert werden.

Sektion

SMTP Ruleset

Über die Schalfläche

Display Ruleset

wird das Ruleset der SEPPmail-Appliance angezeigt. Wurde

dieses über den

Ruleset Generator

157

erzeugt, so steht in den ersten beiden Zeilen Datum und

Uhrzeit der Erzeugung, sowie die Version, mit welcher das Ruleset erzeugt wurde.

In sehr grossen Unternehmen mit entsprechend umfangreichen individuellen Anforderungen besteht die Möglichkeit ein Ruleset mittels der

Referenz der Regelwerk-Anweisungen

248

zu erstellen.

Dieses kann über die Schaltfläche

Upload

importiert und verwendet werden.

169

7.6.1

Untermenü Create new GINA Domain

Sektion

Create new GINA Domain

Parameter Beschreibung

Description

Hostname

Hier ist der Name einzugeben, welcher im Auswahlmenü

Mail Processing

GINA domains

149

angezeigt werden soll.

Ist unter

Mail Processing

GINA Settings

150

die Option "Use virtual hosting" aktiviert, so ist hier der FQDN anzugeben, unter welchem das

Interface erreichbar sein wird (zum Beispiel securemail.meinkunde.ch).

Andernfalls ist hier der Name des Unterverzeichnisses anzugeben, in welchem das GINA-Interface erzeugt werden soll (zum Beispiel meinkunde).

Das neue GINA-Interface wird dann im Unterverzeichnis des unter dem FQDN des [default]-GINA-Eintrages erreichbar sein (zum Beispiel https://securemail.

meinefirma.ch/meinkunde/web.app)

Über die Schaltfläche

Create

wird der Vorgang abgeschlossen.

7.6.2

Untermenü Edit GINA Settings

In diesem Menü können die Einstellungen für die gewählte GINA-Domain individuell vorgenommen werden.

Zusätzlich zu den technischen Einstellungen kann über die Schaltfläche

Edit GINA Layout

jeweils das Design an die Firmenidentität angepasst werden (siehe

Edit GINA Layout

180

Sektion

Secure GINA Host

Parameter Beschreibung

Hostname

Ist unter

Mail Processing

GINA Settings

150

die Option "Use virtual hosting" aktiviert, so ist hier der FQDN anzugeben, unter welchem das

Interface erreichbar sein wird (zum Beispiel securemail.meinkunde.ch).

Andernfalls ist hier der Name des Unterverzeichnisses anzugeben, in welchem das GINA-Interface erzeugt werden soll (zum Beispiel meinkunde).

Das neue GINA-Interface wird dann im Unterverzeichnis des unter dem FQDN des [default]-GINA-Eintrages erreichbar sein (zum Beispiel https://securemail.

meinefirma.ch/meinkunde/web.app).

Hinweis:

Der hier eingetragene FQDN muss aus dem Internet erreichbar sein. Das heisst entsprechender DNS Eintrag muss veranlasst werden.

Port

Key and certificate

If virtual hosting is enabled, you can specify a special port and a special certificate used for this GINA Domain

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

170

Sektion

Master Template

Diese Sektion erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Parameter Beschreibung

Master Template

Durch Auswahl eines Master Templates können in den folgenden Sektionen wahlweise die Einstellungen eines anderen GINA-Interface übernommen werden.

Wird diese Auswahl in einer Sektion getroffen, so werden nach dem Klicken der Schaltfläche

Save

die Eingabefelder dieser Sektion ausgegraut und die

Einstellungen des ausgewählten Master Templates angezeigt.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

Sektion

Admin

Einstellungen für den Versand von GINA-Systemmeldungen.

Parameter Beschreibung

Use settings from master template

Admin E-mail

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der unter

Master Template

gewählten Vorlage übernommen.

An die hier eingegebene E-Mail-Adresse werden Passwort-Anfragen von

GINA-Benutzern des entsprechenden GINA-Interfaces weitergeleitet. Ebenso wird diese E-Mail-Adresse als Absender der GINA-Passwort- und Aktivierungs

E-Mails verwendet.

Send password reset e-mails to original sender instead of Admin

E-mail address

Bleibt dieses Feld leer, so wird die Passwort-Anfrage eines GINA-Benutzers an den Internen Absender weitergeleitet, der dem entsprechenden GINA-

Benutzer über diese Technologie eine E-Mail gesendet hat.

Als Absender der Passwort-E-Mails wird ebenfalls der interne Absender der

GINA-Mail verwendet.

In speziellen Konstellationen können bei leerer

Admin E-mail

und den daraus resultierenden Versand von GINA-Paswwort-/Aktivierungs-E-Mails im Namen des internen Absenders Probleme auftreten. In diesen Fällen ist zwingend eine

Admin E-mail

einzutragen. Soll dennoch bei Passwort-Reset-Anfragen der ursprüngliche Absender anstatt des eingetragenen Admins benachrichtigt werden, so ist an sieser Stelle der Haken zu setzen.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

171

Sektion

Extended settings

Grundlegende Einstellungen für die über das GINA-Webinterface zur Verfügung gestellten Funktionen.

Parameter Beschreibung

Use settings from master template

Default Forward

Page

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der unter

Master Template

gewählten Vorlage übernommen.

Sollte die URL der GINA-Seite ohne den Zusatz "/web.app" aufgerufen werden, kann an dieser Stelle auf eine andere Seite - zum Beispiel die

Homepage des Unternehmens - weitergeleitet werden.

Soll dennoch auf das GINA-Interface weitergeleitet werden, so ist die URL einzugeben, wie sie oberhalb der Eingabezeile angezeigt wird.

Bleibt man beim Beispiel aus der Sektion

Secure GINA Host

würde dort folgendes stehen:

Note: If you want to show the GINA login page by default, enter "https:// securemail.meinefirma.ch/meinkunde/web.app" (without the quotes)

Bei aktiver Option wird der verschlüsselte HTML Anhang der GINA-Mail in eine

ZIP Datei gepackt. Dies wird für die Kompatibilität zu älteren OWA Versionen benötigt. Für einzelne E-Mails kann die Steuerung dieser Funktion durch das

Betreffzeilen Schlüsselwort [zip] vorgenommen werden.

Always zip HTML attachments when encrypting mail with GINA technology

"Send copy to myself" checked by default when writing GINA mails

Sender always receives notification when recipient reads

GINA mails

Mit dieser Option wird der Haken im %OEM-WEBMAIL-GINA%>-Interface für eine Kopie an den Sender bereits als Standard gesetzt.

Dadurch erhält der GINA-Benutzer beim Versenden einer E-Mail diese ebenfalls als GINA-Mail in Kopie und hat somit einen entsprechenden

Nachweis.

Mit dem Setzen dieses Hakens wird die Anforderung einer Lesebestätigung beim Versand von GINA-Mails als Standard definiert.

Eventuell vom Absender definierte Einstellungen dadurch überschrieben.

Allow account self-registration in

GINA portal without initial mail

Erlaubt Personen, welche sich auf dasGINA-Interface (im Beispiel aus der

Sektion

Secure GINA Host

"https://securemail.meinefirma.ch/meinkunde/ web.app") verbinden eine Registrierung ohne initialer GINA-Mail.

Somit wird einem externen Kommunikationspartner ermöglicht, eine sichere E-

Mail-Kommunikation über das GINA-Interface initial zu starten. Voraussetzung hierfür ist, dass ihm auch eine gültige E-Mail-Adresse innerhalb der E-Mail-

Domäne des SEPPmail-Betreibers bekannt ist.

Dies bedingt auch das Aktivieren der Option Allow GINA users to write new

mails.

Hinweis:

Die Self-Registration ist durch einen Mail-Ping abgesichert.

Das heißt durch die Registrierung am Web-Interface wird kein

Benutzer angelegt! Vielmehr wird eine E-Mail mit einem

Bestätigungs-Link an die bei der Registrierung eingegebene

E-Mail Adresse gesendet. Durch Aufruf des Links wird die

Verbindung zum GINA Interface hergestellt und das Konto nach erfolgreicher Anmeldung mit den zuvor eingegebenen

Credentials angelegt.

172

Enable S/MIME certificate / openPGP key search and management in

GINA

Allow download of public domain keys/ domain certificates

Hierdurch wird dem angemeldeten GINA-Benutzer erlaubt, nach öffentlichen

S/MIME beziehungsweise openPGP Schlüsseln von internen SEPPmail-

Benutzern über dasGINA-Portal zu suchen.

Mit dieser Option wird zusätzlich die Suche von öffentlichen Domänen

Schlüsseln der auf der SEPPmail-Appliance verwalteten E-Mail-Domänen zu suchen.

Allow unregistered users to search public keys/ certificates of internal users

Wird dieser Haken gesetzt, so wird die Schlüssel Suche nicht nur angemeldeten GINA-Benutzern, sondern jedem der sich auf das GINA>-Portal verbindet, erlaubt.

Da im GINA-Interface für eine Schlüssel Suche immer die E-Mail-Adresse des

Empfängers eingegeben werden muss, ist ein Adress-Harvesting nicht möglich.

Allow GINA users to write new mails

Diese Option erlaubtGINA-Benutzern initial E-Mails an Empfänger innerhalb der E-Mail-Domäne des SEPPmail-Betreibers zu senden und nicht nur auf erhaltene GINA-Mails zu Antworten.

Do not allowGINA users to edit recipient when replying to emails

Mit diesem Parameter wird festgelegt, ob Empfänger von GINA-Mails beim

Antworten den oder die Empfänger editieren dürfen.

Allow GINA users to reply to external recipients of GINA messages

Erlaubt es einen GINA-Benutzer an alle Empfängern einer GINA-E-Mail - auch externen, also denen, die nicht der E-Mail-Domäne des ursprünglichen

Absenders angehören - zu antworten.

Hinweis:

Wurde diese Option gewählt, so können bei gleichzeitig deaktivierter Option "Do not allowGINA users to edit recipient when replying to e-mails" nur bereits vorhanden Empfänger durch den GINA-Benutzer entfernt, jedoch keine weiteren hinzugefügt werden.

SMTP sender address for sending to external recipients:

Da der Versand der E-Mails an externe Empfänger mit einer existenten E-Mail-

Adresse der lokalen E-Mail-Domäne erfolgen muss (Stichwort SPF Prüfung), ist die Versender-Adresse für die oben genannten Antwort-E-Mails hier einzutragen.

Hinweis:

Die hier angegebene E-Mail-Adresse erhält gegebenenfalls Systembenachrichtigungen wie Bounceoder Non Delivery Report (NDR) E-Mails.

Allow messages to be downloaded as Outlook message (.msg) files

Mit Aktivieren dieser Option wird dem Empfänger einer GINA-Mail im GINA-

Interface eine Schaltfläche zum Download der E-Mail im msg-Format - also

Outlook - angeboten. Somit wird der Empfänger in die Lage versetzt die ursprünglich GINA-verschlüsselte E-Mail in Outlook im Klartext abzuspeichern.

173

Hinweis:

Wird nach abspeichern der Nachricht im Klartext über die "Antworten" Schaltfläche im Outlook geantwortet, so geschieht dies unverschlüsselt!

Allow messages to be downloaded as MIME (.eml) files

Mit Aktivieren dieser Option wird dem Empfänger einer GINA-Mail im GINA-

Interface eine Schaltfläche zum Download der E-Mail im eml-Format für den

Import in einen E-Mail-Client angeboten. Somit wird der Empfänger in die Lage versetzt die ursprünglichGINA-verschlüsselte E-Mail in seinem E-Mail-Client im

Klartext abzuspeichern.

Hinweis:

Wird nach abspeichern der Nachricht im Klartext über die "Antworten" Funktion des E-Mail-Clients geantwortet, so geschieht dies unverschlüsselt!

When encrypting mail with GINA technology, use text-only emails

Versendet GINA-Mail im Text- statt im HTML-Format.

Dies kann gegebenenfalls notwendig sein, wenn ein Empfänger den Empfang von HTML-Mails nicht zulässt.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

174

Sektion

Large File Management

Einstellungen für die Übertragung grosser Dateien. Diese Option steht nur zur Verfügung, wenn Large

File Management (LFM) lizensiert und aktiviert wurde.

Parameter Beschreibung

Use settings from master template

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der unter

Master Template

gewählten Vorlage übernommen.

Enable Large File

Messages without authentication

Mit dem Betreffzeilen-Schlüsselwort [lfm:nocrypt] kann der Absender bei aktivierter Option steuern, dass der Empfänger zur Abholung des LFM-

Anhangs kein Passwort am GINA-Webinterface eingeben muss.

Enable Large File

Management

How long (in days) to store

Large Files

Mit dem Anhaken dieser Option wird das Large File Management (LFM) aktiviert. LFM ist eine Zusatzoption und muss somit auch separat lizensiert werden.

Hier wird die Verweildauer - in Tagen - von LFM-Mails angegeben. Der

Empfänger bekommt das Verfallsdatum im Betreff der GINA-

Benachrichtigungs-Mail mitgeteilt. Die Einstellung "0" null bedeutet, dass LFM

Mails nie gelöscht werden.

Es ist darauf zu achten, dass genügend Speicher auf dem System zur

Verfügung steht, anndernfalls würden LFM Mails abgewiesen (bounced).

Size (in KiB) above which messages are treated as Large

Files

Gibt die Grenze - in kB - an, ab wann eine E-Mail als LFM Mail behandelt wird.

Dabei gilt zu beachten, dass Anhänge in E-Mails aufgrund der BASE-64

Codierung bis um die Hälfte grösser sein können, als im Dateisystem.

Maximum size

(in KiB) for LFM messages

Gibt eine Maximalgrösse für LFM Dateien an. Wird hier "0" (null) einegegeben, so wird kein Limit vorgegeben.

Hinweis:

Dieser Wert muss grösser als der oben genannte unter

"Size (in KiB)" above which messages are treated as

Large Files" sein!

Achtung:

Alle Grössenangaben erfolgen in Kibibyte (siehe auch http://de.wikipedia.org/wiki/

Byte )!

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

Sektion

Terms of use

Einstellungen bezüglich Allgemeiner Geschäftsbedingungen.

Parameter Beschreibung

Use settings from master template

Require new users to accept terms of use

Terms of use

URL

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der unter

Master Template

gewählten Vorlage übernommen.

Nach Empfang der initialen GINA-Mail wird der Empfänger beim

Registrierungsprozess aufgefordert, die Allgemeinen Geschäftsbedingungen zu akzeptieren.

Eingabe der URL zu den Allgemeinen Geschäftsbedingungen, zum Beispiel https://www.ihrefirma.ch/agb.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

175

176

Sektion

Language Settings

Spracheinstellungen des GINA-Webinterfaces und dessen Benachrichtigungen.

Parameter Beschreibung

Use settings from master template

Default language:

Available Languages:

Diese Option erscheint nur, falls ein anderes als das [default] GINA-

Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der unter

Master Template

gewählten Vorlage übernommen.

Über das Auswahlmenü wird die Standard-Sprache für das jeweilige

GINA-Interface gewählt. Diese Sprache muss im folgenden

Menüpunkt auch als Verfügbar (Enabled) markiert sein.

Bei der Auswahl der Sprachen gilt zu beachten, dass mit jeder weiteren Sprache die Länge der GINA-Mail sowie bei initialen E-Mails die Länge der Passwort-Mails zunimmt.

Language Enabled

German (d)

Enfglish (e)

French (f)

Italian (i)

Spanish (s)

Dutch (n)

Polish (p)

Aktiviert oder deaktiviert die jeweilige

Sprache

Über die Schalfläche

Edit translations

öffnet das Menü

Edit Translations

184

der jeweiligen Sprache, über welches die Texte aller GINA-

Komponenten individuell angepasst werden können.

Über die Schaltfläche

Download

kann die jeweilige Sprachdatei heruntergeladen werden. Wird diese im Anschluss angepasst, so kann Sie über die [default] GINA-

Einstellungen wieder hochgeladen werden.

Wird das [default] GINA-Interface editiert, so können über die Schaltfläche

Add new

weitere

Sprachen hinzugefügt werden. Für das Erstellen einer neuen Sprachdatei ist der einfachste Weg, eine bereits vorhandene über die Schaltfläche

Download

(siehe Tabelle oben) herunter zu laden, zu

übersetzen und über die Schaltfläche

Add new

wieder hochzuladen.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

Hinweis:

Je mehr sprachen aktiviert werden, desto länger werden die initialen GINA

Benachrichtigungs- und Passwort- E-Mails.

Deshalb sollte der Grundsatz gelten:

Soviel wie nötig, so wenig wie möglich.

Nur die initiale GINA Benachrichtigungs E-Mail ist mehrsprachig. Jede weitere GINA

Benachrichtigungs E-Mail wird nur noch in der beim Registrierungsprozess gewählten

Sprache versandt.

177

Sektion

Security

In dieser Sektion werden die Passwort-Kriterien sowie die Möglichkeiten zur Passwort-Rücksetzung angegeben.

Parameter Beschreibung

Use settings from master template

Choose how the user can retrieve lost passwords

Diese Option erscheint nur, falls ein anderes als das [default] GINA-

Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der unter

Master Template

gewählten Vorlage übernommen.

Auswahl der Passwort-Rücksetzungs-Möglichkeiten des GINA-

Benutzers.

Hinweis:

Einige Optionen sind nur mit lizensiertem Self-Service-

Password-Management (SSPM) verfügbar.

default

Reset by Email verification

Reset by hotline

Reset by hotline, no reminder question/ answer

Reset by SMS

Standard Einstellung. Diese entspricht der Opton "Reset by hotline".

Diese Einstellung steht nur in Verbindung mit SSPM zur Verfügung

Der GINA-Benutzer muss seine Sicherheitsfrage beantworten, um mit dem Reset Prozess fortfahren zu können

Daraufhin wird der Benutzer aufgefordert ein neues Passwort einzugeben und dieses zu verifizieren.

Der Benutzer erhält daraufhin eine E-Mail mit einem Link zugesendet. Erst durch Aufruf dieses Links erhält das neu vergebene Passwort seine Gültigkeit

Achtung:

Da diese Variante allein auf dem Medium E-Mail basiert, bedeutet dies einen gewissen Einschnitt in die

Sicherheit. Aus diesem Grund ist diese Variante von

SEPPmail nicht empfohlen.

Der GINA-Benutzer erhält nach dem Beantworten seiner

Sicherheitsfrage die Aufforderung zur Eingabe einer Telefonnummer für den Rückruf durch die Hotline.

Standardeinstellung

Der GINA-Benutzer muss seine Sicherheitsfrage beantworten, um mit dem Reset Prozess fortfahren zu können

Der Benutzer wird aufgefordert eine Telefonnummer für den

HelpDesk Rückruf einzugeben.

Der GINA-Benutzer wird ohne Sicherheitsfrage zur Eingabe einer

Telefonnummer für den Rückruf durch die Hotline aufgefordert.

Dies funktioniert jedoch nur, wenn das GINA-Interface über über eine GINA-Mail aufgerufen wurde, also nicht durch die blosse

Anmeldung.

Diese Einstellung steht nur in Verbindung mit dem Self-Service-

Password-Management (SSPM) zur Verfügung

178

Let user choose between hotline and

SMS

Der Benutzer muss seine Sicherheitsfrage beantworten, um mit dem Reset Prozess fortfahren zu können

Wurde bei der Registrierung eine Handynummer für den SMS

Reset eingegeben, so wird diese angezeigt. Mit klicken der

Schaltfläche „Senden“ wird der SMS-Passwort-Versand ausgelöst.

Steht keine Handynummer zur Verfügung, so wird der Benutzer aufgefordert eine Telefonnummer für den HelpDesk Rückruf einzugeben.

Diese Einstellung steht nur in Verbindung mit dem Self-Service-

Password-Management (SSPM) zur Verfügung

Der Benutzer muss seine Sicherheitsfrage beantworten, um mit dem Reset Prozess fortfahren zu können

Wurde bei der Registrierung eine Handynummer für den SMS

Reset eingegeben, so erscheint eine Auswahl, in welcher der

Benutzer zwischen seiner Handynummer (für SMS Reset) und einer einzugebenden Telefonnummer (voreingetragen ist die

Handynummer) wählen kann

Steht keine Handynummer zur Verfügung, so wird der Benutzer aufgefordert eine Telefonnummer für den HelpDesk Rückruf einzugeben.

Gibt die minimale Passwort Länge an. Mögliche Werte liegen zwischen

4 und 16

Minimum password length:

Must contain at least one lower case letter

Passwort muss mindestens einen Kleinbuchstaben enthalten.

Must contain at least one upper case letter

Must contain at least one number

Passwort muss mindestens einen Grossbuchstaben enthalten.

Passwort muss mindestens eine Ziffer enthalten.

Must contain at least one special character

Must not contain own name or mail address

Passwort muss mindestens eine Sonderzeichen enthalten.

Passwort darf nicht die eigene E-Mail-Adresse enthalten.

Must be different from previous password

(s)

Must be changed at least every days

Passwort muss sich von den letzten n Passwörtern unterscheiden.

Passwort muss nach n Tagen geändert werden.

Accounts are locked for

minutes after failed login attempts.

Gibt die Dauer in Minuten an, für welche ein GINA-Benutzer gesperrt ist, wenn er die angegebene Anzahl von Anmelde-Fehlversuchen erreicht hat.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

179

Sektion

Certificate Login

Ermöglicht die Anmeldung an GINA-Portal mittels Zertifikat. Hierfür muss das Rootzertifikat der CA, welche die Login Zertifikate ausstellt in das Eingabefeld eingefügt werden.

Parameter Beschreibung

Use settings from master template

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der unter

Master Template

gewählten Vorlage verwendet.

Eventuell vorgenommene Änderungen der weiteren Konfigurationspunkte dieser Sektion bleiben ohne Auswirkung.

Der zugreifende Benutzer muss sein entsprechendes Benutzer-Zertifikat in seinem Browser installiert haben.

Sollte mehr als ein GINA-Interface konfiguriert werden, so ist für diese Art des LogIns die Option "Use virtual hosting" (siehe

Mail Processing

GINA Settings

150

) zu verwenden.

Weiterhin ist diese Option nicht mit der Einstellung "

System

GINA https Protocol

124

Enable local

https proxy" kompatibel.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

180

7.6.2.1

Untermenü Edit GINA Layout

Sektion

Company Logo

Parameter Beschreibung

Use settings from master template

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der gewählten

Vorlage (siehe Edit GINA Settings

Master Template

170

) verwendet.

Eventuell vorgenommene Änderungen der weiteren Konfigurationspunkte dieser Sektion bleiben ohne Auswirkung.

Ist bereits ein Logo importiert, so wird dieses hier angezeigt.

Über die Browser-Schaltfläche

Datei auswählen

kann ein Logo im gif-Format zum Upload ausgewählt werden.

Die maximale Grösse des Logos ist vom verwendeten Cascaded Style Sheet

(CSS) abhängig. Im Standard beträgt diese 200x55 Pixel.

Über die Schaltfläche

Delete

wird das Logo-Bild gelöscht. Über die Schaltfläche

Save

wird das ausgewählte Bild gespeichert. Ist bereits ein Bild vorhanden, so wird dieses überschrieben.

Sektion

Header Logo (optional)

Parameter Beschreibung

Use settings from master template

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der gewählten

Vorlage (siehe Edit GINA Settings

Master Template

170

) verwendet.

Eventuell vorgenommene Änderungen der weiteren Konfigurationspunkte dieser Sektion bleiben ohne Auswirkung.

Ist bereits ein Kopfzeilen-Logo importiert, so wird dieses hier angezeigt.

Über die Browser-Schaltfläche

Datei auswählen

kann ein Logo im gif-Format zum Upload ausgewählt werden.

Die maximale Grösse des Logos ist vom verwendeten Cascaded Style Sheet

(CSS) abhängig. Im Standard beträgt diese 120x80 Pixel.

Das Header Logo wird nur angezeigt, wenn die Anzeige in den

Extended

Settings

aktiviert wurde.

Über die Schaltfläche

Delete

wird das Logo-Bild gelöscht. Über die Schaltfläche

Save

wird das ausgewählte Bild gespeichert. Ist bereits ein Bild vorhanden, so wird dieses überschrieben.

Sektion

Favourites Icon (optional)

Parameter Beschreibung

Use settings from master template

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der gewählten

Vorlage (siehe Edit GINA Settings

Master Template

170

) verwendet.

Eventuell vorgenommene Änderungen der weiteren Konfigurationspunkte dieser Sektion bleiben ohne Auswirkung.

Ist bereits ein Favoriten-Icon importiert, so wird dieses hier angezeigt.

Über die Browser-Schaltfläche

Datei auswählen

kann ein Icon in den Formaten gif, png, jpeg und ico zum Upload ausgewählt werden.

Die maximale Grösse des Icons beträgt 16x16 Pixel.

Über die Schaltfläche

Delete

wird das Logo-Bild gelöscht. Über die Schaltfläche

Save

wird das ausgewählte Bild gespeichert. Ist bereits ein Bild vorhanden, so wird dieses überschrieben.

Sektion

Footer Logo (optional)

Parameter Beschreibung

Use settings from master template

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der gewählten

Vorlage (siehe Edit GINA Settings

Master Template

170

) verwendet.

Eventuell vorgenommene Änderungen der weiteren Konfigurationspunkte dieser Sektion bleiben ohne Auswirkung.

Ist bereits ein Fusszeilen-Logo importiert, so wird dieses hier angezeigt.

Über die Browser-Schaltfläche

Datei auswählen

kann ein Logo im gif-Format zum Upload ausgewählt werden.

Die maximale Grösse des Logos ist vom verwendeten Cascaded Style Sheet

(CSS) abhängig. Im Standard beträgt diese 120x80 Pixel.

Das Fusszeilen-Logo wird nur angezeigt, wenn die Anzeige in den

Extended Settings

aktiviert wurde.

Über die Schaltfläche

Delete

wird das Logo-Bild gelöscht. Über die Schaltfläche

Save

wird das ausgewählte Bild gespeichert. Ist bereits ein Bild vorhanden, so wird dieses überschrieben.

181

182

Sektion

Background Image (optional)

Parameter Beschreibung

Use settings from master template

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der gewählten

Vorlage (siehe Edit GINA Settings

Master Template

170

) verwendet.

Eventuell vorgenommene Änderungen der weiteren Konfigurationspunkte dieser Sektion bleiben ohne Auswirkung.

Ist bereits ein Hintergrundbild importiert, so wird dieses hier angezeigt.

Über die Browser-Schaltfläche

Datei auswählen

kann ein Bild im gif-Format zum

Upload ausgewählt werden.

Im Standard Cascaded Style Sheet (CSS) wird kein Hintergrundbild verwendet.

Soll dieses Eingebettet werden, so ist das CSS in der Sektion

GINA CSS

entsprechend anzupassen.

Über die Schaltfläche

Delete

wird das Logo-Bild gelöscht. Über die Schaltfläche

Save

wird das ausgewählte Bild gespeichert. Ist bereits ein Bild vorhanden, so wird dieses überschrieben.

Sektion

GINA CSS

Parameter Beschreibung

Use settings from master template

GINA CSS:

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der gewählten

Vorlage (siehe Edit GINA Settings

Master Template

170

) verwendet.

Eventuell vorgenommene Änderungen der weiteren Konfigurationspunkte dieser Sektion bleiben ohne Auswirkung.

Im Eingabefeld kann das Aussehen der GINA-Seiten per Cascaded Style

Sheet (CSS) an das jeweilige Firmen Design angepasst werden.

Dabei ist zu beachten, dass für den GINA-Webmailer die individuell angepassten CSS erst nach den Standard Einstellungen geladen werden. Das heisst bei gleichlautenden Definitionen überschreibt das individuell angepasste

CSS das Standard CSS.

Bei einer GINA-Mail wird bei Verwendung eines individuell angepassten CSS nur dieses geladen. Somit werden hier keine Elemnte aus dem Standard CSS verwendet.

Über die Schaltfläche

Preview GINA

wird ein Beispiel der GINA-Anmeldeseite unter Verwendung der vorgenommen Konfiguration angezeigt .

Die Schaltfläche

Preview Secure email

generiert ein Beispiel für das Aussehen einer GINA-Mail unter Verwendung der vorgenommen Konfiguration.

Sollen die Standard SEPPmail Cascaded Style Sheet (CSS) wieder hergestellt werden, so ist die

Schaltfläche

Restore default CSS

zu klicken.

Mittels

Save

werden die Änderungen am CSS gespeichert.

183

Sektion

Extended settings

Parameter Beschreibung

Use settings from master template

Diese Option erscheint nur, falls ein anderes als das [default] GINA-Interface editiert wird.

Durch Aktivieren dieser Option werden die Einstellungen aus der gewählten

Vorlage (siehe Edit GINA Settings

Master Template

170

) verwendet.

Eventuell vorgenommene Änderungen der weiteren Konfigurationspunkte dieser Sektion bleiben ohne Auswirkung.

Disable "Powered by ..." Logo in

GINA viewer

Deaktiviert das Hersteller Logo rechts unten auf der GINA-Seite.

Enable Header logo on Login page

Aktiviert das Kopfzeilen-Logo auf der GINA-Anmeldeseite. Dies setzt voraus, dass in der Sektion

Header Logo

auch ein Logo hochgeladen wurde.

Enable Header logo on all other pages

Aktiviert das Kopfzeilen-Logo auf allen weiteren GINA-Seiten. Dies setzt voraus, dass in der Sektion

Header Logo

auch ein Logo hochgeladen wurde.

Aktiviert das Fusszeilen-Logo auf der GINA-Anmeldeseite. Dies setzt voraus, dass in der Sektion

Footer Logo

auch ein Logo hochgeladen wurde.

Enable Footer logo on Login page

Enable Footer logo on all other pages

Aktiviert das Fusszeilen-Logo auf allen weiteren GINA-Seiten. Dies setzt voraus, dass in der Sektion

Footer Logo

auch ein Logo hochgeladen wurde.

Enable Footer text on Login page

Enable Footer text on all other pages

Aktiviert die Fussnote auf der GINA-Anmeldeseite. Dies setzt voraus, dass in der Sektion

Footer text

aus dem Sub-Menü

Edit Translations

185

auch ein

Fussnoten Text hinterlegt wurde.

Aktiviert die Fussnote auf allen weiteren GINA-Seiten. Dies setzt voraus, dass in der Sektion

Footer text

aus dem Sub-Menü

Edit Translations

185

auch ein

Fussnoten Text hinterlegt wurde.

Über die Schaltfläche

Save

werden die Einstellungen gespeichert.

184

7.6.2.2

Untermenü Edit Translations

In den folgenden Sektionen sind in den Eingabefeldern jeweils bereits die Standardtexte der gewählten

Sprache enthalten.

Diese Texte können nach Bedarf angepasst oder ersetzt werden.

Sektion

Customization

Diese Sektion beinhaltet Syntax-Hinweise für das Bearbeiten der Sprachdatei.

Weiterhin sind folgende Variablen zulässig:

@email@ E-Mail Adresse des Empfängers der GINA-Mail

@sender@

@subject@

@domain@

Absender der GINA-Mail ursprünglicher Betreff der zu versendenden E-Mail

Name der GINA Domain

Sektion

Text in GINA

In dieser Sektion wird der Textkörper für der GINA-Mail an den Empfänger definiert.

Beschreibung

Das erste Eingabefeld definiert eine Überschrift für den im zweiten Eingabefeld folgenden Text.

Diese wird im Standard fett dargestellt.

Im zweiten Eingabefeld folgt die Beschreibung, wie der Empfänger vorzugehen hat um die anhängende Originalnachricht entschlüsseln zu können.

Mittels

Save

werden Änderungen gespeichert. Über

Restore default

wird der Standard-Inhalt der

Sektion in der Sprachdatei wieder hergestellt.

Sektion

Open hint in GINA

Das hier zur Verfügung stehende Textfeld definiert die Beschreibung, welche nach dem öffnen des

HTML-Anhangs (secure-email.html) unterhalb der Schaltfläche "OK" angezeigt wird.

Die Beschreibung sollte aufzeigen, welche Aktion(en) durch das Klicken von "OK" ausgelöst werden.

Mittels

Save

werden Änderungen gespeichert. Über

Restore default

wird der Standard-Inhalt der der Sektion in der Sprachdatei wieder hergestellt.

Sektion

Greeting on Login page

Beschreibung

Das erste Eingabefeld definiert eine Überschrift für den im zweiten Eingabefeld folgenden Text.

Diese wird im Standard fett dargestellt.

Im zweiten Eingabefeld folgt die Beschreibung, wie der Empfänger vorzugehen hat um die anhängende Originalnachricht entschlüsseln zu können.

Mittels

Save

werden Änderungen gespeichert. Über

Restore default

wird der Standard-Inhalt der der Sektion in der Sprachdatei wieder hergestellt.

Sektion

Footer text

Die Eingabe eines Fussnotentextes ist optional. Das Aktivieren der Anzeige des Fussnotentextes muss unter

Edit GINA Layout

183

in der Sektion

Extended settings

erfolgen.

Mittels

Save

werden Änderungen gespeichert. Über

Restore default

wird der Standard-Inhalt der der Sektion in der Sprachdatei wieder hergestellt.

Sektion

GINA Password Notification Mail

Beschreibung

Die erste Zeile beinhaltet den Text, welcher in der Betreffzeile der Passwort Benachrichtigungsmail enthalten sein soll.

Am Ende dieses Textes wird beim Versand der Password Benachrichtigungsmal ein Leerzeichen und die E-Mail-Adresse des Empfängers der GINA-Mail automatisch eingefügt.

Die zweite Zeile beinhaltet den E-Mail Text der Passwort Benachrichtigungsmail.

Dieser Text beginnt mit der Wiederholung der Betreffzeile. Im Anschluss wird der Text aus Textfeld eingefügt und am Schluss eine Zeile mit dem Passwort in der Form "Passwort: <Initialpasswort>" angefügt.

Mittels

Save

werden Änderungen gespeichert. Über

Restore default

wird der Standard-Inhalt der der Sektion in der Sprachdatei wieder hergestellt.

Sektion

Edit Translation file

Über die Schaltfläche

Advanced View

öffnet die Sektion

Edit Translation file

, welche den

Umgang mit dem Editor beschriebt und weitere Syntax-Hinweise aufgeführt.

Das Eingabefeld des Editors beinhaltet bereits den Text der Standard-Sprachdatei für die gewählte

Sprache zur Anpassung an die individuellen Bedürfnisse.

Mittels

Save

werden Änderungen gespeichert. Über

Restore default

wird der Standard-Inhalt der kompletten Sprachdatei wieder hergestellt.

Über die Schaltfläche

Normal View

wird zur vorherigen Ansicht zurück gewechselt.

185

186

7.6.3

Untermenü Edit Disclaimer

Wird der Standardtext angepasst oder ausgetauscht, so hat dies in beiden Sektionen zu erfolgen.

Sektion

Disclaimer as text

Im Eingabefeld ist der Standardtext in deutsch und englisch bereits vorhanden. Dieser kann den individuellen Bedürfnissen angepasst oder vollständig ersetzt werden.

Sektion

Disclaimer as Html

Im Eingabefeld ist der Standardtext im HTML-Code in deutsch und englisch bereits vorhanden. Bei

Bedarf kann Aussehen und Text durch unterschiedliche HTML-Tags zur Formatierung (zum Beispiel

Absätze, Schriftgrösse oder Schriftfarbe) individuell angepasst werden.

187

7.7 SSL

Im Menüpunkt

SSL

wird das Zertifikat angezeigt, welches für den SSL-Zugang auf das GINAbeziehungsweise auf die Administrations-Oberfläche verwendet wird. Dieses Zertifikat wird auch für die TLS-Verschlüsselung zu anderen Systemen verwendet.

Eine Ausnahme besteht bei Verwendung der Option "Use virtual hosting" aus der Sektion

GINA

Settings

150

des Menüs

Mail Processing

, da hier für jede GINA-Domain ein eigenes Zertifikat einzubinden ist.

Ist bereits ein Zertifikat eingebunden, so wird dieses wie folgt angezeigt.

Andernfalls kann über die Schaltfläche

Request a new Certificate...

ein Zertifikat importiert, oder gegebenfalls ein Self-Signed-Zertifikat erzeugt werden. Das Verwenden eines Self-Signed-Zertifikat empfiehlt sich jedoch nur auf Test Systemen, da hierdurch die Zertifikatsprüfung des Internetbrowsers eines GINA-Mail-Empfangers beim Verbinden auf die Appliance fehlschlagen würde.

Über die Schaltfläche

Backup Certificate

kann das vorhandene SSL-Zertifikat im pem-Format exportiert werden (privater und öffentlicher Schlüssel sowie gegebenenfalls Zwischenzertifikate).

188

Sektion

Issued To

Diese Sektion zeigt Informationen über den Inhaber des SSL-Zertifikates.

Abhängig vom Zertifikat müssen nicht alle hier aufgeführten Parameter vorhanden sein.

Parameter

Name (CN)

E-Mail Address

Org. Unit (OU)

Organization (O)

Locality (L)

State (ST)

Country (C)

Serial No.

Beschreibung

In der Regel beinhaltet dieses Feld den Domänennamen, über welchen das

GINA-Interface zu erreichen ist, zum Beispiel "securemail.firma.ch". Wird ein sogenanntes Wildcard-Zertifikat verwendet, so würde der Domänenname "*.

firma.ch" lauten.

Bei Self-Signed-Zertifikaten kann hier zum Beispiel auch "firma.local" oder auch eine IP-Adresse, zum Beispiel "10.0.0.10" stehen.

In der Regel der wird die E-Mail-Adresse des Antragstellers, beziehungsweise des Verwalters des Zertifikates oder dessen Abteilung eingetragen.

Organisationseinheit wie zum Beispiel ein Abteilungsname wie "Buchhaltung"

Gibt die Organisation an, für welche das Zertifikat ausgestellt wurde, zum

Beispiel "Firma"

Standort zum Beispiel eine Stadt wie "Neuenhof" oder auch ein Teilgebäude wie "Werk2"

Bundesland, Kanton, Provinz oder Ähnliches, zum Beispiel "AG" für "Aargau"

Land, zum Beispiel "CH" für "Schweiz"

Seriennummer des Zertifikats

Sektion

Issued By

Diese Sektion zeigt Informationen über den Aussteller des SSL-Zertifikates (Root-Zertifikat).

Abhängig vom Aussteller müssen nicht alle hier aufgeführten Parameter vorhanden sein.

Parameter

Name (CN)

Beschreibung

Name der ausstellenden Zertifizierungsstelle

In der Regel eine E-Mail-Adresse für Supportanfragen an den Aussteller

E-Mail Address

Org. Unit (OU)

Gibt eine Organisationseinheit des Ausstellers an

Gibt die ausstellende Organisation an

Organization (O)

Locality (L)

Gibt den Standort des Ausstellers an

Gibt ein Bundesland, Kanton, Provinz oder Ähnliches des Ausstellers an

State (ST)

Country (C)

Serial No.

Gibt das Land des Ausstellers an

Seriennummer des Zertifikats

Sektion

Validity

Zeigt die Gültigkeit des Zertifikates.

Parameter

Issued on

Expires on

Beschreibung

Ausstelldatum des SSL-Zertifikates

Ablaufdatum des SSL-Zertifikates

Sektion

Fingerprint

Gibt den Hash des Zertifikates an.

Parameter Beschreibung

Hashalgorhytmus des Zertifikates, zum Beispiel SHA1

Der Fingerprint dient zur Überprüfung eines Zertifikats. Beispiel eines ein

SHA1 Fingerprints:

48:2D:99:B1:64:C1:14:9C:B3:F2:C0:8D:FA:7F:40:9F:22:F5:11:F5

189

190

7.7.1

Untermenü Request a new Certificate

An dieser Stelle kann ein Self-Signed-Zertifikat ( in der Regel nur für Testzwecke) oder ein sogenannter Certificate Signing Request (CSR) erstellt werden.

Wird ein CSR erstellt, so wird das Schlüsselpaar auf der Appliance generiert, und nur der öffentliche

Schlüssel in eine csr-Datei geschrieben, welche bei einer CA zur Signierung eingereicht und als

Zertifikat zurückgegeben wird.

Ist bereits ein passendes SSL-Zertifikat vorhanden, so kann dieses in der Sektion

Upload existing key

importiert werden.

Hinweis:

Falls im oberen Bereich des Menüs die gelb hinterlegte Information Remember to

import the signed certificate angezeigt wird, so wurde zuvor bereits ein

Zertifikatsantrag erstellt.

Das neu erstellte SSL-Device-Zertificate sollte zusammen mit den gegebenenfalls zusätzlich benötigten Zwischen- oder auch Intermediate- CA-Zertifikate(n) und dem

Zertifikat der Root-CA selbst in der Reinhenfolge

1. Public Key des eigenen SSL-Device-Zertifikats

2. Public Key von einer oder mehreren Intermediate CA-Zertifikaten

3. Public Key der Root-CA eingefügt werden

Im Fehlerfall ist das SSL-Device-Zertifikat nicht zu nutzen. Ebenfalls kann dies zu

Problemen beim Zugriff auf die Konfigurationsoberfläche führen. Für diesen Fall sollte sicherheitshalber vor dieser Aktion temporär der HTTP-Port über

System

Advanced View

GUI Protocol

123

HTTP Port

für den Zugriff auf die

Administrationsoberfläche (http://<Appliance>:8080) freigegeben werden.

Sektion

Issued To

In dieser Sektion gibt der SSL-Zertifikats-Anforderer seine entsprechenden Informationen an.

Parameter

Name (CN)

E-Mail Address

Org. Unit (OU)

Organization (O)

Locality (L)

State (ST)

Country (C)

Beschreibung

In der Regel beinhaltet dieses Feld den Domänennamen, über welchen das

GINA-Interface zu erreichen ist, zum Beispiel "securemail.firma.ch". Wird ein sogenanntes Wildcard-Zertifikat angefordert werden, so würde der

Domänenname "*.firma.ch" lauten.

Bei Self-Signed-Zertifikaten kann hier zum Beispiel auch "firma.local" oder auch eine IP-Adresse, zum Beispiel "10.0.0.10" stehen.

In der Regel der wird die E-Mail-Adresse des Antragstellers, beziehungsweise des Verwalters des Zertifikates oder dessen Abteilung eingetragen.

Organisationseinheit wie zum Beispiel ein Abteilungsname wie "Buchhaltung"

Gibt die Organisation an, für welche das Zertifikat ausgestellt wurde, zum

Beispiel "Firma"

Standort zum Beispiel eine Stadt wie "Neuenhof" oder auch ein Teilgebäude wie "Werk2"

Bundesland, Kanton, Provinz oder Ähnliches, zum Beispiel "AG" für "Aargau"

Auswahl des Landes über das Drop-Down-Menü

191

Sektion

Attributes

Parameter

Key size (bits)

Signature

Beschreibung

Über das Drop-Down-Menü lässt sich die gewünschte Schlüssellänge für das

Angeforderte Zertifikat einstellen. In der Regel ist hier die längste

Schlüssellänge zu wählen, um dem jeweils aktuellen Sicherheitsstandard zu entsprechen.

Über das Drop-Down-Menü lässt sich auswählen, ob ein Self-Signed-Zertifikat oder ein CSR generiert werden soll.

Wird ein Self-Signed-Zertifikat erzeugt, so wird dieses umgehend implementiert und nach einem Neustart aktiv.

Wird ein CSR erstellt, so erscheint unten im

SSL

Menü die Schaltfläche

Download and Import signed Certificate...

. Diese führt zum

Folgemenü

Download and Import signed Certificate

193

welches den CSR zur Weiterleitung an die CA.

Über die Schaltfläche

Create Request

- ganz unten im Menü - wird die unter Signature gewählte

Aktion gestartet.

Sektion

Upload existing key

Ist bereits ein SSL-Zertifikat vorhanden, so kann dieses auf zwei Arten - abhängig vom vorliegenden

Zertifikats-Format (pem oder PKCS#12 also p12 oder pfx) - hochgeladen werden.

Dabei werden die ersten beiden Parameter ausschliesslich für die Integration des pem-Formats, die beiden letzteren Parameter für die Integration des PKCS#12-Formates benötigt.

Parameter

X.509 Key

Note: Remove password before uploading a key

X.509 Certificate

(and optional intermediate certificates)

Beschreibung

In dieses Feld wird der Private Schlüssel aus der pem-Datei eingefügt. Hierfür wird die pem-Datei mit einem Editor geöffnet. Falls der Private Schlüssel durch ein Kennwort geschützt ist, muss dieses zuvor entfernt werden. Im

Anschluss wird der Private Schlüssel (dieser beginnt mit -----BEGIN PRIVATE

KEY----- und endet mit -----END PRIVATE KEY-----) in das Eingabefeld kopiert.

Die Eingabe muss unbedingt mit einer Leerzeile abgeschlossen werden!

In dieses Feld wird der Öffentliche Schlüssel aus der pem-Datei eingefügt.

Dieser ist unterhalb des Privaten Schlüssel in der pem-Datei zu finden und beginnt mit -----BEGIN CERTIFICATE----- und endet mit -----END

CERTIFICATE-----.

Unter Umständen sind in der pem-Datei weitere Zertifikate enthalten. Dabei handelt es sich um Zwischen- oder auch Intermediate- Zertifikate, welche unterhalb des Öffentlichen Schlüssels in dieses Feld kopiert werden müssen.

Zuletzt wird das Zertifikat der Root CA eingefügt.

Die Eingabe muss unbedingt mit einer Leerzeile abgeschlossen werden!

Hinweis:

In dieses Eingabefeld sollten alle notwendigen

Zwischenzertifikate für eine vollständige Zertifikatskette eingefügt werden. Eine unvollständige Zertifikatskette führt bei der Zertifikatsprüfung immer dann zu

Problemen, wenn der Gegenstelle diese nicht bereits

192

Parameter Beschreibung bekannt ist. Internet-Tools - wie zum Beispiel CheckTLS

- zeigen dann einen falschen TLS-Status an.

Nicht jede pem-Datei enthält die komplette

Zertifikatskette. In diesem Fall müssen die benötigten

Zwischenzertifikate gegebenenfalls anderweitig besorgt werden.

Key and certificate in PKCS12 format

Über die Internet-Browser Schaltfläche "Datei auswählen" wird die PKCS#12-

Datei (diese hat die Endung .p12 oder .pfx) ausgewählt.

PKCS12 password

Hinweis:

Auch hier muss darauf geachtet werden, dass diese

Datei die komplette Zertifikatskette, also auch die

Zwischenzertifikate enthält. Gegebenenfalls kann nach dem Import der PKCS#12 Datei ein Backup des

Zertifikates (siehe

SSL

187

) vorgenommen werden. Die dadurch zur Verfügung stehende pem-Datei kann mit einem Editor geöffnet und anschliessend wie oben beschrieben wieder inklusive Zwischenzertifikate importiert werden.

Nachdem eine PKCS#12-Datei den Privaten Schlüssel enthält, ist diese

Passwort geschützt. Das Passwort muss vor dem Import der oben ausgewählten PKCS#12-Datei in dieses Eingabefeld eingegeben werden.

Über die Schaltfläche

Upload Key and Certificate

wird das SSL-Zertifikat in die Appliance hochgeladen.

Aktiv wird das Zertifikat nach einem Neustart der Appliance.

193

7.7.1.1

Untermenü Download and Import signed Certificate

Sektion

Request

Das Eingabefeld enthält den CSR wie er an die CA übermittelt werden muss. Die geschieht häufig

über ein Texteingabefeld auf der Webseite der CA.

Sektion

Import Certificate

Wird nach dem Hochladen des CSR zur CA von dieser das Zertifikat zurückgeliefert, so ist der Inhalt dieses Zertifikats in dieses Eingabefeld einzugeben.

Diese Zertifikat beginnt mit -----BEGIN CERTIFICATE----- und endet mit -----END CERTIFICATE-----.

Unter Umständen werden von der CA weitere Zertifikate zur Verfügung gestellt. Dabei handelt es sich um Zwischenzertifikate, welche unterhalb des Öffentlichen Schlüssels in dieses Feld kopiert werden müssen.

Die Eingabe muss unbedingt mit einer Leerzeile abgeschlossen werden!

Hinweis:

In dieses Eingabefeld sollten alle notwendigen Zwischenzertifikate für eine vollständige Zertifikatskette eingefügt werden. Eine unvollständige

Zertifikatskette führt bei der Zertifikatsprüfung immer dann zu Problemen, wenn der Gegenstelle diese nicht bereits bekannt ist. Internet-Tools - wie zum

Beispiel CheckTLS - zeigen dann einen falschen TLS-Status an.

Nicht jede CA liefert automatisch die komplette Zertifikatskette. In diesem Fall müssen die benötigten Zwischenzertifikate gegebenenfalls anderweitig besorgt werden.

Über die Schaltfläche

Import Certificate

wird der Vorgang abgeschlossen. Im Anschluss muss die

Appliance neu gestartet werden.das SSL-Zertifikat in die Appliance hochgeladen.

Die Schaltfläche

Cancel this Certificate enrollmant process

bricht den Vorgang ab. Nach dem

Abbruch besteht keine Möglichkeit mehr das zum CSR passende Zertifikat einzubinden!

Die Appliance kann durch schlichten Wechsel in ein anderes Menü weiter konfiguriert werden, ohne den Vorgang abzubrechen.

194

7.8 CA

Die SEPPmail-Appliance beinhaltet eine vollständige CA. Diese kann als Self-Signed-CA aber auch als Sub-CA konfiguriert werden. Alternativ können Trusted-CA Zertifikate automatisiert über die

Managed Public Key Infrastructure (MPKI) Connectoren bezogen werden.

Die Verwendung einer Self-Signed-CA ist an dieser Stelle ausser für Testzwecke nicht zu empfehlen, da die Signatur von mit Self-Signed-Zertifikaten signierten E-Mails in der Regel vom Empfänger nicht automatisiert geprüft werden kann.

Sektion

Issued To

Diese Sektion zeigt Informationen über den Inhaber des CA-Zertifikates.

Abhängig vom Zertifikat müssen nicht alle hier aufgeführten Parameter vorhanden sein.

Parameter

Name (CN)

E-Mail Address

Org. Unit (OU)

Organization (O)

Locality (L)

State (ST)

Country (C)

Serial No.

Beschreibung

Gibt den Namen der eigenen CA an

In der Regel der wird die E-Mail-Adresse des Verwalters der eigenen CA oder dessen Abteilung eingetragen.

Organisationseinheit wie zum Beispiel ein Abteilungsname wie "Sicherheit"

Gibt die Organisation an, für welche das Zertifikat ausgestellt wurde, zum

Beispiel "Firma"

Standort zum Beispiel eine Stadt wie "Neuenhof"

Bundesland, Kanton, Provinz oder Ähnliches, zum Beispiel "AR" für

"Appenzell Ausserrhoden"

Land, zum Beispiel "CH" für "Schweiz"

Seriennummer des Zertifikats

Sektion

Issued By

Diese Sektion zeigt Informationen über den Aussteller des CA-Zertifikates (Root-Zertifikat).

Abhängig vom Aussteller müssen nicht alle hier aufgeführten Parameter vorhanden sein.

Parameter

Name (CN)

Beschreibung

Name der ausstellenden CA

In der Regel eine E-Mail-Adresse für Supportanfragen an den Aussteller

E-Mail Address

Org. Unit (OU)

Gibt eine Organisationseinheit des Ausstellers an

Gibt die ausstellende Organisation an

Organization (O)

Locality (L)

Gibt den Standort des Ausstellers an

Gibt ein Bundesland, Kanton, Provinz oder Ähnliches des Ausstellers an

State (ST)

Country (C)

Gibt das Land des Ausstellers an

Sektion

Validity

Gibt die Gültigkeit des eigenen CA-Zertifikates an.

Parameter

Issued on

Expires on

Beschreibung

Ausstelldatum des Zertifikates

Ablaufdatum des Zertifikates

Sektion

Fingerprint

Gibt den Hash des eigenen CA-Zertifikates an.

Parameter Beschreibung

Hashalgorhytmus des Zertifikates, zum Beispiel SHA1

Der Fingerprint dient zur Überprüfung eines Zertifikats. Beispiel eines SHA1

Fingerprints:

48:2D:99:B1:64:C1:14:9C:B3:F2:C0:8D:FA:7F:40:9F:22:F5:11:F5

195

196

Sektion

Certificate Revocation List

Wurde die interne CA konfiguriert, so hält diese eine Revocation List für die von ihr ausgestellten

Zertifikate vor. Sollte ein Privater Schlüssel kompromittiert worden sein, so kann dieser in der

Benutzerkonfiguration (siehe Benutzerdetails

S/MIME

226

) als ungültig erklärt werden und taucht dann in der Revocation List auf. Diese kann über die Schaltfläche

Create and Download CRL

heruntergeladen und somit abgefragt werden.

197

Sektion

Internal CA Settings

In dieser Sektion werden die Einstellungen für die Self-Signed- beziehungsweise Sub-CA eingegeben.

Die genannten Extension Settings sind die Standard Einstellung bei Einrichtung einer Self-Signed-CA.

Soll eine Sub-CA Eingerichtet werden, gibt in der Regel der Betreiber der Haupt-CA entsprechende

Werte vor.

Parameter Beschreibung

Static Subject

Part

Validity in days

Als "Static Subject Part" tauchen im Standard die bei der CA Erstellung eingegebenen Parameter für Land, Organisationseinheit und Organisation auf, also zum Beispiel

/C=CH/OU=Sicherheit/O=Firma

Gibt die Gültigkeit der ausgestellten Zertifikate in Tagen an.

Hinweis:

Diese Einstellung gilt auch für die von der Appliance generierten openPGP Schlüsselpaare

Automatically renew expiring certificates if validity days left less than

Gibt an, ob und wenn wieviele Tage vor dem Ablaufen ein Zertifikat erneuert werden soll. Je früher vor Ablauf dieses erneuert wird, desto mehr

Verbreitung wird das neue Zertifikat über die E-Mail Signatur bis zum

Ablaufen des Vorgänger-Zertifikates finden. Dadurch steht das neue

Zertifikat zuverlässiger für Kommunikationspartner zur Verschlüsselung bereit.

Hinweis:

Zertifikate werden nur für diejenigen Benutzer neu generiert, welche auch aktiv sind.

Das heisst, sendet ein Benutzer innerhalb des angegebenen Zeitraums

validity days left

keine E-Mail, so wird auch kein neues Zertifikat generiert.

Hinweis:

Diese Einstellung gilt auch für die von der Appliance generierten openPGP Schlüsselpaare

Extension setting

name:

authorityKeyIdentifier

value:

keyid,issuer:always

Fügt den durch diese CA ausgestellten Zertifikaten die

über den Wert (value:) angegebenen Informationen

über die ausstellende CA hinzu

keyid: subjectKeyIdentifier (siehe nächste Option)

issuer: IssuerName, Serialnumber

:always: Gibt eine Fehlermeldung aus, wenn das

Kopieren der angegebenen Optionen fehlschlägt

name:

subjectKeyIdentifier

Gibt die Art des Fingerprints des ausgestellten Zertifikats an

name:

subjectAltName

value:

hash

hash: bildet einen Hash-Wert gemäss RFC 3280

hex: Ein vordefinierter Hex-Wert wird dem

Zertifikat angehängt (nicht empfohlen!)

value:

email:copy

198

Parameter Beschreibung

Extension setting

(Extension setting)

New

Extension

Ermöglicht das Einbinden weiterer Alternativnamen in das ausgestellte Zertifikat.

email: E-Mail-Adresse

copy: fügt automatisch eine Kopie der E-Mail-

Adresse aus dem "SubjectName" hinzu

URI: uniform resource indicator

DNS: DNS domain name

RID: registered ID: OBJECT IDENTIFIER

IP: IP-Adress im v4 oder v6 Format

dirName: sollte auf einen distinguished name (DN) zeigen. Mehrfach eingabe durch + möglich.

value:

CA:FALSE

name:

basicConstraints

Zeigt auf, ob es sich bei dem

Ausgestellten Zertifikat um ein

CA Zertifikat handelt.

name:

nsComment

Kommentareintrag für das

Zertifikat

CA: mögliche Werte sind TRUE oder FALSE

pathlen: optional bei CA:TRUE: gibt die maximale

Anzahl von CAs an, welche

value:

OpenSSL Generated Certificate

Frei wählbarer Kommentar

name:

nsCertType

Gibt den Zertifikatstyp an

(Netscape)

value:

client, email

client, server, email, objsign, reserved, sslCA, emailCA, objCA

name:

keyUsage

value:

nonRepudiation, digitalSignature, keyEncipherment

Gibt den/die erlaubten

Verwendungszweck(e) für das

Zertifikat an.

digitalSignature: Digitale Signatur

nonRepudiation: Nachweisbarkeit

keyEncipherment: Schlüssel Verschlüsselung

dataEncipherment: Datenverschlüsselung

keyAgreement: Schlüsselvereinbarung

keyCertSign: Zertifikatssignatur

cRLSign: Revocation List Signatur

encipherOnly: nur Verschlüsselung

decipherOnly: nur Entschlüsselung

value:

URI:https://<IhreCA>/certs.crl

name:

crlDistributionPoints

Fügt den Pfad zur Revocation

List der CA an das Zertifikat an.

(diese Einstellung muss bei

Bedarf manuell hinzugefügt werden)

URI: Pfad zur Revocation List. Mehrere URLs werden kommagetrennt eingegeben.

name: value:

An dieser Stelle können bei Bedarf weitere Einstellungen vorgenommen werden.

Nach dem Speichern einer weiteren Extension kommt erscheint jeweils eine weitere

Eingabezeile.

199

Sektion

External CA

An dieser Stelle wird die Entscheidung getroffen ob, und wenn welche CA für den (teil-)automatischen

Bezug von Trusted-CA-Zertifikaten zur Verfügung gestellt werden soll.

Parameter

Select MPKI

Configure MPKI

Beschreibung

A-Trust o

D-Trust o none

(wird in Kürze zur Verfügung gestellt)

(wird in Kürze zur Verfügung gestellt o

SCEP (siehe

SCEP

203

) o

SwissSign (siehe

SwissSign

205

)

Über die Schaltfläche

Save

wird die Auswahl gesichert.

Dieser Parameter taucht nur auf, wenn eine CA ausgewählt wurde, also nicht

"none" ist.

Über die Schaltfläche

<Ausgewählte CA> connector...

wird dann der

Zugang und die Parameter für die Schnittstelle konfiguriert. Die entsprechenden Konfigurationsdaten stellt der CA Anbieter zur Verfügung.

200

Sektion

SafeNet Luna Setup

Diese Sektion zeigt Informationen über den Aussteller des CA-Zertifikates (Root-Zertifikat).

Abhängig vom Aussteller müssen nicht alle hier aufgeführten Parameter vorhanden sein.

Paramet er

Beschreibung

HSM IP or hostnam e

Angabe der IP-Adresse beziehungsweise des Hostnamen, unter welchem Die HSM erreichbar ist.

HSM

Port

Save

SafeNet

Luna

Settings

Angabe des Ports, auf welchem die HSM Anfragen entgegen nimmt.

HSM CA certificat e

Eintrag des HSM CA Zertifikates. Hier ist darauf zu achten, dass am Ende des

Eingabefeldes eine Leerzeile vorhanden ist. Das hier einzutragende Zertifikat beginnt mit

-----BEGIN CERTIFICATE----- und endet mit -----END CERTIFICATE-----.

Über die Schaltfläche gesichert.

Save Settings

werden die oberhalb gemachten Einstellungen

Client certificat e

CN of this device

(hostna me or

IP):

HSM

Status

Angabe des Namens (oder alternativ der IP-Adresse) der SEPPmail-

Appliance. Dieser wird für das Generieren des Schlüsselpaares via

Generate new key pair

benötigt. Dieses Schlüsselpaar wird für das Absichern der

Kommunikation zwischen HSM un SEPPmail-Appliance benötigt

Gibt den Verbindungsstatus zur HSM an.

Über die Schaltflächen

Download Certificate

kann das Root CA Zertifikat - also der Öffentliche

Schlüssel - der CA heruntergeladen werden. Dieser kann gegebenenfalls einem

Kommunikationspartner zur Verfügung gestellt werden, damit dieser Signaturen von E-Mails welche mit Zertifikaten Ihrer Self-Signed-CA signiert wurden automatisiert prüfen kann.

Über

Download Key

kann der Private Schlüssel heruntergeladen und somit gesichert werden.

Die Schaltfläche

Request a new Certificate...

führt zum Untermenü

Request a new Certificate

190

- wie es bereits aus dem Menü SSL bekannt ist - über welches die CA als Self-signed- oder Sub-

CA eingerichtet wird.

201

7.8.1

QUOVADIS

Informationen zur QuoVadis MPKI erhalten Sie unter https://www.quovadisglobal.ch/Dienstleistungen/ZertifikatsServices.aspx

An dieser Stelle wird die Verbindung zur QuoVadis CA, für den automatisierten Bezug von Benutzer-

Zertifikaten konfiguriert.

Hinweis:

Werden in der Zertifikatsanforderung Umlaute benötigt, so sind diese gemäss Tabelle als UTF-8

String einzugeben zu erzeugendes

Zeichen

UTF-8

(in Literal)

\xc3\x84

\xc3\x96

\xc3\x9c

\xc3\xa4

\xc3\xb6

\xc3\xbc

\xc3\x9f

Sektion

Default Parameter

Je nach Vertrag sind hier die erforderlichen Einstellungen vorzunehmen. Diese werden in der Regel mit dem Vertragsschluss zwischen dem E-Mail Domänen Inhaber und QuoVadis von QuoVadis zur

Verfügung gestellt

Parameter Beschreibung

Service URL

Angabe der URL, auf welche über die MPKI zugegriffen werden soll

(wird von QuoVadis mit den Zugangsdaten geliefert)

Static Subject Part

Dieser Teil taucht im Zertifikat des jeweiligen Benutzers als Erweiterung des

Feldes "Antragsteller" auf und kann im Rahmen eines Distinguished Names frei definiert werden

Sektion

Domain specific Parameters (Optional)

Werden auf der SEPPmail-Appliance mehrere E-Mail Domänen (Managed Domains) verwaltet, so können über diese Option jeweils Domänen spezifische Parameter für das Erstellen von

Benutzerzertifikaten mitgegeben werden.

Nach dem Speichern der Domänen spezifischen Option, erscheint jeweils ein weiteres Eingabefeld.

Parameter Beschreibung

Domain:

Angabe der E-Mail Domäne, für welche die beiden folgenden Parameter gültig sein sollen.

URL:

Angabe der für die E-Mail Domäne spezifischen Service URL

(wird von QuoVadis mit den Zugangsdaten geliefert)

Static Subject Part:

Dieser Teil taucht im Zertifikat des jeweiligen Benutzers der jeweiligen E-Mail

Domäne als Erweiterung des Feldes "Antragsteller" auf und kann im Rahmen eines Distinguished Names frei definiert werden.

202

Sektion

Certificate

Dient der Authentifizierung gegenüber dem CA Anbieter (QuoVadis)

Parameter Beschreibung

Authentication Key

Zertifikat zur Authentisierung bei der CA (QuoVadis) für den Bezug von

Benutzer-Zertifikaten. Dieses Zertifikat wird von QuoVadis als Datei zur

Verfügung gestellt.

Trust Chain

Damit die SEPPmail-Appliance beim Signieren von E-Mails die

Zertifikatskette hin zur Root CA (QuoVadis) ergänzen kann, muss diese bekannt gemacht werden. Hierfür muss die Zertifikatskette über eine entsprechende Zertifikatsdatei hochgeladen werden. Diese Datei wird von

QuoVadis bereit gestellt.

Sektion

Settings

Einstellungen für das automatische erneuern von Zertifikaten.

Parameter Beschreibung

Automatically

Renew Expiring

Certificates if validity days left less than

Wird diese Option aktiviert, so werden ablaufende Benutzer-Zertifikate automatisiert erneuert, sobald die Gültigkeit die angegebene Anzahl an

Tagen unterschreitet

Hinweis:

Wird das automatische Erneuern von Zertifikate in den MPKI Einstellungen aktiviert, so werden nur für diejenigen Benutzer neue Zertifikate generiert, welche auch aktiv sind.

Das heisst, sendet ein Benutzer innerhalb des angegebenen Zeitraums

validity days left

keine E-Mail, so wird auch kein neues Zertifikat generiert.

Hinweis:

Je grösser die Überschneidung der

Zertifikatsgültigkeit ist, desto höher ist die Chance, dass der Kommunikationspartner in den Besitz eines gültigen, öffentlichen Schlüssels gelangt, welchen er für das Senden verschlüsselter E-Mails benötigt.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

203

7.8.2

SCEP

Mit dem Simple Certificate Enrollment Protocol (SCEP) wird die Anbindung an Zertifizierungsstellen

Produkte zahlreicher namhafter Hersteller (unter anderem Microsoft) ermöglicht.

Sektion

Parameter

Dieser Sektion beinhaltet die Verbindungsdaten zur externen CA.

Parameter

Service URL

Beschreibung

URL unter welchem die Verbindung zur CA hergestellt wird. Voreingestellt ist die URL mit dem Network Device Enrollment (NDES) Namen der SEPPmail-

Appliance für Microsoft Enterprise CA: http://localhost:10000/certsrv/mscep/mscep.dll

Sektion

Certificate

In dieser Sektion werden die Parameter zur Authentifizierung an der externen CA angegeben.

Parameter Beschreibung

Kennwort für das Übermitteln einer Anforderung an die externe CA

Challenge

Password

Signature

Certificate

CA Certificate

Über diese Funktion wird das Zertifikat zur Signierung der Anforderungen an die externe CA (RA-Zertifikat) eingebunden. Dieses RA-Zertifikat wird von der externen CA in der Regel explizit für die MPKI Anbindung der SEPPmail-

Appliance ausgestellt.

An dieser Stelle wird das Root Zertifikat der extern anzubindenden CA bekannt gemacht.

Sektion

Settings

Optionale Einstellungen, welche der externen CA zur Verfügung gestellt werden.

Parameter Beschreibung

Automatically renew expiring certificates if validity days left less than

Gibt an, ob und wenn wieviele Tage vor dem Ablaufen ein Zertifikat erneuert werden soll. Je früher vor Ablauf dieses erneuert wird, desto mehr

Verbreitung wird das neue Zertifikat über die E-Mail Signatur bis zum

Ablaufen des Vorgänger-Zertifikates finden. Dadurch steht das neue

Zertifikat zuverlässiger für Kommunikationspartner zur Verschlüsselung bereit.

Hinweis:

Zertifikate werden nur für diejenigen Benutzer neu generiert, welche auch aktiv sind.

Das heisst, sendet ein Benutzer innerhalb des angegebenen Zeitraums

validity days left

keine E-Mail, so wird auch kein neues Zertifikat generiert.

204

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

205

7.8.3

SwissSign

Informationen zur Bestellung und zu den Modalitäten für das Einrichten einer SwissSign MPKI erhalten

Sie unter https://www.swisssign.com/de/component/content/article/6/278-partnerinformationen

An dieser Stelle wird die Verbindung zur SwissSign CA, für den automatisierten Bezug von Benutzer-

Zertifikaten konfiguriert.

Hinweis:

Werden in der Zertifikatsanforderung Umlaute benötigt, so sind diese gemäss Tabelle als UTF-8

String einzugeben zu erzeugendes

Zeichen

UTF-8

(in Literal)

\xc3\x84

\xc3\x96

\xc3\x9c

\xc3\xa4

\xc3\xb6

\xc3\xbc

\xc3\x9f

206

Sektion

Parameter

Je nach Vertrag sind hier die erforderlichen Einstellungen vorzunehmen. Diese werden in der Regel mit dem Vertragsschluss zwischen dem E-Mail Domänen Inhaber und SwissSign von SwissSign zur

Verfügung gestellt

Parameter

Silver light certificates

Standard certificates, use the following options:

Server

Beschreibung

Zu aktivieren, sofern "Silver light Zertifikate" bezogen werden sollen

Sollen "Silver" oder "Gold" Zertifikate bezogen werden, so muss diese

Option gewählt werden.

CA Name

RA Name

Angabe des Server, auf welchen über die MPKI zugegriffen werden soll

(wird von SwissSign mit den Zugangsdaten geliefert)

Name der ausstellenden CA

(wird von SwissSign mit den Zugangsdaten geliefert)

Name der Zertifikatsanfordernden RA

(wird von SwissSign mit den Zugangsdaten geliefert)

Extended Profile

Name

Static Subject Part

CSR Creation

Dieser Teil taucht im Zertifikat des jeweiligen Benutzers als Erweiterung des

Feldes "Antragsteller" auf und kann im Rahmen eines Distinguished Names frei definiert werden

Create Encryption

Key Remotely

Im Normalfall werden die Schlüsselpaare ausschliesslich auf der SEPPmail-Appliance generiert und nur der öffentliche Schlüssel als

CSR (Certificate Signing Request) an die CA zum

Signieren übermittelt. Das heisst der sensible

private Schlüssel verlässt die Appliance niemals.

Werden höherwertige Zertifikate angefordert (zum

Beispiel "Gold"), in welchen nicht ausschliesslich die E-Mail Adresse, sondern auch die jeweils zugehörge Person bestätigt wird. so können diese theoretisch auch zum signieren von Dokumenten

(zum Beispiel PDF-Dateien) verwendet werden. Da ein Download der privaten Schlüssel von der

SEPPmail-Appliance nicht möglich ist, besteht über diese Option die Möglichkeit, die Schlüsselpaare durch die CA (SwissSign) generieren zu lassen.

Somit kann der sensible private Schlüssel bei

Bedarf über einen gesicherten Kanal von der CA heruntergeladen werden.

207

Sektion

Domain specific Parameters (Optional)

Werden auf der SEPPmail-Appliance mehrere E-Mail Domänen (Managed Domains) verwaltet, so können über diese Option jeweils Domänen spezifische Parameter für das Erstellen von

Benutzerzertifikaten mitgegeben werden.

Nach dem Speichern der Domänen spezifischen Option, erscheint jeweils ein weiteres Eingabefeld.

Parameter Beschreibung

Domain:

Angabe der E-Mail Domäne, für welche die beiden folgenden Parameter gültig sein sollen.

Wird bei Bedarf von SwissSign mit den Zugangsdaten geliefert.

Extended Profile:

Static Subject Part:

Dieser Teil taucht im Zertifikat des jeweiligen Benutzers der jeweiligen E-Mail

Domäne als Erweiterung des Feldes "Antragsteller" auf und kann im Rahmen eines Distinguished Names frei definiert werden.

Sektion

Certificate

Dient der Authentifizierung gegenüber dem CA Anbieter (SwissSign)

Parameter Beschreibung

PKCS12 identity file

Zertifikat zur Authentisierung bei der CA (SwissSign) für den Bezug von

Benutzer-Zertifikaten. Diese Datei wird von SwissSign zur Verfügung gestellt und ist mit einem Passwort versehen (siehe Parameter PKCS12 Password)

Ist der Zugang zur CA erfolgreich, so erscheint an dieser Stelle die Meldung an operator certificate with valid password has been found.

PKCS12 Password

Passwort zur Freischaltung des im PKCS12 identity file enthaltenen "private keys". Auch dieses wird von SwissSign zur Verfügung gestellt.

Trust Chain

Damit die SEPPmail-Appliance beim Signieren von E-Mails die

Zertifikatskette hin zur Root CA (SwissSign) ergänzen kann, muss diese bekannt gemacht werden. Dies kann durch manuelles Kopieren in das

Eingabefeld erfolgen - hier ist darauf zu achten, dass am Ende des

Eingabefeldes eine Leerzeile vorhanden ist - oder durch klicken der

Schaltfläche

Add or update...

in der Sektion

Settings

208

Sektion

Settings

Einstellungen für das automatische erneuern von Zertifikaten.

Parameter

Automatically

Renew Expiring

Certificates if validity days left less than

Chain certificates

(needed to sign emails)

Beschreibung

Wird diese Option aktiviert, so werden ablaufende Benutzer-Zertifikate automatisiert erneuert, sobald die Gültigkeit die angegebene Anzahl an

Tagen unterschreitet

Hinweis:

Wird das automatische Erneuern von Zertifikate in den MPKI Einstellungen aktiviert, so werden nur für diejenigen Benutzer neue Zertifikate generiert, welche auch aktiv sind.

Das heisst, sendet ein Benutzer innerhalb des angegebenen Zeitraums

validity days left

keine E-Mail, so wird auch kein neues Zertifikat generiert.

Hinweis:

Je grösser die Überschneidung der

Durch Klicken der Schaltfläche

Add or update...

wird die Zertifikatskette

(siehe Sektion

Certificate

Parameter Trust Chain) ergänzt beziehungsweise aktualisiert.

Die vorgenommenen Änderungen werden über die Schaltfläche

Save

gespeichert.

209

7.9 Administration

Dieses Menü beinhaltet Funktionen zur Verwaltung des Systems.

Sektion

License and Registration

Ist eine Gültige Lizenz vorhanden, so wird in diesem Abschnitt die Meldung "Valid License detected" ausgegeben.

Andernfalls muss an dieser Stelle die Registrierung der Appliance vorgenommen werden. im

Normalfall geschieht das über die Schaltfläche

Register this device...

, welche das Untermenü

Register this device

213

öffnet.

Ist der Zugang zum SEPPmail-Lizenzserver (update.seppmail.ch beziehungsweise support.seppmail.

ch) über TCP Port 22 (siehe

Firewall / Router einrichten

sowie Sektion

Proxy Settings

126

des

Menüpunktes

System

) nicht möglich, da es sich zum Beispiel um ein PCI gehärtetes oder ein DMZ abgeschottetes System handelt, so kann die Registrierung über

Import License File...

vorgenommen werden.

Sektion

Update

Über die Schaltfläche

Check for Update

wird die komplette Versions-Historie sowie Inhalte verfügbarer und geplanter Updates der SEPPmail-Appliance ngezeigt. Sollten bei einem Update

Nacharbeiten - in seltenen Fällen muss zum Beispiel das Ruleset neu generiert werden - notwendig sein, so ist auch dies in roter Schrift zu sehen.

Weiterhin kann durch klicken dieser Schaltfläche ein Abgleich mit dem SEPPmail-Lizenzserver erzwungen werden, wodurch zum Beispiel kurzfristig angeforderte Lizenzänderungen sofort

übernommen werden.

Fetch Update

startet bei verfügbarem Update den Download der Firmware vom SEPPmail-

Updateserver und startet das System im Anschluss mit der neuen Firmware. Durch erneutes Klicken dieser Schaltfläche während des Downloads wird jeweils der Fortschritt in % ausgegeben.

Prefetch (reboot manually)

startet bei verfügbarem Update den Download der Firmware vom

SEPPmail-Updateserver. Diese wird beim nächsten manuellen Reboot übernommen.

Ist der Zugang zum SEPPmail-Lizenzserver (update.seppmail.ch beziehungsweise support.seppmail.

ch) über TCP Port 22 (siehe

Firewall / Router einrichten

sowie Sektion

Proxy Settings

126

des

Menüpunktes

System

) nicht möglich, da es sich zum Beispiel um ein PCI gehärtetes oder ein DMZ abgeschottetes System handelt, so kann eine Update Datei über den Support angefordert werden.

Diese Datei wird über

Upload

hochgeladen. Durch einem Neustart der SEPPmail-Appliance wird die neue Firmware aktiv.

Hinweis:

In der Regel wird immer die aktuellste Firmware eingespielt. In seltenen Fällen ist jedoch das Update in mehreren Schritten notwendig, zum Beispiel wenn

Abhängigkeiten bei den Konfigurationsdateien bestehen. In diesen Fällen muss die

Appliance so oft aktualisiert werden, bis Sie auf dem aktuellen Stand ist (Meldung "

You already have the latest version installed").

Beim Update ist im Cluster ist folgendes zu beachten:

Alle Maschinen sollten zeitnah aktualisiert werden, so dass lange Laufzeiten mit unterschiedlichen Versionsständen vermieden werden.

Ist ein Update in mehreren Stufen notwendig (siehe oben), so ist immer auf allen

Clusterpartnern der gleiche Versionsstand herzustellen, bevor auf die nächst höhere Version aktualisiert wird.

Ein Beispiel für die oben genannte Situation wäre das Update von Version 7.0.4 auf

7.2. Hier wird zunächst nur die Version 7.1 zum Update angeboten. Erst wenn alle

Maschinen diesen Stand haben darf auf die dann angebotene Version 7.2 aktualisiert werden.

210

Ist nach einem Update ein erneutes generieren des Rulesets notwendig (dies wird mittels klick auf

Check for Update

angezeigt), so sind zunächst alle Maschinen auf einen einheitlichen Stand zu bringen. Danach muss das Ruleset an einer beliebigen Maschine aktualisiert werden (siehe

Mail Processing

Ruleset

Generator

157

Save and Create Ruleset

Handelt es sich um einen

Frontend/Backend Cluster

, so sind zunächst die

Frontend und erst dann die Backend Maschinen zu aktualisieren.

Sektion

Backup

Die Schaltfläche

Download

startet das Herunterladen der Backup-Datei. Diese Datei beinhaltet ausschliesslich Konfiguration und Schlüsselmaterial der SEPPmail-Appliance. Voraussetzung für den

Download des Backups ist die Vergabe eines Backup Passwortes, welches via

Change Password

gesetzt beziehungsweise geändert werden kann.

Soll ein Backup in die Appliance zurückgespielt werden, so erfolgt dies durch klicken von

Import

Backup File...

. Hierfür wird das zum Zeitpunkt der Erstellung des Backups gültige Backup-Passwort benötigt.

Hinweis:

Mitglieder der Gruppe "backup" (siehe

Groups

233

) erhalten täglich die

Sicherungsdatei per E-Mail zugesandt. Voraussetzung ist natürlich ein gesetztes

Backup Passwort.

Zu beachten gilt, dass Backups älterer Firmware Stände in neuere Firmware Stände eingespielt werden können. Dabei sollte im Anschluss unbedingt das Ruleset neu generiert werden (siehe

Mail Processing

Ruleset Generator

157

Save and

Create Ruleset

Backups neuerer Firmware Stände dürfen keinesfalls auf Maschinen mit älterem

Firmwarestand eingespielt werden.

Sektion

System

Reboot...

startet das System neu. Es erscheint ein Dialog zur Eingabe eines Sicherheitscodes, wodurch ein versehentlicher Neustart verhindert wird.

Shut down...

fährt das System herunter. Es erscheint ein Dialog zur Eingabe eines

Sicherheitscodes, wodurch ein versehentliches Herunterfahren verhindert wird.

Sektion

Database and System Settings

Perform factory reset...

setzt das System auf Werkszustand zurück. Es erscheint ein Dialog zur

Eingabe eines Sicherheitscodes in umgekehrter Schreibweise um ein ungewolltes Zurücksetzen zu verhindern.

211

Sektion

Import

In dieser Sektion werden zahlreiche (Massen-)Importfunktionen zur Verfügung gestellt.

Parameter Beschreibung

Import

Users (CSV)

Import

GINA Users

(CSV)

Über die Schaltfläche

Import

können Encryption/Signature-Benutzer mittels csv-

Datei mit dem Aufbau "USERID;NAME;EMAIL;PASSWORD" importiert werden.

Dabei ist die Vergabe eines Passwortes optional (siehe

Users

223

). Bei Benutzern, welche durch die SEPPmail-Appliance automatisch generiert wurden entsprechen

USERID;NAME;EMAIL jeweils der E-Mail-Adresse des Benutzers, was die

Einmaligkeit garantiert.

Über die Schaltfläche

Import

können GINA-Benutzer mittels csv-Datei mit dem

Aufbau "EMAIL;PASSWORD;NAME;MOBILE" importiert werden. Die Angabe einer

Mobilfunk-Nummer ist dabei optional.

Denkbar wäre die Eingabe einer Kundenliste deren jeweiliges Initialpasswort die

Postleitzahl ist.

Erfolgt bei mandantenfähigen Systemen der Import durch den Mandanten-Admin, so werden die mittels dieser Funktion importierten GINA-Benutzer automatisch dem entsprechenden Mandanten zugeordnet.

Import openPGP secret keys

Über die Schaltfläche

Import openPGP secret keys

ist das Importieren privater openPGP Schlüssel möglich. Sollte für die im Schlüssel vorhandene E-Mail-Adresse noch kein Benutzer auf der SEPPmail-Appliance vorhanden sein, so wird dieser automatisch durch diese Aktion angelegt.

Der Import ist sowohl über eine Datei, als auch durch Einfügen als Text möglich jeweils unter Angabe der passenden Passphrase möglich.

Durch das Aneinanderreihen von Schlüsseln - egal ob als Datei oder als Text - ist auch ein Massen Import möglich. Ebenso können einzelne Schlüsseldateien aus einer unverschlüsselten ZIP-Datei ohne Ordnerstruktur importiert werden. Bei einem

Massen Import ist darauf zu achten, dass alle Schlüssel die selbe Passphrase haben!.

Import

S/MIME keys

Über die Schaltfläche

Import S/MIME keys

ist das Importieren von PKCS#12

Dateien (diese haben die Endung .p12 oder .pfx), welche den privaten S/MIME-

Schlüssel enthalten, unter Angabe der passenden Passphrase möglich. Sollte für die im Schlüssel vorhandene E-Mail-Adresse noch kein Benutzer auf der

SEPPmail-Appliance vorhanden sein, so wird dieser automatisch durch diese Aktion angelegt. Bei diesen automatisch generierten Benutzern wird als User ID die E-Mail

Adresse verwendet. Je nach Güte des Zertifikats wird als User Name der im

Zertifikat eingetragene Name verwendet. Enthält das Zertifikat keinen entsprechenden Namen, so wird auch hier die E-Mail Adresse eingetragen. Ist dies nicht gewünscht, so müssen die Benutzer vor dem Import der S/MIME Keys angelegt werden. Hierzu bietet sich im Vorfeld das Verwenden der Funktion Import

Users (CSV) an.

Hinweis:

Da es sich um eine Massen Import Funktion handelt, wird für den

Import eine unverschlüsselte ZIP-Datei ohne Ordnerstruktur erwartet, welche die PKCS#12 Dateien enthält. Dies setzt natürlich voraus, dass alle Schlüssel die selbe Passphrase haben.

Import

S/MIME certificates

Über

Import S/MIME user and/or CA certificates

können öffentliche S/MIME

Schlüssel zur Verschlüsselung an Kommunikationspartner, wie auch CA Zertifikate für die automatische S/MIME Signaturprüfung importiert werden. Durch das Packen mehrerer Schlüssel Dateien in eine unverschlüsselte ZIP-Datei ohne Ordnerstruktur

212

Parameter Beschreibung

ist auch hier ein Massen Import möglich.

Hinweis:

Werden über diese Methode X.509 Root Zertifikate importiert, so muss im Anschluss noch die korrekte Vertrauensstellung dieser

Zertifikate im Menü

X.509 Root Certificates

238

beziehungsweise

Vertrauensstellung

239

hergestellt werden.

Sektion

Establish Support Connection

Sollten auf der SEPPmail-Appliance unerwartet Probleme auftauchen, so kann mittels

Connect

eine

Support Verbindung zum Hersteller aufgebaut werden. Hierdurch wird eine SSH Verbindung (TCP

Port 22) zum SEPPmail-Supportserver aufgebaut.

213

7.9.1

Untermenü Register this device

Die Registrierungsdaten sollten sorgfältig ausgefüllt werden, da unter anderen bei CERT-Meldungen, von welchen die SEPPmail-Appliance betroffen ist, die hier genannten Kontakte bei Bedarf informiert werden.

Werden mehrere Appliances für den selben Kunden registriert, so ist darauf zu achten, dass die

Eingaben identisch gemacht werden.

Sektion

Customer Information

Eingabefeld für die Kundendaten.

Parameter Beschreibung

Company

Address 1

Pflichtfeld. Firmenname des Kunden.

Pflichtfeld. Adresse des Kunden.

Address 2

City

Optional. Zusätzliches Adressfeld.

Pflichtfeld. Stadt des Kunden.

Postal Code

Country

Pflichtfeld. Postleitzahl des Kunden.

Pflichtfeld. Land des Kunden.

First Name

Last Name

Mobile Phone

Number

Pflichtfeld. Vorname des Ansprechpartners beziehungsweise der zuständigen

Abteilung beim Kunden.

Pflichtfeld. Nachname des Ansprechpartners beziehungsweise der zuständigen

Abteilung beim Kunden.

Email Address

Pflichtfeld. E-Mail-Adresse des Ansprechpartners beziehungsweise der zuständigen

Abteilung beim Kunden.

Phone Number

Pflichtfeld. Telefonnummer in der Form "+<Ländercode> <Vorwahl ohne null"0">

<Rufnummer inklusive Durchwahl>" des Ansprechpartners beziehungsweise der zuständigen Abteilung beim Kunden.

Optional. Mobilfunknummer in der Form "+<Ländercode> <Vorwahl ohne null"0">

<Rufnummer inklusive Durchwahl>" des Ansprechpartners beziehungsweise der zuständigen Abteilung beim Kunden.

Sektion

Reseller Information

Eingabefeld für die Daten des SEPPmail-Partners

Parameter Beschreibung

Pflichtfeld. Firmenname des Partners.

Company

Address 1

Pflichtfeld. Adresse des Partners.

214

Parameter Beschreibung

Address 2

Optional. Zusätzliches Adressfeld.

City

Pflichtfeld. Stadt des Partners.

Postal Code

Pflichtfeld. Postleitzahl des Partners.

Country

Pflichtfeld. Land des Partners.

First Name

Last Name

Pflichtfeld. Vorname des Ansprechpartners beziehungsweise der zuständigen

Abteilung beim Partners.

Pflichtfeld. Nachname des Ansprechpartners beziehungsweise der zuständigen

Abteilung beim Partners.

Email Address

Pflichtfeld. E-Mail-Adresse des Ansprechpartners beziehungsweise der zuständigen

Abteilung beim Partners.

Phone Number

Pflichtfeld. Telefonnummer in der Form "+<Ländercode> <Vorwahl ohne null"0">

<Rufnummer inklusive Durchwahl>" des Ansprechpartners beziehungsweise der zuständigen Abteilung Partners.

Mobile Phone

Number

Optional. Mobilfunknummer in der Form "+<Ländercode> <Vorwahl ohne null"0">

<Rufnummer inklusive Durchwahl>" des Ansprechpartners beziehungsweise der zuständigen Abteilung Partners.

Sektion

Activation Code

Parameter Beschreibung

Enter the device ID of this virtual appliance from your license document.

Leave empty to get a test license

Ist bereits das "SEPPmail License Certificate" der Kauflizenz vorhanden, so ist die darauf befindliche "Device-ID" in dieses Feld in der Form XXXX-XXXX-XXXX einzutragen. Somit werden die erworbenen Lizenzen auf die Appliance übertragen.

Wird dieses Feld leer gelassen, so zieht die Appliance automatisch eine 30-tägige

Testlizenz.

Hinweis:

Wurde eine Testlizenz bezogen und soll diese im Anschluss in die

Produktion übernommen werden, so ist bei der Bestellung unbedingt die "Device ID" aus der Sektion

System

116

des Menüs

Home

mit anzugeben.

Hinweis:

Wurde die "Device-ID" eines "SEPPmail License Certificate" bereits einmal verwendet, so lässt sich dieses - zum Beispiel nach einer Neuinstallation - kein zweites mal Verwenden. In diesem Fall ist der Support zu kontaktieren.

Über das klicken der Schaltfläche

Send

wird der Registrierungsprozess abgeschlossen.

215

7.10 Cluster

Dieses Menü bietet die Möglichkeit mehrere Appliances zu einem Cluster zusammen zu fügen.

Das Verhalten des Clusters ist dabei stark von den vorgenommenen Systemeinstellungen (siehe unter

Anderem Menü

System

Sektionen

IP ALIAS Addresses

120

und

SMTP Loadbalancer

121

)

Maschinen, welche dem Cluster hinzugefügt werden übernehmen die Einstellungen der Basis-

Maschine. Das heisst alle eventuell bereits vorgenommenen Einstellungen werden überschrieben.

Ausgenommen vom Clustering bleiben die Menüpunkte, welche maschinenbezogene Daten enthalten, wie

System

SSL

, teilweise

Logs

und

Statistics

Sektion

Prepare for Cluster

Über die Schaltfläche

Download Cluster Identifier

wird das Zertifikat für die Herstellung der SSH

Verbindung vom zukünftigen Cluster Partner zur Basis-Maschine heruntergeladen. In der Regel heisst diese Datei "clusterid.txt". Das heisst diese Aktion wird an der Maschine vorgenommen, von welcher die Einstellungen übernommen werden sollen.

Sektion

Add this device to existing cluster

Diese Sektion erscheint nur dann, wenn die SEPPmail-Appliance nicht bereits in einem Cluster

Verbund integriert ist und dient dem Hinzufügen zu einem Cluster.

Achtung:

Alle Einstellungen, welche nicht maschinenbezogen sind (siehe Sektion

Prepare for

Cluster

215

), werden durch diese Aktion mit den Einstellungen der Basis-Maschine

überschrieben. Sollten Unsicherheiten bezüglich der Aktion bestehen, empfiehlt sich dringend zuvor ein manuelles Backup zu erstellen (siehe

Administration

Backup

210

Parameter

Cluster Identifier

Cluster Member IP

IP address of this device

Connect

Beschreibung

Über die Browserschaltfläche "Datei auswählen" wird das für die SSH

Verbindung benötigte Zertifikat der Basis-Maschine "clusterid.txt" (siehe

Sektion

Prepare for Cluster

215

) ausgewählt.

An dieser Stelle wird die physikalische IP-Adresse (kein Alias!, also virtuelle

Adresse) der Basis-Maschine über welche die Cluster Kommunikation stattfinden soll sowie der zu verwendende Port (im Standard Port 22 für das

SSH-Protokoll) angegeben.

An dieser Stelle wird die physikalische IP-Adresse (kein Alias!, also virtuelle

Adresse, siehe

System

IP ALIAS Addresses

120

) dieser Maschine über welche die Cluster Kommunikation stattfinden soll sowie der zu verwendende

Port (muss identisch mit dem unter

Cluster Member IP

eingegebenen sein) angegeben.

Über die Schaltfläche

Start

wird die Maschine dem Cluster hinzugefügt.

216

Sektion cluster members

Diese Sektion erscheint nur dann, wenn die SEPPmail-Appliance bereits Bestandteil eines Cluster ist.

In diesem Fall werden alle Clusterpartner mit den folgenden Daten gelistet:

Beschreibung Spalte

Device ID

IP Address

Port

Status

Comment

Location

Zeigt die "Device ID" des jeweiligen Cluster Partners an.

Das Entfernen eines entfernten Cluster Partners kann durch klicken auf die

"Device ID" erfolgen. Hierdurch öffnet ein weiteres Menü, in welchem dann der Server über die Schaltfläche

Remove device from cluster

entfernt werden kann. Die Datenbank bleibt mit dem zuletzt synchronisierten Stand auf dem entfernten System erhalten.

Das Entfernen der lokalen Maschine aus dem Cluster Verbund erfolgt wie in

Sektion

Remove from cluster

beschrieben.

Zeigt die "IP Adresse" des jeweiligen Cluster Partners an, welche für die

Cluster Kommunikation konfiguriert wurde.

Zeigt den Kommunikations-Port an (im Standard Port 22 für das SSH-

Protokoll)

Arbeitet der Cluster korrekt, so steht hier

" OK (XXXX entries in remote database, XXXX entries in local Database) " wobei die Anzahl "XXXX" identisch sein sollte.

Zeigt den für den Clusterpartner definierten Kommentar an (siehe

System

Comment

118

)

Zeigt den für den Clusterpartner definierten Standort an (siehe

System

Comment

118

)

Sektion

Remove from cluster

Durch klicken der Schaltfläche

remove this device from cluster

wird die Maschine aus dem

Cluster herausgenommen. Die lokale Datenbank bleibt dabei erhalten und hat den Stand der letzten

Synchronisierung im Cluster.

217

Sektion

Add this device as frontend server (no local database)

Diese Sektion erscheint nur dann, wenn die SEPPmail-Appliance nicht bereits in einem Cluster

Verbund integriert ist und dient dem Hinzufügen der Maschine als Frontend Server zu einer anderen

Maschine oder einem Cluster. Als Frontend Server wird ein Cluster Partner ohne lokale Datenbank bezeichnet.

Sollte aufgrund von Revisionsvorgaben die SEPPmail-Appliance in einer DMZ platziert werden müssen, in welcher keine Datenhaltung - in diesem Fall in erster Linie Schlüsselmaterial - erlaubt ist, so kann über diese Funktion eine Trennung zwischen dem Datenbanksystem (Backend) und dem E-

Mail verarbeitenden System (Frontend) vollzogen werden.

Der Frontend Server erhält in diesem Fall jeweils nur die diejenigen Daten vom Backend Server, welche aktuell zur Verarbeitung einer E-Mail benötigt werden. Der Backend Server steht ausserhalb der DMZ und hält die Daten in seiner Datenbank.

Frontend Server werden nicht in der Sektion

cluster members

der Backend Systeme angezeigt.

Parameter Beschreibung

Cluster Identifier

Über die Browserschaltfläche "Datei auswählen" wird das für die SSH

Verbindung benötigte Zertifikat der Basis-Maschine "clusterid.txt" (siehe

Sektion

Prepare for Cluster

215

) ausgewählt.

Existing Appliance IP

An dieser Stelle wird IP-Adresse der "Backend Maschine" über welche die

Cluster Kommunikation stattfinden soll sowie der zu verwendende Port (im

Standard Port 22 für das SSH-Protokoll) angegeben.

Existiert ein "Backend Cluster", so kann an dieser Stelle eine virtuelle IP-

Adresse (siehe

System

IP ALIAS Addresses

120

) verwendet werden. Es besteht aber auch die Möglichkeit, der "Frontend Maschine" weitere Backend

Server im Nachhinein hinzu zu fügen (siehe Sektion

Add additional Backend

218

) falls keine virtuelle IP-Adresse verfügbar ist.

Connect

Über die Schaltfläche

Start

wird die Maschine dem Cluster hinzugefügt.

Sektion

Remote LDAP Server

Diese Sektion erscheint nur dann, wenn die SEPPmail-Appliance als Frontend Server bereits

Bestandteil eines Cluster ist. In diesem Fall werden alle Backend Server mit den folgenden Daten gelistet:

Spalte

IP Address

Port

Status

Beschreibung

Zeigt die "IP Adresse" der jeweiligen LDAP-(Backend-)Maschine an.

Das Entfernen eines LDAP-(Backend-)Servers erfolgt durch klicken auf die IP-

Adresse. Hierdurch öffnet ein weiteres Menü, in welchem dann der Server

über die Schaltfläche

Remove device from cluster

entfernt werden kann.

Das Entfernen der lokalen Maschine als Frontend Server erfolgt wie in

Sektion

Detach from LDAP Server

218

beschrieben.

Zeigt den Kommunikations-Port an (im Standard Port 22 für das SSH-

Protokoll)

Arbeitet der Cluster korrekt, so steht hier

" OK (XXXX entries in remote database) "

218

Sektion

Detach from LDAP Server

Über die Schaltfläche

Detach

wird die SEPPmail-Appliance als Frontend Server entfernt. Dabei wird eine leere Lokale Datenbank auf dem System angelegt.

Sektion

Add additional Backend

Sollen mehrere Backend Server aus einem Backend Cluster für LDAP-Anfragen herangezogen werden, ohne dass eine virtuelle IP-Adresse zur Verfügung steht, so können diese über diese Option eingebunden werden.

Parameter Beschreibung

Existing Appliance IP

An dieser Stelle wird die physikalische IP-Adresse einer weiteren Backend

Maschine sowie der zu verwendende Port (im Standard Port 22 für das SSH-

Protokoll) angegeben.

Hierdurch kann ein Backend Cluster ohne Verwendung von virtuellen IP-

Adressen zur Verfügung stehen.

Connect

Über die Schaltfläche hinzugefügt.

Start

wird die zusätzliche Backend Maschine

219

7.11 Logs

Dieses Menü stellt Logs für unterschiedliche Komponenten zur Verfügung

Sektion

Other Logs

Sofern die GINA-Technologie nicht deaktiviert wurde (siehe

Mail Processing

Ruleset

Generator

Advanced Options

165

"Completely disable GINA technology") wird eine entsprechende

Log-Datei geführt, welche über die Schaltfläche

Show GINA log...

einzusehen ist.

Bei lizensiertem Protection Pack und aktiviertem Black- Greylisting (siehe

Mail System

Antispam

136

Blacklists

138

und

Manual Blacklisting / Whitelisting

138

) werden diese Vorgänge in einer entsprechenden Log-Datei geführt. Diese Log-Datei kann über die Schaltfläche

Show Blacklist /

Gereylist Log...

eingesehen werden.

Sektion

Queue Control

Sofern die E-Mail Queue nicht deaktiviert wurde (siehe

Mail Processing

Ruleset Generator

Advanced Options

165

"Run in queueless mode") werden durch SEPPmail-Appliance verarbeitete E-

Mails bei Bedarf - zum Beispiel wenn das Zielsystem temporär nicht erreichbar ist oder aufgrund eines

Greylisting Filters die E-Mail beim ersten Sendeversuch ablehnt - in einer Warteschlange zwischengespeichert. Das SEPPmail-System wird in regelmässigen Abständen versuchen die E-Mails der Warteschlange auszuliefern. Kann eine E-Mail trotz mehrmaliger Auslieferungsversuche nicht zugestellt werden, so wird der Absender darüber benachrichtigt und die E-Mail verworfen.

Der Inhalt dieser Warteschlange ist über die Schaltfläche

Show queued mails...

einzusehen. Ein erneuter Auslieferungsversuch der zwischengespeicherten E-Mails kann über die Schaltfläche

Retry to deliver queued mails...

forciert werden.

Sektion

Log Archive

In dieser Sektion wird das maillog verwaltet. Die SEPPmail-Appliance lagert dabei jeweils ab erreichen von 30 MB in Archiv-Dateien aus. Über die Schaltfläche

Download complete log

wird die aktuelle

Log-Datei sowie alle vorhandenen Archiv-Dateien in einem Stream in eine Datei (maillog.txt) heruntergeladen.

Über die Schaltfläche

Download log archive

werden lediglich alle Archive heruntergeladen. Somit können Die Archive im Anschluss von der Appliance via

Delete log archive

gelöscht werden.

Die ist zum Beispiel dann erforderlich, wenn der Speicherplatz der Log-Partition knapp wird (siehe

Home

Disk statistics

117

Logs).

Ein automatisches Löschen des maillog kann ebenfalls eingestellt werden (siehe

System

Log

Cleanup

125

Automatically delete log archives older than

days).

Sektion

Filter

Über das Eingabefeld kann ein regulärer Ausdruck (regular expression) eingegeben werden, nach welchem durch klicken der Schaltfläche

Apply...

im gesamten maillog (aktuelles sowie alle Archive) gesucht wird. Über die beiden Drop-Down Menüs kann die Suche auf einen bestimmten Zeitraum eingeschränkt werden.

Das Suchergebnis wird in der Sektion

Mail Log (last 500)

220

angezeigt.

220

Sektion

Mail Log (last 500)

Zeigt die letzten 500 maillog Einträge an.

Spalte

Nr.

Source IP

Beschreibung

Laufende Nummer der Log-Einträge. Durch klicken auf die Nummer werden Details zum Log-Eintrag angezeigt.

Quell-IP-Adresse von welcher die E-Mail eingeliefert wurde.

Date

From

Datum und Uhrzeit des Vorgangs.

Absender E-Mail-Adresse

Empfänger E-Mail-Adresse. Diese wird je Nach Status farbig angezeigt: schwarz E-Mail wurde noch nicht verarbeitet oder direkt ausgeliefert. Dieser

Status erscheint zum Beispiel auch bei als SPAM identifizierten E-Mails

(siehe

Mail Processing

Ruleset Generator

Protection Pack

grün orange rot

(Antivirus / Antispam)

162

Check incoming mails for spam and redirect spam to (leave empty to reject spam):

)

E-Mail wurde erfolgreich ausgeliefert

E-Mail konnte nicht ausgeliefert werden und wurde in der

Warteschlange bis zum nächsten Auslieferungsversuch abgelegt

E-Mail konnte nicht ausgeliefert werden und wurde zurückgewiesen.

Eine Benachrichtigungsmail über diesen Vorgang geht an den

Absender.

Message-ID

Eindeutige Kennummer der E-Mail. Mittels dieser ID kann auch auf anderen

Komponenten - zum Beispiel Groupware Server oder AntiSpam Komponente - die E-

Mail nachverfolgt werden.

Subject

Size

Betreff der E-Mail. Dieser wird nur angezeigt, wenn die Anzeige nicht ausgeblendet wurde (siehe

Mail Processing

Ruleset Generator

General Settings

"Show message subject in logs").

157

Grösse der E-Mail.

221

7.12 Statistics

In diesem Menü werden diverse Messgrössen grafisch dargestellt. Dabei wird für jede Sektion jeweils die letzten 24 Stunden (Today) die letzte Woche (Last Week) der letzte Monat (Last Month) das letzte Jahr (Last Year) die letzten drei Jahre (Last 3 Years) dargestellt.

Sektion

Throughput Visualisation

Die Grafiken dieser Sektion stellen den E-Mail Durchsatz dar.

Graph Farbe

Beschreibung grün

Zeigt die Gesamtzahl der empfangenen E-Mails an.

blau

Zeigt die Gesamtzahl der gesendeten E-Mails an.

rot

Zeigt die Gesamtzahl der verschlüsselten E-Mails an.

lila

Zeigt die Gesamtzahl der entschlüsselten E-Mails an.

Sektion

Technology Visualisation

Die Grafiken dieser Sektion stellen die Häufigkeit der verwendeten Verschlüsselungstechnologien dar.

Graph Farbe

Beschreibung blau

Zeigt die Gesamtzahl der mittels GINA Technologie verschlüsselten E-Mails an.

grün rot

Zeigt die Gesamtzahl der mittels S/MIME Technologie verschlüsselten E-Mails an.

S/MIME signierte E.Mails werden nicht dargestellt.

Zeigt die Gesamtzahl der mittels openPGP Technologie verschlüsselten E-Mails an.

lila

Zeigt die Gesamtzahl der mittels Domain Verschlüsselung verschlüsselten E-Mails an.

222

Sektion

Spam Visualisation

Die Grafiken dieser Sektion stellen die Aktionen der SPAM Abwehrmassnahmen dar, sofern das

Protection Pack (VSPP) lizensiert und aktiviert wurde.

Graph Farbe

Beschreibung rot

Zeigt die Gesamtzahl aller aufgrund des Greylistings abgewiesenen E-Mails an.

blau lila

Zeigt die Gesamtzahl der aufgrund der Realtime Blackhole List (RBL) Funktion abgewiesenen E-Mails an.

Zeigt die Gesamtzahl der aufgrund der SPAM Erkennung abgewiesenen E-Mails an.

grün

Zeigt die Gesamtzahl der empfangenen E-Mails an.

Sektion

CPU Usage Visualisation

Die Grafiken dieser Sektion stellen die Prozessorauslastung der Appliance dar.

Graph Farbe

Beschreibung grün

Zeigt die vom System verursachte Prozessor Auslastung in Prozent an.

rot

Zeigt die benutzerbezogene Prozessor Auslastung in Prozent an.

blau

Zeigt die freien Prozessor Ressourcen in Prozent an.

Sektion

Memory Usage Visualisation

Die Grafiken dieser Sektion stellen die Speicherauslastung der Appliance in Megabyte (MB) dar.

Graph Farbe

Beschreibung grün

Zeigt den aktiv in Benutzung befindlichen Speicher an.

rot

Zeigt den belegten Speicher an.

hellblau schwarz

Zeigt den belegten Auslagerungsspeicher an.

dunkelblau

Zeigt die Grösse des zur Verfügung stehenden Auslagerungsspeichers an.

Zeigt die freien Speicher Ressourcen an.

223

7.13 Users

In diesem Menü werden die auf der SEPPmail-Appliance vorhandenen Benutzer angezeigt.

Die Anlage von Benutzern kann automatisch oder manuell (siehe

Mail Processing

Ruleset

Generator

UserCreation

158

) erfolgen.

Spalte

User ID

Name

Beschreibung

Zeigt die "User ID" des jeweiligen Benutzers an.

Diese entspricht bei automatisch generierten Benutzern immer der E-Mail Adresse.

Zeigt den Namen des jeweiligen Benutzers an.

Diese entspricht bei automatisch generierten Benutzern dem Anzeigenamen des

Absenders, sofern vorhanden. Andernfalls wird auch hier die E-Mail Adresse angezeigt.

Zeigt die E-Mail Adresse des Benutzers an.

E-Mail openPGP

Zeigt die Anzahl der für den Benutzer vorhandenen openPGP Schlüssel an.

Zeigt die Anzahl der für den Benutzer vorhandenen S/MIME Schlüssel an.

S/MIME

State

Zeigt den Status des Benutzers an. Im Regelfall ist dieses Feld leer.

Bei technischen Benutzern kann der Status auf "inaktiv" gesetzt werden (siehe

Untermenü Benutzerdetails

User Data

224

Encryption Settings). Inaktive Benutzer sind nicht in der Lage zu verschlüsseln oder signieren und benötigen somit auch keine Benutzerlizenz.

Durch Klicken auf die User ID wird das Untermenü

Benutzerdetails

224

geöffnet.

Sollen Benutzer manuell eingerichtet werden, so erfolgt dies über die Schaltfläche

Create new user account...

(siehe Untermenü

Create new user account

228

Über die Schaltfläche

Password Policy

werden die Passwort Regeln für SEPPmail-Benutzer definiert (siehe Untermenü

Password Policy

229

Die Eingabefeld mit der Schaltfläche

Filter...

dient der Suche nach Benutzern.

Hinweis:

Bei Einrichten des Systems ist der Benutzer "admin" bereits vorhanden. Dieser

Benutzer benötigt keine Benutzerlizenz (Encryption/Signature License).

Es wird empfohlen, diesen Benutzer auch im weiteren Verlauf der Konfiguration nicht zu löschen, um gegebenenfalls ein "Aussperren" aus dem System zu vermeiden.

224

7.13.1 Untermenü Benutzerdetails

Sektion

User Data

Parameter Beschreibung

User ID

Full Name

Zeigt die "User ID" des jeweiligen Benutzers an.

Diese entspricht bei automatisch generierten Benutzern immer der E-Mail Adresse.

Zeigt den Namen des jeweiligen Benutzers an.

Diese entspricht bei automatisch generierten Benutzern dem Anzeigenamen des

Absenders, sofern vorhanden. Andernfalls wird auch hier die E-Mail Adresse eingesetzt.

Zeigt die E-Mail Adresse des Benutzers an.

E-Mail

Password

Encryption

Settings

Notification

Settings

Usage

Statistics

Optional kann hier einem Benutzer ein Passwort vergeben werden.

Das Passwort muss den Passwort Regeln entsprechen (siehe Untermenü

Password Policy

229

Hinweis:

Die Vergabe eines Passwortes ist für das Nutzen der Appliance nicht notwendig. Durch die Vergabe eines Passwortes wird es einem Benutzer ermöglicht, sich interaktiv an der Appliance - also der Administrationsoberfläche - anzumelden. Hierfür muss der jeweilige Benutzer zusätzlich den entsprechenden Gruppen (siehe

Groups

233

) zugeordnet werden.

May not encrypt mails

Untersagt dem Benutzer E-Mails zu verschlüsseln. Fordert der

Benutzer trotzdem Verschlüsselung an, so würde die E-Mail abgewiesen (bounced) werden.

May not sign mails Untersagt dem Benutzer E-Mails zu signieren. Fordert der

Benutzer trotzdem Verschlüsselung an, so würde die E-Mail abgewiesen (bounced) werden.

Sind beide Optionen gewählt, so wird für den Benutzer keine Userlicense in

Anspruch genommen. Dies bietet sich zum Beispiel bei technischen Benutzern an, welche keine E-Mails in das Internet versenden (zum Beispiel Backup-Benutzer).

always receives notification when recipient reads

GINA mail

An dieser Stelle kann für jeden Benutzer individuell eingestellt werden, ob er GINA Lesebestätigungen erhalten soll. Ist diese

Option bereits global in den GINA Domain Settings (siehe

Edit

GINA Settings

171

Extended Settings

Sender always

receives notification when recipient reads GINA mails) ausgewählt, so ist dieser Punkt ausgegraut.

Zeigt die Nutzungsstatistik des Benutzers an.

Last outgoing mail

Zeitpunkt der letzten ausgehenden E-Mail

S/MIME encrypted mails sent

Anzahl der versendeten E-Mails, welche mittels S/MIME-

Technologie verschlüsselt wurden

S/MIME encrypted mails received

Anzahl der empfangenen E-Mails, welche mittels S/MIME-

Technologie verschlüsselt waren

S/MIME signed

Anzahl der versendeten E-Mails, welche mittels S/MIME-

225

Parameter Beschreibung mails sent

S/MIME signed mails received

Technologie signiert wurden

Anzahl der empfangenen E-Mails, welche mittels S/MIME-

Technologie signiert waren

openPGP encrypted mails sent openPGP encrypted mails received

Webmail encrypted mails sent

Anzahl der versendeten E-Mails, welche mittels openPGP-

Technologie verschlüsselt wurden

Anzahl der empfangenen E-Mails, welche mittels -Technologie verschlüsselt waren

Anzahl der versendeten E-Mails, welche mittels GINA-

Technologie verschlüsselt wurden

Webmail encrypted mails received

Anzahl der mittels GINA-Technologie empfangenen E-Mails

S/MIME Domain encrypted mails sent

S/MIME Domain encrypted mails received openPGP Domain encrypted mails received

Anzahl der versendeten E-Mails, welche mittels S/MIME-

Technologie domänenverschlüsselt wurden

Anzahl der empfangenen E-Mails, welche mittels S/MIME-

Technologie domänenverschlüsselt waren

openPGP Domain encrypted mails sent

Anzahl der versendeten E-Mails, welche mittels openPGP-

Technologie domänenverschlüsselt wurden

Anzahl der empfangenen E-Mails, welche mittels openPGP-

Technologie domänenverschlüsselt waren

Sektion

Group Membership

In dieser Sektion werden die Gruppenzugehörigkeiten des Benutzers angezeigt (siehe auch

Groups

233

)

226

Sektion

S/MIME

Serial Certificate Authorothy Issued on Expires on

Zeigt die Seriennummern der

Zertifikate an.

Zeigt die ausstellende CA an Ausstelldatu m des Keys

TT-MM-JJJJ

Ablaufdatum des Keys

TT-MM-JJJJ

Durch Klicken des Fingerprints wird ein Untermenü mit Details zum Key geöffnet. Dieses bietet die

Möglichkeit den öffentlichen Schlüssel (Zertifikat) herunterzuladen beziehungsweise das

Schlüsselpaar zu revozieren beziehungsweise zu löschen.

Über die Schaltfläche

Import S/MIME Certificate...

kann ein bereits vorhandenes Zertifikat - zum

Beispiel ein gekauftes einer Trusted CA - importiert werden (siehe

Mail System

Untermenü "Add/

Edit Managed Domain" Untermenü

Import S/MIME Key

144

Über die Schaltfläche

Generate S/MIME Certificate...

wird durch die integrierte CA ein neues

Schlüsselpaar auf der Appliance generiert.

Ist eine MPKI eingerichtet (siehe

External CA

199

), so erscheint entsprechend der verfügbaren CA die Schaltfläche

Generate <MPKI> Certificate...

. Durch klicken dieser Schaltfläche wird ein

Schlüsselpaar generiert. Der öffentliche Schlüssel wird dabei durch die MPKI signiert und steht somit als trusted Zertifikat zur Verfügung.

Sektion openPGP

In dieser Sektion werden die openPGP Domänen-Schlüssel angezeigt, sofern vorhanden.

Key ID User ID Issued on Expires on

Zeigt die Key IDs der vorhandenen openPGP-Keys an

Zeigt die zur Key ID zugehörige

User ID an. Diese entspricht der

E-Mail-Adresse des Benutzers.

Ausstelldatu m des Keys

TT-MM-JJJJ

Ablaufdatum des Keys

TT-MM-JJJJ

Über die Schaltfläche

Import openPGP key...

kann ein bereits vorhandenes Schlüsselpaar importiert werden (siehe

Mail System

Untermenü "Add/Edit Managed Domain" Untermenü

Import openPGP Key

144

Über die Schaltfläche

Generate new openPGP key

wird ein neues Schlüsselpaar auf der

Appliance generiert. Die Laufzeit sowie das automatische Aktualisieren der so erzeugten Schlüssels entspricht der unter

Internal CA Settings

197

Validity in days

eingegebenen.

Durch Klicken der Key ID wird ein Untermenü mit Details zum Key geöffnet. Dieses bietet die

Möglichkeit den öffentlichen Schlüssel herunterzuladen beziehungsweise das Schlüsselpaar zu löschen.

227

Sektion

Remote POP3

Wurde unter

Mail System

Managed Domains

130

die Option Fetch Mail from remote POP3

server gewählt, so können die POP3 beziehungsweise IMAP Zugangsdaten für den jeweiligen

Benutzer an dieser Stelle eingegeben werden. Die SEPPmail-Appliance wird alle drei Minuten E-Mails abholen. Dabei wird POP3S beziehungsweise IMAPS präferiert.

Parameter Beschreibung

User ID

Password

Mail server

Eingabe der User ID zur Anmeldung am POP3/IMAP Konto. In der Regel entspricht die User ID der E-Mail Adresse.

Zur User ID gehöriges Passwort.

POP3 beziehungsweise IMAP Server von welchem E-Mails abgeholt werden sollen.

Sektion

Customer

Diese Sektion erscheint nur bei mandantenfähigen Systemen (siehe Menüpunkt

Customers

243

Sie ermöglicht die Zuordnung des Benutzers zu einem Mandanten.

Hinweis:

Die Zuordnung von Benutzern zu den jeweiligen Mandanten erfolgt normalerweise automatisch anhand der in der E-Mail Adresse enthaltenen E-Mail Domäne der E-

Mail Adresse. Von Änderungen ist deshalb im Normalfall abzusehen.

Eine erneute automatische Zuordnung kann über die Auswahl "Reset" angestossen werden.

Alle vorgenommenen Änderungen werden über die Schaltfläche

Save changes

gespeichert.

Das Löschen eines Users erfolgt über

Delete User

Hinweis:

Ist einem Benutzer gültiges Schlüsselmaterial zugeordnet, so muss dieses vor dem

Löschen des Benutzer gelöscht werden. Andernfalls erscheint zunächst eine entsprechende Warnmeldung.

228

7.13.2 Untermenü Create new user account

Sektion

User Data

Parameter Beschreibung

User ID

Eingabe einer Eindeutigen "User ID" für den neuen Benutzer.

Es empfiehlt sich - wie bei automatisch generierten Benutzern - auch an dieser

Stelle die E-Mail Adresse zu verwenden, da hierdurch die Eindeutigkeit gewährleistet wird.

Hinweis:

Diese Eingabe kann in den

Benutzerdetails

224

nicht mehr geändert werden.

Full Name

E-Mail

Zeigt den Namen des jeweiligen Benutzers an.

Diese entspricht bei automatisch generierten Benutzern immer der E-Mail Adresse.

Zeigt die E-Mail Adresse des Benutzers an.

Hinweis:

Diese Eingabe kann in den

Benutzerdetails

224

nicht mehr geändert werden.

Password

Optional kann hier einem Benutzer ein Passwort vergeben werden.

Das Passwort muss den Passwort Regeln entsprechen (siehe Untermenü

Password Policy

229

Hinweis:

Groups

233

) zugeordnet werden.

Über die Schaltfläche

Create account

wird der Benutzer angelegt und kann im Anschluss weiter bearbeitet werden (siehe Untermenü

Benutzerdetails

224

Cancel

bricht den Vorgang ab.

229

7.13.3 Untermenü Password Policy

Sektion

Password Settings for system (not GINA) accounts

Die Vergabe eines Passwortes ist ausschliesslich für die Anmeldung an der Administrationsoberfläche notwendig. Die Berechtigungen für Benutzer mit Passwort wird über die Gruppenzugehörigkeit

geregelt (siehe

Groups

233

Das heisst die hier definierten Passwort Regeln sind für die interaktive Anmeldung an der

Administrationsoberfläche gültig.

Parameter Beschreibung

Minimum password length:

Must contain at least one lower case letter

Must contain at least one upper case letter

Must contain at least one number

Must contain at least one special character

Must not contain own name, user name or email address

Auswahl der minimalen Passwort Länge (4 bis 16 Zeichen).

Definiert, ob ein Kleinbuchstabe im Passwort enthalten sein muss.

Definiert, ob ein Grossbuchstabe im Passwort enthalten sein muss.

Definiert, ob eine Ziffer im Passwort enthalten sein muss.

Definiert, ob ein Sonderzeichen im Passwort enthalten sein muss.

Definiert, ob das Passwort den eigenen Namen oder E-Mail Adresse enthalten darf.

Must be different from previous

password(s)

Definiert, mit wie vielen vorangegangenen Passwörter bei einem

Passwortwechsel keine Übereinstimmung bestehen darf (1 bis 28).

Must be changed at least every

days

Definiert, ob und nach wie vielen Tagen das Passwort geändert werden muss.

Accounts are locked for

minutes after

failed login attempts.

Definiert, nach wie vielen fehlgeschlagenen Fehlversuchen bei der

Anmeldung (falsche Passworteingabe) für wie lange (in Minuten) der

Zugang gesperrt wird.

Über die Schaltfläche

Save

werden die angezeigten Einstellungen gesichert.

Mittels

Back

wird das Menü ohne Sicherung verlassen.

230

7.14 GINA Accounts

In diesem Menü werden die auf der SEPPmail-Appliance vorhandenen GINA-Benutzer angezeigt.

Handelt es sich um ein mandantenfähiges System, so sind die Benutzer entsprechend der Mandanten aufgeteilt.

Spalte Beschreibung

E-mail

Account status

Die E-Mail Adresse gewährleistet bei SEPPmail-Benutzern die

Eindeutigkeit.

Zeigt den Status des jeweiligen Benutzers an. Mögliche Status sind:

enabled

Soll-Zustand

enabled (unregistered user)

Benutzer welcher nach Erhalt der initialen GINA-E-Mail den

Registrierungsprozess noch nicht abgeschlossen hat.

locked temporarely

Gesperrter Benutzer. Nahere Details hierzu zeigt der

Last message status

locked temporarely (unregistered user)

Benutzer welcher nach Erhalt der initialen GINA-E-Mail noch vor dem erfolgreichen Abschliessen des Registrierungsprozesses gesperrt wurde.

Nahere Details hierzu zeigt der

Last message status

Zeigt Informationen zur letzten Aktion des Benutzers an. Mögliche Status sind:

Last succesful login MMM TT, JJJJ hh:mm:ss

Gibt Datum und Uhrzeit der letzten erfolgreichen Anmeldung an.

X unsuccessful login attempts

Gibt die Anzahl der fehlgeschlagenen Anmeldeversuche an.

Durch Klicken auf die E-mail-Adresse wird ein Untermenü mit Details zum jeweiligen GINA-Benutzer geöffnet (siehe Untermenü

GINA-Benutzer-Details

231

Sollen Benutzer manuell eingerichtet werden, so erfolgt dies über die Schaltfläche

Create new user account...

(siehe Untermenü

Create new user account

228

Die Eingabefeld mit der Schaltfläche

Filter...

dient der Suche nach GINA-Benutzern.

7.14.1 Untermenü Benutzer-Details

Sektion

User Data

In diesem Untermenü werden Detailinformationen zum GINA-Benutzer angezeigt. Weiterhin dient diese Menü manuellen Passwort Rücksetzungen, zum Beispiel durch den Support (siehe

Edit GINA

Settings

170

Admin

Parameter Beschreibung

Creation Info

Name

E-Mail

Password reminder

Answer

Password

Must Change

Password

Zip Attachement

Zeigt wer gegebenenfalls die initiale GINA-E-Mail gesendet und somit den

Benutzer generiert hat (Anzeige der E-Mail-Adresse bei unregistrierten, beziehungsweise "Created by..." bei bereits registrierten Benutzern) ob es sich um einen selbstregistrierten Benutzer handelt (Account...)

Hat sich der Benutzer registriert, so wird hier der von ihm bei der

Registrierung eingetragene Name angezeigt.

Zeigt die E-Mail Adresse des Benutzers an.

es sind zwei Status möglich:

(Hidden) bei registrierten Benutzern

Not set bei unregistrierten Benutzern (Account Status "...

(unregistered user) ") es sind zwei Status möglich:

(Hidden) bei registrierten Benutzern

Not set bei unregistrierten Benutzern (Account Status "...

(unregistered user) ")

Eingabefelder für das manuelle Rücksetzen des Passwortes durch einen

Administrator

Legt fest, ob der Benutzer nach einem manuellen Rücksetzen des Passwortes dieses beim nächsten Anmelden ändern muss.

Legt individuell für den Benutzer fest, ob dieser den Anhang des GINA-E-Mails statt im HTML- im ZIP-Format erhält.

Account status

External

Authentication

locked

enabled

Zeigt an ob der Benutzer gesperrt ist (zum Beispiel nach mehrfacher falscheingabe des Passwortes) beziehungsweise kann der Administrator den Benutzer durch Aktivieren des

Buttons sperren.

Zeigt an ob der Benutzer aktiv ist beziehungsweise kann der

Administrator den Benutzer durch Aktivieren des Buttons wieder in den Staus "Aktiv".

Exclude this account from external authentication

Ist die externe LDAP Authentisierung aktiviert (siehe auch

Add/Edit

Managed Domain

140

External Authentication

) so kann diese durch

Anhaken dieser Option für einzelne Accounts ausgehebelt werden.

Diese Option ist nur bei intern - das heisst der Managed Domain welcher auch das entsprechende GINA-Interface zugeordnet ist - zugeordneten

Benutzern zu sehen.

231

232

Parameter

Password Security

Level

Mobile number

Beschreibung

Benutzer individuelle Einstellung für das Rücksetzverfahren des Passwortes.

Diese Einstellung überschreibt die globale Einstellung unter

Edit GINA

Settings

177

Security

Mobilfunknummer für das Zurücksetzen des Passwortes via SMS.

Sektion

User Logs

Durch klicken der Schaltfläche

Show user logs

wird ein detailliertes Log bezüglich der aktivitäten des jeweiligen GINA-Benutzers angezeigt.

Alle vorgenommenen Änderungen werden über die Schaltfläche

Save changes

gespeichert.

Das Löschen eines GINA-Benutzers erfolgt über

Delete Account

Hinweis:

Durch das Löschen eines GINA-Benutzers wird auch dessen Schlüssel unwiderruflich gelöscht. Somit kann er eventuell noch in seinem Postfach befindliche

GINA-E-Mails nicht mehr lesen. Der Inhalt dieser E-Mails ist somit verloren!

233

7.15 Groups

In diesem Menü sind bereits administrative Benutzergruppen vorgegeben (siehe Tabelle). Diese dienen der Wirkungsmöglichkeiten einzelner Benutzer bei interaktiver Anmeldung an der

Administrationsoberfläche (siehe auch

Benutzerdetails

224

User Data

Password

)

Weiterhin besteht über die Schaltfläche

Create new user group...

weitere Gruppen zur

Verwendung im Ruleset (siehe

Mail Processing

Ruleset Generator

Custom Commands

164

) zu erzeugen.

Über die Schaltfläche

Edit...

kann die jeweilige Gruppe editiert (Gruppen Name und Beschreibung) sowie Benutzer zugeordnet werden.

Gruppe Beschreibung admin

(Administrator) administrationadmin

(GUI Access to

Administration Section) backup

(Backup Operator ) caadmin

(GUI Access to CA

Section) clusteradmin

(GUI Access to Cluster

Section) domainkeysadmin

(GUI Access to Domain

Keys Section) groupsadmin

(GUI Access to Groups

Section) homeadmin

(GUI Access to Home

Alle Mitglieder dieser Gruppe sind dem Standardbenutzer admin gleichgestellt und haben uneingeschränkten administrativen Zugang zur Konfigurationsoberfläche mit allen Berechtigungen.

Weiterhin erhalten Mitglieder dieser Gruppe die mit "IMPORTANT" gekennzeichneten "Daily Reports" (siehe auch "statisticsadmin") zugesandt.

Hinweis:

Sollten administrative Aufgaben anfallen, so werden die Mitglieder dieser Gruppe darüber informiert.

Somit sollte der Administrator der SEPPmail-

Appliance unbedingt Mitglied dieser Gruppe sein.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

Administration

in der Konfigurationsoberfläche.

Dieser Gruppe ist eine Sonderbedeutung zugeordnet. Sie unterscheidet sich von den Systemgruppen für den Zugriff auf die

Konfigurationsoberfläche dadurch, dass kein Zugriff auf die

Konfigurationsoberfläche erfolgt. Alle Mitglieder dieser Gruppe erhalten das Systembackup des jeweiligen Systems einmal täglich via

E-Mail. Das Systembackup wird täglich um 0.00 Uhr erzeugt und via

E-Mail an alle Mitglieder dieser Gruppe gesendet.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

in der

Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

Cluster

in der Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

Domain keys

in der Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

Groups

in der Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

Home

in der Konfigurationsoberfläche.

234

Gruppe Beschreibung

Section) logsadmin

(GUI Access to Logs

Section) mailprocessingadmin

(GUI Access to Mail

Processing Section) mailsystemadmin

(GUI Access to Mail

System Section) multiplecustomersadmin

(Admin access to

Customer settings in multitenant deployments) openpgpkeysadmin

(GUI Access to openPGP

Keys Section) readonlyadmin

(Read-only GUI Access to all sections) ssladmin

(GUI Access to SSL

Section) statisticsadmin

(GUI Access to Statistics

Section)

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü der Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

Processing

in der Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

System

in der Konfigurationsoberfläche.

Mail

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü Customers in der Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

openPGP public keys

in der Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben ausschliesslich lesenden Zugriff auf alle Menüs der Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

Konfigurationsoberfläche.

Logs

Mail

SSL

in der

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

Statistics

in der Konfigurationsoberfläche. Zusätzlich erhalten alle Mitglieder dieser Gruppe einen täglichen System-Report (Daily Report) des jeweiligen Systems. Der System-Report wird täglich um 0.00 Uhr erzeugt und via E-Mail an alle Mitglieder dieser Gruppe gesendet.

systemadmin

(GUI Access to System

Section) usersadmin

(GUI Access to Users

Section) webmailaccountsadmin

(GUI Access to Webmail

Accounts Section) x509certificatesadmin

(GUI Access to X.509

Certificates Section)

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü der Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

accounts

in der Konfigurationsoberfläche.

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

Certificates

in der Konfigurationsoberfläche.

System

Users

Webmail

X.509

x509rootcertificatesadmin

(GUI Access to X.509 Root

Certificates Section)

Alle Mitglieder dieser Gruppe haben Zugriff auf das Menü

X.509

Root Certificates

in der Konfigurationsoberfläche.

235

7.16 LFM accounts

In diesem Menü werden die auf der SEPPmail-Appliance vorhandenen LFM-Benutzer angezeigt.

Handelt es sich um ein mandantenfähiges System, so sind die Benutzer entsprechend der Mandanten aufgeteilt.

Spalte Beschreibung

E-Mail Adresse desLFM-Benutzers.

E-mail

Account status

Zeigt den Status des jeweiligen Benutzers an. Mögliche Status sind:

inactive

Interne Benutzer welche mehr als vier Wochen keine LFM-Mail versendet haben werden in den Status "inactive" versetzt. Hierdurch wird die bis dahin belegte LFM-Lizenz wieder frei.

active

Interne Benutzer mit aktiver LFM-Lizenz.

Account last used

Zeigt an, wann der LFM Benutzer zuletzt eine grosse Datei versendet hat. Bei aktiven Benutzern lässt sich daraus schliessen, wann dieser auf inaktiv gesetzt wird und somit die Lizenz frei gibt, sofern in der Zwischenzeit nicht eine weitere grosse Datei durch ihn versendet wird.

236

7.17 OpenPGP public keys

Sektion

Local openPGP Keys

In dieser Sektion werden die der Appliance bekannten öffentlichen openPGP Schlüssel von

Kommunikationspartnern angezeigt.

Key ID E-mail addresses User Name Issued on Expires on

Zeigt die Key IDs der vorhandenen openPGP-Keys an

Zeigt die dem

Schlüssel zueordnete/n E-Mail

Adresse/n

Zeigt die zur Key ID zugehörige User ID an. Diese entspricht der E-Mail-Adresse des Benutzers.

Ausstelldatu m des Keys

TT-MM-JJJJ

Ablaufdatum des Keys

TT-MM-JJJJ

Durch Klicken der Key ID wird ein Untermenü mit Details zum Key geöffnet. Dieses bietet die

Möglichkeit den öffentlichen Schlüssel herunterzuladen beziehungsweise das Schlüsselpaar zu löschen.

Das Eingabefeld mit der Schaltfläche

Filter...

dient der Suche nach nach entsprechenden Schlüsseln anhand einer der in der Tabelle aufgeführten Merkmale.

Über die Schaltfläche

Import openPGP key...

kann ein vorhandener Schlüssel eines

Kommunikationspartners - nach Prüfung (Hash) - importiert werden. Im Anschluss steht dieser

Schlüssel für das Verschlüsseln bereit.

237

7.18 X.509 Certificates

In diesem Menü werden die für die S/MIME Verschlüsselung zur Verfügung stehenden Zertifikate wie folgt angezeigt.

Spalte

E-mail Address

Beschreibung

Zeigt E-Mail Adresse (RFC822 Name) des Schlüsselinhabers an.

Certificate Subject

Zeigt das X.509 Subject an.

Serial Number

Seriennummer des Zertifikats.

Fingerprint

Zeigt den Fingerprint (Hash) des Zertifikates an.

Validity

Gibt die Gültigkeit des Zertifikates an. Mögliche Status sind

"keiner", was mit "OK" gleichzusetzen ist

REVOKED

EXPIRED .

OCSP/CRL check

Ergebnis der OCSP/CRL Prüfung. Mögliche Status sind

uncheckable uncheckable (no supported CRL / OCSP mechanism) revoked

Issued on

Ausstelldatum des Zertifikats in der Form TT-MM-JJJJ

Expires on

Ablaufdatum des Zertifikats in der Form TT-MM-JJJJ

Durch Klicken auf die E-Mail Adresse werden Details zum Zertifikat - wie auch Details zum

Revokations Staus - angezeigt. Dieses bietet die Möglichkeit den öffentlichen Schlüssel (Zertifikat) herunterzuladen beziehungsweise das Schlüsselpaar zu löschen.

Das Eingabefeld mit der Schaltfläche

Filter...

dient der Suche nach nach entsprechenden Zertifikaten anhand einer der in der Tabelle aufgeführten Merkmale.

Über die Schaltfläche

Import S/MIME Certificate...

kann ein vorhandenes Zertifikat eines

Kommunikationspartners importiert werden. Im Anschluss steht dieses Zertifikat für das Verschlüsseln bereit - auch wenn die Zertifikatskette nicht geprüft werden kann (siehe auch

X.509 Root Certificates

238

). In der Regel werden die Zertifikate von Kommunikationspartnern aus deren E-Mail Signaturen automatisch eingesammelt. Dies funktioniert allerdings nur dann, wenn der Aussteller des Zertifikates

bei den

X.509 Root Certificates

238

eingetragen ist und eine entsprechende Vertrauensstellung

(Trusted) vorhanden ist. Das heisst die Zertifikatskette muss für die SEPPmail-Appliance nachvollziehbar sein.

Die Schaltfläche

Clean up duplicate certificates...

entfernt eventuell doppelt vorhandenen

Zertifikate.

Über die Schaltfläche

Delete expired certificates...

werden alle Zertifikate von dr Appliance entfernt, bei welchen das "Expires on" Datum überschritten ist. Damit wird bei Bedarf auch gewährleistet, dass diese Zertifikate nicht mehr für die Verschlüsselung verwendet werden. Im

Standard verwendet die Appliance auch abgelaufene Zertifikate, natürlich nur wenn kein aktuelles zur

Verfügung steht.

238

Hinweis:

Stehen für einen Empfänger mehrere, gültige Zertifikate zur Verfügung, so wird der Session Key mit jedem dieser Zertifikate verschlüsselt.

Verwendet der Empfänger zum Beispiel mehrere Hardware Clients, auf welchen jeweils unterschiedliche (private) Schlüssel bereit stehen, so wird hierdurch gewährleistet, dass die E-Mail auf allen Clients gelesen werden kann, sofern natürlich deren zugehörige öffentliche Schlüssel auf der Appliance bekannt sind.

Abgelaufene Zertifikate werden nur dann verwendet, wenn kein aktuelles

Zertifikat für das Verschlüsseln zur Verfügung steht.

7.19 X.509 Root Certificates

In diesem Menü wird die Vertrauensstellung zu den einzelnen Zertifizierungsstellen (CA) verwaltet.

Root Zertifikate welche nicht bekannt sind werden aus signierten E-Mails eingesammelt und mit dem

Status "?" (unbekannt) gespeichert. Eine Einstufung dieser Zertifizierungsstellen muss durch den

Administrator vorgenommen werden. Somit wächst das System dynamisch.

Angezeigt werden die Root Zertifikate wie folgt.

Spalte

Trust State

Issued to

Issued by

Issued on

Expires on

Fingerprint

Beschreibung

Zeigt die Vertrauensstellung an. Mögliche Status sind

"trusted" (vertrauenswürdig), "untrusted" (nicht vertrauenswürdig) und

"?" (unbekannt). Bei unbekanntem Status ist ein Eingreifen des

Adminstrators erforderlich. Dieser muss entscheiden, ob der CA vertraut werden soll oder nicht. Sind Zertifikate mit dem Status "?" vorhanden, so werden diese dem Administrator (siehe Menü

Groups

233

) im täglichen

Report gemeldet.

Durch Klicken auf den Vertrauensstatus des Zertifikates können Details eingesehen und die Vertrauensstellung angepasst werden (siehe Untermenü

Vertrauensstellung

239

)

Zeigt an, für wen das Zertifikat ausgestellt wurde.

Zeigt an, von wem das Zertifikat ausgestellt wurde.

Ausstelldatum des Zertifikats in der Form TT-MM-JJJJ

Ablaufdatum des Zertifikats in der Form TT-MM-JJJJ

Zeigt den Fingerprint (Hash) des Zertifikates an.

Das Eingabefeld mit der Schaltfläche

Filter...

dient der Suche nach nach entsprechenden Zertifikaten anhand einer der in der Tabelle aufgeführten Merkmale.

Über die Schaltfläche

Import S/MIME Root Certificate...

kann ein vorhandenes Zertifikat einer

Zertifizierungsstelle einzeln importiert werden. Hier können zum Beispiel auch Root Zertifikate einer

Self-Signed-CA eines vertrauenswürdigen Kommunikationspartners eingetragen werden. Somit werden auch dessen Self-Signed Zertifikate als vertrauenswürdig eingestuft.

239

7.19.1 Untermenü Vertrauensstellung

Sektion

Issued To

Diese Sektion zeigt Informationen über den Inhaber des CA-Zertifikates.

Abhängig vom Zertifikat müssen nicht alle hier aufgeführten Parameter vorhanden sein.

Parameter

Name (CN)

E-Mail Address

Org. Unit (OU)

Organization (O)

Locality (L)

State (ST)

Country (C)

Serial No.

Beschreibung

Gibt den Namen der eigenen CA an

In der Regel der wird die E-Mail-Adresse des Verwalters der eigenen CA oder dessen Abteilung eingetragen.

Organisationseinheit wie zum Beispiel ein Abteilungsname wie "Sicherheit"

Gibt die Organisation an, für welche das Zertifikat ausgestellt wurde, zum

Beispiel "Firma"

Standort zum Beispiel eine Stadt wie "Neuenhof"

Bundesland, Kanton, Provinz oder Ähnliches, zum Beispiel "AR" für

"Appenzell Ausserrhoden"

Land, zum Beispiel "CH" für "Schweiz"

Seriennummer des Zertifikats

Sektion

Issued By

Diese Sektion zeigt Informationen über den Aussteller des CA-Zertifikates (Root-Zertifikat).

Abhängig vom Aussteller müssen nicht alle hier aufgeführten Parameter vorhanden sein.

Parameter

Name (CN)

E-Mail Address

Org. Unit (OU)

Organization (O)

Locality (L)

State (ST)

Country (C)

Beschreibung

Name der ausstellenden CA

In der Regel eine E-Mail-Adresse für Supportanfragen an den Aussteller

Gibt eine Organisationseinheit des Ausstellers an

Gibt die ausstellende Organisation an

Gibt den Standort des Ausstellers an

Gibt ein Bundesland, Kanton, Provinz oder Ähnliches des Ausstellers an

Gibt das Land des Ausstellers an

240

Sektion

Validity

Gibt die Gültigkeit des eigenen CA-Zertifikates an.

Parameter

Issued on

Expires on

Beschreibung

Ausstelldatum des Zertifikates

Ablaufdatum des Zertifikates

Sektion

Fingerprint

Gibt den Hash des eigenen CA-Zertifikates an.

Parameter Beschreibung

Hashalgorhytmus des Zertifikates, zum Beispiel SHA1

Der Fingerprint dient zur Überprüfung eines Zertifikats. Beispiel eines SHA1

Fingerprints:

48:2D:99:B1:64:C1:14:9C:B3:F2:C0:8D:FA:7F:40:9F:22:F5:11:F5

Sektion

Comment

An dieser Stelle kann ein persönlicher Kommentar zum Zertifikat eingegeben werden, zum Beispiel weshalb die entsprechende Vertrauensstellung gewählt wurde.

Mit

Save Comment

wird dieser Kommentar gespeichert.

Über die Schaltfläche

Download Certificate

besteht die Möglichkeit das Zertifikat im CRT-Format zu speichern.

Je nach Vertrauensstellung wird die Schaltfläche

Trust this certificate

, über welche dem Zertifikat das Vertrauen bestätigt wird oder

Untrust this Certificate

, durch welche das Vertrauen abgelehnt wird, vorhanden.

Über

Delete Certificate

wird das Zertifikat von der SEPPmail-Appliance gelöscht. Wird im

Anschluss eine E-Mail empfangen, welche mit einem Schlüssel dieser Zertifizierungsstelle signiert wurde, so wird das Zertifikat wieder mit dem Truststatus "?" in der Appliance gespeichert.

241

7.20 Domain Certificates

Domänen Zertifikate werden für die Domänenverschlüsselung, also die E-Mail Verschlüsselung zwischen zwei Appliances benötigt. Da die Zertifikate in der Regel direkt durch die Administratoren ausgetauscht werden, reichen an dieser Stelle im Normalfall Self-Signed Zertifikate aus.

Aufgeführt sind hier die öffentlichen Schlüssel der Kommunikationspartner, zu denen

Domänenverschlüsselt werden soll. Die Schlüssel zu den intern in der SEPPmail-Appliance verwalteten E-Mail Domänen sind unter

Add/Edit Managed Domain

141

je nach

Verschlüsselungstechnologie in der Sektion

openPGP Domain Encryption

141

oder

S/MIME Domain

Encryption

142

zu finden. Die öffentlichen Schlüssel für diese Domänen können je nach GINA-

Konfiguration vom Kommunikationspartner auch über das GINA-Web-Portal auf sicherem Wege heruntergeladen werden (siehe

Edit GINA Settings

171

Extended Settings

Enable S/MIME

certificate / openPGP key search and management in GINA).

Sektion

openPGP Domain Keys

Zeigt die Schlüssel aller E-Mail Domänen an, zu denen hin mittels openPGP verschlüsselt wird.

Diesen Domänen sollte im Gegenzug der öffentliche openPGP Key der durch diese SEPPmail-

Appliance verwalteten E-Mail Domäne(n) bekannt sein.

Mail Domain

Gibt die E-Mail Domäne an, für welche der Schlüssel gültig ist.

Durch klicken auf die Domäne werden Details zum Schlüssel angezeigt. Ebenso wird die hierdurch die Möglichkeit geboten, den Key im ASC-

Format zu speichern oder zu löschen.

Key ID Issued on Expires on

Zeigt die Key IDs der vorhandenen openPGP-Keys an

Ausstelldatu m des Keys

TT-MM-JJJJ

Ablaufdatum des Keys

TT-MM-JJJJ

Über die Schaltfläche Import

Import openPGP Key...

besteht die Möglichkeit Schlüssel weiterer

Kommunikationspartner (E-Mail Domänen) aufzunehmen.

242

Sektion

SMIME Domain Certificates

Zeigt die Zertifikate aller E-Mail Domänen an, zu denen hin mittels S/MIME verschlüsselt wird. Diesen

Domänen sollte im Gegenzug das S/MIME Zertifikatder durch diese SEPPmail-Appliance verwalteten

E-Mail Domäne(n) bekannt sein.

Spalte

Mail Domain

Beschreibung

Zeigt E-Mail Adresse (RFC822 Name) des Schlüsselinhabers an.

(Pseudo-)E-Mail Adresse für die Domänenverschlüsselung

E-mail Address

Serial Number

Seriennummer des Zertifikats.

Ausstelldatum des Zertifikats in der Form TT-MM-JJJJ

Issued on

Expires on

Ablaufdatum des Zertifikats in der Form TT-MM-JJJJ

Über die Schaltfläche Import

Import S/MIME Certificate...

besteht die Möglichkeit, Zertifikate weiterer Kommunikationspartner (E-Mail Domänen) aufzunehmen. Um Fehlerquellen auszuschliessen, sollte darauf geachtet werden, dass die Domainzertifikate dem Standard RFC 3183 ( https://tools.ietf.org/html/rfc3183 ) entsprechen.

Sektion

Managed Domain Certificates

Da SEPPmail-Appliances im Standard (siehe

Mail System

Managed Domains

130

"Automatically

create and publish S/MIME domain keys for all domains") am sogenannten "Managed Domain

Service" teilnehmen, findet zwischen SEPPmail-Appliances immer eine Domänenverschlüsselung statt, ohne explizit Schlüsselmaterial austauschen zu müssen. Dies geschieht automatisch über den

SEPPmail-Key Server.

Das automatische Herunterladen der öffentlichen Schlüssel anderer Appliances erfolgt dabei über die

Option "Auto-Update SMIME Domain Certificates". Im Bedarfsfall (zum Beispiel bei Hinzukommen eines neuen, bekannten Kommunikationspartners) kann ein sofortiges Herunterladen neu hinzugekommenr Schlüssel über die Schaltfläche

Update Domain Certificates...

forciert werden.

Die Anzahl der über diesen Dienst verfügenden E-Mail Domänen wird im Text darunter angegeben.

Um festzustellen, ob ein Kommunikationspartner ebenfalls am SEPPmail-Managed-Domain-Service teilnimmt, bietet das Eingabefeld mit der Schaltfläche

Search Domain Certificate...

eine entsprechende Möglichkeit nach dem E-Mail Domänennamen zu suchen.

Die Domänen, zu welchen in den letzten drei Monaten über den Managed Domain Service verschlüsselt kommuniziert wurde werden in der Tabelle dieser Sektion aufgeführt.

Hinweis:

Die Domänenverschlüsselung ist bei der SEPPmail-Appliance bereits in der Basis-

Lizenz enthalten. Das heisst diese wird auch für Absender verwendet, welche über kein Benutzerkonto (siehe

Users

223

) verfügen, ohne Mehrkosten zu produzieren.

243

7.21 Customers

Ist eine Multitenancy Lizenz vorhanden, so lässt sich in diesem Menü die Mandantenfähigkeit des

Systems aktivieren, beziehungsweise die Mandanten verwalten.

Sektion

Multiple Customers

Über die Schaltfläche

Enable

lässt sich die Mandantenfähigkeit aktivieren. Sollte diese bereits aktiv sein, so bietet sich die Möglichkeit über das DropDown-Menü einen Mandanten auszuwählen und über die Schaltfläche

Delete...

zu löschen oder über

Edit...

zu bearbeiten. Weiter bietet die Schaltfläche

Create new customer...

die Möglichkeit einen neuen Mandanten anzulegen.

Dabei existieren nach Anschalten der Mandantenfähigkeit bereits zwei Standard Customers ("No

Customer" und "Default Customer"), welche für die interne Verwaltung benötigt werden und keinesfalls gelöscht werden dürfen.

Wird bei einer bereits bestehenden Installation mit bereits vorhandenen GINA-Accounts nachträglich die Mandantenfähigkeit aktiviert, so werden diese Accounts zunächst dem "Default Customer" zugeordnet. Um das nachträgliche zuordnen der Accounts zum richtigen Mandanten zu erleichtern, wird angezeigt, aus welcher Managed Domain der Account erzeugt wurde.

Der "No Customer" bietet die Möglichkeit, einzelne Accounts - gegebenenfalls temporär - komplett aus der Mandantenfähigkeit auszuschliessen.

Ist bei einem nachträglichen Anschalten der Mandantenfähigkeit das sofortige zuordnen zu einem

Mandanten aus dem "Default Customer" heraus nicht erwünscht - wenn der Account zum Beispiel einem später noch einzuirichtenden Mandanten zugeordnet werden soll - so kann dieser im "No

Customer" quasi "zwischengeparkt" werden.

Sektion

Notes

Für einen Mandanten muss immer ein eigenes GINA-Interface angelegt werden (siehe gegebenenfalls

Create new GINA Domain

169

). Sollte der Mandant mehrere "Managed Domains" inne haben, so kann all diesen das gleiche GINA-Interface zugeordnet (siehe

Mail System

Managed

Domains

130

GINA Settings) werden.

Achtung:

Keinesfalls darf ein GINA-Interface für mehrere Mandanten verwendet werden!

Das Verwenden eines GINA-Interface für mehrere E-Mail Domänen eines einzigen

Mandaten ist hingegen problemlos möglich.

Externe Empfänger welche mit mehreren Mandanten mittels GINA kommunizieren, erhalten für jeden

Mandanten ein eigenes GINA-Konto, mit den daraus resultierenden Einschränkungen (siehe

Edit

GINA Settings

171

Extended settings

Öffentliche Schlüssel (siehe

openPGP public keys

236

und

X.509 Certificates

237

) stehen grundsätzlich allen Mandanten für die Verschlüsselung zur Verfügung.

244

7.21.1 Untermenü Create new / Edit Settings for customer

Dieses Menü dient der Anlage neuer beziehungsweise der Verwaltung bereits vorhandener

Mandanten auf dem SEPPmail-System.

Die Anlage neuer Mandanten kann manuell, oder durch den Import eines bereits bestehenden

Mandanten Backup (zum Beispiel für den Umzug eines Mandanten auf eine andere Maschine) erfolgen.

Sektion

Customer details

Diese Sektion enthält Informationen zum Mandanten und verhält sich je nach Modus - "Create" oder

"Edit" - unterschiedlich.

Parameter Beschreibung

Customer

Eingabe des System-Namens für einen neuen Mandanten. Die Eingabe ist nur bei der Neuanlage möglich. Im Editier-Modus wird der Name lediglich angezeigt.

Anzeige-Name des Mandanten.

Customer Name

Customer Admin E-mail

E-Mail Adresse des Mandanten-Admin, welcher die Mandanten spezifischen

Systemmeldungen erhalten soll. Dieser User erhält täglich automatisiert auch das Customer Backup.

Comment

Optionaler, frei wählbarer Kommentar.

Creation info

Systeminformationen zur Erzeugung des Mandanten. Dieses Feld ist erst nach dem Erzeugen des Mandanten, also im Editier-Modus zu sehen.

Im "Create"-Modus wird der Benutzer mittels Schaltfläche

Create

mit den angegebenen Daten angelegt. Das System wechselt sodann in den Editier-Modus.

Im Editier-Modus werden vorgenommene Änderungen über die Schaltfläche

Change

übernommen.

Sektion

Import Backup

Diese Sektion erscheint nur im "Create"-Modus und dient der Anlage neuer Mandanten durch den

Import eines bereits bestehenden Mandanten Backups (zum Beispiel für den Umzug eines Mandanten auf eine andere Maschine) erfolgen.

Die vorhandene Backup Datei wird über die Schaltfläche

Import Backup File ...

eingespielt.

Alle folgenden Menüs sind nur im Editier-Modus zu sehen.

245

Sektion

Customer administrators

Dient der Verwaltung von Mandanten-Admins. Mandanten Admins sind in der Lage sich interaktiv am

System anzumelden und sehen die für sie relevanten Menüs

Login

114

Mail Processing

149

Logs

219

, und optional bei aktivierter Option

LFM accounts

235

. Dabei beschränkt sich die Anzeige in den

Menüs ausschliesslich auf die Daten des jeweiligen Mandanten.

Bereits zugeordnete Mandanten-Admins sind in der folgenden Tabelle zu sehen und können dort verwaltet werden.

User ID

Zeigt die Benutzer ID des jeweiligen Administrators, wie

sie unter

Users

223

angezeigt wird.

E-Mail

Zeigt die E-Mail Adresse des jeweiligen Administrators, wie sie unter

Users

223

angezeigt wird.

Remove from this customer

Beinhaltet die Schaltfläche

Remove

zum Entfernen des jeweiligen Mandantenadmins.

Die weitere Tabelle der Sektion dient dem Zuordnen weiterer Mandanten-Admins.

Name Assign to this customer

Beherbergt das DropDown Menü zur Auswahl des Benutzers, der als Mandanten-Admin zugeordnet werden soll.

Über die Schaltfläche

Assign

wird der unter

Name ausgewählte Benutzer als Mandanten-

Admin hinzugefügt.

Hinweis:

Mandanten-Admins müssen über ein Passwort verfügen (siehe Benutzerdetails

User

Data

224

Password

), damit das Anmelden am System möglich ist!

Sektion

Assigned managed domains

In dieser Sektion werden die dem Mandanten zugeordneten "Managed Domains" angezeigt. Die

Zuordnung von "Managed Domains" zum Mandanten erfolgt in der Regel bereits bei der Anlage über

das Menü

Add/Edit Managed Domain

139

Domain name

Zeigt die zugeordnete(n) "Managed Domain(s)"

Remove from this customer and reassign to

Default Customer

Beinhaltet die Schaltfläche

Remove

zum

Entfernen der jeweiligen Managed Domain.

Die folgende Tabelle wird nur dann angezeigt, wenn nicht zugeordnete "Managed Domains" vorhanden sind..

Domain name Assign to this customer

Beherbergt das DropDown Menü zur Auswahl der "Managed Domain", welche dem Mandanten zugeordnet werden soll.

Über die Schaltfläche

Assign

wird der unter

Domain name ausgewählte Benutzer als

Mandanten-Admin hinzugefügt.

246

Sektion

Assigned GINA accounts

In dieser Sektion wird die Anzahl der dem Mandanten zugeordneten GINA-Benutzer angezeigt.

Über die Schaltfläche

Manage accounts

können die GINA-Benutzer des Mandanten verwaltet

sowie gegebenenfalls nicht zugeordnete Accounts zugeordnet werden (siehe

Manage GINA accounts

246

Sektion

Backup

Die Schaltfläche

Download

startet das Herunterladen der Mandanten-Backup-Datei. Diese Datei beinhaltet ausschliesslich Konfiguration und Schlüsselmaterial des Mandanten der SEPPmail-

Appliance. Voraussetzung für den Download des Backups ist die Vergabe eines Backup Passwortes, welches via

Change Password

gesetzt beziehungsweise geändert werden kann.

Soll ein Backup in die Appliance zurückgespielt werden, so erfolgt dies durch klicken von

Import

Backup File

. Hierfür wird das zum Zeitpunkt der Erstellung des Backups gültige Backup-Passwort benötigt.

Hinweis:

Die in der Sektion

Customer details

244

unter Customer Admin E-mail eingetragen Adresse erhält täglich die Mandanten-Sicherung per E-Mail zugesandt. Voraussetzung ist natürlich ein gesetztes Backup Passwort.

7.21.1.1 Manage GINA accounts

Sektion

Assigned GINA accounts

Zeigt die dem Mandanten bereits zugeordneten GINA-Benutzer an und bietet die Möglichkeit einzelne

GINA-Benutzer von diesem Mandanten zu entfernen, um diesen zum Beispiel einem anderen zuzuordnen. Somit bleibt das Schlüsselmaterial des GINA-Benutzers trotz dem Wechsel zu einem anderen Mandanten identisch.

Name E-Mail

Zeigt den Namen des jeweiligen GINA-

Benutzers, den er bei der Registrierung eingetragen hat.

Zeigt die E-Mail

Adresse des jeweiligen GINA-

Benutzers.

Creation info Remove from this customer

Zeigt wer gegebenenfalls die initiale GINA-E-Mail gesendet und somit den

Benutzer generiert hat

(Anzeige der E-Mail-

Adresse bei unregistrierten, beziehungsweise

"Created by..." bei bereits registrierten

Benutzern) ob es sich um einen selbstregistrierten

Benutzer handelt

(Account...)

Beinhaltet die

Schaltfläche

Remove

zum

Entfernen GINA-

Benutzers.

247

Sektion

Assign other GINA accounts

GINA-Benutzer, welche aktuell keinem Benutzer zugeordnet sind werden hier in zwei Tabellen angezeigt.

Dabei zeigt die erste Tabelle diejenigen GINA-Benutzer, welche dem Mandanten zwar nicht zugeordnet sind, jedoch von einem internen Benutzer der SEPPmail-Appliance erzeugt wurden, dessen E-Mail Domäne (Managed Domain) dem Mandanten zugeordnet ist.

In der Regel sollten solche GINA-Benutzer dem Mandanten mittels Schaltfläche

Assign

zugeordnet werden.

Name

Zeigt den Namen des jeweiligen GINA-

Benutzers, den er bei der Registrierung eingetragen hat.

E-Mail Creation info

Zeigt die E-Mail

Adresse des jeweiligen

GINA-Benutzers.

Zeigt wer die initiale

GINA-E-Mail gesendet und somit den

Benutzer generiert hat.

Dies ist immer ein interner Benutzer einer

Managed Domain des

Mandanten.

Assign to this customer

Beinhaltet die

Schaltfläche

Assign

mit welcher der GINA-

Benutzer dem

Mandanten zugeordnet werden kann.

Die zweite Tabelle der Sektion zeigt diejenigen GINA-Benutzer, welche keinem Mandanten zugeordnet sind und a) von einem internen Benutzer der SEPPmail-Appliance erzeugt wurden, dessen E-Mail Domäne

(Managed Domain) nicht dem Mandanten zugeordnet ist b) mittels Selbstregistrierung (siehe ) generiert wurden.

In der Regel sollten GINA-Benutzer, welche von einem internen Benutzer der SEPPmail-Appliance einer "Managed Domain" eines anderen Mandanten erzeugt wurden, nicht zugeordnet werden.

Name

Zeigt den Namen des jeweiligen GINA-

Benutzers, den er bei der Registrierung eingetragen hat.

E-Mail Creation info

Zeigt die E-Mail

Adresse des jeweiligen

GINA-Benutzers.

Zeigt, ob es sich um einen selbst registrierten GINA-

Benutzer handelt, beziehungsweise wer die initiale GINA-E-Mail gesendet und somit den Benutzer generiert hat. Dies ist kein

Benutzer einer

Managed Domain des

Mandanten.

Assign to this customer

Beinhaltet die

Schaltfläche

Assign

mit welcher der GINA-

Benutzer dem

Mandanten zugeordnet werden kann.

248

8 Referenz der Regelwerk-Anweisungen

Für den Fall, dass die Anforderungen an die Funktion beziehungsweise den Ablauf der im

Ruleset

Generator

157

bereit gestellten Möglichkeiten hinaus gehen, wird die Option von

Custom Commands

164

zur Verfügung gestellt. Hiermit wird die Möglichkeit geschaffen, das Regelwerk programmatisch zu erweitern und die jeweils kundenspezifiischen Teile entsprechend zu platzieren. In speziellen Fällen kann auch ein komplettes Regelwerk - ohne die Zuhilfenahme der Möglichkeiten des

Ruleset

Generator

157

s erstellt und als

SMTP Ruleset

168

eingespielt werden.

In diesem Kapitel werden die möglichen Befehle aufgelistet und die jeweilige Funktion beschrieben.

249

8.1 Allgemeine Informationen

Syntax

Abschluss von Befehlen

Befehle müssen grundsätzlich mit einem Semicolon (;) abgeschlossen werden.

Parameter

Parameter werden immer durch einfache Anführungszeichen ' ' begrenzt.

Parameter in eckigen Klammern, wie zum Beispiel [oldrecipient] sind optional und müssen nicht angegeben werden. Fehlt dieser Parameter wird in der Regel ein vordefinierter Standardwert bzw.

Standardverhalten angewendet.

Eingabe Beispiele: command([optional], required);

Eingabe command(‘’, ‘required’); oder command(‘required’); command(required, [optional], [optional]);

Eingabe command(‘required’); oder command(‘required’, ‘’, ‘’); oder command(‘required’, ‘’, ‘optional’);

Reguläre Ausdrücke

Innerhalb von Befehlen werden zum Teil reguläre Ausdrücke (regular expressions) verwendet, welche der Perl Systax entsprechen müssen.

Zahlreiche Erklärungen und Beispiele hierzu sind im Internet zu finden, beispielsweise unter http://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck http://wiki.selfhtml.org/wiki/Perl/Regul%C3%A4re_Ausdr%C3%BCcke

Verwenden von Anführungszeichen in Strings

Werden doppelte Anführungszeichen innerhalb eines Strings verwendet, so sind diese innerhalb der einfachen Anführungszeichen zu schreiben, also ' " " '.

Sind einfache Anführungszeichen innerhalb eines Strings zu schreiben, so sind diese durch doppelte

Anführungszeichen zu begrezen, also " ' ' "

Variablen

Grundsätzlich stehen innerhalb von Vorlagen und gegebenenfalls Befehlen folgende Variablen zur

Verfügung:

Variable Beschreibung

$header_from

$from

$header_to

$to

$header_cc

$mailid

$subject liefert den Wert (Absender-Adresse) des "from headers" zurück.

liefert den Absender aus dem "envelope" zurück.

liefert den Wert (Empfänger-Adresse) des "to headers" zurück.

liefert den Empfänger aus dem "envelope" zurück.

liefert den Wert (Empfänger-Adresse) des "cc headers" zurück.

liefert die eindeutige Message ID der E-Mail aus dem header zurück.

liefert den Betreff der E-Mail aus den "subject header" zurück.

250

8.2 Kontrollstrukturen - if/else Anweisungen

Die if/else Anweisungen sind Kontrollstrukturen und dienen innerhalb des Rulesets der

Ablaufsteuerung. Sie sind ein elementarer Bestandteil des Regelwerks. Ist eine Bedingung erfüllt, wird eine Aktionen ausgeführt, sonst wird eine alternative Aktion ausgeführt. Die auszuführende Aktion kann immer nur ein Befehl sein. Wenn als Aktion mehrere Befehle ausgeführt werden sollen, so können diese einzelnen Befehle in einem Anweisungsblock zusammengefasst werden. Ein

Anweisungsblock wird innerhalb geschweifter Klammern geschrieben.

Mit if wird festgelegt, welche Voraussetzung zur Ausführung einer Aktion erfüllt sein muss. Mit else wird eine alternative Aktion eingeleitet, sollte die durch if geforderte Bedingung nicht erfüllt sein. Eine if/else

Anweisung muss nicht durch ein Semikolon abgeschlossen werden. if/else Anweisungen können geschachtelt werden.

Jede if Anweisung muss mit einem else abgeschlossen werden.

Aufbau einer if/else Anweisung

if (Bedingung) {

Anweisungsblock 1;

} else {

} oder if (Bedingung) {

Anweisungsblock 1;

} else {

Anweisungsblock 2;

}

Die if-Anweisung bestimmt aufgrund des Rückgabewertes der Bedingung den weiteren Verlauf im Programmablauf. Die Bedingung besteht aus einem einzelnen Befehl, welcher mindestens einen Rückgabewert hat.

Anweisungsblock 1

wird nur dann ausgeführt, wenn der Rückgabewert positiv ist.

Anderenfalls wird - falls vorhanden - ausschliesslich Anweisungsblock 2 ausgeführt.

Beispiel

if (authenticated()) {

} else { createaccount('@CREATEGPGKEYS@'); log(1, 'user account generated');

}

Erklärung

Das Beispiel wertet den Rückgabewert des Befehls authenticated() aus. Konnte der interne interne Absender der E-Mail erfolgreich authentifiziert werden, so ist der Rückgabewert true.

Nachdem für diesen Fall keine weitere Anweisung definiert wurde, wird ohne weitere Aktion im

Programmablauf fortgefahren. Schlug die Authentifizierung fehl, das heisst der Rückgabewert ist

false, so kommt der unter else angeführte Anweisungsblock zu tragen. Im Beispiel würde somit ein Benutzerkonto für den Absender angelegt und ein openPGP Schlüsselpaar erzeugt.

8.3 Allgemeine Befehle

8.3.1

add_rcpt()

Der Befehl add_rcpt() fügt der E-Mail eine zusätzliche Empfänger E-Mail-Adresse im Envelope hinzu.

Aufbau des Befehls

add_rcpt('e-mMail-address');

Rückgabewert

positiv

immer

Parameter e-mail-address

Dieser Parameter definiert die E-Mail-Adresse welche dem Envelope als zusätzlicher Empfänger hinzugefügt werden soll.

Beispiel

add_rcpt('[email protected]');

Erklärung

In diesem Beispiel wird der Empfänger "In diesem Beispiel wird der Empfänger "" hinzugefügt.

Beim Empfänger erscheint die E-Mail im Posteingang so, als ob diese via BCC gesendet wurde.

Der ursprüngliche Empfänger wird nicht verändert.

251

252

8.3.2

authenticated()

Der Befehl authenticated() überprüft den Identifikationsstatus des Absenders.

Der Identifikationsstatus des Absenders beinhaltet die Identität und die Authentifizierung.

Aufbau des Befehls

authenticated(['header']);

Rückgabewert

positiv

sofern der Absender erfolgreich authentifiziert werden konnte

negativ

bei Fehlschlagen der Authentifizierung des Absenders

Hinweis:

Authentifiziert bedeutet entweder, dass sich der Benutzer via SMTP authentifiziert hat, oder dass die E-Mail von einem E-Mail-Server kommt, der eine Relay-Berechtigung hat. Die Relay-Berechtigung ist in

Mail System

Relaying

135

vorzunehmen.

Als Benutzer werden die lokalen "Named User" auf der Appliance bezeichnet

(siehe

Users

223

Parameter

header (optional)

Wird header als Wert angegeben, so wird der Benutzer erneut mittels der im FROM-Feld des

Headers der E-Mail enthaltenen E-Mail-Adresse authentifiziert. Im Standard wird die Adresse aus dem Envelope verwendet.

Beispiel 1

if (authenticated()) {

} else { createaccount('@CREATEGPGKEYS@'); log(1, 'user account generated');

}

Erklärung

Das Beispiel wertet den Rückgabewert des Befehls authenticated() aus. Konnte der interne interne Absender der E-Mail erfolgreich authentifiziert werden, so ist der Rückgabewert true.

Nachdem für diesen Fall keine weitere Anweisung definiert wurde, wird ohne weitere Aktion im

Programmablauf fortgefahren. Schlug die Authentifizierung fehl, das heisst der Rückgabewert ist

false, so kommt der unter else angeführte Anweisungsblock zu tragen. Im Beispiel würde somit ein Benutzerkonto für den Absender angelegt und ein openPGP Schlüsselpaar erzeugt.

Beispiel 2

if (authenticated('header')) {

} else { createaccount('@CREATEGPGKEYS@'); log(1, 'user account generated');

}

Erklärung

Dieses Beispiel wertet den Rückgabewert des Befehls authenticated() aufgrund des FROM-

Feldes des Headers aus. Konnte der interne interne Absender der E-Mail aufgrund des Eintrags im FROM-Feld erfolgreich authentifiziert werden, so ist der Rückgabewert true. Nachdem für diesen Fall keine weitere Anweisung definiert wurde, wird ohne weitere Aktion im Programmablauf

253 fortgefahren. Schlug die Authentifizierung fehl, das heisst der Rückgabewert ist false, so kommt der unter else angeführte Anweisungsblock zu tragen. Im Beispiel würde somit ein Benutzerkonto für den Absender angelegt und ein openPGP Schlüsselpaar erzeugt.

254

8.3.3

compare()

Der Befehl compare() prüft Werte in Headerfeldern auf einen zu definierenden Vergleichswert.

Dieser Befehl vergleicht den Inhalt eines Headers (header-field) mit Hilfe eines

Vergleichsoperators (operator) mit einem angegebenen Wert (value)..

Aufbau des Befehls

compare('header-field', 'operator', 'value');

Rückgabewert

positiv

bei zutreffender Bedingung

negativ

bei nicht zutreffender Bedingung

Parameter header-field

Gibt das Kopfzeilen-Feld an, dessen Inhalt gegen den Inhalt des Parameters value vergleichen werden soll. Als Kopfzeilen-Felder können alle Header in einer E-Mail verwendet werden.

Mögliche Werte return-path date from sender reply-to to cc bcc subject beliebiger x-header

operator

Mögliche Werte equal match substitute vergleicht auf Gleichheit prüft auf das Zutreffen eines regulären Ausdrucks ist gleich wie match, entfernt aber den zutreffenden Teil von value aus header-field

Hinweis:

Codierte Felder werden vor dem Vergleich decodiert. Die Sonderzeichen

Tabulator, Wagenrücklauf, Zeilenvorschub und Seitenende werden vor einem

Vergleich mit dem Operator equal entfernt.

value

Gibt den Wert an, gegen den Vergleichen werden soll. Dieser Wert kann auch ein regulärer

Ausdruck sein.

Beispiel 1

compare('x-smenc', 'equal', 'yes');

Erklärung

255

Dieses Beispiel prüft, ob das Header-Field x-smenc exakt den Wert yes beinhaltet. Dies bedeutet nicht, dass der Wert yes lediglich vorhanden ist, sondern, dass der Wert ausschliesslich yes

beinhaltet.

Beispiel 2

if (compare('to', 'match', '\@customer\.com')) { tagsubject('[nosign]');

} else {

}

Erklärung

Dieses Beispiel prüft bei einer ausgehenden E-Mail im Header-Field to mit dem Operator match auf das Vorhandensein der Domain @customer.com innerhalb der Empfänger E-Mail-Adresse.

Wenn die E-Mail-Adresse des Empfängers die Zeichenkette @customer.com enthält, dann ist der Rückgabewert von compare() true, im Betreff wird das das Tag [nosign] hinzugefügt. Je nach Basiskonfiguration des Rulesets wird dadurch das Signieren der E-Mail unterdrückt.

Beispiel 3

compare('subject', 'substitute', '(\s)*\[secure\]');

Erklärung

Dieses Beispiel prüft den Betreff (Header-Feld subject) einer E-Mail auf das Vorhandensein der

Zeichenkette [secure] (als regulärer Ausdruck (\s)*\[secure\]). Wird diese Zeichenkette innerhalb des Betreff gefunden, so wird diese entfernt.

256

8.3.4

compareattr()

Der Befehl compareattr() prüft Attribute/Systemvariablen auf einen zu definierenden

Vergleichswert.

Dieser Befehl vergleicht den Inhalt einer Variablen (attribute) mit Hilfe eines Vergleichsoperators ( operator

) mit einem angegebenen Wert (value)..

Aufbau des Befehls

compareattr('attribute', 'operator', 'value');

Rückgabewert

positiv

bei zutreffender Bedingung

negativ

bei nicht zutreffender Bedingung

Parameter attribute

attribute

kann die Variable connect_from adressieren oder Variablen, die mit ldap_read()

(siehe

ldap_read

307

) oder setuserattr() (siehe

setuserattr

276

) geschrieben wurden.

operator

Mögliche Werte equal match vergleicht auf Gleichheit.

prüft auf das Zutreffen eines regulären Ausdrucks.

value

Wert gegen den verglichen werden soll.

Beispiel

if (compareattr('connect_from','equal','172.16.161.1')) {

log(1,'Message comes from 172.16.161.1');

} else {

log(1,'Message does NOT come from 172.16.161.1');

}

Erklärung

In diesem Beispiel wird überprüft, ob die zu verarbeitende E-Mail von einem E-Mail-Server bestimmten Server kommt. Es wird die Systemvariable connect_from ausgewertet.

257

8.3.5

comparebody()

Der Befehl comparebody() prüft den Nachrichtentext der E-Mail auf Vorhandensein einer

Zeichenkette.

Dieser Befehl durchsucht den Nachrichtentext einer E-Mail nach dem angegebenen Wert (value).

Aufbau des Befehls

comparebody('value');

Rückgabewert

positiv

sofern der Wert aus value wenigstens einmal im Nachrichtentext vorkommt

negativ

sofern der Wert aus value nicht im Nachrichtentext vorkommt

Parameter value

Der Parameter value definiert den Suchbegriff, nach dem innerhalb der E-Mail gesucht wird.

value

hat das Format eines regulären Ausdrucks.

Beispiel

if (comparebody('(\d{1,3}\.){3}\d{1,3}')) {

log(1, 'Mail contains an IP address');

} else {

log(1, 'Mail does not contain an IP address');

}

Erklärung

In diesem Beispiel wird innerhalb des Nachrichtentextes einer E-Mail auf das Vorhandensein einer

IP-Adresse geprüft. Wird mindestens eine IP-Adresse gefunden, so wird der Log-Eintrag 'Mail contains an IP address' im System-Logger geschrieben. Wird keine IP-Adresse gefunden, so wird der Log-Eintrag 'Mail does not contain an IP address' im System-Logger geschrieben.

258

8.3.6

disclaimer()

Der Befehl disclaimer() fügt einen Textanhang einer bestehenden E-Mail hinzu.

Dieser Befehl fügt einen Textanhang aus dem angeführten Vorlage (template) einer bestehenden E-

Mail hinzu. Wird keine Vorlage angegeben, so wird versucht, anhand der Einstellungen der Managed

Domains den richtigen Disclaimer zu wählen. Dazu werden die den jeweiligen E-Mail Domänen zugeordneten Disclaimer ausgewertet.

Aufbau des Befehls

disclaimer(['template'], ['position'], ['force']);

Dieser Befehl fügt einen Textanhang aus dem angeführten template einer bestehenden E-Mail hinzu. Wenn eine leere Zeichenfolge als template angegeben ist, wird versucht, anhand der

Einstellungen der Managed Domains den richtigen Disclaimer zu wählen. Dazu werden die den jeweiligen E-Mail Domänen zugeordneten Disclaimer ausgewertet.

Rückgabewert

positiv

immer

Parameter

template (optional)

Definiert den Namen der Vorlage (template), welche als Textanhang verwendet werden soll.

Fussnoten- (Disclaimer-)Vorlagen werden über die Administrationsoberfläche (siehe

Mail

Processing

Edit Disclaimer

154

) konfiguriert und verwaltet.

Wird keine Vorlage angegeben, so wird das [default] Disclaimer Template verwendet.

position (optional)

Mögliche Werte top oberhalb des E-Mail-Body bottom unterhalb des E-Mail-Body default ist bottom

force (optional)

Dieser Paramater erzwingt das Hinzufügen eines Textanhangs an eine ausgehende E-Mail. Das heisst der Textanhang wird auch an Antwort-E-Mail angehängt.

Mögliche Werte: true, yes oder 1 false, no oder 0 default ist 0

Beispiel

disclaimer('', 'bottom', 'yes');

Erklärung

In diesem Beispiel wird der Standard Textanhang anhand der Einstellungen innerhalb der

Managed Domains ausgewählt und am Ende jeder versendeten E-Mail angehängt. Es ist dabei unerheblich, ob es sich um eine Antwort-E-Mail handelt oder nicht.

259

8.3.7

from_managed_domain()

Der Befehl from_managed_domain() prüft, ob eine E-Mail von einem Absender einer Managed

Domain stammt.

Aufbau des Befehls

from_managed_domain();

Rückgabewert

positiv

sofern die E-Mail von einem Absender einer Managed Domain (siehe

Mail System

Managed Domains

130

) stammt

negativ

falls die E-Mail von einer anderen E-Mail Domäne stammt.

Parameter

keine

Beispiel

if (from_managed_domain()) {

log('1', 'E-Mail is from managed domain');

} else {

log('1', "E-Mail isn't from managed domain");

}

Erklärung

In diesem Beispiel wird geprüft, ob eine E-Mail von einer unter Managed Domains eingetragenen

Absender E-Mail-Adresse gesendet wurde.

260

8.3.8

incoming()

Der Befehl incoming() bestimmt das Auslieferungsziel (intern/extern) einer E-Mail.

Dieser Befehl prüft, ob eine E-Mail lokal ausgeliefert wird. Sind nicht alle Empfänger der E-Mail

ausschliesslich lokal oder ausschliesslich extern, so werden zwei Gruppen gebildet.

Als "lokal" werden Empfänger bezeichnet, welche einer "Managed Domain" (siehe

Mail System

Managed Domains

130

) zugehörig sind.

Aufbau des Befehls

incoming();

Rückgabewert

positiv

für die Gruppe der lokalen Empfänger

negativ

für die Gruppe der externen Empfänger

Hinweis:

Als lokale Empfänger werden diejenigen bezeichnet, deren E-Mail-Domänen auf der Appliance als Managed Domains definiert sind.

Alle anderen Empfänger werden als extern bezeichnet.

Parameter

keine

Beispiel

if (incoming()) {

Ruleset-Anweisungen für alle E-Mails die lokal zugestellt werden können

Anweisungsblock 1 - Rückgabewert: positiv

} else {

Ruleset-Anweisungen für alle E-Mails die extern zugestellt werden müssen

Anweisungsblock 2 - Rückgabewert: negativ

}

Erklärung

In diesem Beispiel wird für eine eingehende E-Mail der Anweisungsblock 1 ausgeführt. Für eine ausgehende E-Mail wird der Anweisungsblock 2 ausgeführt.

261

8.3.9

log()

Der Befehl log() Erzeugt eiunen Eintrag im System-Log.

Der Eintrag im System-Log zeigt einen frei definierbaren Text (description) sowie eine Gewichtung

(severity) des Eintrags. Weiterhin wird dem Eintrag in Spitzklammern die Message-ID aus dem E-

Mail Header hinzugefügt. Die Aufgezeichneten Log-Meldungen können im Menü

Logs

219

eingesehen werden.

Aufbau des Befehls

log('severity', 'description');

Rückgabewert

positiv

immer

Parameter severity

Dieser Parameter gibt die Gewichtung des Log-Eintrags an.

severity Bedeutung

2 debug info notice

7 warning error critical alert emergency

description

Beschreibung wie Sie im System Log aufgezeichnet werden soll.

Beispiel

log('1', 'Hello World');

Header der E-Mail:

Date: Fri, 05 Aug 2013 11:40:00 +0200

From: [email protected]

To: [email protected]

Subject: Some Topic

Content-Type: text/plain;

Message-Id: <E0D4DE42-DCB5-11D7>

Aufzeichnung im Log:

Aug 05 11:40:04 test gateway: <E0D4DE42-DCB5-11D7> Hello World

Erklärung

Die Zeichenkette (description) 'Hello World' wird mit der Gewichtung (info) im System Log aufgezeichnet.

262

8.3.10 logheader()

Der Befehl logheader() schreibt den Inhalt des genannten Headers oder x-header in das System-

Log.

Dieser Befehl dient im Regelfall dem Debuggen der Verarbeitung von E-Mails durch die RuleEngine.

Die Aufgezeichneten Log-Meldungen können im Menü

Logs

219

eingesehen werden.

Aufbau des Befehls

logheader('header');

Rückgabewert

positiv

immer

Parameter header

Angabe des zu protokollierenden Headers oder X-Headers.

Mögliche Werte return-path date from sender reply-to to cc bcc subject beliebiger x-header

Beispiel

logheader('Message-ID');

Header der E-Mail:

Date: Fri, 05 Aug 2013 11:40:00 +0200

From: [email protected]

To: [email protected]

Subject: Some Topic

Content-Type: text/plain;

Message-Id: <E0D4DE42-DCB5-11D7>

Aufzeichnung im Log:

Aug 05 11:40:04 Message-Id: <E0D4DE42-DCB5-11D7>

Erklärung

Die Zeichenkette aus dem Header "Message-ID:" wird wie aufgezeigt im System Log aufgezeichnet.

8.3.11 logsubject()

Der Befehl logsubject() protokolliert den Inhalt der Betreffzeile einer E-Mail im System-Log.

Die Aufgezeichneten Log-Meldungen können im Menü

Logs

219

eingesehen werden.

Aufbau des Befehls

logsubject();

Rückgabewert

positiv

immer

Parameter

keine

Beispiel

logsubject();

Header der E-Mail:

Date: Fri, 05 Aug 2013 11:40:00 +0200

From: [email protected]

To: [email protected]

Subject: Some Topic

Content-Type: text/plain;

Message-Id: <E0D4DE42-DCB5-11D7>

Aufzeichnung im Log:

Aug 05 11:40:04 Message Subject is Some Topic

Erklärung

Die Zeichenkette aus dem Header "Subject:" wird wie aufgezeigt im System Log aufgezeichnet.

263

264

8.3.12 normalize_header()

Der Befehl normalize_header() ersetzt alle Sonderzeichen in einem (X-)Header durch normale

ASCII-Zeichen.

Dieser Befehl ersetzt alle Sonderzeichen des angegebenen Headers (header) durch normale ASCII-

Zeichen. Sonderzeichen können zum Beispiel deutsche Umlaute wie ä, ö, ü aber auch ? sein.

Aufbau des Befehls

normalize_header('header');

Rückgabewert

positiv

immer

Parameter header

Angabe des zu bearbeitenden Headers oder X-Headers an.

Mögliche Werte return-path date from sender reply-to to cc bcc subject beliebiger x-header

Beispiel 1

normalize_header('subject');

Erklärung

In diesem Beispiel wird im Header-Feld subject zum Beispiel aus der Zeichenkette "Herr Müller" die normalisierte Form "Herr Mueller".

Beispiel 2

normalize_header('to');

Erklärung

In diesem Beispiel wird im Header-Feld to aus der Zeichenkette

'<Bernd Hänsel> [email protected]' die normalisierte Form

'<Bernd Haensel> [email protected]'.

265

8.3.13 notify()

Der Befehl notify() sendet eine E-Mail Benachrichtigung an einen zu definierenden Empfänger bei

Verarbeitung einer anderen E-Mail.

Dieser Befehl erzeugt eine E-Mail Benachrichtigung an einen zu definierenden Empfänger ( recipient

) unter Verwendung der Vorlage (template). Optional können header beziehungsweise x-header

in diese Benachrichtigungs-E-Mail geschrieben werden.

Aufbau des Befehls

notify('recipient', 'template', ['header: value[;header: value]']);

Rückgabewert

positiv

immer

Parameter recipient

Angabe der Empfänger-E-Mail-Adresse der Benachrichtigungs-E-Mail.

Mögliche Werte

E-Mail-Adresse Sendet eine Benachrichtigung an die angegebene SMTP-E-Mail-Adresse sender

Benachrichtigt den ursprünglichen Absender der E-Mail admin

Benachrichtigt den lokalen SEPPmail-Administrator

Dieser wird in

Mail System

SMTP settings

134

unter Postmaster

address definiert.

template

Dieser Parameter definiert die zu verwendende Vorlage für diese Benachrichtigungsmail.

Die Vorlage kann in

Mail Processing

Edit Email Templates

155

erstellt und verwaltet werden.

header: value (optional)

Angabe des zu schreibenden headers inklusive des zugehörigen Wertes value.

Mögliche Werte für header return-path: date: from: sender: reply-to: to: cc: bcc: subject: beliebiger x-header

Hinweis:

Das Setzen mehrerer header beziehungsweise x-header ist durch trennen mittels Semicolon möglich.

Beispiel

notify('sender', 'bounce_noenc', 'from: "System Admin"

266

<[email protected]>;subject: Benachrichtigung; x-MyOwnHeader: Test');

Erklärung

In diesem Beispiel wird eine Benachrichtigungs-E-Mail an den ursprünglichen Absender - welcher

über die Variable sender zur Verfügung gestellt wird - generiert. Als Vorlage für die E-Mail wird das Standard Template bounce_noenc verwendet. Im header der Benachrichtigungs-E-Mail wird als Absender ""System Admin" <[email protected]>" und als Betreff "Benachrichtigung" gesetzt. Weiterhin wird ein x-header mit der Bezeichnung "x-MyOwnHeader" und dem Wert "Test" geschrieben.

267

8.3.14 replace_rcpt()

Der Befehl replace_rcpt() ersetzt den oder die Empfänger einer E-Mail durch einen anzugebenden anderen.

Die Empfänger der zu verarbeitenden E-Mail können in Abhängigkeit der verwendeten Parameter verändert werden. Jeder Parameter entspricht einem regulären Ausdruck, der als Ergebnis eine E-

Mail-Adresse oder einen Teil einer E-Mail-Adresse liefern muss.

Ebenfalls können Teile der beiden Parameter als regulärer Ausdruck beschrieben werden. So kann zum Beispiel nach dem Domainanteil innerhalb der Parameter gesucht werden und dieser durch einen neuen Wert ersetzt werden.

Mehrere Empfänger können durch Semikolon getrennt eingegeben werden.

Aufbau des Befehls

replace_rcpt(['oldrecipient',] 'newrecipient');

Rückgabewert

positiv

immer

Parameter

oldrecipient (optional)

Regulärer Ausdruck der die ursprügliche E-Mail-Adresse oder Teile davon beschreibt.

newrecipient

Regulärer Ausdruck der die neue E-Mail-Adresse oder Teile davon beschreibt.

Beispiel 1

replace_rcpt(' [email protected]');

Erklärung

In diesem Beispiel wird der ursprüngliche Empfänger der E-Mail durch den Empfänger " [email protected]" ersetzt.

Wäre beispielsweise der ursprünglich Empfänger der E-Mail "[email protected]", so würde dieser entfernt und durch den neuen Empfänger (newrecipient) "[email protected]" ersetzt. Somit wird die E-Mail an den neuen Empfänger "[email protected]" gesendet.

Beispiel 2

replace_rcpt('@mydomain\.com', '@customer\.ch');

Erklärung

In diesem Beispiel wird im Parameter oldrecipient der Domainanteil der ursprünglichen E-

Mail-Adresse des/der Empfänger/s von '@mydomain.com' in den Wert des Paramaters newrecipient

, '@customer.ch', geändert. Der Bestandteil der E-Mail-Adresse vor dem '@' bleibt dabei unverändert. Falls oldrecipient angegeben wird, wird nur dieser Empfänger bzw.

der Bestandteil des Empfängers angepasst.

Falls mehrere E-Mail-Empfängeradressen vorhanden sind, würden alle Empfängeradressen von

'@mydomain.com' zu '@mydomain.ch' geändert werden.

268

8.3.15 replace_sender()

Der Befehl replace_sender() verändert den Absender im Envelope einer E-Mail.

Dieser Befehl ersetzt den ursprünglichen Absender einer E-Mail im Envelope durch einen Anderen ( newsender

). Der Wert des Headers from wird dadurch nicht verändert.

Weiterhin können auch Teile der Absenderadresse über reguläre Ausdrücke (Parameter subst) manipuliert werden.

Aufbau des Befehls

replace_sender('newsender', ['subst']);

Rückgabewert

positiv

immer

Parameter newsender

Dieser Parameter ist der Wert, durch den die ursprüngliche Absender E-Mail-Adresse im

Envelope ersetzt wird. Ist der Parameter subst mit angegeben, so ist newsender die

Zeichenkette, die für den Teil der E-Mail-Adresse eingesetzt wird auf den subst zutrifft.

subst (optional)

Regulärer Ausdruck der auf die ursprüngliche Absender E-Mail-Adresse angewendet wird.

Beispiel 1

replace_sender('[email protected]');

Erklärung

In diesem Beispiel wird die E-Mail-Adresse im Envelope der E-Mail durch ' [email protected]' ersetzt.

Beispiel 2

replace_sender('@customer.com', '\@customer\.org');

Erklärung

In diesem Beispiel wird der Teil die E-Mail-Adresse im Envelope der E-Mail durch auf den regulären Ausdruck '\@customer\.org' zutrifft durch '@customer.com' ersetzt.

269

8.3.16 rmatch()

Der Befehl rmatch() prüft, ob ein regulärer Ausdruck auf mindestens einen Empfänger im Envelope zutrifft.

Aufbau des Befehls

rmatch('regexp');

Rückgabewert

positiv

wenn der reguläre Ausdruck (regexp) auf mindestens einen Empfänger zutrifft

negativ

wenn der reguläre Ausdruck (regexp) auf keinen Empfänger zutrifft

Parameter regexp

Definiert den regulären Ausdruck der verglichen werden soll.

Beispiel 1

if (rmatch('\@customer\.org')) {

notify ('sender', 'info_send_email');

} else {

}

Erklärung

In diesem Beispiel wird überprüft, ob die E-Mail-Adresse mindestens eines Empfängers einer E-

Mail den Domain-Bestandteil '@customer.org' hat. Ist dies der Fall, dann wird eine E-Mail

Benachrichtigung an den Absender gesendet.

270

8.3.17 rmatchsplit()

Der Befehl rmatchsplit() prüft, ob ein regulärer Ausdruck auf mindestens einen Empfänger im

Envelope zutrifft und teilt die Mail in zwei Gruppen

Über diesem Befehl wird im Envelope einer E-Mail auf das Vorhandensein eines regulären Ausdrucks

(regexp) geprüft. Eine E-Mail wird bei Bedarf in zwei Gruppen aufgeteilt: Eine Gruppe, mit

Empfängern, welche dem dem regulären Ausdruck entsprechen und eine weitere Gruppe dessen

Empfänger den regulären Ausdruck nicht enthalten. Somit wird der Befehl rmatchsplit() klassisch innerhalb der if/else Kontrollstruktur verwendet.

Aufbau des Befehls

rmatchsplit('regexp');

Rückgabewert

positiv

für die Gruppe, deren Empfänger den regulären Ausdruck regexp enthalten

negativ

für die Gruppe, deren Empfänger den regulären Ausdruck regexp nicht enthalten

Parameter regexp

Dieser Parameter definiert den regulären Ausdruck auf dessen Vorhandensein innerhalb der E-

Mail geprüft wird.

Beispiel

if (rmatchsplit('sales@customer\.com|invoice')) {

log(1, 'regex test successful');

} else {

log(1, 'regex test not successful');

}

Erklärung

In diesem Beispiel wird die E-Mail auf das Vorhandensein des Ausdrucks [email protected]

oder invoice geprüft. Wird einer dieser Textbestandteile innerhalb des Envelope der E-Mail gefunden, so wird die Anweisung log(1, 'regex test successful') ausgeführt, sonst wird die Anweisung log(1, 'regex test not successful') ausgeführt.

8.3.18 rmheader()

Der Befehl rmheader() löscht eine Header oder X-Header Zeile innerhalb einer E-Mail.

Aufbau des Befehls

rmheader('header');

Rückgabewert

positiv

immer

Parameter header

Angabe des zu löschenden Headers oder X-Headers an.

Mögliche Werte return-path date from sender reply-to to cc bcc subject beliebiger x-header

Hinweis:

Falls mehrere Header mit dem unter header angegebenen Namen existieren, werden alle zutreffenden Header gelöscht.

Beispiel

rmheader('X-Greylist');

Erklärung

In diesem Beispiel werden alle X-Greylist Header entfernt.

271

272

8.3.19 setheader()

Der Befehl setheader() fügt eine Header-Zeile innerhalb einer E-Mail hinzu oder verändert eine vorhandene.

Aufbau des Befehls

setheader('header', 'value');

Rückgabewert

positiv

immer

Parameter header

Angabe des Headers oder X-Headers der hinzugefügt oder geändert werden soll.

Mögliche Werte return-path date from sender reply-to to cc bcc subject beliebiger x-header

Hinweis:

Falls mehrere Header mit dem unter header angegebenen Namen existieren, wird der jeweils erste gefundene Header angepasst.

value

Angabe des Wertes, den der Header annehmen soll.

Beispiel 1

setheader('x-smenc','yes');

Erklärung

In diesem Beispiel wird einer E-Mail der zusätzliche Header x-smenc mit dem Wert 'yes' hinzugefügt.

Beispiel 2

setheader('from','[email protected]');

Erklärung

In diesem Beispiel wird in einer E-Mail das Header-Feld from auf dem Wert '[email protected]' geändert.

273

8.3.20 splitrecipients()

Der Befehl splitrecipients() erzeugt für jeden Empfänger einer E-Mail eine separate E-Mail.

Aufbau des Befehls

splitrecipients();

Rückgabewert

positiv

immer

Parameter

keine

8.3.21 tagsubject()

Der Befehl tagsubject() fügt dem Betreff einer E-Mail den zu definierenden Text hinzu.

Aufbau des Befehls

tagsubject('text');

Rückgabewert

positiv

immer

Parameter text

Der Parameter gibt den Text (Zeichenkette) an, der am Ende der Betreffzeile angehängt wird.

Beispiel

tagsubject('[priv]');

Erklärung

In diesem Beispiel wird an den Inhalt der Betreffzeile einer E-Mail die Zeichenkette '[priv]' am Ende angehängt.

8.3.22 tag_subject()

Der Befehl tag_subject() wurde durch tagsubject() (siehe

tagsubject

273

) ersetzt und ist nicht länger gültig.

274

8.4 Befehle für die Benutzerverwaltung

8.4.1

createaccount()

Der Befehl createaccount() erstellt neue Benutzerkonten.

Als Benutzerkonto wird ein lokales SEPPmail Benutzerkonto bezeichnet. Dieses Benutzerkonto kann im Menü

Users

223

eingesehen werden.

Aufbau des Befehls

createaccount(['keys'],['userID'],['name']);

Rückgabewert

positiv

immer

Parameter

keys (optional)

Dieser Parameter gibt an, welches Schlüsselmaterial beim Erstellen der Benutzerkontos automatisch generiert werden soll. Das Format entspricht einer Bitmaske in Oktalnotation. Wird der Parameter nicht angegeben, so wird kein Schlüsselmaterial erzeugt.

Die folgenden Werte stehe zur Verfügung:

Bit 0 : openPGP-Schlüsselpaar generieren

Bit 1

Bit 2

: S/MIME-Zertifikat mit der eigenen CA generieren

: S/MIME-Zertifikat via CA-Connector generieren

Bit 0: openPGP

Bit 1: S/MIME mit eigener CA

Bit 2: S/MIME via CA-Connector

Wert für keys

Mask x x x x x x x

1 3 5 4 2

userID (optional)

Dieser Parameter gibt die eindeutige ID des Benutzers an.

Wird dieser Parameter nicht angegeben, so wird für das Generieren des Benutzers seine E-Mail

Adresse als userID verwendet.

name (optional)

Dieser Parameter gibt des Namen des Benutzers an.

Wird dieser Parameter nicht angegeben, so wird für das Generieren des Benutzers der

Anzeigename, beziehungsweise wenn dieser nicht vorhanden ist seine E-Mail Adresse als name verwendet.

Hinweis:

Für userID und name können Variablen benutzt werden, die durch den Befehl ldap_read() gesetzt wurden.

Sonderzeichen in userID und name werden automatisch ersetzt.

8.4.2

member_of()

Der Befehl member_of() prüft die zugehörigkeit eines Absenders zu einer Gruppe.

Als Gruppe wird eine lokale SEPPmail Gruppe bezeichnet. Diese Gruppen werden im Menü

Groups

233

verwaltet.

Aufbau des Befehls

member_of('group');

Rückgabewert

positiv

wenn der Absender der angegebenen Gruppe zugeordnet ist

negativ

wenn der Absender nicht der angegebenen Gruppe zugeordnet ist

Parameter group

Definiert den Namen der Gruppe auf dessen Mitgliedschaft die E-Mail-Adresse des Absenders geprüft werden soll.

Beispiel

if (member_of('support')) {

setheader('x-smenc','yes');

} else {}

Erklärung

In diesem Beispiel wird geprüft, ob der Absender Mitglied der Gruppe 'support' ist. Falls ja, dann wird als Rückgabewert true geliefert, und der Befehl setheader() wird ausgeführt. Falls nein wird als Rückgabewert false geliefert.

275

276

8.4.3

setuserattr()

Der Befehl setuserattr() fügt einem Benutzerkonto Attribute hinzu oder ändert diese.

Das Benutzerkonto kann im Menü

Users

223

eingesehen werden.

Aufbau des Befehls

setuserattr('attr', 'value');

Rückgabewert

positiv

immer

Parameter

ATTR und VALUE

Folgende Systemattribute (attr) stehen mit den jeweiligen Werten (value) gemäss folgender

Tabelle zur Verfügung:

ATTR VALUE

accountOptions Bit 0: User darf nicht verschlüsseln

Bit 1: nicht belegt

Bit 2: User darf nicht signieren

UID

Bit 0: User darf nicht verschlüsseln

Bit 1: nicht belegt

Bit 2: User darf nicht signieren

Wert für value

Standardwert ist '0' (darf alles)

Name des Benutzers

User ID

Mask x x

x x

1 4 5

Hinweis:

Für value können Variablen benutzt werden, die durch ldap_read

()

gesetzt wurden.

Es können alle Attribute von InetOrgPerson benutzt werden.

Die Attribute können in der Administrationsoberfläche angezeigt werden.

Das Alleinstellungsmerkmal eines SEPPmail Benutzerkontos ist die E-

Mail Adresse, weshalb diese auch nicht geändert werden kann.

277

8.5 Befehle für die Zertifikatsverwaltung

8.5.1

attachpgpkey()

Der Befehl attachpgpkey() hängt den openPGP-Public-Key des Absenders (User) an eine E-Mail an.

Dieser Befehl hängt den openPGP-Public-Key des Absenders (interner Benutzer in der Appliance aus dem Menü

Users

226

) an eine E-Mail als Dateianhang an, um diesen dem Empfänger bereit zu stellen.

Aufbau des Befehls

attachpgpkey();

Rückgabewert

positiv

immer

Parameter

keine

8.5.2

smime_create_key()

Der Befehl smime_create_key() erstellt ein S/MIME-Zertifikat für einen internen Benutzer durch die lokale CA.

Aufbau des Befehls

smime_create_key(['subject']);

Rückgabewert

positiv

immer

Parameter

subject (optional)

Definiert das Subject für das zu erzeugende S/MIME-Zertifikat.

Innerhalb der subject-Zeichenkette steht die Variable $sender zur Verfügung, welch in die E-

Mail Adresse des Absenders aufgelöst wird.

Wird kein Parameter angegeben, so wird als subject der "Static Subject Part" aus der internen

CA (siehe

197

Internal CA Settings

Static Subject Part) und die E-Mail Adresse des

Absenders eingetragen.

Beispiel

smime_create_key('/C=CH/OU=Department/O=Company/emailAddress=$sender');

Erklärung

In diesem Beispiel wird ein S/MIME-Zertifikat über die lokale CA generiert, in welchem das optionale subject mitgegeben wird.

278

8.6 Befehle für das Handhaben von Nachrichten

8.6.1

archive()

Der Befehl archive() kopiert die E-Mail und stellt sie einen zusätzlichen Empfänger zu.

Die E-Mail wird innerhalb der Verarbeitung kopiert und in einem neuen Envelope der zusätzlich

angegebenden E-Mail Adresse (e-mail-address) zugestellt (vergleiche

Mail Processing

157

Ruleset Generator

Archiving).

Aufbau des Befehls

archive('e-mail-address');

Rückgabewert

positiv

immer

Parameter

e-mail-address (optional)

E-Mail Adresse des zusätzlichen Empfängers.

Beispiel

archive('[email protected]');

Erklärung

In diesem Beispiel wird die gerade verarbeitete E-Mail zusätzlich an den Empfänger ' [email protected]' gesendet.

279

8.6.2

bounce()

Der Befehl bounce() verweigert das Annehmen einer E-Mail.

Dieser Befehl erzeugt eine Bounce-E-Mail und löscht die ursprüngliche E-Mail. Das Aussehen der

Bounce-E-Mail wird durch eine Vorlage definiert. Der Absender dieser Bounce-E-Mail ist der

Postmaster (siehe

Mail System

134

SMTP settings

Postmaster address). Optional wird der Header der ursprünglichen E-Mail der Bounce-E-Mail als Dateianlage angehängt.

Hinweis:

Alle nachfolgenden Befehle werden ignoriert.

Dieser Befehl kann nicht die Bedingung einer if/else Anweisung sein (siehe

Abschnitt

Kontrollstrukturen - if/else Anweisungen

250

Aufbau des Befehls

bounce('template', ['attachheader']);

Rückgabewert kein

Parameter template

Definiert die zu verwendende Vorlage.

Vorlagen werden über die Administrationsoberfläche (siehe

Mail Processing

Templates

) definiert und verwaltet.

155

Edit Mail attach_header

Dieser Parameter gibt an, ob der Header der ursprünglichen E-Mail der Bounce-E-Mail als

Dateianlage angehängt werden soll (true) oder nicht (false).

Mögliche Werte: true, yes oder1 false, no oder 0 default ist 0

Beispiel

bounce('bounce', 'yes');

Erklärung

Die Auslieferung der E-Mail soll verhindert werden. Zugleich sollen dem Absender über eine Rück-

(Bounce-)E-Mail Informationen zur Verfügung gestellt werden. Der Inhalt dieser Rück-E-Mail ist in der Vorlage bounce definiert. Weiterhin wird der Header der nicht ausgelieferten E-Mail als

Anlage angehängt (Wert yes des Parameters attach_header).

280

8.6.3

deliver()

Der Befehl deliver() ermöglicht es, eine E-Mail unmittelbar auszuliefern.

Hinweis:

Alle nachfolgenden Befehle werden ignoriert.

Dieser Befehl kann nicht die Bedingung einer if/else Anweisung sein (siehe

Abschnitt

Kontrollstrukturen - if/else Anweisungen

250

Aufbau des Befehls

deliver(['mailserver[:port]'|'loop'|'queueless']);

Rückgabewert

positiv

immer

Parameter

Wird kein Parameter angegeben, so wird die E-Mail dem lokalen Mail-Transport-Agent (MTA)

übergeben.

mailserver (optional)

Gibt den E-Mail Server an, über welchen die E-Mail ausgeliefert werden soll.

Wird kein Parameter angegeben, so wird die E-Mail dem lokalen Mail-Transport-Agent (MTA)

übergeben.

:port (optional)

Gibt den Port an, auf welchem der angegeben E-Mail Server E-Mails empfängt.

Standard ist Port 25 SMTP

loop (optional)

Die E-Mail wird an den E-Mail Server zurückgegeben, von welchem sie angenommen wurde.

queueless (optional)

Diese Einstellung bewirkt, dass E-Mails an einzelne Empfänger während der Verarbeitung nicht zwischengelagert werden. Stattdessen wird die eingehende Verbindung erst quittiert, wenn dieabgehende Verbindung quittiert wurde. Wenn beim Versand an mehrere Empfänger die

Annahme für einige Empfänger nicht quittiert wird, befinden sich diese E-Mails kurzzeitig bis zur

Quittierung durch die empfangenden E-Mail Server auf der Appliance.

Hinweis:

Die Parameter

mailserver[:port],

loop,

queueless schliessen sich gegenseitig aus.

Beispiel 1

deliver('relay.customer.com:587');

Erklärung

In diese Beispiel wird die E-Mail an den angegebenen E-Mail Server mit dem Ziel-Port TCP/587 gesendet.

Beispiel 2

deliver();

Erklärung

In diesem Beispiel wird die E-Mail direkt über den eigenen lokalen E-Mail-Transport-Agent (MTA)

281 ausgeliefert.

8.6.4

drop()

Der Befehl drop() verwirft eine E-Mail und schreibt den angegebenen SMTP-Code sowie einen frei definierbarem Informationstext in das System-Log.

Hinweis:

Alle nachfolgenden Befehle werden ignoriert.

Dieser Befehl kann nicht die Bedingung einer if/else Anweisung sein (siehe

Abschnitt

Kontrollstrukturen - if/else Anweisungen

250

Der Absender wird über das verwerfen der E-Mail nicht informiert

Aufbau des Befehls

drop(['smtp-code'], ['text']);

Rückgabewert

positiv

immer

Parameter

smtp-code (optional)

Der smtp-code gibt den Grund für das Zurückweisen einer E-Mail an.

Wird dieser Parameter nicht angegeben, so wird der Code "555" verwendet.

Die Bedeutung der Codes gliedert sich wie folgt:

1XX

2XX

3XX

4XX

5XX

Mailserver hat die Anforderung akzeptiert, ist aber selbst noch nicht tätig geworden.

Eine Bestätigungsmeldung ist erforderlich.

Mailserver hat die Anforderung erfolgreich ohne Fehler ausgeführt.

Mailserver hat die Anforderung verstanden, benötigt aber zur Verarbeitung weitere

Informationen.

Mailserver hat einen temporären Fehler festgestellt. Wenn die Anforderung ohne jegliche Änderung wiederholt wird, kann die Verarbeitung möglicherweise abgeschlossen werden.

Mailserver hat einen fatalen Fehler festgestellt. Die Anforderung kann nicht verarbeitet werden.

Quelle: Wikipedia

Detaillierte Auflistungen der Fehlercodes sind zum Beispiel unter http://www.supermailer.de/ smtp_reply_codes.htm

zu finden.

text (optional)

Der Informationstext spezifiziert den Grund des Abweisens näher.

Default: Wird dieser Parameter nicht angegeben, so wird der Text "mail NOT accepted" ausgegeben.

Beispiel

drop('451', 'Die Nachricht konnte nicht entschluesselt werden');

Erklärung

In diesem Beispiel wird eine E-Mail verworfen. Im System-Log wird für diese Aktion folgender

Eintrag generiert: "Message Rejected. (451 Die Nachricht konnte nicht entschluesselt werden)".

282

8.6.5

reprocess()

Der Befehl reprocess() ermöglicht es, eine oder mehrere E-Mail(s) erneut zu verarbeiten.

Alle an eine E-Mail angehängten E-Mails - oder auch openPGP verschlüsselten Dateien - werden erneut verarbeitet und an den Absender zurückgesendet. Dies kann dann erforderlich sein, wenn sich im Posteingang eines Benutzers noch verschlüsselte E-Mails befinden. Diese E-mails können als

Anhang einer neuen E-Mail des betroffenen Benutzers zur erneuten Verarbeitung - also zum entschlüsseln - an die Appliance gesendet werden.

Der Befehl hat keinen Rückgabewert. Dieser Befehl hat keinen Parameter.

Hinweis:

Die ursprüngliche Message-ID wird aus den neu entschlüsselten E-Mails entfernt.

Es wird keine Bounce E-Mail an den Absender erzeugt.

Alle nachfolgenden Befehle werden ignoriert.

Dieser Befehl kann nicht die Bedingung einer if/else Anweisung sein (siehe

Abschnitt

Kontrollstrukturen - if/else Anweisungen

250

Aufbau des Befehls

reprocess();

Rückgabewert kein

Parameter

keine

Beispiel

if (compare('to', 'match', '(?i)reprocess\@decrypt\.reprocess')) {

log(1, 'reprocess recipient found - Re-injecting attached messages');

reprocess();

drop('220', 'message reprocessed');

} else {

}

Erklärung

Sendet ein interner Benutzer (eine) verschlüsselte E-Mail(s) als Anhang in einer neuen, nicht verschlüsselten E-Mail an die systemspezifische E-Mail-Adresse reprocess@decrypt.

reprocess

,so werden die E-Mails aus dem Anhang erneut verarbeitet. Somit wird versucht diese anhängenden E-Mails zu entschlüsseln. Für den Vorgang werden entsprechende Log-Einträge erzeugt. Nach dem Ausführen von reprocess() wird die ursprüngliche, neue E-Mail mit drop() gelöscht.

283

8.7 Befehle für kryptographische Behandlung

8.7.1

openPGP

8.7.1.1

pgp_encrypted()

Der Befehl pgp_encrypted() prüft, ob eine E-Mail openPGP verschlüsselt ist.

Dieser Befehl prüft, ob eine E-Mail openPGP verschlüsselt ist. Dabei spielt die Art der Verschlüsselung

(Domänen oder Benutzer basiert) keine Rolle.

Aufbau des Befehls

pgp_encrypted();

Rückgabewert

positiv

wenn die E-Mail openPGP verschlüsselt ist

negativ

wenn die E-Mail nicht openPGP verschlüsselt ist

Parameter

keine

Beispiel

Zeile Code

01 if (pgp_encrypted()) {

04 log(1, 'e-mail is pgp encrypted'); if (decrypt_domain_pgp()) { log(1, 'email successfully pgp domain decrypted');

}

} else {

}

} else { log(1, 'email could not be pgp domain decrypted'); if (decrypt_pgp() {

} else {

} log(1, 'email successfully pgp decrypted'); log(1, 'email could not be pgp decrypted'); log(1, 'e-mail is not pgp encrypted');

Erklärung

In diesem Beispiel wird zunächst geprüft, ob eine E-Mail openPGP verschlüsselt ist (Zeile 1) und ein entsprechender ein Log Eintrag geschrieben (Zeile 2 und 14). Ist die E-Mail openPGP verschlüsselt, so wird zunächst versucht die E-Mail mit dem privaten openPGP Domänen

Schlüssel zu entschlüsseln (Zeile 3) und Erfolg beziehungsweise Misserfolg protokolliert wird

(Zeile 4 und 6).

Konnte nicht mit dem privaten open PGP Domänen Schlüssel entschlüsselt werden, so wird nun versucht mit einem Benutzer basierten, privaten open PGP Schlüssel zu entschlüsseln (Zeile 7).

Das Ergebnis dieser Aktion wird ebenfalls protokolliert (Zeile 8 und 10).

284

8.7.1.2

Domänen basiert

8.7.1.2.1 decrypt_domain_pgp()

Der Befehl decrypt_domain_pgp() entschlüsselt openPGP Domänen verschlüsselte E-Mails.

Dieser Befehl versucht eingehende openPGP Domänen verschlüsselten Texte und Anlagen einer E-

Mail zu entschlüsseln, die durch den Absender mittels öffentlichen openPGP Domänen Schlüssel

(siehe

Mail System

Add/Edit Managed Domain

141

openPGP Domain Encryption

) verschlüsselt wurden.

Aufbau des Befehls

decrypt_domain_pgp();

Rückgabewert

positiv

wenn mindestens ein Text oder eine Anlage entschlüsselt werden wurde

negativ

wenn das Entschlüsseln fehlgeschlagen ist.

Parameter

keine

Beispiel

Zeile Code

01 if (decrypt_domain_pgp() {

03 log(1, 'email successfully pgp domain decrypted');

} else {

05 } log(1, 'email could not be pgp domain decrypted');

Erklärung

In diesem Beispiel wird eine openPGP Domänen verschlüsselte E-Mail entschlüsselt (Zeile 1).

Erfolg beziehungsweise Misserfolg des Entschlüsselns wird protokolliert (Zeile 2 und 4).

8.7.1.2.2 domain_pgp_keys_avail()

Der Befehl domain_pgp_keys_avail() prüft die Verfügbarkeit von öffentlichen openPGP

Domänen Schlüsseln.

Dieser Befehl prüft die Verfügbarkeit öffentlicher openPGP Domänen Schlüssel (siehe

Domain

Certificates

Mails.

241

openPGP Domain Keys

) der Empfänger für das Verschlüsseln ausgehender E-

Aufbau des Befehls

domain_pgp_keys_avail();

Rückgabewert

positiv

für die Gruppe mit vorhandenem öffentlichen openPGP Domänen Schlüssel

negativ

für die Gruppe ohne öffentlichen openPGP Domänen Schlüssel

Parameter

keine

Beispiel

Zeile Code

01 if (domain_pgp_keys_avail(){

04 log(1, 'pgp domain key available for recipient(s) $to'); if (encrypt_domain_pgp() { log(1, 'email successfully pgp domain encrypted');

} else { log(1, 'email could not be pgp domain encrypted');

}

} else { log(1, 'no pgp domain key available for recipient(s) $to');

}

Erklärung

In diesem Beispiel wird zunächst geprüft, ob ein passender öffentlicher openPGP Domänen

Schlüssel für das Verschlüsseln zur Verfügung steht (Zeile 1). Das Ergebnis dieser Abfrage wird protokolliert (Zeile 2 und 9). Steht ein entsprechender Schlüssel zur Verfügung, wird mit dem

Verschlüsseln fortgefahren (Zeile 3), dessen Erfolg beziehungsweise Misserfolg ebenfalls protokolliert wird (Zeile 4 und 6).

285

286

8.7.1.2.3 encrypt_domain_pgp()

Der Befehl encrypt_domain_pgp() verschlüsselt E-Mails mittels openPGP Domänen

Verschlüsselung.

Dieser Befehl verschlüsselt alle Texte und Anlagen ausgehender E-Mails via openPGP Domänen

Verschlüsselung. Dabei wird das openPGP-Inline Verfahren genutzt.

Stehen nicht für alle Empfänger der E-Mail Domäne öffentliche openPGP Domänen Schlüssel (siehe

Domain Certificates

Gruppen gebildet.

241

openPGP Domain Keys

) für das Verschlüsseln bereit, so werden zwei

Aufbau des Befehls

encrypt_domain_pgp();

Rückgabewert

positiv

für die Gruppe der Empfänger, für die verschlüsselt werden konnte

negativ

für die Gruppe der Empfänger, bei denen das Verschlüsseln nicht möglich gewesen ist

Parameter

keine

Beispiel

Zeile Code

01 if (encrypt_domain_pgp() {

03 log(1, 'email successfully pgp domain encrypted');

} else {

05 } log(1, 'email could not be pgp domain encrypted');

Erklärung

In diesem Beispiel wird versucht eine E-Mail mittels öffentlichen openPGP Domänen Schlüssel des Kommunikationspartners zu Verschlüsseln (Zeile 1). Erfolg beziehungsweise Misserfolg der

Aktion wird protokolliert (Zeile 2 und 4).

287

8.7.1.3

Benutzer basiert

8.7.1.3.1 decrypt_pgp()

Der Befehl decrypt_pgp() entschlüsselt openPGP verschlüsselte E-Mails.

Dieser Befehl versucht alle openPGP verschlüsselten Texte und Anlagen einer eingehenden E-Mail zu entschlüsseln, die durch den Absender mittels des persönlichen öffentlichen openPGP Schlüssels des

Empfängers (siehe

Users

Benutzerdetails

226

openPGP

) verschlüsselt wurden.

Aufbau des Befehls

decrypt_pgp();

Rückgabewert

positiv

wenn mindestens ein Text oder eine Anlage entschlüsselt werden konnte

negativ

wenn das Entschlüsseln fehlgeschlagen ist.

Parameter

keine

Beispiel

Zeile Code

01 if (decrypt_pgp() {

05 log(1, 'email successfully pgp decrypted');

} else {

} log(1, 'email could not be pgp decrypted');

Erklärung

In diesem Beispiel wird eine Benutzer basiert openPGP verschlüsselte E-Mail entschlüsselt (Zeile

1). Erfolg beziehungsweise Misserfolg des Entschlüsselns wird protokolliert (Zeile 2 und 4).

288

8.7.1.3.2 pgp_keys_avail()

Der Befehl pgp_keys_avail() prüft die Verfügbarkeit von öffentlichen openPGP Schlüsseln.

Dieser Befehl prüft die Verfügbarkeit personenbezogener öffentlicher openPGP Schlüssel der

Empfänger (siehe

openPGP public keys

236

) für das Verschlüsseln ausgehender E-Mails.

Aufbau des Befehls

pgp_keys_avail();

Rückgabewert

positiv

für die Gruppe mit vorhandenem öffentlichen openPGP Schlüssel

negativ

für die Gruppe ohne öffentlichen openPGP Schlüssel

Parameter

keine

Beispiel

Zeile Code

01 if (pgp_keys_avail(){

09 log(1, 'pgp key available for recipient(s) $to'); if (encrypt_pgp() {

} else {

}

} else { log(1, 'email successfully pgp encrypted'); log(1, 'email could not be pgp encrypted'); log(1, 'no pgp key available for recipient(s) $to');

10 }

Erklärung

In diesem Beispiel wird zunächst geprüft, ob ein passender, Benutzer basierter öffentlicher openPGP Schlüssel für das Verschlüsseln zur Verfügung steht (Zeile 1). Das Ergebnis dieser

Abfrage wird protokolliert (Zeile 2 und 9). Steht ein entsprechender Schlüssel zur Verfügung, wird mit dem Verschlüsseln fortgefahren (Zeile 3), dessen Erfolg beziehungsweise Misserfolg ebenfalls protokolliert wird (Zeile 4 und 6).

289

8.7.1.3.3 encrypt_pgp()

Der Befehl encrypt_pgp() ermöglicht es, E-Mails via openPGP zu verschlüsseln und zu signieren.

Dieser Befehl verschlüsselt alle Texte und Anlagen einer ausgehenden E-Mail mit dem öffentlichen openPGP Schlüssel des Empfängers (siehe

openPGP public keys

236

). Dabei wird das openPGP-

Inline Verfahren genutzt. Optional kann zusätzlich mit dem privaten openPGP Schlüssel des

Absenders (siehe

Users

Benutzerdetails

226

openPGP

) signiert werden.

Stehen nicht für alle Empfänger öffentliche openPGP Schlüssel bereit, so werden zwei Gruppen gebildet.

Aufbau des Befehls

encrypt_pgp(['sign'], ['address']);

Rückgabewert

positiv

für die Gruppe der Empfänger, für die verschlüsselt werden konnte, unabhängig ob das optionale Signieren erfolgreich war

negativ

für die Gruppe der Empfänger, bei denen das Verschlüsseln nicht möglich gewesen ist

Parameter sign

Dieser Parameter entscheidet, ob die E-Mail mit dem privaten openPGP Schlüssel des Absenders signiert werden soll.

Mögliche Werte: true, yes oder1 false, no oder 0 default ist 0

address

E-Mail-Adresse des Empfängers, dessen öffentlicher openPGP Schlüssel für das Verschlüsseln verwendet werden soll.

Wird kein Parameter angegeben, so wird der öffentliche openPGP Schlüssel des jeweiligen

Empfängers verwendet.

Beispiel

encrypt_pgp('yes', '[email protected]');

Erklärung

In diesem Beispiel wird versucht alle Texte und Anlagen einer E-Mail zu verschlüsseln und zu signieren, da der Parameter sign den Wert 'yes' hat. Für das Verschlüsseln wird der öffentliche openPGP Schlüssel des durch den Parameter address spezifizierten Empfängers verwendet. Im

Beispiel '[email protected]'.

290

8.7.2

S/MIME

8.7.2.1

smime_encrypted()

Der Befehl smime_encrypted() prüft, ob eine E-Mail S/MIME verschlüsselt ist.

Aufbau des Befehls

smime_encrypted();

Rückgabewert

positiv

wenn die E-Mail S/MIME verschlüsselt ist

negativ

wenn die E-Mail nicht S/MIME verschlüsselt ist

Parameter

keine

Beispiel

Zeile Code

01 if (smime_encrypted()) {

05 log(1, 'e-mail is S/MIME encrypted'); if (decrypt_domain_smime()) { log(1, 'email successfully S/MIME domain decrypted');

} else {

15 } log(1, 'email could not be S/MIME domain decrypted'); if (decrypt_smime() {

} else {

} log(1, 'email successfully S/MIME decrypted'); log(1, 'email could not be S/MIME decrypted');

}

} else { log(1, 'e-mail is not S/MIME encrypted');

Erklärung

In diesem Beispiel wird zunächst geprüft, ob eine E-Mail S/MIME verschlüsselt ist (Zeile 1) und ein entsprechender ein Log Eintrag geschrieben (Zeile 2 und 14). Ist die E-Mail S/MIME verschlüsselt, so wird zunächst versucht die E-Mail mit dem privaten S/MIME Domänen Schlüssel zu entschlüsseln (Zeile 3) und Erfolg beziehungsweise Misserfolg protokolliert wird (Zeile 4 und 6).

Konnte nicht mit dem privaten S/MIME Domänen Schlüssel entschlüsselt werden, so wird nun versucht mit einem Benutzer basierten, privaten S/MIME Schlüssel zu entschlüsseln (Zeile 7). Das

Ergebnis dieser Aktion wird ebenfalls protokolliert (Zeile 8 und 10).

291

8.7.2.2

Domänen basiert

8.7.2.2.1 decrypt_domain_smime()

Der Befehl decrypt_domain_smime() entschlüsselt S/MIME Domänen verschlüsselte E-Mails.

Dieser Befehl versucht eingehende S/MIME Domänen verschlüsselte E-Mails zu entschlüsseln, die durch den Absender mittels öffentlichen S/MIME Domänen Schlüssel (siehe

Mail System

Add/Edit

Managed Domain

142

S/MIME Domain Encryption

) verschlüsselt wurden.

Aufbau des Befehls

decrypt_domain_smime([keydomain]);

Rückgabewert

positiv

wenn die E-Mail entschlüsselt werden konnte

negativ

wenn das Entschlüsseln der E-Mail fehlgeschlagen ist.

Parameter

keydomain (optional)

An dieser Stelle kann die "Managed Domain" angegeben werden, deren Domain Keys für das entschlüsseln von E-Mails verwendet werden sollen.

Beispiel

Zeile Code

01 if (decrypt_domain_smime() {

03 log(1, 'email successfully S/MIME domain decrypted');

} else {

05 } log(1, 'email could not be S/MIME domain decrypted');

Erklärung

In diesem Beispiel wird eine S/MIME Domänen verschlüsselte E-Mail entschlüsselt (Zeile 1).

Erfolg beziehungsweise Misserfolg des Entschlüsselns wird protokolliert (Zeile 2 und 4).

292

8.7.2.2.2 domain_smime_keys_avail()

Der Befehl domain_smime_keys_avail() prüft die Verfügbarkeit von öffentlichen S/MIME

Domänen Schlüsseln (Zertifikaten).

Dieser Befehl prüft die Verfügbarkeit von Domänen Zertifikaten (siehe

Domain Certificates

242

SMIME Domain Certificates

beziehungsweise

Managed Domain Certificates

) der Empfänger für das Verschlüsseln ausgehender E-Mails.

Aufbau des Befehls

domain_smime_keys_avail();

Rückgabewert

positiv

für die Gruppe mit vorhandenem S/MIME Domänen Zertifikat

negativ

für die Gruppe ohne S/MIME Domänen Zertifikat

Parameter

keine

Beispiel

Zeile Code if (domain_smime_keys_avail(){

03 log(1, 'S/MIME domain certificate available for recipient(s)

$to'); if (encrypt_domain_smime() { log(1, 'email successfully S/MIME domain encrypted');

} else { log(1, 'email could not be S/MIME domain encrypted');

}

} else { log(1, 'S/MIME domain certificate available for recipient(s)

$to');

Erklärung

In diesem Beispiel wird zunächst geprüft, ob ein passendes S/MIME Domänen Zertifikat das

Verschlüsseln zur Verfügung steht (Zeile 1). Das Ergebnis dieser Abfrage wird protokolliert (Zeile

2 und 9). Steht ein entsprechender Schlüssel zur Verfügung, wird mit dem Verschlüsseln fortgefahren (Zeile 3), dessen Erfolg beziehungsweise Misserfolg ebenfalls protokolliert wird (Zeile

4 und 6).

293

8.7.2.2.3 encrypt_domain_smime()

Der Befehl encrypt_domain_smime() verschlüsselt E-Mails mittels S/MIME Domänen

Verschlüsselung.

Dieser Befehl verschlüsselt die komplette ausgehende E-Mail via S/MIME Domänen Verschlüsselung.

Davon ausgenommen sind lediglich E-Mail Header, da diese unter anderem für den E-Mail Transport benötigt werden.

Stehen nicht für alle Empfänger der E-Mail Domäne öffentliche S/MIME Domänen Schlüssel (

Zertifikate) für das Verschlüsseln bereit (siehe

Domain Certificates

242

SMIME Domain

Certificates

beziehungsweise

Managed Domain Certificates

), so werden zwei Gruppen gebildet.

Aufbau des Befehls

encrypt_domain_smime();

Rückgabewert

positiv

für die Gruppe der Empfänger, für die verschlüsselt werden konnte

negativ

für die Gruppe der Empfänger, bei denen das Verschlüsseln nicht möglich gewesen ist

Parameter

keine

Beispiel

Zeile Code

01 if (encrypt_domain_smime() {

05 log(1, 'email successfully S/MIME domain encrypted');

} else {

} log(1, 'email could not be S/MIME domain encrypted');

Erklärung

In diesem Beispiel wird versucht eine E-Mail mittels S/MIME Domänen Zertifikat des

Kommunikationspartners zu Verschlüsseln (Zeile 1). Erfolg beziehungsweise Misserfolg der Aktion wird protokolliert (Zeile 2 und 4).

294

8.7.2.3

Benutzer basiert

8.7.2.3.1 decrypt_smime()

Der Befehl decrypt_smime() entschlüsselt S/MIME verschlüsselte E-Mails.

Dieser Befehl entschlüsselt eingehende E-Mails, welche durch den Absender mittels des persönlichen

öffentlichen S/MIME Schlüssel (Zertifikat) des Empfängers (siehe

Users

Benutzerdetails

226

MIME

) verschlüsselt wurden.

Aufbau des Befehls

decrypt_smime();

Rückgabewert

positiv

wenn die E-Mail entschlüsselt wurde

negativ

wenn das Entschlüsseln der E-Mail fehlgeschlagen ist.

Parameter

keine

Beispiel

Zeile Code

02 if (decrypt_smime() { log(1, 'email successfully S/MIME decrypted');

} else {

} log(1, 'email could not be S/MIME decrypted');

Erklärung

In diesem Beispiel wird eine Benutzer basiert S/MIME verschlüsselte E-Mail entschlüsselt (Zeile

1). Erfolg beziehungsweise Misserfolg des Entschlüsselns wird protokolliert (Zeile 2 und 4).

295

8.7.2.3.2 smime_keys_avail()

Der Befehl smime_keys_avail() prüft die Verfügbarkeit von öffentlichen S/MIME Schlüsseln

(Zertifikate).

Dieser Befehl prüft die Verfügbarkeit personenbezogener Zertifikate der Empfänger (siehe

X.509

Certificates

237

) für das Verschlüsseln ausgehender E-Mails.

Aufbau des Befehls

smime_keys_avail();

Rückgabewert

positiv

für die Gruppe mit vorhandenem S/MIME Zertifikat

negativ

für die Gruppe ohne S/MIME Zertifikat

Parameter

keine

Beispiel

Zeile Code if (smime_keys_avail(){

01 log(1, 'S/MIME certificate available for recipient(s) $to');

03 if (encrypt_smime() { log(1, 'email successfully S/MIME encrypted');

} else { log(1, 'email could not be S/MIME encrypted');

}

} else {

10 log(1, 'no S/MIME certificate available for recipient(s)

$to');

}

Erklärung

In diesem Beispiel wird zunächst geprüft, ob ein passendes, Benutzer basiertes S/MIME Zertifikat für das Verschlüsseln zur Verfügung steht (Zeile 1). Das Ergebnis dieser Abfrage wird protokolliert

(Zeile 2 und 9). Steht ein entsprechender Schlüssel zur Verfügung, wird mit dem Verschlüsseln fortgefahren (Zeile 3), dessen Erfolg beziehungsweise Misserfolg ebenfalls protokolliert wird (Zeile

4 und 6).

296

8.7.2.3.3 encrypt_smime()

Der Befehl encrypt_smime() verschlüsselt E-Mails mittels S/MIME Domänen Verschlüsselung.

Dieser Befehl verschlüsselt die komplette ausgehende E-Mail via S/MIME Verschlüsselung. Davon ausgenommen sind lediglich E-Mail Header, da diese unter anderem für den E-Mail Transport benötigt werden.

Stehen nicht für alle Empfänger der E-Mail personenbezogene öffentliche S/MIME Schlüssel (

Zertifikate) für das Verschlüsseln bereit (siehe

X.509 Certificates

237

), so werden zwei Gruppen gebildet.

Aufbau des Befehls

encrypt_smime();

Rückgabewert

positiv

für die Gruppe der Empfänger, für die verschlüsselt werden konnte

negativ

für die Gruppe der Empfänger, bei denen das Verschlüsseln nicht möglich gewesen ist

Parameter

keine

Beispiel

Zeile Code

01 if (encrypt_smime() {

03 log(1, 'email successfully S/MIME encrypted');

} else {

05 } log(1, 'email could not be S/MIME encrypted');

Erklärung

In diesem Beispiel wird versucht eine E-Mail mittels Benutzer basiertem S/MIME Zertifikat des

Kommunikationspartners zu Verschlüsseln (Zeile 1). Erfolg beziehungsweise Misserfolg der Aktion wird protokolliert (Zeile 2 und 4).

8.7.2.3.4 smime_signed()

Der Befehl smime_signed() prüft, ob eine E-Mail S/MIME signiert ist.

Aufbau des Befehls

smime_signed();

Rückgabewert

positiv

wenn die E-Mail S/MIME signiert ist

negativ

wenn die E-Mail nicht S/MIME signiert ist

Parameter

keine

Beispiel

Zeile Code

02 if (smime_signed()) { log(1, 'e-mail is S/MIME signed');

10 } if (validate_smime_sig('1') {

}

} else { log(1, 'signature is valid');

} else { log(1, 'signature is invalid'); log(1, 'e-mail is not S/MIME signed');

Erklärung

In diesem Beispiel wird zunächst geprüft, ob eine E-Mail S/MIME signiert ist (Zeile 1) und ein entsprechender ein Log Eintrag geschrieben (Zeile 2 und 9). Ist die E-Mail S/MIME signiert, so wird Signatur geprüft (Zeile 3) und Erfolg beziehungsweise Misserfolg protokolliert wird (Zeile 4 und 6).

297

298

8.7.2.3.5 validate_smime_sig()

Der Befehl validate_smime_sig() prüft die S/MIME Signatur einer E-Mail auf ihre Gültigkeit.

Aufbau des Befehls

validate_smime_sig('fetch-certificate');

Rückgabewert

positiv

wenn folgende Bedingungen erfüllt sind: die E-Mail ist unverändert der Signatur-Schlüssel ist gültig, das heisst er o er stammt von einer als vertrauenswürdig eingestuften Certificate Authority (CA) o hat das Ablaufdatum noch nicht überschritten o ist auf keiner der Appliance bekannten Certificate Revocation List (CRL) aufgeführt

negativ

wenn eine der Bedingungen nicht erfüllt ist

Parameter

fetch-certificate (optional)

Dieser Parameter gibt an, ob bei der in der Signatur enthaltene öffentliche Schlüssel (Zertifikat) des Absenders gespeichert werden soll (siehe

X.509 Certificates

237

). Gespeichert werden nur

Zertifikate, deren Zertifikatskette bekannt ist (siehe

X.509 Root Certificates

238

). Dies unabhängig davon, ob die E-Mail verändert wurde oder nicht

Mögliche Werte: true, yes oder 1 false, no oder 0 default ist 0

Beispiel

Zeile Code

01 if (validate_smime_sig('1') {

05 log(1, 'signature is valid');

} else {

} log(1, 'signature is invalid');

Erklärung

In diesem Beispiel wird die S/MIME Signatur einer E-Mail geprüft (Zeile 1) und Erfolg beziehungsweise Misserfolg protokolliert wird (Zeile 2 und 4).

8.7.2.3.6 delete_smime_sig()

Der Befehl delete_smime_sig() ermöglicht es, die S/MIME-Signatur einer E-Mail zu löschen.

Dieser Befehl löscht eine Signatur aus der signierten E-Mail.

Hinweis:

Die Gültigkeit der S/MIME-Signatur wird nicht geprüft.

299

Aufbau des Befehls

delete_smime_sig();

Rückgabewert

positiv

wenn die E-Mail S/MIME signiert war

negativ

wenn die E-Mail nicht S/MIME signiert war

Parameter

keine

Beispiel

Zeile Code

01 if (validate_smime_sig('1') {

03 log(1, 'signature is valid'); delete_smime_sig();

} else { log(1, 'signature is invalid');

}

Erklärung

In diesem Beispiel wird die S/MIME Signatur einer E-Mail geprüft (Zeile 1) und Erfolg beziehungsweise Misserfolg protokolliert wird (Zeile 2 und 5). Wurde die Signatur als gültig eingestuft, so wird sie gelöscht (Zeile 3).

300

8.7.2.3.7 has_smime_key()

Der Befehl has_smime_key() prüft, ob der Benutzer einen gültigen privaten S/MIME-Schlüssel besitzt.

Dieser Befehl prüft, ob ein Benutzer (interner Benutzer in der Appliance aus dem Menü

Users

226

) einen gültigen privaten S/MIME-Schlüssel besitzt.

Aufbau des Befehls

has_smime_key();

Rückgabewert

positiv

wenn der Benutzer einen gültigen privaten S/MIME-Schlüssel besitzt

negativ

wenn der Benutzer keine oder nur abgelaufene S/MIME-Schlüssel besitzt.

auf den Status may not encrypt gesetzt ist.

auf den Status may not sign gesetzt ist.

Parameter

keine

301

8.7.2.3.8 sign_smime()

Der Befehl sign_smime() signiert eine E-Mail.

Dieser Befehl signiert die ausgehende E-Mail mit dem persönlichen privaten S/MIME Schlüssels des

Absenders (siehe

Users

Benutzerdetails

226

S/MIME

Aufbau des Befehls

sign_smime();

Rückgabewert

positiv

wenn die Nachricht erfolgreich signiert wurde

negativ

bei Fehlschlagen der Signatur

Parameter

keine

Beispiel

Zeile Code

01 if (has_smime_key(){

03 log(1, 'S/MIME key available, trying to sign'); if (sign_smime() { log(1, 'signing successful');

} else { log(1, 'signing failed');

}

} else { log(1, 'no S/MIME key available, do not sign');

Erklärung

In diesem Beispiel wird zunächst geprüft, ob ein privater S/MIME Schlüssel verfügbar ist (Zeile 1).

Das Ergebnis wird protokolliert (Zeile 2 und 9). Ist ein privater S/MIME Schlüssel vorhanden, so wird versucht die E-Mail zu signieren (Zeile 3) und das Ergebnis dieser Aktion wird ebenfalls in das

Log geschrieben (Zeile 4 beziehungsweise 6).

302

8.7.3

GINA

8.7.3.1

encrypt_webmail()

Der Befehl encrypt_webmail() verschlüsselt eine E-Mail unter Verwendung der GINA-

Technologie.

Dieser Befehl verschlüsselt eine ausgehende Nachricht via GINA-Technologie an die

Empfängeradresse.

Die Empfängeradresse wird aus der aktuell verarbeiteten Nachricht entnommen.

Nach dem verschlüsseln einer Nachricht mittels GINA-Technologie sollte diese immer direkt mit deliver()

versendet werden.

Aufbau des Befehls

encrypt_webmail(['template']);

Rückgabewert

positiv

immer

Parameter

template (optional)

Definiert das angelegte GINA-Profil beziehungsweise die GINA-Domain.

Wird kein Parameter angegeben, so wird die Vorlage anhand der E-Mail-Domäne der

Absenderadresse ausgewählt (siehe

Mail System

130

Managed Domains

GINA Settings)

Beispiel

Zeile Code if (encrypt_webmail() {

02 log(1, 'email successfully deliver();

GINA encrypted');

} else { log(1, 'email could not be

GINA encrypted');

07 drop('451', 'Die Nachricht konnte nicht verschluesselt werden');

}

Erklärung

In diesem Beispiel wird versucht eine E-Mail mittels <%OEM-WEBMAIL-GINA%-Technologie zu

Verschlüsseln (Zeile 1). Erfolg beziehungsweise Misserfolg der Aktion wird protokolliert (Zeile 2 und 5). Bei erfolgreichem Verschlüsseln wird die E-Mail - wie empfohlen - direkt ausgeliefert (Zeile

3). Andernfalls wird sie mit dem temporären Fehler "451" und dem Hinweistext "Die Nachricht konnte nicht verschluesselt werden" abgewiesen (Zeile 6).

303

8.7.3.2

pack_mail()

Der Befehl pack_mail() ermöglicht das Senden von GINA-E-Mails über ein abgekoppeltes GINA-

Relay-System.

Dieser Befehl ermöglicht das Senden von GINA-E-Mails über ein abgekoppeltes GINA-Relay-System

(vergleiche

Mail Processing

157

Ruleset Generator

Advanced Options Use remote GINA server, reachable under the following email address).

Aufbau des Befehls

pack_mail('e-mail-address', ['domainsignature']);

Rückgabewert

positiv

bei erfolgreichem Weiterleiten der GINA-Anforderung an das GINA-Relay-System

negativ

bei fehlgeschlagenem Weiterleiten der GINA-Anforderung an das GINA-Relay-System

Parameter e-mail-address

Definiert die E-Mail-Adresse unter welcher das GINA-Relay-System erreichbar ist.

domainsignature (optional)

Durch diesen Parameter wird die an das GINA-Relay-System weitergeleitete E-Mail zusätzlich mit einer Domänensignatur - ohne Prüfen des Absenders!!! - versehen.

Geprüft wird auf Empfängerseite (siehe

unpack_mail()

304

) mittels Fingerabdruck des Domänen

Zertifikates.

Mögliche Werte: true, yes oder 1 false, no oder 0 default ist 0

Beispiel

Zeile Code

02 if (pack_mail('[email protected]', 'yes') { log(1, 'email successfully sent to remote

GINA server');

} else {

04 log(1, 'email could not delivered to remote

GINA server'); drop('451', 'Die Nachricht konnte nicht verschluesselt

06 werden');

}

Erklärung

In diesem Beispiel wird die ausgehende E-Mail zur Weiterleitung an ein GINA-Relay-System gepackt, welches unter der (Pseudo) E-Mail Adresse "[email protected]" erreichbar ist und mit dem Domainzertifikat signiert (Zeile 1). Erfolg beziehungsweise Misserfolg der Aktion wird protokolliert (Zeile 2 und 4). Bei fehlschlagen der Aktion wird die E-Mail mit dem temporären

Fehler "451" und dem Hinweistext "Die Nachricht konnte nicht verschluesselt werden" abgewiesen

(Zeile 5).

304

8.7.3.3

unpack_mail()

Der Befehl unpack_mail() entpackt auf einem GINA-Relay-System die vom Basis-System

übermittelten GINA-Anforderungen.

Mit diesem Befehl werden die vom Basis-System mittels

pack_mail()

303

übermittelten GINA-

Anforderungen angenommen (vergleiche

Mail Processing

Options This is a remote GINA server).

157

Das weitere Verarbeiten der E-Mail findet im Anschluss statt.

Ruleset Generator

Advanced

Aufbau des Befehls

unpack_mail();

Rückgabewert

positiv

immer

Parameter

keine

305

8.7.3.4

webmail_keys_avail()

Der Befehl webmail_keys_avail() prüft, ob ein GINA-Benutzerkonto vorhanden ist.

Aufbau des Befehls

webmail_keys_avail();

Rückgabewert

positiv

für die Gruppe mit vorhandenem GINA-Benutzerkonto

negativ

für die Gruppe ohne GINA-Benutzerkonto

Parameter

keine

Beispiel

Zeile Code

06 if (webmail_keys_avail(){ log(1, '

GINA account already exists');

} else {

} log(1, 'no

GINA account available, creating new account'); webmail_keys_gen('', '8');

Erklärung

In diesem Beispiel wird zunächst geprüft, ob ein GINA-Benutzerkonto vorhanden ist (Zeile 1). Das

Ergebnis dieser Abfrage wird protokolliert (Zeile 2 und 4). Ist kein GINA-Benutzerkonto vorhanden, so wird ein neues angelegt (Zeile 5).

306

8.7.3.5

webmail_keys_gen()

Der Befehl webmail_keys_gen() erstellt ein GINA-Benutzerkonto.

Dieser Befehl generiert ein GINA-Benutzerkonto und schickt das Initial Kennwort an den Absender der ursprünglichen E-Mail oder alternativ an eine optional anzugebende E-Mail Adresse.

Aufbau des Befehls

webmail_keys_gen(['recipient'], ['password_length'],

['no_pw_email_if_sms_sent']);

Rückgabewert

positiv

immer

Parameter

recipient (optional)

Definiert die E-Mail Adresse, an welche die E-Mail mit dem Initial Kennwort gesendet werden soll.

Wird keine E-Mail Adresse angegeben, so wird die Absender E-Mail Adresse verwendet.

password_length (optional)

Definiert die Länge des Initial Kennworts. Dabei steht die "0" (null) für ein leeres Kennwort.

Wird der Parameter nicht angegeben, so wird der Standardwert der Konfigurationsoberfläche

(siehe

Mail Processing

150

GINA Settings

Password Length) verwendet.

no_pw_email_if_sms_sent (optional)

Mit dieser Option wird die E-Mail mit dem Initial Passwort an den Absender unterbunden, wenn dieses bereits per SMS übermittelt werden konnte (siehe auch Schlüsselwort [SMS:] in Tabelle 1 des Kapitels

Steuern der Appliance

Mögliche Werte: true, yes oder 1 false, no oder 0 default ist 0

Beispiel

webmail_keys_gen('', '8');

Erklärung:

In diesem Beispiel wird ein GINA-Benutzerkonto erzeugt. Der Absender der ursprünglichen E-Mail erhält eine E-Mail-Benachrichtigung mit dem Initial Kennwort. Dieses Initial Kennwort hat '8'

(acht) Zeichen.

307

8.8 Befehle für LDAP (Zugriff auf externe Quellen)

8.8.1

ldap_read

Der Befehl ldap_read() liest einen Wert aus einem LDAP-Verzeichnis aus und legt diesen in einer

Variablen ab.

Dieser Befehl baut eine Verbindung zu einem LDAP-Server auf, liest den Wert eines Attributs aus und legt diesen in einer Variable ab.

Wird keiner der angegebenen LDAP Server erreicht, so wird die E-Mail mit einem temporären Fehler abgewiesen (420, could not bind to LDAP server).

Aufbau des Befehls

ldap_read('ldap', 'attr', 'var');

Rückgabewert

positiv

wenn das Attribute 'attr' gefunden und somit der Variablen 'var' ein Wert zugewiesen werden kann

negativ

wenn der Variablen 'var' kein Wert zugewiesen werden kann

Parameter ldap

Der Parameter ist wie folgt aufgebaut:

'URI;BindDN;Password;SearchBase;Filter'

Die Bedeutung der einzelnen Teil Strings ist der der folgenden Tabelle beschrieben:

Parameter Beschreibung

URI

BindDN

Password

SearchBase

Filter

Angabe des LDAP Servers, der abgefragt werden soll. Als Eingabe wird der

Hostname oder die IP-Adresse aktzeptiert. Es können auch zwei mit Komma getrennte Werte angegeben werden: In diesem Fall wird automatisch auf den zweiten Server zugegriffen, wenn der erste nicht erreicht werden kann.

Eingabe des vollständigen Distinguished Name (DN) des (read-only)

Accounts, welcher zur Suche des unter "SearchBase" in der LDAP Datenbank berechtigt ist.

Das Passwort des unter BindDN angegebenen Benutzers

Suchpfad: Gibt den Zweig der LDAP Datenbank an, in welchem das Attribute aus dem Parameter 'attr' zu suchen ist.

Angabe eines Attributes der LDAP Datenbank, unter welchem das gesuchte

Attribute aus dem Parameter 'attr' im Zweig der "SearchBase" zu finden ist.

attr

Attribut nach welchem im LDAP-Verzeichnis gesucht werden soll.

var

Name der Variablen, in welcher der Wert des Attributes 'attr' abgelegt werden soll

Beispiel

Der Wert des Attributs "name" soll aus einem LDAP-Verzeichnis ausgelesen werden. Dieser soll in der Variable "name" abgespeichert werden.

Die Anweisung sieht wie folgt aus:

308 ldap_read('192.168.10.10;CN=Peter Mueller,OU=SBSUsers,OU=Users,

OU=MyBusiness,DC=Firma,DC=local;mypassword;OU=SBSUsers,OU=Users,

OU=MyBusiness,DC=Firma,DC=local; (mail=$sender)','name','name'););

Erklärung

Der LDAP Server mit der IP-Adresse 192.168.10.10 (und dem Standardport 389) wird abgefragt.

Der DistinguishedName (DN) des Benutzers (Peter Mueller) unter welchem die Abfrage ausgeführt wird (dieser muss die entsprechenden Berechtigungen besitzen) lautet

CN=Peter Mueller,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Firma,DC=local

Das Passwort dieses Benutzers lautet mypassword

Der LDAP Pfad, in welchem nach dem Attribut "name" gesucht werden soll lautet

OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Firma,DC=local

Der Benutzer, dessen Gruppenzugehörigkeit festgestellt werden soll, wird anhand der Absender

E-Mail Adresse 'ldap/Filter' definiert.

Existiert das angegebene Attribut 'attr' oder der gesuchte Eintrag nicht, so wird der Variable

'var'

ein leerer Wert zugewiesen.

Werden mehrere Einträge (Objekte) im Attribut 'attr' gefunden, so wird nur der erste ausgewertet.

Sollten mehrere Attribute 'attr' vorhanden sein, so werden alle Attribute ausgewertet (multi value).

Wird keiner der angegebenen LDAP Server erreicht, so wird die E-Mail mit einem temporären

Fehler abgewiesen.

309

8.8.2

ldap_compare()

Der Befehl ldap_compare() vergleicht einen vorgegebenen Wert mit dem Wert eines LDAP-

Attributs.

Dieser Befehl baut eine Verbindung zu einem LDAP-Server auf und prüft den Wert eines Attributs.

Wird keiner der angegebenen LDAP Server erreicht, so wird die E-Mail mit einem temporären Fehler abgewiesen (420, could not bind to LDAP server).

Aufbau des Befehls

ldap_compare('ldap', 'attr', 'value');

Rückgabewert

Der Rückgabewert ist abhängig von der verwendeten Variable im LDAP-Suchstring

Parameter ldap

Der Parameter ist wie folgt aufgebaut:

'URI;BindDN;Password;SearchBase;Filter'

Die Bedeutung der einzelnen Teil Strings ist der der folgenden Tabelle beschrieben:

Parameter Beschreibung

URI

BindDN

Password

SearchBase

Filter

Angabe des LDAP Servers, der abgefragt werden soll. Als Eingabe wird der

Hostname oder die IP-Adresse aktzeptiert. Es können auch zwei mit Komma getrennte Werte angegeben werden. In diesem Fall wird automatisch auf den zweiten Server zugegriffen, wenn der erste nicht erreicht werden kann.

Eingabe des vollständigen Distinguished Name (DN) des (read-only)

Accounts, welcher zur Suche des unter "SearchBase" angegebenen Pfades der LDAP Verzeichnisstruktur berechtigt ist.

Das Passwort des unter BindDN angegebenen Benutzers

Suchpfad: Gibt den Zweig des LDAP Verzeichnisses an, in welchem das

Attribut 'attr' aus dem Parameter mittels Suchfilter (siehe nächste Zeile) zu suchen ist.

Suchfilter: Hier wird auf Übereinstimmung des Wertes des angegebenen

Attributes aus dem LDAP Suchpfad verglichen.

Variablen

$sender

Diese Variable gibt den Absender der E-Mail aus.

Rückgabewert bei Verwendung dieser Variable

pos

wenn der Wert 'value' für das angegebene Attribut 'attr' im

itiv

LDAP Suchstring 'ldap/SearchBase' gefunden wurde.

neg

wenn kein entsprechender Wert gefunden wurde.

ativ

$recipients

Diese Variable gibt die Empfänger einer E-Mail aus. Dabei wird die E-Mail in zwei Gruppen gesplittet. Eine Gruppe mit den Empfängern, welche über den Wert 'value' im angegebenen Attribut 'attr' des LDAP

Suchstrings 'ldap/SearchBase' verfügen, und eine weitere Gruppe für die Empfänger, welche nicht darüber verfügen.

Rückgabewert bei Verwendung dieser Variable

posfür die Gruppe mit dem entsprechenden Wert 'value'

310

Parameter Beschreibung

itiv neg

für die Gruppe ohne dem entsprechenden Wert 'value'

ativ

$one_recipient

Enthält eine E-Mail mehrere Empfänger, so wird für alle Empfänger der

Wert 'value' für das angegebene Attribut 'attr' im LDAP Suchstring

'ldap/SearchBase'

geprüft.

Rückgabewert bei Verwendung dieser Variable

pos

wenn mindestens bei einem Empfänger der Wert 'value' für das

itiv

angegebene Attribut 'attr' im LDAP Suchstring 'ldap/

SearchBase'

gefunden wurde .

neg

wenn bei keinem Empfänger ein entsprechender Wert 'value'

ativ

gefunden wurde.

$all_recipients

Enthält eine E-Mail mehrere Empfänger, so wird für alle Empfänger der

Wert 'value' für das angegebene Attribut 'attr' im LDAP Suchstring

'ldap/SearchBase'

geprüft. 'ldap/SearchBase' gefunden wurde

Rückgabewert bei Verwendung dieser Variable

pos

wenn bei allen Empfängern der Wert 'value' für das angegebene

itiv

Attribut 'attr' im LDAP Suchstring 'ldap/SearchBase' gefunden wurde.

neg

wenn auch nur bei einem Empfänger der Wert 'value' nicht

ativ

gefunden wurde.

attr

Attribut nach welchem im LDAP-Verzeichnis gesucht werden soll.

Hinweis:

Sollten mehrere Attribute 'attr' vorhanden sein, so werden alle

Attribute ausgewertet (multi value).

value

Wert, welcher im abgefragten Attribut 'attr' vorkommen soll.

Hinweis:

Werden mehrere Einträge 'value' gefunden, so wird nur der erste ausgewertet.

Beispiel 1

Die Zugehörigkeit des internen Absenders einer E-Mail "(mail=$sender)" zur Gruppe "MailCrypt" soll im LDAP geprüft werden, um festzustellen, ob er berechtigt ist, kryptographisch behandelte E-

Mails zu senden.

Die Anweisung sieht wie folgt aus: ldap_compare('192.168.10.10;CN=Peter Mueller,OU=SBSUsers,OU=Users,

OU=MyBusiness,DC=Firma,DC=local;mypassword;OU=SBSUsers,OU=Users,

OU=MyBusiness,DC=Firma,DC=local;(mail=$sender)','memberOF','MailCrypt');

311

Erklärung

Der LDAP Server mit der IP-Adresse 192.168.10.10 (und dem Standardport 389) wird abgefragt.

Der DistinguishedName (DN) des Benutzers unter welchem die Abfrage ausgeführt wird (dieser muss die entsprechenden Berechtigungen besitzen) lautet

CN=Peter Mueller,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Firma,DC=local

Das Passwort dieses Benutzers lautet mypassword

Der LDAP Pfad, in welchem der Suchfilter (mail=$sender) angewendet werden soll soll lautet

OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Firma,DC=local

Der Benutzer, dessen Gruppenzugehörigkeit festgestellt werden soll, wird also in diesem Beispiel anhand der Absender E-Mail Adresse (mail=$sender) festgestellt.

Mindestens ein Wert des Attributes "memberOF" muss den Wert "MailCrypt" haben, damit der

Rückgabewert positiv ist.

Beispiel 2

Ausgangspunkt sind zwei unterschiedliche Groupware- (interne E-Mail-) Server (zum Beispiel

Exchange und Domino), welche parallel eingesetzt werden.

Es soll abgefragt werden, ob das Postfach wenigstens eines internen Empfängers einer eingehenden E-Mail - mit gegebenenfalls mehreren Empfängern - ein Exchange Postfach ist.

Die Anweisung sieht wie folgt aus: ldap_compare('192.168.10.10;CN=Peter Mueller,OU=SBSUsers,OU=Users,

OU=MyBusiness,DC=Firma,DC=local;mypassword;OU=SBSUsers,OU=Users,

OU=MyBusiness,DC=Firma,DC=local;

(mail=$recipient)','MailServerGruppe','Exchange'){ log(1, 'Mitglied der AD-Gruppe Exchange');

} else { log(1, 'nicht Mitglied der AD-Gruppe Exchange');

}

Erklärung

Im LDAP Suchpfad (SearchBase) wird der Suchfilter (Filter) "(mail=$recipients)" angewendet.

Für die Empfänger der E-Mail, welche im LDAP--Verzeichnis gefunden wurden, im Besitz des genannten Attributs sind und der Wert dieses Attributs der Vorgabe entspricht "wird der Log-

Eintrag "Mitglied der AD-Gruppe Exchange" generiert. Für alle anderen Empfänger wird der Log-

Eintrag "nicht Mitglied der AD-Gruppe Exchange" generiert.

Beispiel 3

Ausgangspunkt sind wieder zwei unterschiedliche Groupware-Server, welche parallel eingesetzt werden.

Es soll abgefragt werden, ob das Postfach wenigstens eines internen Empfängers einer eingehenden E-Mail - mit gegebenenfalls mehreren Empfängern - ein Exchange Postfach ist.

Die Anweisung sieht wie folgt aus: ldap_compare('192.168.10.10;CN=Peter Mueller,OU=SBSUsers,OU=Users,

OU=MyBusiness,DC=Firma,DC=local;mypassword;OU=SBSUsers,OU=Users,

OU=MyBusiness,DC=Firma,DC=local;

(mail=$one_recipient)','MailServer','Exchange');

Erklärung

Im LDAP Suchpfad (SearchBase) wird der Suchfilter (Filter) "(mail=$one_recipient)" angewendet.

Hat wenigstens ein Empfänger der E-Mail "(mail=$one_recipient)" den Wert "Exchange" im

Attribut "MailServer" so ist der Rückgabewert positiv.

Beispiel 4

Es soll abgefragt werden, ob das Postfach aller internen Empfänger einer eingehenden E-Mail mit gegebenenfalls mehreren Empfängern - Domino Postfächer sind.

312

Die Anweisung sieht wie folgt aus: ldap_compare('192.168.10.10;CN=Peter Mueller,OU=SBSUsers,OU=Users,

OU=MyBusiness,DC=Firma,DC=local;mypassword;OU=SBSUsers,OU=Users,

OU=MyBusiness,DC=Firma,DC=local;

(mail=$all_recipients)','MailServer','Domino');

Erklärung

Im LDAP Suchpfad (SearchBase) wird der Suchfilter (Filter) "(mail=$all_recipients)" angewendet.

Nur wenn alle internen Empfänger der E-Mail "(mail=$all_recipients)" den Wert "Domino" im

Attribut "MailServer" haben, so ist der Rückgabewert positiv.

313

8.8.3

ldap_getcerts()

Der Befehl ldap_getcerts() ruft öffentliche S/MIME Schlüssel (Zertifikate) bei einem LDAP-

Verzeichnisdienst ab.

Dieser Befehl ruft für jeden Empfänger einer E-Mail öffentliche S/MIME Schlüssel (Zertifikate) bei einem LDAP-Verzeichnisdienst ab.

Aufbau des Befehls

ldap_getcerts('ldap');

Rückgabewert

positiv

immer

Parameter ldap

Der Parameter ist wie folgt aufgebaut:

'URI;BindDN;Password;SearchBase'

Die Bedeutung der einzelnen Teil Strings ist der der folgenden Tabelle beschrieben:

Parameter Beschreibung

URI

BindDN

Password

SearchBase

Angabe des LDAP Servers, der abgefragt werden soll. Als Eingabe wird der

Eingabe des vollständigen Distinguished Name (DN) des (read-only)

Accounts, welcher zur Suche des unter "SearchBase" in der LDAP Datenbank berechtigt ist.

Das Passwort des unter BindDN angegebenen Benutzers

Suchpfad: Gibt den Zweig der LDAP Datenbank an, in welchem das Attribute aus dem Parameter 'attr' zu suchen ist.

Beispiel

ldap_getcerts('ldap-directory.domain.tld;;;ou=pki-participant,dc=pki, dc=domain,dc=tld');

Erklärung

Der LDAP Server, welcher unter dem Fully Qualified Domain Naime (FQDN) "ldap-directory.

domain.tld" (auf dem Standardport 389) erreichbar ist, wird abgefragt.

Ein Benutzer (BindDN) mit Passwort (Password) zur Authorisierung der Abfrage ist nicht notwendig, da es sich im Beispiel um einen öffentlichen LDAP Verzeichnisdienst handelt.

Der LDAP Pfad, in welchem die Zertifikate abliegen lautet ou=pki-participant,dc=pki,dc=domain,dc=tld

314

8.8.4

ldap_getpgpkeys()

Der Befehl ldap_pgpkeys() ruft öffentliche openPGP Schlüssel bei einem LDAP-Verzeichnisdienst ab.

Dieser Befehl ruft für jeden Empfänger einer E-Mail öffentliche openPGP Schlüssel bei einem LDAP-

Verzeichnisdienst ab.

Aufbau des Befehls

ldap_getpgpkeys('ldap');

Rückgabewert

positiv

immer

Parameter ldap

Der Parameter ist wie folgt aufgebaut:

'URI;BindDN;Password;SearchBase'

Die Bedeutung der einzelnen Teil Strings ist der der folgenden Tabelle beschrieben:

Parameter Beschreibung

URI

BindDN

Password

SearchBase

Angabe des LDAP Servers, der abgefragt werden soll. Als Eingabe wird der

Eingabe des vollständigen Distinguished Name (DN) des (read-only)

Accounts, welcher zur Suche des unter "SearchBase" in der LDAP Datenbank berechtigt ist.

Das Passwort des unter BindDN angegebenen Benutzers

Suchpfad: Gibt den Zweig der LDAP Datenbank an, in welchem das Attribute aus dem Parameter 'attr' zu suchen ist.

Beispiel

ldap_getpgpkeys('ldap-directory.domain.tld;;;ou=pki-participant,dc=pki, dc=domain,dc=tld');

Erklärung

Der LDAP Server, welcher unter dem Fully Qualified Domain Naime (FQDN) "ldap-directory.

domain.tld" (auf dem Standardport 389) erreichbar ist, wird abgefragt.

Ein Benutzer (BindDN) mit Passwort (Password) zur Authorisierung der Abfrage ist nicht notwendig, da es sich im Beispiel um einen öffentlichen LDAP Verzeichnisdienst handelt.

Der LDAP Pfad, in welchem die öffentlichen openPGP Schlüssel abliegen lautet ou=pki-participant,dc=pki,dc=domain,dc=tld

315

8.9 Befehle für Content Management

8.9.1

iscalendar()

Der Befehl iscalendar() prüft, ob es sich bei einer E-Mail um einen Kalendereintrag handelt.

Der Befehl prüft, unter anderem anhand des Mime-Type text/calendar, ob es sich bei einer E-Mail um einen Kalendereintrag - zum Beispiel Einladungen, Termine, Besprechungsanfragen oder die jeweiligen Zu/Absagen - handelt. Diese Abfrage wird typischerweise für das anschliessende

Unterbinden kryptographischer Aktionen bei Kalendereinträgen verwendet, da viele E-Mail Clients damit nicht umgehen können.

Aufbau des Befehls

iscalendar();

Rückgabewert

positiv

wenn es sich bei der E-Mail um einen Kalendereintrag handelt

negativ

wenn es sich bei der E-Mail nicht um einen Kalendereintrag handelt

Parameter

keine

316

8.9.2

isspam()

Der Befehl isspam() prüft, ob es sich bei einer E-Mail um SPAM handelt.

Dieser Befehl ist nur bei aktiviertem Protection Pack verfügbar. Er prüft den SPAM Level einer E-Mail und führt die entsprechend der eingestellten Schwellwerte definierte Aktion aus (Markieren oder

Abweisen).

(siehe auch

Mail Processing

157

Ruleset Generator

Protection Pack (Anti-Spam / Anti-Virus)).

Aufbau des Befehls

isspam('marklevel', 'tag', 'rejectlevel');

Rückgabewert

positiv

immer

Parameter marklevel

Dieser Parameter definiert den Punktwert, ab welchem eine E-Mail als SPAM E-Mail markiert wird.

Wertebereich: 0.5 - 9.5

Schrittweite: 0.5

Markieren heisst dem Betreff einer E-Mail wird ein entsprechendes Merkmal hinzugefügt. Dieses

Merkmal wird mittels dem Parameter tag definiert

tag

Dieser Parameter definiert einen Wortbestandteil (tag) der zur Markierung einer E-Mail als SPAM an den Betreff angehängt wird.

rejectlevel

Dieser Parameter definiert den Punktwert, ab welchem eine E-Mail als SPAM E-Mail abgewiesen wird.

Wertebereich: 0.5 - 9.5

Schrittweite: 0.5

Beispiel

isspam('2.5', '[SPAM]', '4.5');

Erklärung

In diesem Beispiel wird eine E-Mail auf SPAM überprüft. Wird der SPAM Level von "2.5" erreicht, bleibt jedoch unter "4.5", so wird die E-Mail im Betreff mit dem Hinweis "[SPAM]" gekennzeichnet.

Ab Erreichen des Schwellwertes 4.5 wird die E-Mail abgewiesen (rejected).

317

8.9.3

partoftype()

Der Befehl partoftype() ermittelt den Dateityp von E-Mail Dateianhängen.

Dieser Befehl prüft, ob die Dateianlagen einer E-Mail einem bestimmten Typ entsprechen. Ist dies der

Fall , so wird eine definierte Aktion ausgeführt.nlagen passiert, wenn die Prüfung auf den Typ positiv ist. Die Inhalte von Archivdateien werden durchsucht, wenn check_archive den booleschen Wert true

hat. Statt true kann auch yes oder 1 verwendet werden.

Aufbau des Befehls

partoftype('type', 'action', 'check_archive');

Rückgabewert

positiv

wenn der angegebene MIME Type in der/den Anlage(n) der E-Mail gefunden wurde

negativ

wenn keine Anlage des genannten MIME Types gefunden wurde

Parameter type

Weitere Informationen zum Parameter Typ sind im Abschnitt

Liste der Dateitypen

319

zu finden.

action

Mögliche Werte info stellt das Resultat für die folgenden Befehle zu Verfügung delete default ist info entfernt zusätzlich die entsprechende Dateianlage aus der E-Mail

check_archive

Durch Anschalten dieses Parameter wird der angegebene MIME Type zusätzlich in Archivdateien

(siehe

Liste von Dateigruppen

318

ARCHIVES) gesucht.

Mögliche Werte: true, yes oder 1 false, no oder 0 default ist 0

Beispiel

partoftype('EXE', 'delete', 'true');

Erklärung

In diesem Beispiel wird eine E-Mail auf das Vorhandensein von Dateianhängen desTyps 'EXE'

überprüft. Wird ein Dateianhang gefunden, so wird dieser aus der E-Mail entfernt. Enthält die E-

Mail als Dateianhang eine Archivdatei, so wird diese ebenfalls durchsucht. Wird innerhalb der

Archivdatei eine Datei vom Typ 'EXE' gefunden, so wird die Datei aus dem Archiv entfernt.

318

8.9.3.1

Liste von Dateigruppen

Folgende Gruppen von Dateitypen werden unterschieden:

8.10 Vordefinierte Funktionen

Vordefinierte Funktionen beinhalten gegebenenfalls eine Abfolge von Befehlen, welche für das

Realisieren einer bestimmten Funktion von Nöten sind. Dabei werden vor allem variable Werte aus dem Ruleset Generator (siehe

Mail Processing

157

Ruleset Generator

) übernommen.

Dadurch kann die Ruleset Programmierung dynamisch auf Änderungen variabler Werte reagieren und wird somit vereinfacht, verkürzt und übersichtlicher.

8.10.1 @ADDDISCLAIMER@

Die Funktion @ADDDISCLAIMER@ hängt die Fussnote an, welche gemäss der Managed Domain

(siehe "

Mail System

130

Managed Domains

" Spalte "Disclaimer Setting" der angezeigten Tabelle) zur E-Mail Domäne des Absenders passt.

8.10.2 @ARCHIVE@

Die Funktion @ARCHIVE@ archiviert E-Mails unter Verwendung der unter "

Mail Processing

157

Ruleset Generator

Archiving" eingetragenen E-Mail Adresse.

8.10.3 @CREATEGPGKEYS@

Die Funktion @CREATEPGPKEYS@ erzeugt für den Absender einer E-Mail ein Schlüsselpaar, so wie es in der Administrationsoberfläche (siehe

Mail Processing

157

Ruleset Generator

Key Generation) definiert wurde.

Beispiel

createaccount('@CREATEGPGKEYS@');

8.10.4 @CREATEUSER@

Die Funktion @CREATEUSER@ generiert einen neuen Benutzer (siehe

Users

223

), gemäss der

Einstellungen wie sie in der Administrationsoberfläche unter

Mail Processing

157

Ruleset

Generator

User Creation definiert wurden, sofern dieser nicht bereits vorhanden ist.

8.10.5 @CREATESEPPMAILACCOUNT@

Die Funktion @CREATESEPPMAILACCOUNT@ generiert einen neuen GINA-Benutzer (siehe

GINA accounts

230

), gemäss der Einstellungen wie sie in der Administrationsoberfläche unter

Mail

Processing

150

GINA Settings

definiert wurden, sofern dieser nicht bereits vorhanden ist.

322

8.10.6 @KEYSERVER@

Die Funktion @KEYSERVER@ sucht auf den unter "

Mail Processing

157

Ruleset Generator

Key

Server" eingetragenen Schlüssel Servern nach öffentlichen Schlüsseln - egal ob openPGP oder S/

MIME - für das Verschlüsseln an externe Kommunikationspartner.

Beispiel

Zeile Code

01 @KEYSERVER@

03 if (pgp_keys_avail(){ log(1, 'pgp key available');

07 if (encrypt_pgp() { log(1, 'email successfully pgp encrypted');

} else { log(1, 'email could not be pgp encrypted');

11 }

}

} else { log(1, 'no pgp key available');

Erklärung

In diesem Beispiel wird über @KEYSERVER@ definiert, dass öffentliche Schlüssel - egal ob S/

MIME oder openPGP - nicht nur lokal auf der Appliance, sonder auch auf den in der

Administrationsoberfläche angegebenen Schlüssel Servern (siehe

Mail Processing

157

Ruleset

Generator

Key Server) gesucht werden soll (Zeile 1).

Der Befehl pgp_keys_avail() prüft somit sowohl lokal auf der Appliance als auch auf den in der Administrationsoberfläche angegebenen Schlüsselservern, ob ein passender, Benutzer basierter öffentlicher - im Beispiel openPGP - Schlüssel für das Verschlüsseln zur Verfügung steht

(Zeile 2). Das Ergebnis dieser Abfrage wird protokolliert (Zeile 3 und 10). Steht ein entsprechender

Schlüssel zur Verfügung, wird mit dem Verschlüsseln fortgefahren (Zeile 4), dessen Erfolg beziehungsweise Misserfolg ebenfalls protokolliert wird (Zeile 5 und 7).

8.10.7 @NOENCTEXT@

Die Funktion @NOENCTEXT@ gibt das im Ruleset Generator angegebene Betreffzeilen Schlüsselwort für das Unterdrücken des Verschlüsselns (siehe

Mail Processing

157

Ruleset Generator

Encryption/Decryption Outgoing e-mails

Do not encrypt mails with the following text in subject:

) aus.

Beispiel

Zeile Code

01 if (iscalendar()) {

log(1, 'meeting request, do not encrypt');

@REMOVETAGS@

tagsubject('@NOENCTEXT@');

} else {

}

Erklärung

In diesem Beispiel wird über den Befehl

iscalendar()

315

(Zeile 1) geprüft, ob es sich bei der E-

Mail um einen Kalendereintrag handelt. Wenn dem so ist, so wird dies im Log eingetragen (Zeile

2) , alle eventuell bereits vorhandenen Tags via

@REMOVETAGS@

325

entfernt (Zeile 3) und als nicht zu verschlüsselnd (@NOENCTEXT@) (Zeile 4) markiert.

323

8.10.8 @NOSIGNTEXT@

Die Funktion @NOSIGNTEXT@ gibt das im Ruleset Generator angegebene Betreffzeilen Schlüsselwort

für das Unterdrücken des Signierens (siehe

Mail Processing

157

Ruleset Generator

Signing

Outgoing e-mails

Do not S/MIME sign outgoing mails with the following text in subject:

) aus.

Beispiel

Zeile Code

01 if (iscalendar()) {

log(1, 'meeting request, do not encrypt or sign');

compare('subject','substitute','@SIGNTEXT@');

tagsubject('@NOSIGNTEXT@');

} else {

}

Erklärung

In diesem Beispiel wird über über den Befehl

iscalendar()

315

(Zeile 1) geprüft, ob es sich bei der

E-Mail um einen Kalendereintrag handelt. Wenn dem so ist, so wird dies im Log eingetragen (Zeile

2). Ein eventuell vorhandenes Tag zum Signieren (

@SIGNTEXT@

325

) der E-Mail wird entfernt

(Zeile 3) und - für den Fall, dass die Option für das Signieren aller ausgehenden E-Mails gesetzt ist - als nicht zu signierend (@NOSIGNTEXT@) (Zeile 4) markiert.

8.10.9 @PLAINTEXT@

Die Funktion @PLAINTEXT@ gibt das im Ruleset Generator angegebene Betreffzeilen Schlüsselwort für das Unterdrücken sämtlicher kryptographischer Verfahren (siehe

Mail Processing

157

Ruleset

Generator

General Settings

Do not touch mails with the following text in subject:

) aus.

Beispiel

Zeile Code

01 if (iscalendar()) {

log(1, 'meeting request, do not touch');

@REMOVETAGS@

tagsubject('@PLAINTEXT@');

} else {

}

Erklärung

In diesem Beispiel wird über über den Befehl

iscalendar()

315

(Zeile 1) geprüft, ob es sich bei der

E-Mail um einen Kalendereintrag handelt. Wenn dem so ist, so wird dies im Log eingetragen (Zeile

2) , alle eventuell bereits vorhandenen Tags via

@REMOVETAGS@

325

entfernt (Zeile 3) und als kryptographisch nicht zu behandelnd (@PLAINTEXT@) (Zeile 4) markiert.

324

8.10.10 @REMOVEFAILSIG@

Die Funktion @REMOVEFAILSIG@ entfernt die E-Mail Signatur aus einer E-Mail, wenn diese beim

Prüfen als ungültig erkannt wurde (vergleiche

Mail Processing

157

Ruleset Generator

Signing

Incoming e-mails "remove signature if S/MIME signature check fails").

Beispiel

Zeile Code

01 if (validate_smime_sig('true')) {

log(1, 'smime signed valid');

} else {

log(1, 'smime signed, but signature invalid');

@REMOVEFAILSIG@

}

Erklärung

In diesem Beispiel wird über über den Befehl

validate_smime_sig()

298

(Zeile 1) die Signatur einer E-Mail überprüft. Ist die Signatur valide, so wird das mittels

log()

261

in das Log geschrieben

(Zeile 2).

Ist die Signatur ungültig, So wird dies ebenfalls über den Befehl log() in das Log geschrieben

(Zeile 4). Zusätzlich wird über die Funktion @REMOVEFAILSIG@ die E-Mail Signatur der E-Mail entfernt (Zeile 5)

8.10.11 @REMOVEOKSIG@

Die Funktion @REMOVEOKSIG@ entfernt die E-Mail Signatur aus einer E-Mail, wenn diese beim Prüfen

als valide erkannt wurde (vergleiche

Mail Processing

157

Ruleset Generator

Signing Incoming emails "remove signature if S/MIME signature check succeeds").

Beispiel

Zeile Code

01 if (validate_smime_sig('true')) {

log(1, 'smime signed valid');

@REMOVEOKSIG@

} else {

log(1, 'smime signed, but signature invalid');

}

Erklärung

In diesem Beispiel wird über über den Befehl

validate_smime_sig()

298

(Zeile 1) die Signatur einer E-Mail überprüft. Ist die Signatur valide, so wird das mittels

log()

261

in das Log geschrieben

(Zeile 2). Zusätzlich wird über die Funktion @REMOVEOKSIG@ die E-Mail Signatur der E-Mail entfernt (Zeile 3).

Ist die Signatur ungültig, So wird dies ebenfalls über den Befehl log() in das Log geschrieben

(Zeile 5).

8.10.12 @REMOVELFMTAGS@

Die Funktion @REMOVELFMTAGS@ entfernt alle von der Appliance für LFM verwendeten Tags

(Betreffzeilen Schlüsselworte) aus einer E-Mail, also [LFM] und [LFM:nocrypt] (siehe auch Tabelle 1 des Kapitels

Steuern der Appliance

8.10.13 @REMOVETAGS@

Die Funktion @REMOVETAGS@ entfernt alle von der Appliance verwendeten Tags (Betreffzeilen

Schlüsselworte und Kennzeichen) aus einer E-Mail (siehe auch Tabelle 1 des Kapitels

Steuern der

Appliance

, in welcher die Standard Schlüsselworte gelistet sind). Dabei werden die im Ruleset

Generator (siehe

Mail Processing

157

Ruleset Generator

) vorgenommenen Änderungen der

Standard tags berücksichtigt.

8.10.14 @REMOVETAGDECRYPTED@

Die Funktion @REMOVETAGDECRYPTED@ entfernt das in der Appliance über den Ruleset Generator

(siehe

Mail Processing

157

Ruleset Generator

Encryption/Decryption Incoming e-mails

Add this text to message subject after decryption

) festgelegte Tag (Betreffzeilen Kennzeichen), welches nach erfolgreichem

Entschlüsseln gesetzt wird - im Standard [secure] - aus dem Betreff einer E-Mail.

325

8.10.15 @REMOVETAGSIGNED@

Die Funktion @REMOVETAGSIGED@ entfernt das in der Appliance über den Ruleset Generator (siehe

Mail Processing

S/MIME signature check succeeds:

) festgelegte tag (Betreffzeilen Kennzeichen), welches nach dem erfolgreichen Prüfen einer S/MIME Signatur - im Standard [signed OK] - gesetzt wird, aus dem Betreff einer E-Mail.

157

Ruleset Generator

Signing Incoming e-mails

Add this text to message subject if

8.10.16 @REMOVETAGSIGNEDINVALID@

Die Funktion @REMOVETAGSIGNEDINVALID@ entfernt das in der Appliance über den Ruleset

Generator (siehe

Mail Processing

157

Ruleset Generator

Signing Incoming e-mails

Add this text to message subject if S/MIME signature check fails:

) festgelegte tag (Betreffzeilen Kennzeichen), welches nach dem Prüfen einer S/MIME signierten E-Mail mit ungültiger Signatur - im Standard ist das [signed

INVALID] - gesetzt wird, aus dem Betreff einer E-Mail.

8.10.17 @SIGNTEXT@

Die Funktion @SIGNTEXT@ gibt das im Ruleset Generator angegebene Betreffzeilen Schlüsselwort für das Signieren (siehe

Mail Processing

157

Ruleset Generator

Signing Outgoing e-mails

S/MIME sign outgoing mails with the following text in subject:

) aus.

326

8.10.18 @TAGDECRYPTED@

Die Funktion @TAGDECRYPTED@ fügt dem Betreff einer E-Mail das im Ruleset Generator (siehe

Mail

Processing

157

Ruleset Generator

Encryption/Decryption Incoming e-mails

Add this text to message subject after decryption

) eingetragene Schlüsselwort für entschlüsselte E-Mails an.

Beispiel

Zeile Code

01 if (decrypt_smime()) {

log(1, 'mail is smime signed encrypted');

@TAGDECRYPTED@

} else {

log(1, 'mail could not be smime decrypted');

}

Erklärung

In diesem Beispiel wird über über den Befehl

decrypt_smime()

294

(Zeile 1) versucht die E-Mail

mit einem passenden S/MIME User-Key zu entschlüsseln. Gelingt dies, so wird das mittels

log()

261

in das Log geschrieben (Zeile 2). Zusätzlich wird über die Funktion @TAGDECRYPTED@ (Zeile

3) dem Betreff der E-Mail das Kennzeichen für die erfolgreiche Entschlüsselung (im Standard

[secure]) hinzugefügt.

Schlägt die Entschlüsselung fehl, so wird dies ebenfalls über den Befehl log() in das Log geschrieben (Zeile 5).

8.10.19 @TAGHEADERDECRYPTED@

Die Funktion @TAGHEADERDECRYPTED@ fügt einer E-Mail den im Ruleset Generator (siehe

Mail

Processing

157

Ruleset Generator

Header tagging

Set header to value For all mails that have been decrypted

) eingetragenen x-header mit dem entsprechenden Wert an.

Beispiel

Zeile Code

01 if (decrypt_smime()) {

log(1, 'mail is smime signed encrypted');

@TAGHEADERDECRYPTED@

} else {

log(1, 'mail could not be smime decrypted');

}

Erklärung

In diesem Beispiel wird über über den Befehl

decrypt_smime()

294

(Zeile 1) versucht die E-Mail

mit einem passenden S/MIME User-Key zu entschlüsseln. Gelingt dies, so wird das mittels

log()

261

in das Log geschrieben (Zeile 2). Zusätzlich wird über die Funktion

@TAGHEADERDECRYPTED@

(Zeile 3) der E-Mail der x-header für erfolgreich entschlüsselte E-Mails angefügt.

Schlägt die Entschlüsselung fehl, so wird dies ebenfalls über den Befehl log() in das Log geschrieben (Zeile 5).

327

8.10.20 @TAGHEADERENCRYPTED@

Die Funktion @TAGHEADERENCRYPTED@ fügt einer E-Mail den im Ruleset Generator (siehe

Mail

Processing

157

Ruleset Generator

Header tagging

Set header to value For all mails that have been encrypted

) eingetragenen x-header mit dem entsprechenden Wert an.

Beispiel

Zeile Code

02 if (encrypt_smime()) {

log(1, 'mail is smime signed encrypted');

@TAGHEADERENCRYPTED@

} else {

log(1, 'mail could not be smime decrypted');

}

Erklärung

In diesem Beispiel wird über über den Befehl

encrypt_smime()

296

(Zeile 1) versucht die E-Mail

mit einem passenden S/MIME User-Key zu entschlüsseln. Gelingt dies, so wird das mittels

log()

261

in das Log geschrieben (Zeile 2). Zusätzlich wird über die Funktion

@TAGHEADERENCRYPTED@

(Zeile 3) der E-Mail der x-header für erfolgreich verschlüsselte E-Mails angefügt.

Schlägt die Verschlüsselung fehl, so wird dies ebenfalls über den Befehl log() in das Log geschrieben (Zeile 5).

8.10.21 @TAGSIGNED@

Die Funktion @TAGSIGNED@ fügt dem Betreff der E-Mail die zur Kennzeichnung erfolgreich geprüfter

Signaturen definierte Markierung hinzu (siehe

Mail Processing

157

Ruleset Generator

Signing

Incoming e-mails "Add this text to message subject if S/MIME signature check succeeds:").

Beispiel

Zeile Code

01 if (validate_smime_sig('true')) {

log(1, 'smime signed valid');

@TAGSIGNED@

} else {

log(1, 'smime signed, but signature invalid');

}

Erklärung

In diesem Beispiel wird über über den Befehl

validate_smime_sig()

298

(Zeile 1) die Signatur einer E-Mail überprüft. Ist die Signatur valide, so wird das mittels

log()

261

in das Log geschrieben

(Zeile 2). Zusätzlich wird über die Funktion @TAGSIGNED@ (Zeile 3) dem Betreff der E-Mail das

Kennzeichen für erfolgreich geprüfte Signaturen - im Standard [signed OK] angefügt.

Ist die Signatur ungültig, so wird dies ebenfalls über den Befehl log() in das Log geschrieben

(Zeile 5).

328

8.10.22 @TAGSIGNEDINVALID@

Die Funktion @TAGSIGNEDINVALID@ fügt dem Betreff der E-Mail die zur Kennzeichnung ungültiger

Signaturen definierte Markierung hinzu (siehe

Mail Processing

157

Ruleset Generator

Signing

Incoming e-mails "Add this text to message subject if S/MIME signature check fails:").

Beispiel

Zeile Code

01 if (validate_smime_sig('true')) {

log(1, 'smime signed valid');

} else {

log(1, 'smime signed, but signature invalid');

@TAGSIGNEDINVALID@

}

Erklärung

In diesem Beispiel wird über über den Befehl

validate_smime_sig()

298

(Zeile 1) die Signatur einer E-Mail überprüft. Ist die Signatur valide, so wird das mittels

log()

261

in das Log geschrieben

(Zeile 2).

Ist die Signatur ungültig, So wird dies ebenfalls über den Befehl log() in das Log geschrieben

(Zeile 4). Zusätzlich wird über die Funktion @TAGSIGNEDINVALID@ (Zeile 5) dem Betreff der E-

Mail das Kennzeichen für ungültige Signaturen - im Standard [signed INVALID] - angefügt.

8.10.23 @TRIGGERTEXT@

Die Funktion @TRIGGERTEXT@ gibt das im Ruleset Generator angegebene Betreffzeilen

Schlüsselwort für das Verschlüsseln (siehe

Mail Processing

157

Ruleset Generator

Encryption/

Decryption Outgoing e-mails

Always encrypt mails with the following text in subject:

) aus.

329

330

8.11 Anwendungsbeispiele für das Regelwerk

Die hier dargestellten Codebeispiele sollen als Vorlage zur Abbildung spezifischer Anforderungen dienen.

Achtung !!!

Bei den hier aufgelisteten Code-Beispielen handelt es sich lediglich Vorschläge beziehungsweise Empfehlungen.

Vor dem Aktivieren ist in jedem Fall zu prüfen, ob das jeweilige Beispiel 100%ig auf die Anforderung passt und gegebenenfalls entsprechend anzupassen.

Sollten Kombinationen aus diesen Code-Beispielen benötigt werden, so ist unbedingt auf die korrekte Reihenfolge sowie der entsprechenden Platzierung im Regelwerk zu achten.

331

8.11.1 Bounce von E-Mails nicht authentifizierter Benutzer

Wurde zum Beispiel unter

Mail Processing

Ruleset Generator

User Creation die Option

"Manual User Creation" gewählt (siehe

Mail Processing

157

Ruleset Generator

), so werden im

Standardverhalten der Appliance E-Mails von Benutzern aus Managed Domains kryptographisch

unbehandelt durchgeleitet, wenn diese Absender keinen Benutzer Account (siehe auch

Users

223

) auf der Appliance haben.

Sollen E-Mails dieser Absender entgegen dem Standardverfahren abgewiesen (bounced) werden, so kann dies über einen Custom Command erreicht werden.

Konfigurationsvorschlag

Anlegen des Templates "bounce_no_user" über

Mail Processing

Edit Mail Templates

(siehe

Mail Processing

155

Edit Mail Templates

)

Navigieren zu

Mail Processing

Ruleset Generator

Custom Commands

Custom commands for User Creation:

(siehe

Mail Processing

157

Ruleset Generator

)

Aktivieren der Option sowie Einfügen des folgenden Codes in das darunter liegende

Eingabefeld:

Zeile Code

01 if (authenticated()) {

} else { bounce('bounce_no_user', 'true');

05 } log(1, 'user account missing');

Umstellen der Option

Mail Processing

Ruleset Generator

User Creation von Manual

user creation: Only process outgoing mails from users with an account auf automatically

create accounts for new users if user tries to sign / encrypt

Beschreibung

Zunächst wird hier geprüft, ob der Absender der E-Mail einen Benutzer Account auf der Appliance besitzt (Zeile 01). Ist dies der Fall, so wird das Standard Ruleset weiter ausgeführt. Andernfalls wird die E-Mail abgewiesen (gelöscht) und eine Bounce-Mail an den Absender unter Verwendung der Vorlage "bounce_no_user" und mit dem Header der ursprünlichen E-Mail an den Absender gesendet (Zeile 03) und der Vorgang in das Log geschrieben (Zeile 04).

Damit im Ruleset die entsprechende Stelle erreicht werden kann, muss die User Creation von

Manual user creation auf automatically create accounts for new users if user tries to sign /

encrypt umgestellt werden.

Variationen

Anstelle des Befehls bounce() kann die E-Mail auch über den Befehl drop() abgewiesen werden.

Verwendete

Befehle

authenticated()

bounce()

drop()

281

279

log()

261

252

Funktionen

keine

332

8.11.2 Einschränken des LFM berechtigten Personenkreises mittels LDAP Abfrage

Ist auf der Appliance das Zusatz-Feature LFM zwar lizensiert und aktiviert (siehe

Mail Processing

GINA domains

Edit

Large File Management

174

), soll jedoch nur einem eingeschränkten

Personenkreis zur Verfügung gestellt werden, so kann dies zum Beispiel durch die Abfrage eines

LDAP-Verzeichnisdienstes erfolgen.

Konfigurationsvorschlag

Navigieren zu

Mail Processing

Ruleset Generator

Custom Commands

Custom commands for outgoing e-mails BEFORE encryption:

(siehe

Mail Processing

157

Ruleset

Generator

)

Aktivieren der Option sowie Einfügen des folgenden Codes in das darunter liegende

Eingabefeld:

Zeile Code

01 if (compare('X-ESWmail-LFM','match','.')) {

log(1,'Mail is LFM, check if user is allowed to use');

if (ldap_compare('192.168.10.10;CN=Peter Mueller,OU=SBSUsers,

OU=Users,OU=MyBusiness,DC=Firma,DC=local;mypassword;OU=SBSUsers,

OU=Users,OU=MyBusiness,DC=Firma,DC=local;

(mail=$sender)','memberOF','LFM-Benutzer')) {

log(1,'User is allowed to send large files, proceeding');

} else {

log(1,'User is not allowed to send large files, mail will be

10 rejected');

drop('500','User is not allowed to send large files');

}

} else {

}

Beschreibung

In diesem Beispiel wird zunächst geprüft, ob es sich um eine "LFM"-Mail Handelt (Zeile 01). Ist dies der Fall, so wird dies zunächst in das Log geschrieben (Zeile 02) und anschliessend über eine

LDAP-Anfrage (in diesem Fall AD) die Zugehörigikeit des Absenders zur berechtigten Gruppe geprüft (Zeile 03). Ist der Absender berechtigt, so wird dies im Log eingetragen und im Ruleset fortgefahren (Zeile 04). Andernfalls wird dies ebenfalls in das Log eingetragen (Zeile 06), die Mail jedoch verworfen (Zeile 07).

Variationen

Anstelle des Befehls drop() kann die E-Mail auch über den Befehl bounce() unter Verwendung eines entsprechenden Templates abgewiesen werden.

Verwendete

Befehle

authenticated()

bounce()

279

compare()

254

ldap_compare()

drop()

281

252

309

log()

261

Funktionen

keine

333

8.11.3 GINA-Verschlüsselung zwischen Mandanten erzwingen

Ist die SEPPmail-Appliance als mandantenfähiges System (siehe

Customers

243

) mit der Anforderung eingerichtet, alle E-Mails mit einem Verschlüsselungskennzeichen zwischen den Mandanten mittels

GINA-Technologie zu verschlüsseln, so kann dies zum Beispiel wie folgt realisiert werden.

Konfigurationsvorschlag

Navigieren zu

Mail Processing

Ruleset Generator

Custom Commands

Custom commands for incoming e-mails BEFORE decryption:

(siehe

Mail Processing

157

Ruleset

Generator

)

Einfügen des folgenden Codes in das Eingabefeld:

Zeile Code

01 log(1, 'Start custom commands for incoming e-mails BEFORE decryption');

02 if (from_managed_domain()) {

if (compare('x-smenc', 'equal', 'yes')) {

log(1, 'Encryption requested by AddIn, encrypt with GINA');

@REMOVETAGS@

@CREATEUSER@

@CREATESEPPMAILACCOUNT@

if (encrypt_webmail()) {

} else {

log(1, 'webmail encryption failed');

drop ('550', 'Mail not accepted');

}

} else {

}

if (compare('subject', 'substitute', '(?i)@TRIGGERTEXT@')) {

log(1, 'Encryption requested by tag @TRIGGERTEXT@, encrypt with GINA');

@REMOVETAGS@

@CREATEUSER@

@CREATESEPPMAILACCOUNT@

if (encrypt_webmail()) {

} else {

log(1, 'webmail encryption failed');

drop ('550', 'Mail not accepted');

}

} else {

}

if (compare('sensitivity', 'equal', '(?i)companyconfidential'))

{

log(1, 'Encryption requested by sensitivity flag, encrypt with GINA');

@REMOVETAGS@

@CREATEUSER@

@CREATESEPPMAILACCOUNT@

if (encrypt_webmail()) {

} else {

log(1, 'webmail encryption failed');

drop ('550', 'Mail not accepted');

}

} else {

}

334

Zeile Code

39 } else {

40 }

Beschreibung

Zunächst wird hier geprüft, ob die E-Mail von einer bekannten Maildomäne (siehe

Mail System

130

Managed Domains

) stammt (Zeile 2). Im nächsten Schritt wird geprüft, ob vom Absender ein

Verschlüsselungsmerkmal gesetzt wurde (Zeile 3, 15, 27). Die folgenden zwölf Anweisungen auf die zuvor genannten Abfragen aus den Zeilen 3, 15 und 27 sind identisch.

So wird der auslösende Trigger protokolliert (Zeile 4, 16, 28) und eventuell weitere vorhandene

Betreffzeilen Schlüsselworte und Kennzeichen entfernt (Zeile 5, 17, 29).

Der Absender der E-Mail wird als Benutzer auf der Appliance angelegt, sofern er noch nicht vorhanden ist (Zeile 6, 18, 30). Ebenso wird der oder die Empfänger der E-Mail als GINA-Benutzer angelegt, sofern diese nicht bereits vorhanden sind (Zeile 7, 19, 31).

Danach wird die E-Mail GINA verschlüsselt (Zeile 8, 20, 32). Sollte die GINA-Verschlüsselung fehlschlagen (Zeile 9, 21, 33, so würde dies protokolliert (Zeile 10, 22, 34) und die E-Mail verworfen werden (Zeile 11, 23, 35).

Variationen

Zurückweisen von E-Mails bei Fehlschlagen der GINA Verschlüsselung anstatt diese zu verwerfen

Im Anweisungsblock if (encrypt_webmail()) {

} else { log(1, 'webmail encryption failed');

drop('550', 'Mail not accepted');

} ist jeweils der Befehl drop() durch bounce() zu ersetzen, zum Beispiel if (encrypt_webmail()) {

} else { log(1, 'webmail encryption failed');

bounce('bounce_noenc');

}

Kennzeichnen der E-Mails statt diese mittels GINA Technologie zu verschlüsseln

Wird der komplette Anweisungsblock if (encrypt_webmail()) {

} else { log(1, 'webmail encryption failed'); drop('550', 'Mail not accepted');

} jeweils durch die Funktion @TAGHEADERENCRYPTED@ ersetzt,

@TAGHEADERENCRYPTED@ so werden statt dem Erzwingen der GINA-Technologie die entsprechenden E-Mails lediglich als sicher gekennzeichnet (Standardkennzeichen ist [secure]).

Verwendete

Befehle

bounce()

279

compare()

254

drop()

281

encrypt_webmail()

302

from_managed_domain()

log()

261

259

Funktionen

@CREATEUSER@

321

@CREATESEPPMAILACCOUNT@

@REMOVETAGS@

325

321

@TAGHEADERENCRYPTED@

@TRIGGERTEXT@

329

326

335

336

8.11.4 Behandlung von E-Mails zwischen Mandanten

Auf mandantenfähigen Systemen ist das Standardverhalten bei der Kommunikation zwischen den

Mandanten systembedingt anders, als bei der Kommunikation hin zu externen

Kommunikationspartnern.

Wird zum Beispiel eine E-Mail vom Absender an einen anderen Mandanten auf der gleichen

SEPPmail-Appliance als zu verschlüsselnd markiert, so ergäbe es keinen Sinn diese zu verschlüsseln und anschliessend sofort wieder zu entschlüsseln.

Um das Markieren der E-Mails so anzupassen, dass es für den jeweiligen Empfänger-Mandanten so aussieht, als käme die E-Mail aus dem Internet und nicht von einem anderen Mandanten auf der gleichen SEPPmail-Appliance, sind die folgenden "Custom Commands" in das Ruleset einzubinden.

ACHTUNG !!!

Der Grund, weshalb diese Funktion nicht bereits im Standard Bestandteil mandantengetrennter Systeme ist, liegt in einem gewissen Gefahrenpotential, bei unsachgemäß eingerichteter Infrastruktur.

Deshalb ist vor dem Aktivieren dieses „Custom“ Teils unbedingt vom Betreiber sicher zu stellen – in der Regel durch vorgeschaltete Schutzinstanzen – dass weder aus dem Internet, noch von Managed Domains anderer, auf der SEPPmail-Appliance verwalteten Mandanten, E-Mails mit gefälschtem Absender auf die SEPPmail-

Appliance gelangen.

Würde eine, aus dem Internet stammende E-Mail, mit einer gefälschten

Absenderadresse einer Managed Domain auf die Appliance gelangen, so würde diese ebenfalls gemäß diesem Ruleset behandelt und somit fälschlicherweise als

„sicher“ eingestuft!

Konfigurationsvorschlag

Navigieren zu

Mail Processing

Ruleset Generator

Custom Commands

Custom commands for outgoing e-mails BEFORE decryption:

(siehe

Mail Processing

157

Ruleset

Generator

)

Aktivieren der Option sowie Einfügen des folgenden Codes in das darunter liegende

Eingabefeld:

Zeile Code

01 log(1, 'Start custom commands for incoming e-mails BEFORE decryption');

03 if (from_managed_domain()) {

log(1, 'Mail is from Managed Domain');

if (compare('x-smsign', 'equal', 'yes')) {

log(1, 'Signing requested by AddIn, tag as signed ok');

rmheader('x-smenc');

@TAGSIGNED@

} else {

}

if (compare('subject', 'substitute', '@SIGNTEXT@')) {

log(1, 'Signing requested by subject tag, tag as signed ok');

@TAGSIGNED@

} else {

}

if (compare('sensitivity', 'equal', 'private')) {

log(1, 'GINA encryption requested by sensitivity flag, encrypt with GINA');

337

Zeile Code

17 @CREATEUSER@

@CREATESEPPMAILACCOUNT@

if (encrypt_webmail()) {

deliver();

} else {

log(1, 'webmail encryption failed');

bounce('bounce_noenc');

}

} else {

}

if (compare('subject', 'equal', '[priv]')) {

log(1, 'GINA encryption requested by sensitivity flag, encrypt with GINA');

@CREATEUSER@

@CREATESEPPMAILACCOUNT@

if (encrypt_webmail()) {

deliver();

} else {

log(1, 'webmail encryption failed');

bounce('bounce_noenc');

}

} else {

}

log(1, 'Deleting encryption triggers, tag as secure');

if (compare('x-smenc', 'equal', 'yes')) {

rmheader('x-smenc');

} else {

}

compare('subject', 'substitute', '@TRIGGERTEXT@');

@TAGDECRYPTED@

deliver();

} else {

log(1, 'Mail is not from Managed Domain, going on in standard ruleset');

}

Beschreibung

Mit Zeile 1 wird der Beginn der "Custom Command" Abfolge in das Log geschrieben

In Zeile 2 wird geprüft, ob eine E-Mail von einer auf der SEPPmail-Appliance verwalteten E-Mail

Domäne (Manged Domain) - also einem anderen Mandanten - kommt. Falls nicht, wird dies im

Log eingetragen (Zeile 47) und im Standard Ruleset fortgefahren.

Die beiden folgenden Anweisungsblöcke sind nur dann relevant, wenn die Optionen

S/MIME sign outgoing mails with the following text in subject:

und

Add this text to message subject if S/MIME signature check succeeds:

des

Ruleset Generator

s im Abschnitt Signing aktiv sind.

Im Block Zeile 4 - 9 wird geprüft, ob die E-Mail mittels Outlook AddIn als zu signierend gekennzeichnet wurde. Ist dies der Fall, so wird der entsprechende x-header (x-smsign) aus der

E-Mail entfernt und dem Betreff der E-Mail das Kennzeichen für eine gültige Signatur - im

Standard [signed OK] - hinzugefügt.

Im Block Zeile 10 - 14 wird geprüft, ob die E-Mail mittels Betreffzeilen Kennzeichen - im Standard

[sign] - als zu signierend gekennzeichnet wurde. Ist dies der Fall, so wird dieses Kennzeichen mit dem Kennzeichen für eine gültige Signatur - im Standard [signed OK] - ersetzt.

Der Anweisungsblock Zeile 15 - 26 ist nur dann relevant, wenn die Option

Always use GINA technology for mails with Outlook "private" flag set

des

Ruleset Generator

s im Abschnitt

Encryption/Decryption aktiv ist.

338

Es wird geprüft, ob GINA-Verschlüsselung über den sensitivity-header (dieser wird zum Beispiel im Outlook durch das Setzen des Vertraulichkeits-Flags gesetzt) "private" angefordert wurde. Ist dies der Fall, so wird die E-Mail GINA-verschlüsselt.

Der Anweisungsblock Zeile 27 - 38 ist nur dann relevant, wenn die Option

Always use GINA technology for mails with the following text in subject:

des

Ruleset Generator

s im Abschnitt

Encryption/Decryption aktiv ist.

Es wird geprüft, ob GINA-Verschlüsselung über in der Option angegebene Schlüsselwort angefordert wurde. Ist dies der Fall, so wird die E-Mail GINA-verschlüsselt.

Im Block Zeile 39 - 44 werden jegliche Verschlüsselungs-Trigger entfernt.

In Zeile 45 wird die E-Mail als sicher - im Standard [secure] - markiert, da die E-Mail sowohl beim

Übermitteln vom Absender-Mandanten, wie auch hin zum Empfänger-Mandanten über gesicherte

Kanäle stattfindet.

Verwendete

Befehle

bounce()

279

compare()

254

deliver()

280

encrypt_webmail()

302

from_managed_domain()

log()

261

rmheader()

271

259

Funktionen

@CREATESEPPMAILACCOUNT@

321

@CREATEUSER@

321

@TAGDECRYPTED@

326

@TAGSIGNED@

327

339

9 HowTo

9.1 IronPort Anbindung der SEPPmail

Achtung:

Wichtig ist, die aktuelle Policy des IronPort Systems zu verstehen, bevor Änderungen durchgeführt werden.

Konfigurationsvorschlag

Alle einkommenden E-Mails werden von IronPort empfangen und auf SPAM und Viren geprüft. Alle soweit geprüften E-Mails werden an die SEPPmail-Appliance weitergeleitet, wo diese gegebenenfalls entschlüsselt und zur IronPort zurück gesendet werden. Dort werden alle E-Mails (jetzt auch die entschlüsselten) nochmals Viren und SPAM geprüft und an das interne Groupware-System, zum

Beispiel MS-Exchange oder Lotus Notes, weitergeleitet.

Alternativ kann das IronPort-System veranlasst werden, verschlüsselte und/oder signierte E-Mails zu erkennen und nur diese an die SEPPmail-Appliance umleiten. Alle anderen E-Mails werden direkt an das interne Groupware-System weitergeleitet.

Ausgehende E-Mails schickt das interne Groupware-System zu IronPort. Dieses leitet ausgehende E-

Mails in jedem Fall zu SEPPmail weiter. Dort wird das Regelwerk gepflegt, welche E-Mails signiert und verschlüsselt werden sollen. Anschliessend werden die ausgehenden E-Mails vom SEPPmail-System zurück zum IronPort-System geleitet, welches als einziges System E-Mails in Richtung Internet versendet.

Das Problem bei dieser Konfiguration ist, dass das SEPPmail-System in der Relayliste des IronPort-

Systems stehen muss, da das SEPPmail-System ausgehende E-Mails in Richtung Internet versenden will. Für alle Hosts in der Relay-Liste von IronPort gilt automatisch immer die Outgoing Mail Policy.

Nach der akutellen Outgoing Policy findet dort keine Virenprüfung statt, so dass die SEPPmail

Anbindung so keinen Zusatznutzen bringt.

Dazu gibt es zwei Lösungen:

1. Die Outgoing Mail Policy auf dem IronPort System wird so umgebaut, dass sie ähnlich aussieht wie die Incoming Policy. Das ist aber eine unschöne Lösung.

2. Sie konfigurieren einen speziellen Listener, über den die SEPPmail-Appliance eingehende E-Mails einliefert. Auf diesem Listener darf das SEPPmail-System nicht in der Relay-Liste eingetragen sein.

Dieser Listener kann zum Beispiel auf der bestehenden IP-Adresse 192.168.1.11 auf einen speziellen Port (zum Beispiel 10025) gebunden sein, oder auf einer weiteren IP-Adresse im IP-

Netzwerk 192.168.1.0/24.

Die Umleitung kann man auf zwei Arten Implementieren:

1. per Content Filter

2. per Message Filter

Der Unterschied zwischen Message Filter und Content Filter ist, dass ein Message Filter immer auf die gesamte E-Mail angewendet wird. Hat eine E-Mail zum Beispiel mehrere Empfänger, so gilt die Aktion für alle Empfänger. Bei einem Content Filter kann man über verschiedene Policy-Einträge die E-Mail aufsplitten. Das sollte in unserem Fall keine Rolle spielen. Ein weiterer Unterschied ist, dass man im

Message Filter erkennen kann, ob eine E-Mail verschlüsselt oder signiert ist und somit nur diese E-

Mail zur SEPPmail-Appliance umleiten kann.

340

Um die Lösung einfach und übersichtlich zu gestalten empfehlen wir, alle ausgehenden E-Mails zur

SEPPmail-Appliance weiterzuleiten (nicht nur die zu verschlüsselnden oder signierenden E-Mails) und mit einem Content Filter zu arbeiten.

Konfiguration

IronPort

Bestehender Listener mit SEPPmail in der Relay-Liste

Neuer Listener Incoming SEPPmail mit SEPPmail nicht in der Relay-Liste

Incoming Contentfilter : IncomingSEPPmail

(normalerweise nicht notwendig: Receiving Listener = IncomingMail AND)

Remote IP IS NOT \[IP von SEPPmail 1\]

AND

Remote IP IS NOT \[IP von SEPPmail 2\]

(optional, falls Sie nur eine Ihrer Domänen über SEPPmail betreiben lassen wollen: AND Envelope Recipient ends with @securemailcustomer.ch

)

Action: Send to Alternate Destination Host: \[Cluster IP der beiden SEPPmail\]

SEPPmail

Das SEPPmail System ist so einzurichten, dass eingehende E-Mails an den Incoming SEPPmail

Listener geschickt werden.

Menü

Mail System

: Siehe

" Zu verwaltende E-Mail Domänen einrichten"

Sektion

Managed Domains

Das Problem hier ist, dass in der SEPPmail Konfiguration nur eine einzige IP-Adresse angegeben werden kann, wohin die eingehenden E-Mails weitergeleitet werden, also nicht beide Incoming IP-

Adressen Ihrer IronPorts. Hierzu ist es notwendig, einen (fiktiven) DNS-Eintrag zu erzeugen, welcher in beide IP-Adressen der IronPorts aufgelöst werden kann. Dieser fiktive DNS-Name wird als "Server

IP Address" der E-Mail-Domäne eingetragen.

Ausgehende E-Mail versendet SEPPmail an den bestehenden Listener:

Siehe

Ausgehenden E-Mail-Verkehr steuern"

Sektion

Outgoing Server

Hier ist die IP-Adresse des Listeners anzugeben, bzw. wie oben ein Hostname, welcher auf beide

Listener aufgelöst wird.

Für beide IP-Adressen der IronPort Systeme ist im SEPPmail-System die Relay-Berechtigung einzutragen. Siehe

Mail Relaying"

Sektion

Relaying

Die Konfigurationsbeschreibung für die SEPPmail - IronPort Anbindung wurde uns mit freundlicher

Genehmigung zur Verfügung gestellt von:

AVANTEC AG

Badenerstrasse 281

CH-8003 Zürich http://www.avantec.ch

[email protected]

341

342

9.2 Mehrere SMTP-Authentifizierungen verwalten

Bezüglich des Verwaltens mehrerer SMTP Authentifizierungen könnte ich gegebenenfalls einen

Workaround anbieten. Allerdings nur für die Verbindung von Groupware Systemen auf die SEPPmail

Appliance, nicht von der SEPPmail Appliance auf einen Smarthost zum oder im Internet.

Für das Einrichten des Workarounds gehen Sie bitte wie folgt vor:

1. Erstellen einer (Pseudo-)Managed Domain, welche als Forwarding Server die [127.0.0.1] eingetragen bekommt

Administrationsoberfläche Menü „Mail System“, Sektion „Managed Domains“ Schaltfläche „Add

Domain…“, Sektion „Settings“ Eingabefeld „Domain Name“, Eingabe des Pseudo- Domänen

Namen zum Beispiel „pseudo.local“, Eingabefeld „Forwarding Server“, Eingabe „[127.0.0.1]“

2. Anlage je eines Benutzers pro benötigter SMTP-Authentifizierung

Administrationsoberfläche Menü „Users“, Schaltfläche „Create new user account...“, Sektion

„User Data“ z.B.

Zugriff A

Zugriff B usw.

Am Groupware System wird nun die SEPPmail Appliance als SMTP-Server eingetragen und als

Benutzer für „Zugriff A“ „[email protected]“ mit dem vergebenen Passwort, als Benutzer für

„Zugriff B“ „[email protected]“ mit dem vergebenen Passwort usw..

343

Damit diese (Pseudo-)User keine User-Lizenz auf der Appliance verbrauchen, empfiehlt es sich diesen (Anmelde-)Benutzern das Recht für das kryptographischen Behandeln von E-Mails zu entziehen.

Hierzu sind in der Administrationsoberfläche im Menü „Users“ die entsprechenden Benutzer (im

Beispiel SMTP_Auth_A und SMTP_Auth_B) jeweils anzuklicken. Im Folgenden Menü sind in der

Sektion „User Data“ unter dem Punkt „Encryption Settings“ jeweils die Haken bei den Optionen „May not Encrypt mails“ und May not sign mail“ zu setzen.

344

9.3 Migrieren der Daten von einer „on premise Appliance“ auf eine

Mandanten Instanz einer MSP-Appliance

Die korrekte Vorgehensweise für das Migrieren der Daten von einer „on premise Appliance“ auf eine

Mandanten Instanz einer MSP-Appliance sieht wie folgt aus:

auf der „on premise Appliance“

a) a) Falls ausschliesslich die [default] GINA eingesetzt wurde, Erzeugen eines neuen GINA

Interfaces in dessen Namen und Hostname sich möglichst der Firmenname wiederspiegelt.

Andernfalls kann mit Punkt f) fortgefahren werden

-> Menü „Mail Processing“, Sektion „GINA domains“ Schaltfläche „Create new GINA Domain“ b) Öffnen der Eigenschaften dieser neuen "GINA domain"

-> Menü „Mail Processing“, Sektion „GINA domains“, Auswahl der zuvor erzeugten neuen GINA,

Schaltfläche „Edit“ c) Auswahl des Master Template [default]

-> Sektion "Master Template", Abschnitt "Master Template", Auswahl des Templates [default],

Schaltfläche "Save" d) Übernehmen aller Einstellungen aus dem "Master Template"

-> In allen folgenden Sektionen den Haken der Option "Use settings from master template" setzen und jeweils die Schaltfläche "Save" klicken. Im Anschluss jeweils den Haken aus "Use settings from master template" wieder entfernen und mit "Save" bestätigen.

e) Übernehmen der neu erzeugten GINA für die verwalteten Domänen

-> Menü "Mail System", Sektion "Managed Domains", anklicken einer verwalteten Domäne, im

Folgemenü in der Sektion "GINA and Disclaimer Settings" im Abschnitt "Use GINA Settings" die neu erstellte GINA auswählen. Der Vorgang muss für jede verwaltete Domäne wiederholt werden.

f) Aktivieren der Mandantenfähigkeit auf der „on premise Appliance“ (dieses Feature schalte ich auf

Anfrage für die entsprechende Appliance frei)

-> Menü „Customers“, Sektion „Multiple Customers“, Schaltfläche „Enable“ g) Einrichten eines Mandanten auf der Maschine, wobei die Namensgebung bereits den Konventionen des MSPs entsprechen sollte. Die hier eingetragene „Customer Admin E-Mail“ wird später täglich automatisiert das Mandanten Backup empfangen.

-> Menü „Customers“, Sektion „Multiple Customers“, Schaltfläche „Create new customer…“ h) Öffnen der Eigenschaften für den neu angelegten Mandanten

-> Menü „Customers“, Sektion „Multiple Customers“, Auswahl des zuvor erzeugten Mandanten,

Schaltfläche „Edit…“ i) Zuordnen des/r Mandanten Administrator(en). Diese können später selbständig die Log-Eintrage ihrer zugeordneten E-Mail Domänen sehen, ihre GINA Einstellungen vornehmen und ihre GINA

Benutzer verwalten.

-> Sektion „Customer Administrators“, Auswahl des/r Administratoren, Schaltfläche „Assign“ j) Zuordnen aller auf der Appliance verwalteten Domänen

-> Sektion „Assigned managed Domains“, Auswahl der Domäne(n), Schaltfläche „Add“ k) Zuordnen aller auf der Appliance vorhandenen GINA Benutzer

-> Sektion „Assigned GINA accounts“, Schaltfläche „Manage accounts“ -> Sektion „Assign oter

GINA accounts“, Auswahl der Schaltfläche „Assign“ für jeden in der Sektion befindlichen GINA

Benutzer

-> nach Abschluss dieser Aktion zurück in das übergeordnete Menü über die Schaltfläche „Back“ l) Vergeben des Mandanten Backup Passwortes

-> Sektion „Backup/Restore“, Abschnitt „Backup“, Schaltfläche „Change Password“ m) Download des Backups

-> Sektion „Backup/Restore“, Abschnitt „Backup“, Schaltfläche „Download“

auf der „MSP Appliance“

n) Erstellen eines neuen Mandanten

-> Menü „Customers“, Sektion „Multiple Customers“, Schaltfläche „Create new customer…“ o) Im Menü für das Erstellen eines neuen Mandanten das zuvor auf der „on premise Appliance“ erstellte Backup importieren

-> Sektion „Backup/Restore“, Abschnitt „Restore“, Schaltfläche „Import Backup File“

345