Im Menüpunkt Mail Processing wird das Regelwerk des SEPPmail Secure E-Mail Gateways konfiguriert.
Dieses Regelwerk ist mit einem Workflow System vergleichbar und stellt das zentrale Element des SEPPmail Secure E-Mail Gateways dar.
Um spezielle Verschlüsselungsmethoden zu einzelnen Zielen einzurichten, steht über Edit policy table... das Sub-Menü zur Verfügung. Über dieses können - gegebenenfalls mandantengetrennt - entsprechende Regeln definiert werden.
(neu in 13.0.0)
Weiterhin steht über Edit extended fields... das Sub-Menü zur Verfügung. Über dieses können zusätzliche Konfigurationsfelder definiert werden, über welche allgemeingültige, beziehungsweise Managed Domain oder Customer spezifische Kennzeichen erstellt werden können, welche später beispielsweise für das Auslösen spezieller Verhaltensweisen im SMTP Ruleset verwendet werden können.
Abschnitte auf dieser Seite:
Zeigt die Erstelldaten des aktiven Rulesets an.
Parameter |
Beschreibung |
|
|---|---|---|
Zeigt die Firmware Version, mit welcher das aktuelle Ruleset erstellt, beziehungsweise hochgeladen wurde. |
||
Zeigt den User, welcher das aktuelle Ruleset aktiviert hat |
||
Zeigt das Aktivierungsdatum des aktuellen Rulesets. |
||
Zeigt, wie das Ruleset erstellt wurde. |
||
|
Über Generate ruleset mit den unter Ruleset generator angezeigten, beziehungsweise vorgenommenen Einstellungen. |
|
Über Upload ruleset |
||
Über Show ruleset wird der Ruleset Code angezeigt |
||
Generate ruleset generiert ein Ruleset mit den unter Ruleset generator angezeigten, beziehungsweise vorgenommenen Einstellungen.
|
Ist ein Ruleset vom Type „Upload“ aktiv, so wird Generate ruleset grau dargestellt. Um den Type auf „Generator“ ändern zu können, muss im Ruleset Generator zweimal Save geklickt werden! |
Upload ruleset... importiert einen, gegebenenfalls unter Zuhilfenahme der Referenz der Regelwerk-Anweisungen manuell geschriebenen Code aus der ausgewählten Datei.
Im Regelfall ist dies nicht zu empfehlen, da dieses Regelset dann auch unter Umständen bei Versionsupdates angepasst werden muss. Sinnvoller ist in der Regel, individuelle Anpassungen über Custom commands des Ruleset generator entsprechend im Code zu platzieren.
Sonstige Einstellungen.
Parameter |
Beschreibung |
|||
|---|---|---|---|---|
|
Ermöglicht den Zugriff auf die auf dem SEPPmail Secure E-Mail Gateway bekannten Verschlüsselungszertifikate externer Kommunikationspartner, welche unter X.509 Certificates gelistet sind.
|
|||
|
Standardeinstellung.
|
|||
Aktiviert die LDAP Key Server Funktion des SEPPmail Secure E-Mail Gateways, für die unter X.509 Certificates vorhandenen Zertifikate. |
||||
|
Diese Option ist im Standard inaktiv und mit der Auswahl „sendpgpkeys“ vorbelegt. Wird für einen Benutzer auf dem SEPPmail Secure E-Mail Gateway ein OpenPGP Schlüsselpaar erzeugt - egal ob manuell oder automatisch (siehe Sektion Ruleset generator dieses Menüs unter Key generation die Option Issue local OpenPGP keys for users) - so wird durch Aktivieren dieser Option der öffentliche Schlüssel des automatisch generierten Schlüsselpaares unter Verwendung der ausgewählten E-Mail Vorlage (siehe auch ) an den neu erzeugten 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. Die für den Versand verwendete E-Mail Vorlage kann bei Bedarf pro Managed Domain individuell übersteuert werden (siehe Send OpenPGP keys). Der Absender dieser E-Mail ist der globale Postmaster, falls kein individueller Postmaster hinterlegt wurde.
|
|||
Die vorgenommenen Änderungen werden über die Schaltfläche Save gespeichert.
Mit dem Ruleset generator wird quasi ein „Workflow System“ für eingehende und ausgehende E-Mails definiert.
|
Beim Einsatz von Frontend Servern (siehe Cluster Add this device as frontend server) muss jede Änderung im Ruleset generator durch erneutes Speichern am Frontend Server (Generate ruleset) bekannt gemacht werden. |
Die in dieser Sektion vorhandenen Eingabefelder für Betreffzeilen Schlüsselwörter (text in subject) sind mit „regular expressions“ zu befüllen. Das heißt Sonderzeichen müssen mit einem backslash „\“ als solche gekennzeichnet werden. Ein Aneinanderreihen mehrerer Schlüsselwörter ist durch das Trennen mit dem pipe-Zeichen „|“ möglich.
Beispiel:
Soll als Betreffzeilen Schlüsselwörter <abc> verwendet werden so ist diese wie folgt einzugeben: \<abc\>
Soll sowohl das Betreffzeilen Schlüsselwörter <abc> als auch [def] verwendet werden so ist diese wie folgt einzugeben: \<abc\>|[def]
(siehe auch Reguläre Ausdrücke)
Groß-/Kleinschreibung wird bei der Eingabe des Schlüsselwortes in der Betreffzeile ignoriert.
Bei Verwenden des COM Add-In für MS Exchange / Outlook on premises im Betreffzeilen-Modus (siehe Registry Wert "subject-mod=1") ist darauf zu achten, dass bei Änderungen der Schlüsselwörter im SEPPmail Secure E-Mail Gateway, diese entweder als zusätzliche Werte hinzugefügt werden, oder die Werte im Add-In (siehe Registry Werte "s-sm...") an die Werte der Appliance angepasst werden müssen.
Wird das MS Outlook Cross-Platform-Add-In, beziehungsweise des COM Add-In für MS Exchange / Outlook on premises im X-Header-Modus (siehe Registry Wert "subject-mod=0") betrieben, so ist zu beachten, dass die durch den jeweiligen X-Header ausgelöste Funktion auch im Ruleset Generator aktiv ist.
|
Generell werden bei eingehenden E-Mails - also solche, die nicht von einer Managed domain stammen - alle hier definierten Schlüsselwörter entfernt. Das heißt, von außen können weder Steuerbefehle an die Appliance übergeben werden, noch können von der Appliance durchgeführte kryptographische Aktionen (Entschlüsseln, Prüfen von Signaturen) vorgetäuscht werden. |
|
Um auf der Appliance keine undefinierten Zustände zu erzeugen, ist das gleichzeitige Verwenden unterschiedlicher, sowie insbesondere entgegengesetzter Steuermerkmale (Schlüsselwörter, (X-)Header) in ausgehenden E-Mails unbedingt zu vermeiden! Weiterhin können mit einem Schlüsselwort nicht zwei Aktionen gleichzeitig angesteuert werden. |
Parameter |
Beschreibung |
||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Im Standard ist diese Option aktiv und hat das Schlüsselwort \[plain\] hinterlegt. Wird das angegebene Schlüsselwort im Betreff einer ausgehenden E-Mail gefunden, so wird diese kryptographisch unbehandelt weitergeleitet. Das Ruleset wird nicht weiter durchlaufen. Dies ergibt unter Umständen Sinn, wenn all diese Voraussetzungen gegeben sind: •Einstellung Always use S/MIME or OpenPGP if user keys are available aktiv •Absender weiß, dass der Empfänger temporär nur auf einem Mobilen Endgerät empfangen kann •Inhalt der E-Mail ist nicht vertraulich |
|||||||||||||
(in 12.0 nach Settings Disclaimer Initial disclaimer verschoben) |
|||||||||||||
(in 12.0 nach Settings Disclaimer Reply disclaimer verschoben) |
|||||||||||||
|
reprocess@ decrypt.reprocess |
Im Standard ist diese Option aktiv. Ermöglicht einem Empfänger eine verschlüsselte E-Mail aus seinem Postfach erneut an das SEPPmail Secure E-Mail Gateway zum Entschlüsseln zu senden. Hierfür ist die verschlüsselte E-Mail als Anhang in eine neue (Träger-)E-Mail zu packen und an die Adresse „reprocess@decrypt.reprocess“ zu senden. Auf dem SEPPmail Secure E-Mail Gateway wird die Träger-E-Mail verworfen und die darin befindliche, ursprünglich verschlüsselte Nachricht erneut verarbeitet und zugestellt. Dies setzt natürlich voraus, dass der für das Entschlüsseln benötigte private Schlüssel dem SEPPmail Secure E-Mail Gateway bekannt ist. 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 zum SEPPmail Secure E-Mail Gateway 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. |
||||||||||||
Diese Option ist im Standard inaktiv. Durch das Aktivieren dieses Punktes werden von der Appliance gesetzte Kennzeichen (siehe zum Beispiel Add this text to message subject after decryption oder Add this text to message subject if S/MIME signature check succeeds:) anstatt am Ende des Betreffs an den Anfang gesetzt. |
|||||||||||||
Im Standard ist diese Option aktiv. Aktiviert das Anzeigen des Betreffs in Logs. Dies erleichtert zwar oft die Fehleranalyse, ist aber gelegentlich aus revisionstechnischen Gründen untersagt. |
|||||||||||||
|
|
|||||||||||||
|
Benutzer müssen auf der Appliance manuell - gegebenenfalls auch durch Bulk-Imports (siehe Administration Bulk Import Import users (CSV), Import X.509 key s and certficates, beziehungsweise Import OpenPGP key pairs) - angelegt werden.
|
||||||||||||
|
Standardeinstellung. Absender, welche über ein entsprechendes Merkmal eine E-Mail als zu verschlüsselnd oder zu signierend markieren und noch nicht als Benutzer (siehe Users) auf dem SEPPmail Secure E-Mail Gateway vorhanden sind, werden automatisch angelegt. Bei Verwenden dieser Option ist darauf zu achten, dass genügend freie Benutzerlizenzen vorhanden sind (siehe Home Licenses Encryption/Signature licenses). Bei Überschreiten des Lizenzkontingents werden E-Mails mit dem Hinweis „license violation“ abgewiesen (bounced) und eine Watchdog-Meldung erzeugt.
|
||||||||||||
Jeder Absender, der über das SEPPmail Secure E-Mail Gateway eine E-Mail sendet, wird als Benutzer angelegt, sofern noch nicht vorhanden. Ob dabei Verschlüsseln/Signieren angefordert wurde oder nicht, spielt bei dieser Einstellung keine Rolle. Diese Einstellung ist geeignet, um zum Beispiel generell alle E-Mails aus einem Unternehmen zu signieren. Natürlich muss dann auch das Versorgen der hier angelegten Benutzer mit entsprechendem Schlüsselmaterial gewährleistet sein (siehe auch Key Generation). Ein weiterer Anwendungsfall wäre, wenn das SEPPmail Secure E-Mail Gateway nicht direkt im E-Mail Strom steht, sondern bereits über eine vorgelagerte Komponente entschieden wird, welche E-Mails kryptographisch zu behandeln sind und nur diese an das SEPPmail Secure E-Mail Gateway übergeben werden.
|
|||||||||||||
|
|||||||||||||
Standardeinstellung. Mit dieser Option wird kein Unterschied zwischen ausgehenden E-Mails von Fremd- oder Managed domains (siehe Mail System Managed domain) gemacht. Das heißt, sollte eine E-Mail im FROM-Header eine Adresse enthalten, welche nicht von einer Managed domain stammt, so werden - sofern eine Option zur automatischen Benutzeranlage (siehe oben) gewählt ist - gegebenenfalls auch für Absender fremder Adressen User generiert.
|
|||||||||||||
Durch diese Option werden E-Mails von Fremd-Absendern immer unverändert, also „plain“ (vergleiche auch General settings Do not touch mails with the following text in subject:) versendet.
|
|||||||||||||
Durch diese Option werden E-Mails von Fremd-Absendern immer abgewiesen. |
|||||||||||||
|
|
|||||||||||||
Diese Option ist im Standard inaktiv. Generiert automatisch ein OpenPGP Schlüsselpaar. |
|||||||||||||
|
S/MIME certificates for users |
Diese Option ist im Standard inaktiv. Generiert automatisch ein S/MIME-Schlüsselpaar. Der öffentliche Schlüssel wird von der lokalen CA signiert (Self-Signed-Certificate). |
||||||||||||
|
Diese Option ist im Standard inaktiv. Generiert automatisch ein S/MIME-Schlüsselpaar. Der öffentliche Schlüssel wird von der unter MPKI eingestellten CA signiert.
|
||||||||||||
|
|
|||||||||||||
Im Standard ist diese Option aktiv und hat das Schlüsselwort \[secure\] hinterlegt. Eingehende, durch das SEPPmail Secure E-Mail Gateway entschlüsselte E-Mails werden im Betreff mit dem hinterlegten Schlüsselwort gekennzeichnet.
|
|||||||||||||
Diese Option ist im Standard inaktiv. Bei eingehenden, durch das SEPPmail Secure E-Mail Gateway entschlüsselten E-Mails wird der Header „Sensitivity“ mit dem Wert „Company-Confidential“ gesetzt. |
|||||||||||||
|
S/MIME decryption fails |
Im Standard ist diese Option aktiv. Eingehende, verschlüsselte E-Mails werden abgewiesen (bounced), sofern sie durch das SEPPmail Secure E-Mail Gateway nicht entschlüsselt werden konnten.
|
||||||||||||
|
|
|||||||||||||
Im Standard ist diese Option aktiv und hat das Schlüsselwort \[confidential\] hinterlegt. Wird das angegebene Schlüsselwort im Betreff einer ausgehenden E-Mail gefunden, so wird diese verschlüsselt.
|
|||||||||||||
Im Standard ist diese Option aktiv. Wird in einer ausgehenden E-Mail der Header „Sensitivity“ mit dem Wert „Company-Confidential“ gefunden, so wird die E-Mail verschlüsselt. |
|||||||||||||
|
Im Standard ist diese Option aktiv und hat das Schlüsselwort \[priv\] hinterlegt. Wird das angegebene Schlüsselwort im Betreff einer ausgehenden E-Mail gefunden, so wird das Verschlüsseln mittels GINA-Technologie erzwungen.
|
||||||||||||
|
Diese Option ist im Standard inaktiv. Wird in einer ausgehenden E-Mail der Header „Sensitivity“ mit dem Wert „Private“ gefunden, so wird das Verschlüsseln mittels GINA-Technologie erzwungen.
|
||||||||||||
|
Diese Option ist im Standard inaktiv und hat das Schlüsselwort \[emptypw\] hinterlegt. Wird das angegebene Schlüsselwort im Betreff einer ausgehenden E-Mail gefunden, so wird bei initialem Verwenden der GINA-Technologie kein Initial-Password benötigt. Dadurch wird im Einzelfall die GINA-Variante 2a (siehe Unterschiedliche Registrierungsarten) aktiviert. |
||||||||||||
|
S/MIME or OpenPGP if user keys are available |
Im Standard ist diese Option aktiv. Ausgehende E-Mails werden immer verschlüsselt, sofern dem SEPPmail Secure E-Mail Gateway ein öffentlicher Schlüssel - egal ob S/MIME (siehe X.509 Certificates) oder OpenPGP (siehe OpenPGP Public Keys) - des Kommunikationspartners (Empfängers) vorliegt.
|
||||||||||||
Diese Option ist im Standard inaktiv. Kalendereinträge sowie RTF formatierte E-Mails werden vom automatischen Verschlüsseln der übergeordneten Option ausgenommen.
|
|||||||||||||
|
Diese Option ist im Standard inaktiv. Ausgehende E-Mails werden immer mittels GINA-Technologie verschlüsselt, sofern dem SEPPmail Secure E-Mail Gateway kein öffentlicher Schlüssel - weder S/MIME noch OpenPGP - bekannt ist, jedoch ein GINA Account für den Kommunikationspartner (Empfänger) vorliegt. |
||||||||||||
|
Diese Option ist im Standard inaktiv und hat das Schlüsselwort \[noenc\] hinterlegt. Wird das angegebene Schlüsselwort 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. |
||||||||||||
Diese Option ist im Standard inaktiv. E-Mails, welche von einer Managed domains zu einer Anderen gesendet werden. werden als „sicher“ markiert (siehe auch Incoming e-mails Add this text to message subject after decryption).
|
|||||||||||||
Diese Option ist im Standard inaktiv. TLS Verschlüsselung wird für Zieldomänen, welche unter Mail System TLS settings mit einer höheren Sicherheitseinstellung als „may“ eingetragen wurden, als gültige E-Mail Verschlüsselungsoption anerkannt. Somit ändert sich bei diesen Zieldomänen die Verschlüsselungshierarchie wie folgt (siehe Punkt 5.): 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 der Empfänger Domäne 4.Geprüfte öffentlicher OpenPGP Domänen Schlüssel der Empfänger Domäne 5.TLS-Verschlüsselung höher „may“ - wobei diese auch zusätzlich verwendet wird, wenn bereits eines der höher priorisierten Verfahren zum Einsatz kam. Sollte keines der vorangegangenen (Standard-)Verfahren verfügbar sein 6.GINA mit hinterlegtem Empfängerpasswort 7.GINA mit Initialpasswort
|
|||||||||||||
|
S/MIME encryption |
Diese Option ist im Standard inaktiv. Verwenden von OAEP global als Padding-Verfahren für das Verschlüsseln via S/MIME (siehe gegebenenfalls auch https://de.wikipedia.org/wiki/Padding_(Informatik)) und https://de.wikipedia.org/wiki/Optimal_Asymmetric_Encryption_Padding). OAEP funktioniert abwärtskompatibel. |
||||||||||||
|
S/MIME encryption: |
Diese Option ist im Standard inaktiv. Bei Aktivieren kann über dieses Auswahl-Menü der Algorithmus des bei S/MIME Verschlüsselung verwendeten Session-Keys gewählt werden. Bleibt diese Einstellung deaktiviert, so wird Triple-DES verwendet.
|
||||||||||||
Niedrigster Sicherheitsstandard aber höchste Kompatibilität (zum Beispiel auch zu Outlook 2003 und früher,Secure-E-Mail-Gateway Herstellern,welche nur diesen Cipher bei Domänenverschlüsselung unterstützen oder vom Empfänger eingesetzte Hardware (zum Beispiel Kartenleser)). |
|||||||||||||
Wird zum Teil noch gefordert (zum Beispiel EDIFACT) |
|||||||||||||
Wird zum Teil noch gefordert (zum Beispiel EDIFACT) |
|||||||||||||
Standardeinstellung. Aktueller Sicherheitsstandard. Sollte von allen gängigen E-Mail Clients in deren jeweils aktuellen Version unterstützt werden. |
|||||||||||||
Gibt die Methode für die OpenPGP Verschlüsselung auf Basis personenbezogener Schlüssel (siehe auch OpenPGP Public Keys Local OpenPGP Keys) an.
|
|||||||||||||
Bei Inline PGP wird jeder Anhang einer E-Mail - wobei auch der Mail-Body ein Anhang ist - separat verschlüsselt.
Vorteil: Inline PGP wird von den meisten Open Source Produkten unterstützt und erhöht somit die Kompatibilität bei den Kommunikationspartnern.
Nachteil: Formatierungsprobleme, zum Beispiel werden bei Inline-Tabellen zwar die Inhalte der Tabelle angezeigt, jedoch nicht die Tabelle selbst.
|
|||||||||||||
Standardeinstellung. Bei PGP/MIME wird die gesamte E-Mail verschlüsselt (wie auch bei S/MIME).
Vorteil: Keine Formatierungsprobleme.
Nachteil: Eventuell Kompatibilitätsprobleme und somit Nichtlesbarkeit der E-Mail beim Kommunikationspartner |
|||||||||||||
Gibt die Methode für die OpenPGP Verschlüsselung auf Basis von Domänen Schlüsseln (siehe auch Manual OpenPGP Domain Keys) an.
|
|||||||||||||
|
|
|||||||||||||
|
|
|||||||||||||
S/MIME signature check succeeds: |
Im Standard ist diese Option aktiv und hat das Schlüsselwort \[signed\sOK\] hinterlegt. Eingehende, S/MIME signierte E-Mails, deren Signaturen durch das SEPPmail Secure E-Mail Gateway geprüft und als in Ordnung befunden wurden, werden mit dem angegebenen Schlüsselwort im Betreff gekennzeichnet.
|
||||||||||||
|
S/MIME signature check succeeds |
Diese Option ist im Standard inaktiv. Entfernt die S/MIME E-Mail Signatur nach erfolgreicher Prüfung.
|
||||||||||||
Im Standard ist diese Option aktiv und hat das Schlüsselwort \[signed\sINVALID\] hinterlegt. Eingehende, signierte E-Mails, deren Signaturen durch das SEPPmail Secure E-Mail Gateway geprüft und als ungültig befunden wurden, werden mit dem angegebenen Schlüsselwort im Betreff gekennzeichnet. Zusätzlich wird unter Logs Mail log ein entsprechender OpenSSL-Fehler ausgegeben. |
|||||||||||||
Diese Option ist im Standard inaktiv. Entfernt die S/MIME E-Mail Signatur nach fehlgeschlagener Prüfung.
|
|||||||||||||
|
Diese Option ist im Standard inaktiv und hat das Schlüsselwort \[signed\sok\] hinterlegt. Eingehende, OpenPGP MIME signierte E-Mails, deren Signaturen durch das SEPPmail Secure E-Mail Gateway geprüft und als gültig befunden wurden, werden mit dem angegebenen Schlüsselwort im Betreff gekennzeichnet.
|
||||||||||||
|
Diese Option ist im Standard inaktiv und hat das Schlüsselwort \[signed\sINVALID\ hinterlegt. Eingehende, OpenPGP signierte E-Mails, deren Signaturen durch das SEPPmail Secure E-Mail Gateway geprüft und als ungültig befunden wurden, werden mit dem angegebenen Schlüsselwort im Betreff gekennzeichnet. |
||||||||||||
|
(neu in 12.1) |
Diese Option ist im Standard inaktiv. Aktiviert die „Triple Wrapping“ Unterstützung (siehe RFC 2634).
|
||||||||||||
|
|
|||||||||||||
|
Im Standard ist diese Option aktiv und hat das Schlüsselwort \[sign\] hinterlegt. Wird das angegebene Schlüsselwort im Betreff einer ausgehenden E-Mail gefunden, so wird diese S/MIME signiert.
|
||||||||||||
|
S/MIME certificate available |
Im Standard ist diese Option aktiv. Signiert alle ausgehenden E-Mails (keine Kalendereinträge sowie oder RTF formatierte Nachrichten!) von SEPPmail Secure E-Mail Gateway Benutzern (Users) mit gültigem S/MIME Zertifikat.
|
||||||||||||
|
Diese Option ist im Standard inaktiv. E-Mails, bei welchen aufgrund der Verschlüsselungshierarchie OpenPGP zum Einsatz kommt, werden automatisch OpenPGP signiert, sofern der Absender im Besitz eines gültigen OpenPGP Schlüsselpaares auf der Appliance ist.
|
||||||||||||
|
Im Standard ist diese Option aktiv und hat das Schlüsselwort \[nosign\] hinterlegt. Wird das angegebene Schlüsselwort im Betreff einer ausgehenden E-Mail gefunden, so wird das automatische S/MIME Signieren (siehe „Sign all outgoing mails if S/MIME certificate available“) in jedem Fall unterdrückt. Andere kryptographische Aktionen (Verschlüsseln) sind davon nicht betroffen.
|
||||||||||||
Diese Option ist im Standard inaktiv. In der Regel werden E-Mail Signaturen im Klartext angehangen. Somit kann eine signierte E-Mail, auch ohne Prüfen der Signatur und damit mit jedem x-beliebigen E-Mail Client, gelesen werden. Bei der Opaque Signatur wird der E-Mail Inhalt und die Signatur gemeinsam in einem MIME-Part gespeichert. Somit können Opaque signierte E-Mails ausschließlich mit S/MIME-fähigen E-Mail-Clients gelesen werden. |
|||||||||||||
|
(neu in 12.1) |
Diese Option ist im Standard inaktiv. Aktiviert das „Triple Wrapping“ (siehe RFC 2634) beim Senden von E-Mails.
|
||||||||||||
Diese Option ist im Standard inaktiv. Bei Aktivieren kann über dieses Auswahl-Menü der zu verwendende Hash-Algorithmus beim Signieren ausgewählt werden. Bleibt diese Einstellung deaktiviert, so wird SHA-256 verwendet.
|
|||||||||||||
Niedrigster Sicherheitsstandard aber höchste Kompatibilität. Sollte nicht mehr verwendet werden, da dieses Verfahren als unsicher gilt. |
|||||||||||||
Standardeinstellung (empfohlen). Aktueller Sicherheitsstandard. Wird in der Regel von den aktuellen E-Mail Client-Produkten bei der Signaturprüfung unterstützt. |
|||||||||||||
Höchster Sicherheitsstandard. Dieser kann jedoch unter Umständen auf Empfängerseite zu Kompatibilitätsproblemen führen |
|||||||||||||
|
S/MIME signatures |
Diese Option ist im Standard inaktiv. Verwenden von PSS global als Padding-Verfahren für das Signieren via S/MIME (siehe gegebenenfalls auch https://de.wikipedia.org/wiki/Padding_(Informatik) und https://de.wikipedia.org/wiki/Probabilistic_Signature_Scheme).
|
||||||||||||
|
(nur mit entsprechender Large File Transfer (LFT) Lizenz (siehe auch Home Licenses Large File Transfer (LFT) licenses), sowie per GINA Domains aktiviertem Large File Transfer funktionsfähig. |
|||||||||||||
|
Im Standard ist diese Option aktiv und hat das Schlüsselwort \[lfm\] hinterlegt. Wird das angegebene Schlüsselwort im Betreff einer ausgehenden E-Mail gefunden, so wird diese - unabhängig von der Größe - mittels Large File Transfer (LFT) Technologie versendet. Dies impliziert eine gültige Large File Transfer (LFT) Lizenz |
||||||||||||
|
Diese Option ist im Standard inaktiv und hat das Schlüsselwort \[nolfm\] hinterlegt. Wird das angegebene Schlüsselwort im Betreff einer ausgehenden E-Mail gefunden, so wird das Verwenden der LFT-Technologie selbst dann unterdrückt, wenn der eingestellte Größen-Schwellwert (siehe Large File Transfer Outgoing policy Size (in KB) above which messages are treated as large files (set to 0 to treat all messages as large files)) überschritten wird. |
||||||||||||
|
(neu in 14.0.0) |
In diesem Abschnitt wird die globale LFT-Quota definiert.
Die globalen Einstellungen können durch lokale Einstellungen für Customer, Managed domain, Mail processing group and User überschrieben werden. |
||||||||||||
Legt die globale Quota fest. LFT wird diesen Wert nicht überschreiten. |
|||||||||||||
Der Standardwert ist „80,90,95“. Wenn die globale Quota einen dieser Werte überschreitet, wird eine Benachrichtigung per E-Mail gesendet. |
|||||||||||||
Wenn aktiviert, wird die globale Quota strikt eingehalten. Wenn nicht, dann wird nur eine Warnung ausgegeben, wenn die globale Quota überschritten wird. |
|||||||||||||
|
Legt die Quota pro Benutzer fest. |
||||||||||||
Wenn diese Option aktiviert ist, dürfen die Benutzer LFT verwenden. Mögliche Werte sind „true“, „false“ und „reset to default values“. |
|||||||||||||
|
(nur mit entsprechender Protection Pack (PP) Lizenz (siehe auch Home Licenses Protection Pack (AntiSpam / AntiVirus)), sowie unter Mail System Antispam entsprechend aktivierter Funktionen funktionsfähig. |
|||||||||||||
|
Diese Option ist im Standard inaktiv. Aktiviert die Viren-Scan-Funktion. Infizierte E-Mails werden an die optional einzugebende E-Mail Adresse umgeleitet (Quarantäne). Bleibt das Eingabefeld für die E-Mail Adresse leer, so werden infizierte E-Mails abgewiesen (bounced).
|
||||||||||||
|
Diese Option ist im Standard inaktiv. Für den Fall, dass ClamAV nach einem Signatur-Update sogenannte „false positive“ Meldungen erzeugt, können an dieser Stelle Ausnahmen vom Virenscan definiert werden. Dies können •heuristische Teil-Prüfungen sein (siehe gegebenenfalls www.clamav.net)) •einzelne Viren Namen, wie sie dem Log zu entnehmen sind (als Regulärer Ausdruck, das heißt Sonderzeichen müssen als solche markiert werden (siehe Reguläre Ausdrücke). sein. Im Standard verwendet die Scan Engine die ClamAV Signaturen sowie weitere Signaturen von Sanesecurity (http://sanesecurity.com) (siehe Mail System AntiSpam Enable unofficial signatures for ClamAV). |
||||||||||||
|
Diese Option ist im Standard inaktiv. Versendet Benachrichtigungen über Viren-Funde an die angegebene E-Mail Adresse. |
||||||||||||
Diese Option ist im Standard inaktiv. E-Mails, welche ausführbare Windows Dateiformate enthalten werden abgelehnt (rejected).
|
|||||||||||||
Im Standard ist diese Option aktiv. Bei aktiver Option wird auch in ZIP Archiven nach ausführbaren Windows Dateiformaten gesucht.
|
|||||||||||||
Diese Option ist im Standard inaktiv. E-Mails, welche übliche, ausführbare Skript Dateiformate enthalten werden abgelehnt (rejected). |
|||||||||||||
Im Standard ist diese Option aktiv. Bei aktiver Option wird auch in ZIP Archiven nach ausführbaren Skript Dateiformaten gesucht.
|
|||||||||||||
|
|||||||||||||
|
Diese Option ist im Standard inaktiv und hat das Schlüsselwort [SPAM] hinterlegt. Als SPAM klassifizierte E-Mails werden mit 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).
|
||||||||||||
Auswahl, des Schwellwertes für die SPAM-Erkennung. Je niedriger dieser Wert (0.5 bis 19.5) gesetzt wird, desto strenger sind die Kriterien für die SPAM-Erkennung. Im Standard ist der Wert „2“ gewählt. Bei niedrigen Werten erhöht sich das Risiko von Falscherkennungen, so dass gegebenenfalls auch legitime E-Mails als SPAM erkannt und markiert werden. |
|||||||||||||
|
Diese Option ist im Standard inaktiv. Als SPAM klassifizierte E-Mails werden an die optional einzugebende E-Mail Adresse umgeleitet (Quarantäne). Bleibt das Eingabefeld für die E-Mail Adresse leer, so werden die klassifizierten E-Mails abgewiesen (bounced). Basis für die SPAM-Erkennung ist der angegebene Spam level (siehe nächste Option).
Infizierte E-Mails werden an die optional einzugebende E-Mail Adresse gesendet (Quarantäne). Bleibt das Eingabefeld für die E-Mail Adresse leer, so werden infizierte E-Mails abgewiesen (bounced).
|
||||||||||||
Auswahl, des Schwellwertes für die SPAM-Erkennung. Je niedriger dieser Wert (0.5 bis 19.5) gesetzt wird, desto strenger sind die Kriterien für die SPAM-Erkennung. Im Standard ist der Wert „4“ gewählt. Bei niedrigen Werten erhöht sich das Risiko von Falscherkennungen, so dass gegebenenfalls auch legitime E-Mails als SPAM erkannt und umgeleitet beziehungsweise abgelehnt (bounced) werden. |
|||||||||||||
|
Diese Option ist im Standard inaktiv. Stammt der Absender im Envelope oder FROM Header (oder SENDER Header, sofern vorhanden) einer eingehenden E-Mail aus einer Managed domain wird die E-Mail abgewiesen.
|
||||||||||||
|
Diese Option ist im Standard inaktiv. Enthält der FROM-Header (und SENDER Header, sofern vorhanden) einer E-Mail keine gültige E-Mail Adresse, so wird die E-Mail abgewiesen.
|
||||||||||||
|
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 das SEPPmail Secure E-Mail Gateway 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.
|
|||||||||||||
Diese Option ist im Standard inaktiv. Setzt den angegebenen X-Header mit dem zugeordneten Wert für alle eingehenden und internen (siehe auch Set header ñ to value ñ for all internal mails) E-Mails. |
|||||||||||||
Diese Option ist im Standard inaktiv. Setzt den angegebenen X-Header mit dem zugeordneten Wert für alle ausgehenden E-Mails. |
|||||||||||||
Diese Option ist im Standard inaktiv. Setzt den angegebenen X-Header mit dem zugeordneten Wert für alle internen E-Mails, also von einer Managed domain an eine Managed domain.
|
|||||||||||||
Diese Option ist im Standard inaktiv. Setzt den angegebenen X-Header mit dem zugeordneten Wert für alle E-Mails, welche durch das SEPPmail Secure E-Mail Gateway verschlüsselt wurden. |
|||||||||||||
Diese Option ist im Standard inaktiv. Setzt den angegebenen X-Header mit dem zugeordneten Wert für alle E-Mails, welche durch das SEPPmail Secure E-Mail Gateway entschlüsselt wurden. |
|||||||||||||
Diese Option ist im Standard inaktiv. Sendet eine 1:1 Kopie aller über das SEPPmail Secure E-Mail Gateway transportierten E-Mails - noch vor dem Ver-, beziehungsweise nach dem Entschlüsseln - an die angegebene E-Mail Adresse. |
|||||||||||||
|
Über Custom Commands können, über den in den Regelwerk-Anweisungen definierten Befehlssatz, spezifische Anforderungen an entsprechender Stelle im Ruleset eingefügt werden.
|
|||||||||||||
Diese Option ist im Standard inaktiv. Fügt den im Eingabefeld vorhandenen Code an der Stelle im Ruleset für eingehende E-Mails VOR dem Entschlüsseln ein. |
|||||||||||||
Diese Option ist im Standard inaktiv. Fügt den im Eingabefeld vorhandenen Code an der Stelle im Ruleset für eingehende E-Mails NACH dem Entschlüsseln ein. |
|||||||||||||
Diese Option ist im Standard inaktiv. Fügt den im Eingabefeld vorhandenen Code an der Stelle im Ruleset für ausgehende E-Mails VOR dem Verschlüsseln ein. |
|||||||||||||
Diese Option ist im Standard inaktiv. Fügt den im Eingabefeld vorhandenen Code an der Stelle im Ruleset für eingehende GINA-Mails ein. |
|||||||||||||
Diese Option ist im Standard inaktiv. Ersetzt den Code für das unter User creation ausgewählte Standardverfahren für das Generieren neuer Benutzer. Ist die Option aktiv, so wird dieser Code bei Auswahl von •Do not create accounts (also disables custom commands for user creation) nie •Create accounts for new users if user tries to sign / encrypt nur beim Versuch zu verschlüsseln/signieren •Create accounts for all users immer durchlaufen.
|
|||||||||||||
|
Diese Option ist im Standard inaktiv. An dieser Stelle können Makros - also Code-Blöcke, welche einmalig definiert und im Anschluss beliebig oft in den Custom commands verwendet werden können - erstellt werden. Diese werden im Ruleset (siehe SMTP ruleset Display ruleset) ganz oben platziert. Somit kann an dieser Stelle auch Code vor dem eigentlichen „Mail Processing“ platziert werden. |
||||||||||||
|
Über Key Server wird das zusätzliche Abfragen öffentlicher Schlüssel von Kommunikationspartnern ermöglicht. Somit kann gegebenenfalls auch dann verschlüsselt werden, wenn auf dem SEPPmail Secure E-Mail Gateway noch kein Schlüsselmaterial des Empfängers bekannt, jedoch auf dem eingetragenen Key Server vorhanden ist. Die Key Server Abfrage findet jeweils noch vor der Abfrage des eigenen Schlüsselspeichers (siehe X.509 Certificates, beziehungsweise OpenPGP Public Keys) statt. Die Abfrage wird immer vom E-Mail verarbeitenden System ausgeführt. Sofern dies ein Frontend-Server ist, übergibt dieser das so bezogene Schlüsselmaterial zum Speichern an das Backend-System.
Nach dem Speichern eines Key Server Eintrags wird jeweils ein weiteres Eingabefeld eingeblendet.
|
|||||||||||||
Auswahl des abzufragenden Schlüsselmaterials. Die Suchfilter für eine Schlüsselserver-Abfrage sind für die Standard-Technologien S/MIME und OpenPGP genormt. Sollte dennoch ein anderer Suchfilter erforderlich sein, so besteht die Möglichkeit eine benutzerdefinierte Abfrage über Custom commands, mittels der Befehle ldap_getpgpkeys(), beziehungsweise ldap_getcerts() zu erstellen. |
|||||||||||||
Standardeinstellung. Auswahl für S/MIME Schlüsselsuche. (Standardsuchfilter (mail=<E-Mail Adresse des Empfängers>))
|
|||||||||||||
Auswahl für OpenPGP Schlüsselsuche. (Standardsuchfilter (pgpUserID=<E-Mail Adresse des Empfängers>)
|
|||||||||||||
Regulärer Ausdruck, welcher die Ziel-E-Mail-Domänen für die Abfrage bestimmt. Soll die Abfrage beispielsweise für nur eine E-Mail-Domäne gelten, so könnte der Ausdruck wie folgt lauten: @mein-kommunikationspartner.tld\.de oder bei Gütigkeit für mehrere E-Mail-Domänen auch @mein-kommunikationspartner.tld\.de|@mein-weiterer-kommunikationspartner.tld\.de |
|||||||||||||
Gibt den Pfad zum Schlüsselserver an. Mehrere Werte können kommagetrennt angegeben werden. In diesem Fall wird automatisch auf den jeweils nächsten Server zugegriffen, wenn der vorherige nicht erreicht werden kann. Beispiele: ldap://mein-kommunikationspartner.tld\.de ldaps://mein-kommunikationspartner.tld\.de ldaps://mein-kommunikationspartner.tld\.de:1636 ldaps://server1.mein-kommunikationspartner.tld,ldaps://server2.mein-kommunikationspartner.tld\ |
Die Zugangsdaten müssen vom Betreiber des Schlüsselservers bereitgestellt werden. |
||||||||||||
|
(optional) |
Zur Abfrage berechtigter Benutzer, zum Beispiel cn=meinefirma,ou=keys,o=mein-kommunikationspartner.tld,c=de |
||||||||||||
|
(optional) |
Zum Benutzer zugehöriges Passwort
|
||||||||||||
LDAP-Suchpfad, in welchem die zu suchenden Schlüssel abliegen. |
|||||||||||||
Diese Option ist im Standard inaktiv. Verhindert das Ablehnen (bounce) der E-Mail im Falle der Nichterreichbarkeit des LDAP-Servers. |
|||||||||||||
|
(neu in 14.0.1) |
Diese Option ist im Standard inaktiv. Wenn diese Option aktiviert ist, wird jedes S/MIME-Zertifikat, das vom Key Server heruntergeladen wird, mit den Root-CAs abgeglichen, um festzustellen, ob die Root vollständig, vertrauenswürdig und vorhanden ist. |
||||||||||||
Diese Option ist im Standard inaktiv. Deaktiviert komplett die GINA-Technologie. Als Folge würden als „zu verschlüsselnd“ gekennzeichnete E-Mails abgewiesen werden, wenn keine andere Verschlüsselungsmethoden (S/MIME, OpenPGP, Domain) verfügbar sind.
|
|||||
|---|---|---|---|---|---|
Diese Option ist im Standard inaktiv. Deaktiviert sowohl die benutzerbezogene S/MIME- als auch OpenPGP-Technologie. Diese Option wird verwendet, wenn ausschließlich Domänen- und/oder GINA-Verschlüsselung verwendet werden soll.
|
|||||
|
Diese Option ist im Standard inaktiv. Muss aus revisionstechnischen Gründen der GINA-Teil in einer anderen Demilitarisierten Zone (DMZ) als der SMTP verarbeitende Teil stehen, so ist über diese Option ein entsprechendes Auftrennen der Lösung möglich. Die einzelnen Funktionsteile können dabei sogar auf unterschiedliche Standorte verteilt werden. Alle GINA zu verschlüsselnden E-Mails werden dann über die hier angegebene Pseudo-E-Mail Adresse (zum Beispiel GINA@GINApseudodomain.local) S/MIME verschlüsselt per SMTP an den GINA-Satelliten geleitet. |
||||
Diese Option ist im Standard inaktiv. Definiert den Gegenpart zur Option Use remote GINA server, reachable under the following e-mail 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). 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 GINA Domains Domains). |
|||||
Hier sind die Managed domains des Basis-Systems als Regulärer Ausdruck einzutragen (siehe Mail System Managed domains). Das Trennen der Domains erfolgt durch ein Pipe-Zeichen „|“, also domain1\.tld|domain2\.tld|domainn\.tld .
|
|||||
Hier ist die gleiche Pseudo-E-Mail Adresse einzutragen wie auf dem „Basis“-System unter Use remote GINA server, reachable under the following e-mail address:. |
|||||
Hier sind die SHA1-Fingerprints der Domänen Zertifikate der unter „Relay for domain“ angegebenen Managed domains anzugeben, jeweils durch ein Pipe-Zeichen „|“ getrennt als Regulärer Ausdruck, also fingerprint1|fingerprint2|fingerprintn (siehe S/MIME domain encryption). |
|||||
Diese Option ist im Standard inaktiv. Aktiviert den Schweizer Dienst Incamail anstelle der GINA Technologie. |
|||||
Im Standard ist diese Option leer. Ist ein Eintrag vorhanden, wird die Option rot dargestellt! Legt die Art und Weise des E-Mail Flusses fest. Beispielsweise kann die vor Version 11.1.11 verfügbare Option Re-inject mails to sending mailserver durch den Eintrag von „loop“ (siehe auch Konfig: Re-Inject mails to sending mailserver), beziehungsweise die Option Run in queueless mode durch den Eintrag von „queueless“ (siehe auch Konfig: Queueless Mode) hervorgerufen werden.
Weiterhin kann über diese Option quasi ein „Custom commands for outgoing e-mails AFTER encryption“ abgebildet werden (siehe auch Konfig: Custom commands for outgoing e-mails AFTER encryption). |
|||||
Die vorgenommenen Änderungen werden über die Schaltfläche Save and create ruleset gespeichert. Das Ruleset wird mit den vorgenommen Einstellungen generiert.
