Frequently asked Questions

Lizenz

Kann die Aktualisierung der Lizenzdaten vom SEPPmail Update Server forciert werden beziehungsweise wie häufig werden die Daten abgeglichen?

Die Lizenzdaten werden täglich um Mitternacht sowie bei jedem Reboot der Appliance abgeglichen.
Ebenso werden die Daten bei einem Update abgeglichen („Fetch Update“ / „Prefetch (reboot manually)“).

Ein manueller Abgleich ist über den Punkt „Check for Update“ möglich.

Die Schaltflächen sind in der Administrationsoberfläche unter „Administration -> Update“ zu finden.

Was passiert, wenn die Lizenz abgelaufen ist?

Die Appliance läuft ohne Einschränkung des laufenden Betriebes. Allerdings können aber keine weiteren Updates durchgeführt werden. Zusätzlich erhält der Systemadministrator Warnungen auf der Administrationsoberfläche sowie per „Daily Report“.

Bei Demolizenzen:
Bei Ablauf der Demolizenz werden keine weiteren kryptographischen Aktionen ausgeführt, also weder ver- noch entschlüsselt, noch signiert.

Konfiguration

Meine virtuelle SEPPmail Appliance unter Microsoft Hyper-V reagiert nicht wie erwartet auf die Eingetragenen IP Alias Adressen.

Sollen IP ALIAS Addresses auf virtuellen Appliances eingesetzt werden, welche auf Microsoft Hyper-V hosted sind, so ist darauf zu achten, dass die Option „Spoofing von MAC-Adressen aktivieren“ in der Konfiguration der virtuellen Netzwerkkarte aktiviert wurde. Diese Option ist in den Hyper-V Einstellung der virtuellen Maschine unter „Ältere Netzwerkkarte -> Erweiterte Features“ zu finden.

1

 

Sind bei der Migration von ESXi 5.5 auf die Version 6.0 Probleme bekannt?

Die Migration auf ESXi 6.0 wurde bereits von uns erfolgreich getestet und bereits von mehreren Kunden problemlos vollzogen.

Können E-Mails zu einer bestimmten E-Mail Ziel-Domäne über einen bestimmten E-Mail Server geleitet werden?

Ja, durch den Eintrag  der E-Mail Domäne als TLS-Domain.

Hierzu ist zunächst in der Administrationsoberfläche im Menü „Mail System“, in der Sektion „TLS settings“ über die Schaltfläche „Add TLS Domain…“  das Menü für das Hinzufügen neuer TLS Ziel Domänen zu öffnen.
Anschliessend ist in der Sektion „Domain Info“ unter „Domain Name“ der Name der E-Mail Domäne einzutragen, welche  über einen bestimmten E-Mail Server geleitet werden sollen. Besagter E-Mail Server ist unter „Optional Forwarding Server Address“ einzutragen.
Über die Schaltfläche Save ist der Eintrag zu sichern.

Hinweis:
Im Standard wird die TLS Einstellung (siehe Sektion „TLS Settings“) „May“ (opportunistisch, verschlüsseln wenn möglich) verwendet.
Natürlich kann bei dieser Gelegenheit bei Bedarf auch ein individueller Level eingestellt, beziehungsweise die TLS Verschlüsselung unterdrückt werden.

Weshalb erhalte ich teilweise E-Mails als Anhang einer leeren Träger-E-Mail?

Die SEPPmail Appliance ist so konfiguriert, dass sie nach dem Prüfen einer S/MIME Signatur diese nicht abschneidet.

Das beziehungsweise ein nachfolgendes E-Mail System – in der Regel der interne Groupware Server – versucht der E-Mail einen Disclaimer oder Footer anzuhängen, zum Beispiel „Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss!“.
Dabei stellt das E-Mail-System fest, dass die von der SEPPmail zugestellte E-Mail über eine S/MIME Signatur verfügt. Da diese Signatur durch Anhängen des Disclaimers zerstört würde, packt das System die komplette E-Mail als Anhang in eine Träger-E-Mail, welche dann mit dem Disclaimer versehen wird.

Um dieses Verhalten abzustellen sollte das Anhängen des Disclaimers abgeschaltet werden. Alternativ kann auf der SEPPmail die Signatur nach deren Prüfung abgeschnitten werden (Remove signature if S/MIME signature check…).

 

Wie kann das Datumsformat in der GINA Oberfläche geändert werden?

Grundsätzlich sind alle Texte der GINA Oberfläche jeweils in den Spracheinstellungen vorzunehmen. Dabei ist jede verwendete Sprache separat zu betrachten.

Anbei eine Beschreibung anhand der deutschen Sprachdatei:
Zunächst ist in der Administrationsoberfläche das Menü „Mail Processing“ zu wählen. In der Sektion „GINA domains“ ist die zu Ändernde GINA Oberfläche aus dem DropDown Menü zu wählen. Durch klicken der Schaltfläche „Edit“ öffnet das Folgemenü mit den entsprechenden „GINA settings“.  Dort ist in der Sektion „Language settings“, Abschnitt „German (d)“  die Schaltfläche „Edit translations“ zu klicken. Ein weiteres Folgemenü öffnet, in welchem ganz unten rechts die Schaltfläche „Advanced View“ zu klicken ist. Im Anschluss kann über die Browser Suchfunktion nach „date_format“ gesucht werden. Im darunter befindlichen Message String „msgstr“ kann das Datumsformat dann nach den individuellen Vorlieben geändert werden. Abschliessend ist der Vorgang mit „Save“ zu beenden.

Hinweis zum Datumsformat:
Die Formatierungen sind ANSI-C89 kompatibel. Eine genauere Beschreibung hierzu ist unter
http://man7.org/linux/man-pages/man3/strftime.3.html
zu finden.
Um das korrekte Format zu generieren ist steht zum Beispiel folgendes Tool im Internet zur Verfügung:
http://www.foragoodstrftime.com/

 

Mein Admin Account wurde nach mehrmaliger Passwort Falscheingabe gesperrt. Wie kann ich diesen wieder entsperren.

Der Account wird nach der eingestellten Zeit (siehe Administrationsoberfläche, Menü „Users“, Schaltfläche „Password policy“) von selbst entsperrt. Im Standard sind das 30 Minuten.

Gegebenenfalls ist das Anlegen eines weiteren Admin Accounts sinnvoll (siehe Menü „Groups“, Sektion „admin (Administrator)“).

Unterstützt SEPPmail MultiDomain (SAN) SSL Zertifikate?

Ja.

Warum weist meine Appliance nach dem Aktivieren des Virenscanners alle E-Mails ab?

Nach dem Aktivieren der Option(en) Use ClamAV AntiVirus Engine (Note: remember to activate in ruleset) und gegebenenfalls Enable unofficial Signatures for ClamAV aus dem Menü Mail System, Sektion AntiSpam kann es je nach Internetanbindung sehr lange dauern, bis die Signaturen für die AntiVirus Engine zur Verfügung stehen.
Solange die Signaturen noch nicht zur Verfügung stehen, werden bei aktivierter Option alle E-Mails mit dem Fehler „Virus scan: Runtime Error“ abgewiesen „Message Rejected. (421 Rule Engine Error)“.

Weshalb synchronisiert NTP mehrmals binnen einer Minute?

Unter optimalen Bedingungen synchronisiert NTP standardmässig alle 64 bis 1024 Sekunden.

Synchronisiert NTP öfter, kann das an vielen Dingen liegen, vor allem aber:

1. Je nach Synchronisationsgüte muss NTP öfter die Serverzeit anfordern.
2. Sollte NTP zu bestimmten Servern per Firewall gesperrt sein, gibt es natürlich erneute Anfragen.
3. NTP verwendet verbindungsloses UDP. Je nach Paketverlustrate kann dies auch zu wiederholten Anfragen führen.

Ausschlaggebend kann  auch die Art der Appliance sein (Hardware oder virtuell).
Bei Microsoft Hyper-V kann zum Beispiel durch starken Clock-Drift im Gastsystem vermehrt die in Punkt 1 genannte Ursache auftreten.

Ruleset

Kann der interne Absender nach dem Versand einer verschlüsselten E-Mail eine Art Status Mail erhalten, in welcher der erfolgreiche, verschlüsselte Versand inklusive des angewandten Verschlüsselungsverfahrens dokumentiert ist.

Natürlich wäre das Generieren solcher Status Mails möglich. Allerdings ist so ein Verhalten weder notwendig noch wünschenswert, da die zu vermutende Anzahl dieser Status Mails SPAM-Charakter hätte.

Aus diesem Grund sendet die SEPPmail-Appliance in der Standardkonfiguration nur Meldungen wenn ein Problem auftaucht, also die Mail nicht ausgeliefert wurde. Verschlüsselt wird die E-Mail – sofern sie als zu verschlüsselnd markiert wurde – immer „best effort“. Sofern vom Empfänger kein Schlüsselmaterial vorhanden sein sollte, wird die GINA-Technologie verwendet.

Sind mehrere Schlüsselwörter für eine Funktion möglich? Z.B. unter “Always encrypt mails with the following text in subject:” ausser dem Standard \[confidential\] auch \{encrypt\} und/oder \

Ja, nachdem die Eingabe als Regulärer Ausdruck (regular expressions) erfolgt, würde der entsprechedene Ausdruck (string) wie folgt aussehen:

\[confidential\]|\{encrypt\}|\<vertraulich\>

Eine detaillierte Beschreibung zu regulären Ausdrücken ist im Handbuch in den „Allgemeine Informationen“ der „Referenz der Regelwerkanweisungen“ im Punkt „Reguläre Ausdrücke“ zu finden.

Weshalb erhalte ich teilweise E-Mails als Anhang einer leeren Träger-E-Mail?

Die SEPPmail Appliance ist so konfiguriert, dass sie nach dem Prüfen einer S/MIME Signatur diese nicht abschneidet.

Das beziehungsweise ein nachfolgendes E-Mail System – in der Regel der interne Groupware Server – versucht der E-Mail einen Disclaimer oder Footer anzuhängen, zum Beispiel „Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss!“.
Dabei stellt das E-Mail-System fest, dass die von der SEPPmail zugestellte E-Mail über eine S/MIME Signatur verfügt. Da diese Signatur durch Anhängen des Disclaimers zerstört würde, packt das System die komplette E-Mail als Anhang in eine Träger-E-Mail, welche dann mit dem Disclaimer versehen wird.

Um dieses Verhalten abzustellen sollte das Anhängen des Disclaimers abgeschaltet werden. Alternativ kann auf der SEPPmail die Signatur nach deren Prüfung abgeschnitten werden (Remove signature if S/MIME signature check…).

 

OpenPGP

Weshalb werden Public OpenPGP Keys nicht automatisch von der SEPPmail eingesammelt, wenn diese zum Beispiel als Anhang oder als Teil des Mail-Bodies mitgeschickt werden.

Dieses Verfahren OpenPGP-Keys einzusammeln ist sicherheitstechnisch bedenklich.
Selbst wenn diese Keys durch den Administrator verifiziert werden, liegt ihm hierfür lediglich die eMail Adresse des Absenders vor. Somit ist die Verifizierung über einen zweiten, unabhängigen Kanal (z.B. Telefon, SMS) nicht oder nur schwer möglich.
Aus diesem Grund wird dieses Verfahren so nicht von der SEPPmail Appliance unterstützt. Stattdessen werden drei andere Möglichkeiten für den OpenPGP Schlüsselimport angeboten:

  1. Über die GINA Technologie
    Da über eine GINA-Anmeldung eine Person eindeutig identifiziert wird, ist das von ihr hochgeladene Schlüsselmaterial in jedem Fall vertrauenswürdig.
  2. Bei der Möglichkeit das Schlüsselmaterial via Administrationsoberfläche hochzuladen, obliegt es dem Administrator die eindeutige Herkunft des Materials zu prüfen.
  3. Zusätzlich können auch per LDAP Key-Server Schlüssel abgefragt werden.

SEPPmail scheint mit OpenPGP Signaturen nicht umgehen zu können. Kann die Prüfung der Signaturen aktiviert werden?

OpenPGP Signaturen eingehender E-Mails werden von der Appliance ignoriert. Hintergrund ist, dass eine OpenPGP Signatur – anders als bei S/MIME – nur dann geprüft werden könnte, wenn der Public Key des Absenders bereits auf der Appliance bekannt ist.

Lassen sich die von der SEPPmail Appliance generierten Keys mit einer Laufzeit belegen?

Ja, für die von der Appliance generierten Schlüsselpaare (egal ob OpenPGP oder S/MIME) wird die in der Administrationsoberfläche unter „CA“ -> „internal CA Settings“ -> „Validity in days“ definierte Laufzeit verwendet.

Werden abgelaufene OpenPGP-Schlüssel weiterhin für die Verschlüsselung verwendet?

Nein. Sollte kein weiterer, gültiger OpenPGP-Key vorhanden sein, so wird je nach Konfiguration entweder ein alternatives Verschlüsselungsverfahren angewandt, oder die Mail wird abgewiesen (bounced).

Werden die von der Appliance generierten OpenPGP-Schlüssel ebenfalls automatisch vor Ablauf erneuert?

Ja, für die von der Appliance generierten Schlüsselpaare (egal ob OpenPGP oder S/MIME) wird der in der Administrationsoberfläche unter „CA“ -> „internal CA Settings“ -> „Validity in days“ -> „Automatically renew expiring certificates if validity days left less than“ eingestellte Wert für das Erneuern verwendet.

Weshalb wird eine HTML-E-Mail nach der OpenPGP Verschlüsselung beim Empfänger als Text-Mail angezeigt?

Bei OpenPGP gibt es generell zwei Möglichkeiten eine E-Mail zu verschlüsseln, „pgp/partitioned“ und „pgp/MIME“. Bei „pgp/partitioned“ wird jedes Attachment einzeln verschlüsselt. Bei pgp/MIME wird – ähnlich wie bei S/MIME – die gesamte E-Mail verschlüsselt.

Der „Body“ einer E-Mail ist aus MIME – Sicht nichts anderes als ein Attachment, wenngleich auch ein spezielles, da dieses in einer E-Mail fast immer doppelt mitgeliefert wird, einmal als Text und einmal als HTML. Der E-Mail Client stellt dann jeweils das dar, was er kann.
Da bei pgp/partitioned jedoch ein Body im HTML-Format nicht möglich ist, wird jeweils nur der Text verschlüsselt und das HTML verworfen. Einige OpenPGP – Implementationen hängen auch als Workaround den HTML – Body als Attachment an.

Für das Entschlüsseln beherrscht SEPPmail sowohl pgp/partitioned als auch pgp/mime. Beim Senden wird jedoch generell pgp/partitioned verwendet. Hintergrund hierfür ist der hohe Verbreitungsgrad von Implementationen welche nicht mit pgp/MIME umgehen können. Eine Einstellung pro Empfänger ist aufgrund des sehr hohen Administrationsaufwandes keine Option, jedoch ist eine generelle Einstellung in den SEPPmail Optionen beziehungsweise – wie oben erwähnt – die HTML – Nachricht als Attachment anzuhängen geplant.

GINA

Wie wird der html-Anhang einer GINA Mail verschlüsselt?

Die Verschlüsselung wird mittels einem AES256 Schlüssel vorgenommen, welcher dem jeweiligen GINA Benutzer zugeordnet ist.

Was passiert mit dem (AES256)Schlüssel eines GINA Benutzers, wenn dieser gelöscht wird?

Wird der GINA Benutzer gelöscht, so wird auch dessen persönlicher AES256 Schlüssel von der Appliance entfernt. Somit kann dieser Benutzer eventuell in seinem Besitz befindliche, nicht exportierte (*.msg/*.eml) GINA Mails nicht mehr zugreifen.

Bezieht sich „Always“ aus „Always use GINA encryption if account exists and no S/MIME or openPGP key is known“ nur auf Mails die als „zu verschlüsselnd“ gekennzeichnet sind oder wirklich auf alle Mails?

„Always“ bezieht sich auf alle Mails, egal ob diese als „zu verschlüsselnd“ gekennzeichnet wurden oder nicht.

Mein Sicherheitsscanner zeigt an, dass die SEPPmail Appliance eine anfällig auf RC4 Attacken ist.

Bei Konfiguration der Appliance wurde ursprünglich auf maximale Kompatibilität geachtet. Durch setzen des Hakens in der Administrationsoberfläche unter „Mail Processing“ – „GINA Settings“ – „Disallow insecure ciphers (breaks windows XP compatibility, but necessary for PCI compliance)“ wird die Anfälligkeit auf RC4 Attacken abgeschaltet.
Dies führt jedoch zur Inkompatibilität mit älteren Systemen.

Warum öffnet der GINA Dateianhang auf meinem iOS (iPad / iPhone) trotz installierter SEPPmail App nicht?

Damit das iOS Gerät in Verbindung mit der SEPPmail App korrekt arbeiten kann, ist ein gültiges Zertifikat für den GINA Zugang auf der SEPPmail Appliance erforderlich. Wenden Sie sich gegebenenfalls an den Betreiber der SEPPmail Appliance.

In der Administrationsoberfläche der Appliance muss im Menü „SSL“ ein Zertifikat einer vertrauenswürdigen CA, welches den FQDN des GINA Zugangs beinhaltet, hinterlegt werden (siehe auch Handbuch „Referenz der Menüpunkte SSL).

Kann das GINA-Interface mittels „Captcha“ vor Robot Eingaben geschützt werden?

Ein Schutz des GINA Interfaces vor Robots mittels Captcha ist aus folgenden Gründen nicht notwendig:

Die Self-Registration ist durch einen Mail-Ping abgesichert. Das heißt durch die Registrierung am Web-Interface wird noch 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.

Auch bei der Anmeldung eines bestehenden Benutzers wurde aus Usability Gründen auf ein Captcha verzichtet. Bei mehrfacher Falscheingabe eines Passwortes – die Anzahl ist natürlich konfigurierbar –  wird der GINA-Benutzer jedoch gesperrt, so dass ein Missbrauch auch hier ausgeschlossen ist.

Weshalb können über die Windows Mail App (Metro Oberfläche) GINA-Mails nicht geöffnet werden?

Die Windows Mail App kann nicht mit den im Standard eingebetteten Cascading Style Sheets (CSS) umgehen.
Die Verwendung von CSS in den Benachrichtigungs E-Mails kann jedoch jeweils pro GINA Interface (siehe Auswahl in der Administrationsoberfläche im Menü „Mail Processing“ in der  Sektion „GINA domains“) abgeschaltet werden. Hierzu wird über die Schaltfläche „Edit“ in das Konfigurationsmenü der zuvor ausgewählten GINA domain gewechselt und dort weiter über die Schaltfläche „Edit GINA Layout“ (oben rechts) zur Sektion „E-Mail CSS“ navigiert. Durch das Entfernen des Hakens der Option „Use HTML e-mail templates based on tables and separate CSS“ wird das Verwenden von CSS in GINA-Mails unterbunden, wodurch diese auch über die Windows Mail App lesbar werden. Über die Schaltfläche „Save“ muss die Änderung noch gespeichert werden.

Wie kann ein vorgeschalteter Loadbalancer die Verfügbarkeit der GINA-Interfaces auf den SEPPmail Appliances eines Clusters prüfen?

Im Standard kann die Verfügbarkeit via OpenSSL wie folgt geprüft werden:

Zunächst die Verbindung zur Appliance (FQDN aus den [default] GINA Einstellungen, im Beispiel securemail.meinfirma.ch) herstellen:

openssl s_client -connect securemail.meinfirma.ch:443

Daraufhin wird Zertifikat, Handshake und so weiter angezeigt. Nun

GET / HTTP/1.0

eingeben und zwei mal (!) Enter drücken. Ist das Interface verfügbar, so wird zunächst die Meldung

HTTP/1.1 200 OK

sowie einige weitere Informationen ausgegeben.

Werden auf der Appliance mehrere GINA Interfaces bereitgestellt, so können diese bei Bedarf explizit durch Angabe deren „Hostname“ Eintrages (zum Beispiel „Mandant1“) aus den jeweiligen GINA Einstellungen geprüft werden (Achtung, Gross-/Kleinschreibung ist zu beachten). Die Abfrage würde nach Herstellen der Verbindung zur Appliance wie folgt lauten:

GET /Mandant1/ HTTP/1.0

Mein Kommunikationspartner hat Probleme bei der Darstellung von GINA-Mails in seinem Browser.

Das GINA Web Interface wird von uns mit jedem Versionswechsel mit den gängigen Browsern getestet. Sollten dennoch Darstellungsprobleme auftauchen, können diese durch leeren des Browser Caches, beziehungsweise wenn dies erfolglos bleibt durch zurücksetzen des Browsers auf Werkseinstellungen beseitigt werden.

Wie kann das Datumsformat in der GINA Oberfläche geändert werden?

Grundsätzlich sind alle Texte der GINA Oberfläche jeweils in den Spracheinstellungen vorzunehmen. Dabei ist jede verwendete Sprache separat zu betrachten.

Anbei eine Beschreibung anhand der deutschen Sprachdatei:
Zunächst ist in der Administrationsoberfläche das Menü „Mail Processing“ zu wählen. In der Sektion „GINA domains“ ist die zu Ändernde GINA Oberfläche aus dem DropDown Menü zu wählen. Durch klicken der Schaltfläche „Edit“ öffnet das Folgemenü mit den entsprechenden „GINA settings“.  Dort ist in der Sektion „Language settings“, Abschnitt „German (d)“  die Schaltfläche „Edit translations“ zu klicken. Ein weiteres Folgemenü öffnet, in welchem ganz unten rechts die Schaltfläche „Advanced View“ zu klicken ist. Im Anschluss kann über die Browser Suchfunktion nach „date_format“ gesucht werden. Im darunter befindlichen Message String „msgstr“ kann das Datumsformat dann nach den individuellen Vorlieben geändert werden. Abschliessend ist der Vorgang mit „Save“ zu beenden.

Hinweis zum Datumsformat:
Die Formatierungen sind ANSI-C89 kompatibel. Eine genauere Beschreibung hierzu ist unter
http://man7.org/linux/man-pages/man3/strftime.3.html
zu finden.
Um das korrekte Format zu generieren ist steht zum Beispiel folgendes Tool im Internet zur Verfügung:
http://www.foragoodstrftime.com/

 

Domänenverschlüsselung

Wie richte ich Domänenverschlüsselung zur SEPPmail Appliance eines meiner Kommunikationspartner ein?

Aufgrund des Managed Domain Services wird der Domain Key aller SEPPmail Appliances automatisch ausgetauscht. Somit werden alle Mails von und zu Kommunikationspartnern, welche eine SEPPmail Appliance betreiben verschlüsselt.

Mein Kommunikationspartner setzt ein Verschlüsselungsgateway eines anderen Herstellers ein. Kann ich trotzdem Domänenverschlüsselung verwenden?

 

Ja, sofern das Verschlüsselungs-Gateway des Kommunikationspartners diese Funktion ebenfalls unterstützt. Dabei muss mit dem Kommunikationspartner der Domänen Schlüssel (bevorzugt S/MIME, wobei auch OpenPGP möglich ist) ausgetauscht werden.

Der öffentliche Domänen Schlüssel der SEPPmail Appliance kann vom Kommunikationspartner direkt über das GINA-Portal heruntergeladen werden, sofern diese Funktion freigeschaltet ist.

Andernfalls ist der Schlüssel in der Administrationsoberfläche unter „Mail System“ -> „Managed Domains“ -> „<Auswahl Ihrer Managed Domain>“ durch den Administrator aus der entsprechenden Sektion (OpenPGP beziehungsweise S/MIME Domain Encryption) herunterzuladen und dem Kommunikationspartner zur Verfügung zu stellen.

Der vom Kommunikationspartner zur Verfügung gestellte öffentliche Domänen Schlüssel ist unter „Domain certificates“ an der entsprechenden Stelle einzubinden.

Verarbeitet die SEPPmail Appliance auch E-Mails an Sub-Domänen der unter „Managed Domains“ eingetragenen Mail-Domänen?

Beispiel:
Unter „Managed Domain“ existiert der Eintrag „ihre-maildomain.ch“. Wird dann eine eingehende Mail an die Adresse max.mustermann@subdomain.ihre-domain.ch ebenfalls von der Appliance verarbeitet und somit an den „Forwarding Server“ der Managed Domain „ihre-maildomain.ch“ weitergeleitet?

Nein, die Maildomain “subdomain.ihre-domain.ch” gilt in diesem Fall an der SEPPmail als unbekannt. Es müssen zwei „Manged Domains“ erstellt werden:
• ihre-maildomain.ch
• subdomain.ihre-maildomain.ch

Trotz eingebundenen Zertifikats für die Domänenverschlüsselung verschlüsselt die Appliance nicht an meinen Kommunikationspartner.

Vermutlich entspricht das zur Verfügung stehende Zertifikat nicht dem Standard für Domain Zertifikate, wie er im RFC3183 (siehe https://tools.ietf.org/html/rfc3183 auf Seite 14 Punkt „4.1 Domain Confidentiality Naming Conventions“) definiert ist.

Ich möchte mit einem Domänenzertifikat alle ausgehenden E-Mails signieren. Was ist zu beachten?

Zwar erscheint die Domänensignatur, also das Signieren aller ausgehender E-Mails mit nur einem S/MIME (Domänen-)Schlüssel, zunächst als günstige Alternative zum Signieren mit jeweils personifizierten S/MIME Schlüsseln. Tatsächlich wird dieses Verfahren jedoch über Kurz oder Lang zu Problemen beziehungsweise enormen Verwaltungsaufwänden führen.

Zur Funktionsweise:
Damit der Antragsteller eines Domänenzertifikates mit dem Absender der E-Mail übereinstimmt, und somit die Signaturprüfung beim Empfänger erfolgreich durchgeführt werden kann, muss der Absender der E-Mail bei jeder ausgehenden E-Mail manipuliert werden, so dass er mit dem Antragsteller des Domänenzertifikats übereinstimmt. Somit wird bei jeder E-Mail die eigentliche Absenderadresse (zum Beispiel max.mustermann@meinefirma.tld) in den „reply to“ Header geschrieben und Inhalt des „from“ Header (max.mustermann@meinefirma.tld) durch die Adresse des Antragstellers des Zertifikates (zum Beispiel signatur@meinefirma.tld) ersetzt.
Antwortet der Empfänger einer solchen E-Mail direkt, so wird die Adresse des „reply to“ Headers verwendet und alles funktioniert wie erwartet.
Nimmt der Empfänger jedoch den Absender der E-Mail in sein Adressbuch auf (Max, Mustermann), so wird unter dessen Namen nicht wie erwartet die E-Mail Adresse (max.mustermann@meinefirma.tld) des angezeigten Absenders (Max, Mustermann) in das Adressbuch übernommen, sondern die umgesetzte Adresse aus dem „from“ Header (signatur@meinefirma.tld). Sendet der ursprüngliche Empfänger nun eine E-Mail an den ursprünglichen Absender Max Mustermann, so wird diese an signatur@meinefirma.tld anstatt max.mustermann@meinefirma.tld gesendet. Ebenso werden sogenannte Non Delivery Reports (NDR) immer an den tatsächlichen Absender einer E-Mail gesendet. Das heißt, erreicht die E-Mail eines Absenders aus der Domäne meinefirma.tld den externen Empfänger gar nicht, so wird der NDR statt an den ursprünglichen Absender an signatur@meinefirma.tld gesendet. Somit ist für den Absender nicht ersichtlich, dass seine E-Mail nicht zugestellt wurde.

Fazit:
Je länger mit einer Domänen Signatur gearbeitet wird, desto mehr und desto häufiger werden E-Mails – irrtümlich – an die Antragsteller Adresse aus dem Zertifikat gesendet. Das heißt auch, dieses Postfach muss in regelmäßigen, kurzen Abständen von einer Person überprüft und die falsch zugestellten E-Mails manuell an die richtigen Empfänger (sofern überhaupt möglich/erkennbar) weitergeleitet werden. Unterbleibt dies, können daraus nicht zuletzt rechtliche Nachteile entstehen.

In unserem Handbuch zum entsprechenden Konfigurationspunkt dementsprechend auch folgende Warnung zu finden:
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.

TLS

Mein Sicherheitsscanner zeigt an, dass die SEPPmail Appliance eine alte TLS Version verwendet.

Meist ist die Ursache für solche Meldungen, dass der TLS Tunnel gar nicht an der SEPPmail Appliance, sondern einem vorgelagerten E-Mail Relay / Firewall terminiert wird.

In seltenen Fällen könnte jedoch auch bei Terminierung des Tunnels durch die SEPPmail Appliance eine veraltete TLS Version angezeigt werden.  Hintergrund hierfür ist, dass die verwendete TLS Version vom eingestellten TLS Sicherheitslevel abhängig ist. Im Standard verwendet die Appliance opportunistisches TLS (verwenden wenn möglich/vorhanden). Dieser Sicherheitslevel ist in der aktuellsten Version von TLS nicht mehr zulässig.

Weshalb verwendet die SEPPmail Appliance kein Perfect Forward Secrecy (PFS)?

PFS Könnte problemlos auf dem Frontend durchgesetzt werden. Allerdings könnten Anwender mit älteren Browsern dadurch nicht mehr zugreifen.

Derzeit sind wir auf der Suche nach einer sinnvollen Kombination, die sowohl PFS sicherstellt aber auch mit den meisten Browsern funktioniert.

Bei SMTP TLS ist PFS im Standard aktiviert.

Interne Mailverschlüsselung IME

Zertifikate

Werden zwingend (Kauf-)Zertifikate für den Betrieb einer SEPPmail Appliance benötigt?

Für den produktiven Betrieb einer SEPPmail Appliance empfiehlt es sich, wenigstens ein Server-Zertifikat einer vertrauenswürdigen Zertifizierungsstelle (Trusted-CA) für den SSL-Zugriff auf die GINA-Webseite einzubinden. Sollte hier ein selbst generiertes Zertifikat (self signed certificate) verwendet werden, so kommt beim Aufruf der GINA-Seite eine Meldung des Browsers, dass der Seite nicht vertraut wird.

Sollen ausgehende E-Mails signiert werden, empfiehlt es sich zusätzlich – wenigstens für diejenigen Benutzer, welche signieren sollen – E-Mail Zertifikate einer Trusted-CA zu verwenden.

Ist die Anbindung einer Hardware Security Modules (HSM) möglich?

In der Regel macht das Sicherheitskonzept der Appliance in Kombination mit den vorhandenen Überwachungsmöglichkeiten (SamHain, Audit Log, SNMP etc) ein HSM unnötig.

Weiterhin kann über die Möglichkeit, die Appliance PCI-compliant aufzusetzen, ein Anmelden an die Appliance via Kommandozeile (CLI) oder SSH unterbunden werden. Somit ist der Zugriff auf das Betriebssystem nicht mehr möglich. Alle Aktionen auf der Appliance werden zusätzlich in einem Audit-Log dokumentiert und auf Wunsch an einen – bei Bedarf separaten – Syslogserver gesendet.
Das Schlüsselmaterial selbst liegt in der Appliance in einem wiederum verschlüsselten LDAP Verzeichnis. Ein Export der Schlüssel aus dem System ist somit unmöglich. Das heisst die Funktion zum Schutz des Schlüsselmaterials entspricht in der PCI-Variante der eines HSMs.

Sollte dennoch  weiterer Schutz des Schlüsselmaterials gefordert sein, so besteht die Möglichkeit, einen Security-(USB-)Token für den Schlüssel des intern verwendeten, verschlüsselten LDAP Verzeichnisses zu verwenden.

Nichtsdestotrotz unterstützt die Appliance die Anbindung von Netzwerk-HSMs der Hersteller Thales und SafeNet voll – das heisst auch in Clusterkonfigurationen.

Weshalb wird die Signatur einer E-Mail als ungültig [signed INVALID] angezeigt

letztendlich gibt es zwei Möglichkeiten, weshalb eine Signatur als ungültig eingestuft wird:

  1. Die Signatur Kette „CA -> ggf. SubCA(s) -> Persönlicher Schlüssel“ kann nicht geprüft werden
    1. Dies ist meist bei selbst signierten Zertifikaten so, da hier der Aussteller in der Regel nicht bei den vertrauenswürdigen Stammzertifizierungsstellen (X.509 Root Certificates) eingetragen ist.
    2. Wenn das Root Zertifikat der ausstellenden CA nicht bekannt ist.
    3. Wenn das Root Zertifikat der ausstellenden CA zwar bekannt ist, diesem aber nicht vertraut wird.
    4. Wenn das Zertifikat einer eventuellen SubCA, welche zur Vervollständigung der Kette notwendig ist, weder in der Signatur enthalten, noch auf der prüfenden Maschine bekannt ist.
  2. Die E-Mail nach dem Signieren verändert wurde
    Dies kann

    1. mutwillig durch einen Dritten
    2. durch das Anhängen – zum Beispiel eines Disclaimers – nach dem Signieren
    3. durch ein ungewolltes umcodieren an einem zwischengelagerten E-Mail Server

passieren.

Um nachvollziehen zu können, weshalb eine Signatur als ungültig erkannt wurde, empfiehlt es sich, diese – zumindest für diesen Fall – nicht abzuschneiden (Mail Processing :: Ruleset Generator :: Signing :: Incoming e-mails :: remove signature if S/MIME signature check fails -> kein Haken)

Damit wird der Empfänger in die Lage versetzt, die Signatur am Client erneut zu prüfen.

Sind von einem Empfänger mehrere Zertifikate auf der SEPPmail Appliance bekannt, welches wird dann für das Verschlüsseln verwendet?

Die E-Mail – beziehungsweise genauer, der symmetrische Schlüssel – wird jeweils mit allen gültigen Zertifikaten des Empfängers verschlüsselt. Der Empfänger kann die E-Mail somit mit jedem zu einem dieser Zertifikate gehörigen Schlüssel entschlüsseln.
Sollten ausschliesslich abgelaufene Zertifikate des Empfängers bekannt sein, so wird das aktuellste dieser Zertifikate für das Verschlüsseln herangezogen.

Welcher X.509 Schlüssel wird für das Signieren von E-Mails verwendet, wenn für einen Benutzer mehrere Schlüssel auf der SEPPmail Appliance bereit stehen?

Für das  Signieren verwendet die SEPPmail Appliance das Zertifikat mit der jeweils längsten Gültigkeit.
Generell gilt jedoch, per MPKI ausgestellte Zertifikate werden bevorzugt zur Signierung verwendet („Bonus“ von 10 Jahren). Damit wird verhindert, dass „Umsteiger“, welche zunächst Zertifikate einer selbst signierten CA (diese stellt im Standard Zertifikate mit einer Laufzeit von zehn Jahren aus) im Einsatz hatten, weiterhin mit diesen Zertifikaten anstatt der über die MPKI bezogenen Trusted Zertifikate (diese werden in der Regel mit einer Laufzeit von nur einem Jahr ausgestellt) signieren.

Welche Parameter müssen für das Anbinden der MPKI an SwissSign angegeben werden?

Für Neukunden:
Neukunden erhalten nach dem Einrichten der Schnittstelle seitens SwissSign eine „Welcome E-Mail“. Darin enthalten ist eine Schritt für Schritt Kurzanweisung zum entsprechenden Konfigurationsmenü in der SEPPmail Appliance sowie den in die jeweiligen Eingabefelder einzusetzenden Parametern.

Für SEPPmail Bestandskunden, welche von einem anderen MPKI Anbieter zu SwissSign wechseln
SEPPmail Bestandskunden sollten bei einem MPKI-Wechsel zu SwissSign unbedingt darauf achten, dass der Versionsstand der Appliance 7.4.6 oder höher ist.
Ansonsten gilt das gleiche Procedere wie bei Neukunden.

Für SwissSign Bestandskunden:
Die im folgenden Dokument bereit gestellten Informationen  zur Einrichtung des „SwissSign legacy“ Connectors wurden mit freundlicher Genehmigung der SwissSign AG Verfügung gestellt:
Hinweise zur Einrichtung der „SwissSign legacy“ MPKI
Bei Einsatz der Appliance Version 7.4.6 oder höher, besteht die Möglichkeit auf den neuen CMC Connector zu wechseln, welcher den Legacy Connector ersetzt.
Sollten kundenseitig Änderungen an der bestehenden SwissSign Connector Konfiguration erforderlich sein (zum Beispiel hinzufügen einer weiteren E-Mail Domäne), so sprechen Sie Ihren SwissSign Betreuer bitte bezüglich der Umstellung auf den CMC Connector an.

Werden nach dem Umstellen der MPKI auf einen anderen Anbieter die Zertifikate für Bestands-User automatisch vom neuen Anbieter bezogen?

Ja, nach dem Umstellen der MPKI von einem Anbieter auf einen anderen werden neue Zertifikate – auch bei der automatischen Erneuerung, sofern eingestellt – sofort vom neuen Anbieter bezogen.

Weshalb sendet SwissSign trotz automatischer Zertifikatserneuerung Benachrichtigungen über abgelaufene Zertifikate?

In der SEPPmaail Appliance ist die SwissSign MPKI aktiviert und eine automatische Zertifikatserneuerung X-Tage vor Ablauf eines Zertifikate s eingestellt.

Trotzdem erhalten Benutzer eine Benachrichtigungs-E-Mail von „ca@swisssign.net“, dass ein Zertifikat abgelaufen sei, zum Beispiel:

Betreff: SwissSign – Your Certificate xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Has Expired

Dear customer,

The following SwissSign certificate has expired:

/CN=Secure Mail: SEPPmail Certificate
/Email=max.mustermann@meinefirma.tld<mailto:Certificate
/Email=max.mustermann@meinefirma.tld<mailto:Certificate
/Email=max.mustermann@meinefirma.tld%3cmailto:Certificate
/Email=max.mustermann@meinefirma.tld>>

The request ID is

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

If you bought your certificate in our webshop please visit our SwissSign Webshop<https://www.swisssign.com/en> again and request a new SwissSign Certificate. If you are a Managed PKI user please request a new certificate via your Managed PKI IT administrator.

If you have already renewed your certificate, you can ignore this message.

This is an automatically generated email. Please do not reply to this email. If you have any questions as direct customer of our SwissSign web shop please feel free to use our contact form<https://www.swisssign.com/contact&gt;. If you are a Managed PKI customer please contact directly the helpdesk of your organization.

Best regards,

Your SwissSign Team

Da die Zertifikate nicht verlängert werden (können), wird jeweils vor Ablauf eines Zertifikates ein neues erstellt. Ist bei SwissSign eine Warnung bei Ablauf von Zertifikaten eingestellt, wird für das ablaufenede, aber bereits ersetzte Zertifikat dennoch eine Benachrichtigungs-E-Mail generiert.
Sofern die automatische Zertifikatserneuerung in der MPKI aktiv ist, kann diese E-Mail also ignoriert werden. Alternativ kann diese Benachrichtigung durch SwissSign generell abgestellt lassen. Wenden Sie sich hierfür bitte an Ihren SwissSign Ansprechpartner.

Unterstützt SEPPmail MultiDomain (SAN) SSL Zertifikate?

Ja.

Sicherheit

Mein Sicherheitsscanner zeigt an, dass die SEPPmail Appliance eine alte TLS Version verwendet.

Meist ist die Ursache für solche Meldungen, dass der TLS Tunnel gar nicht an der SEPPmail Appliance, sondern einem vorgelagerten E-Mail Relay / Firewall terminiert wird.

In seltenen Fällen könnte jedoch auch bei Terminierung des Tunnels durch die SEPPmail Appliance eine veraltete TLS Version angezeigt werden.  Hintergrund hierfür ist, dass die verwendete TLS Version vom eingestellten TLS Sicherheitslevel abhängig ist. Im Standard verwendet die Appliance opportunistisches TLS (verwenden wenn möglich/vorhanden). Dieser Sicherheitslevel ist in der aktuellsten Version von TLS nicht mehr zulässig.

Ist die Anbindung einer Hardware Security Modules (HSM) möglich?

In der Regel macht das Sicherheitskonzept der Appliance in Kombination mit den vorhandenen Überwachungsmöglichkeiten (SamHain, Audit Log, SNMP etc) ein HSM unnötig.

Weiterhin kann über die Möglichkeit, die Appliance PCI-compliant aufzusetzen, ein Anmelden an die Appliance via Kommandozeile (CLI) oder SSH unterbunden werden. Somit ist der Zugriff auf das Betriebssystem nicht mehr möglich. Alle Aktionen auf der Appliance werden zusätzlich in einem Audit-Log dokumentiert und auf Wunsch an einen – bei Bedarf separaten – Syslogserver gesendet.
Das Schlüsselmaterial selbst liegt in der Appliance in einem wiederum verschlüsselten LDAP Verzeichnis. Ein Export der Schlüssel aus dem System ist somit unmöglich. Das heisst die Funktion zum Schutz des Schlüsselmaterials entspricht in der PCI-Variante der eines HSMs.

Sollte dennoch  weiterer Schutz des Schlüsselmaterials gefordert sein, so besteht die Möglichkeit, einen Security-(USB-)Token für den Schlüssel des intern verwendeten, verschlüsselten LDAP Verzeichnisses zu verwenden.

Nichtsdestotrotz unterstützt die Appliance die Anbindung von Netzwerk-HSMs der Hersteller Thales und SafeNet voll – das heisst auch in Clusterkonfigurationen.

Mein Sicherheitsscanner zeigt an, dass die SEPPmail Appliance eine anfällig auf RC4 Attacken ist.

Bei Konfiguration der Appliance wurde ursprünglich auf maximale Kompatibilität geachtet. Durch setzen des Hakens in der Administrationsoberfläche unter „Mail Processing“ – „GINA Settings“ – „Disallow insecure ciphers (breaks windows XP compatibility, but necessary for PCI compliance)“ wird die Anfälligkeit auf RC4 Attacken abgeschaltet.
Dies führt jedoch zur Inkompatibilität mit älteren Systemen.

Kann das GINA-Interface mittels „Captcha“ vor Robot Eingaben geschützt werden?

Ein Schutz des GINA Interfaces vor Robots mittels Captcha ist aus folgenden Gründen nicht notwendig:

Die Self-Registration ist durch einen Mail-Ping abgesichert. Das heißt durch die Registrierung am Web-Interface wird noch 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.

Auch bei der Anmeldung eines bestehenden Benutzers wurde aus Usability Gründen auf ein Captcha verzichtet. Bei mehrfacher Falscheingabe eines Passwortes – die Anzahl ist natürlich konfigurierbar –  wird der GINA-Benutzer jedoch gesperrt, so dass ein Missbrauch auch hier ausgeschlossen ist.

Eine Prüfung der TLS Verbindung zum Beispiel mit CheckTLS(.com) zeigt an, dass das Zertifikat nicht validiert werden konnte, obwohl auf der Appliance ein SSL Zertifikat einer Trusted CA eingebunden ist.

Diensten wie CheckTLS sind nur die Root Zertifikate der üblichen Trusted CAs bekannt. Häufig werden jedoch SSL Zertifikate nicht durch die Root CA direkt, sondern durch Sub CAs ausgestellt. Deshalb ist beim Importieren des Zertifikates darauf zu achten, dass über die Administrationsoberfläche im Menü „SSL“ über die Funktion „Request a new certificate…“ zum privaten Schlüssel nicht nur der passende öffentliche Schlüssel, sondern auch der/die öffentliche(n) Schlüssel der Sub-CA(s) eingefügt werden.
So wird sichergestellt, dass die Zertifikatskette auch dann geprüft werden kann, wenn dem prüfenden System nur das Root CA Zertifikat vorliegt.

Ist SEPPmail von der GLIBC Lücke betroffen?

Nein.

SEPPmail basiert auf OpenBSD und ist somit nicht betroffen.

Warum weist meine Appliance nach dem Aktivieren des Virenscanners alle E-Mails ab?

Nach dem Aktivieren der Option(en) Use ClamAV AntiVirus Engine (Note: remember to activate in ruleset) und gegebenenfalls Enable unofficial Signatures for ClamAV aus dem Menü Mail System, Sektion AntiSpam kann es je nach Internetanbindung sehr lange dauern, bis die Signaturen für die AntiVirus Engine zur Verfügung stehen.
Solange die Signaturen noch nicht zur Verfügung stehen, werden bei aktivierter Option alle E-Mails mit dem Fehler „Virus scan: Runtime Error“ abgewiesen „Message Rejected. (421 Rule Engine Error)“.

Gruppen

Antivirus

Warum weist meine Appliance nach dem Aktivieren des Virenscanners alle E-Mails ab?

Nach dem Aktivieren der Option(en) Use ClamAV AntiVirus Engine (Note: remember to activate in ruleset) und gegebenenfalls Enable unofficial Signatures for ClamAV aus dem Menü Mail System, Sektion AntiSpam kann es je nach Internetanbindung sehr lange dauern, bis die Signaturen für die AntiVirus Engine zur Verfügung stehen.
Solange die Signaturen noch nicht zur Verfügung stehen, werden bei aktivierter Option alle E-Mails mit dem Fehler „Virus scan: Runtime Error“ abgewiesen „Message Rejected. (421 Rule Engine Error)“.

Antispam

Large File Management

Gibt es eine Grössenbeschränkung für LFT-Mails?

Die Grössenbeschränkung bei LFT ergibt sich grundsätzlich aus dem hierfür zur Verfügung gestellten Speicherplatz. Natürlich kann bei Bedarf manuell limitiert werden. Diese Limits können pro GINA-Interface individuell eingestellt werden.
Werden LFT-Mails über den „normalen“ Mailstrom, also vom Groupware Server direkt per SMTP eingeliefert,  so entsteht aus den SMTP Partitionsgrössen eine systemabhängige Beschränkung. Die genaue maximal mögliche Größe ist in der Administrationsoberfläche im Menü „Mail System“, Sektion „SMTP settings“ im Abschnitt „max. message size (kB)” als Kommentar zu sehen (Note: cannot exceed xxxxx kB).

Nähere Informationen zur Dimensionierung der Appliance können dem Handbuch, Kapitel „3.3.2 Sizing“ entnommen werden.

Mandantenfähigkeit

Mein Mandant hat eine dynamische IP-Adresse. Aus diesem Grund kann ich diese nicht als Relaying Host eintragen. Wie kann ich diese Problem umgehen?

Gehen Sie wie folgt vor:

  1. Richten Sie unter „Mail System -> Managed Domains“ mittels „Add Domain…“ eine neue Managed Domain mit dem Namen „loginpseudodomain.local“ und der IP 127.0.0.1 ein.
  2. Generieren Sie für den betroffenen Mandanten einen Benutzer mit dem Namen (User ID, Full Name, E-Mail jeweils) „smtplogin@<E-Mail Domäne des Kunden>“.
  3. Vergeben Sie dem neu Angelegten Benutzer „smtplogin@<E-Mail Domäne des Kunden>“ ein Passwort.
  4. Haken Sie bei diesem Benutzer unter „User Data -> Encryption Settings“ die beiden Punkte
     May not encrypt mails
     May not sign mails
    an. Dadurch verhindern Sie, dass eine Benutzerlizenz gezählt wird.
  5. Ordnen Sie diesen Benutzer dem entsprechenden Mandanten zu (unter Customer).
  6. Tragen Sie beim Kunden als SMTP-Server die SEPPmail Appliance ein mit der Option der SMTP Authentifizierung via TLS. Als Benutzernamen tragen Sie den hierfür angelegten Benutzer „smtplogin@<E-Mail Domäne des Kunden>“ und dessen zuvor vergebenes Passwort ein.

Clusterbetrieb

Weshalb treten Probleme bei der Einrichtung eines Clusters beziehungsweise bei der Sychronisierung auf?

Für den Clusterbetrieb ist die korrekte Zeit der Clusterpartner unerlässlich. Das heisst an jeder Maschine ist zu prüfen, dass

  • NTP aktiv ist
  • die gleichen Zeitserver verwendet werden
  • der NTP Zugriff und somit die Zeitsyschronisation auf allen Clusterpartnern funktioniert

Wie kann ein vorgeschalteter Loadbalancer die Verfügbarkeit der GINA-Interfaces auf den SEPPmail Appliances eines Clusters prüfen?

Im Standard kann die Verfügbarkeit via OpenSSL wie folgt geprüft werden:

Zunächst die Verbindung zur Appliance (FQDN aus den [default] GINA Einstellungen, im Beispiel securemail.meinfirma.ch) herstellen:

openssl s_client -connect securemail.meinfirma.ch:443

Daraufhin wird Zertifikat, Handshake und so weiter angezeigt. Nun

GET / HTTP/1.0

eingeben und zwei mal (!) Enter drücken. Ist das Interface verfügbar, so wird zunächst die Meldung

HTTP/1.1 200 OK

sowie einige weitere Informationen ausgegeben.

Werden auf der Appliance mehrere GINA Interfaces bereitgestellt, so können diese bei Bedarf explizit durch Angabe deren „Hostname“ Eintrages (zum Beispiel „Mandant1“) aus den jeweiligen GINA Einstellungen geprüft werden (Achtung, Gross-/Kleinschreibung ist zu beachten). Die Abfrage würde nach Herstellen der Verbindung zur Appliance wie folgt lauten:

GET /Mandant1/ HTTP/1.0

In welcher Reihenfolge sollte ein Update im Cluster durchgeführt werden?

Da Prinzipiell alle Appliances in einem Cluster gleichberechtigt sind, spielt es keine Rolle, in welcher Reihenfolge das Update von statten geht.
Wird auf der Appliance jedoch mit virtuellen IP Adressen gearbeitet, so ist gegebenenfalls die hier eingestellte Hierarchie beim Entgegennehmen von SMTP-Traffic zu beachten.

Eine Ausnahme sind Frontend-Backend Cluster, da diese Maschinen nicht gleichberechtigt sind. Hier ist/sind immer zunächst die Frontend Maschine(n) zu aktualisieren.

Updates sind in der Regel kumulativ. Einige Updates haben jedoch Auswirkungen auf die in der Appliance vorhandene Datenbank. Diese müssen immer als Zwischenschritt installiert werden, damit die nächste Version auf einen entsprechenden Datenbank Stand aufsetzen kann. Das heisst, wurde das System nicht stets auf den aktuellen Stand gebracht, wird unter Umständen nicht die aktuellste, sondern eine dieser Zwischenversionen zum Update angeboten.
In diesem Fall sind immer alle Appliances des Clusters zunächst auf den nächst höheren Stand zu bringen, bevor mit dem Update auf den aktuellen Stand fortgefahren wird.

Erfordert das Update ein aktualisieren des Rulesets (dies ist gegebenenfalls in der Administrationsoberfläche im Menü „Administration“ in der Sektion „Update“ durch klicken der Schaltfläche „Check for update“ nachzulesen), so sollte diese Aktion erst dann ausgeführt werden, wenn alle Appliances im Cluster den entsprechenden Versionsstand haben.
Grundsätzlich funktioniert ein „altes“ Ruleset auf der neueren Version immer.
Mit dem Generieren des neuen Rulesets werden neue Funktionen des Ruleset freigeschaltet. Das Ruleset muss nur an einer Maschine des Clusters aktualisiert werden, da es sofort nach dem Generieren an die weiteren Cluster Partner repliziert wird.

Warum übernimmt bei Ausfall eines Cluster-Partners nicht der andere?

Die virtuele IP-Adresse wird nur dann vom entsprechend konfigurierten Cluster-Partner übernommen, wenn die problembehaftete Maschine auch netzwerktechnisch nicht mehr erreichbar ist.

Dieser Fall kann dann eintreten, wenn zum Beispiel die problembehaftete (virtuelle) Maschine aufgrund eines nicht mehr, oder nicht mehr zuverlässig verfügbaren Datenspeicher „kernel panic“ anzeigt.

Backup

Weshalb funktioniert der „Factory reset“ nicht, obwohl ich den Sicherheitscode eingegeben habe?

Aufgrund der folgenschweren Auswirkungen eines versehentlich durchgeführten „Factory reset“, muss der Sicherheitscode rückwärts eingegeben werden.

Ist es möglich, Backups und/oder Log-Dateien auch abzuholen?

Ja, die Möglichkeit diese Dateien per SCP abzuholen besteht. Die Vorgehensweise ist im Handbuch in der „Referenz der Menüpunkte“ unter „Administration“ in der Sektion „Backup“ beschrieben.

Migration

Wie können nach einer Migration auf SEPPmail, lokal im E-Mail Client abliegende, verschlüsselte E-Mails nach entfernen des Schlüsselmaterials vom Client dennoch entschlüsselt werden?

Nachdem das zuvor auf den Clients verteilte Schlüsselmaterial auf der SEPPmail importiert wurde hat jeder (migrierte) Benutzer die Möglichkeit noch lokal abliegende, verschlüsselte E-Mails von der SEPPmail Appliance Entschlüsseln zu lassen, sofern diese Funktion durch den Administrator freigeschaltet ist (Aktive Option „Reprocess mails sent to reprocess@decrypt.reprocess“ in der welche in der Administrationsoberfläche im Menü „Mail Processing“, Sektion „Ruleset Generator“, Abschnitt „General Settings“ zu finden ist).

Hierzu wird die zu entschlüsselnde E-Mail vom betroffenen Benutzer in eine neue E-Mail eingefügt (nicht weiterleiten!!!) und an die Adresse reprocess@decrypt.reprocess gesendet. Die Appliance verwirft die neue Träger-E-Mail und sendet die ursprünglich verschlüsselte E-Mail entschlüsselt an den betroffenen Benutzer zurück.
Auf diese Weise können zudem bei Bedarf OpenPGP verschlüsselte Dokumente entschlüsselt werden.

Performanz

Wie kann ich E-Mails an zwei interne Mailserver abgeben? Unter „Mail System -> Managed Domains“ besteht nur die Möglichkeit eine IP-Adresse als „Forwarding Server“ anzugeben.

 

Die Server können über einen MX-Record angesprochen werden. Dieser sollte idealerweise auf dem internen DNS-Server angelegt werden.

Ist dies nicht möglich, so besteht die Möglichkeit in der Administrationsoberfläche im Menü „System“ in der Ansicht „Advanced View“ in der Sektion „DNS“ unter „add local zone:“ eine entsprechende Pseudo-Domäne anzulegen, welche dann als Forwarding Server angegeben werden kann.

Beispiel:

2

3

Das Aufrufen des Menüs „Administration“ in der Administrationsoberfläche dauert extrem lange. Alle anderen Seiten öffnen relativ normal. Gegebenenfalls wird auch eine Meldung angezeigt, dass das System nicht registriert sei. Beim Versuch die Appliance zu registrieren erscheint jedoch die Meldung, dass diese bereits registriert sei.

Der im Menü „System“ eingetragene (erste) DNS-Server ist nicht erreichbar. Das Warten auf einen entsprechenden Timeout verursacht diese Problematiken.

Durch Eintragen eines erreichbaren DNS-Server als „Primary“, wird das Problem behoben.

Weshalb synchronisiert NTP mehrmals binnen einer Minute?

Unter optimalen Bedingungen synchronisiert NTP standardmässig alle 64 bis 1024 Sekunden.

Synchronisiert NTP öfter, kann das an vielen Dingen liegen, vor allem aber:

1. Je nach Synchronisationsgüte muss NTP öfter die Serverzeit anfordern.
2. Sollte NTP zu bestimmten Servern per Firewall gesperrt sein, gibt es natürlich erneute Anfragen.
3. NTP verwendet verbindungsloses UDP. Je nach Paketverlustrate kann dies auch zu wiederholten Anfragen führen.

Ausschlaggebend kann  auch die Art der Appliance sein (Hardware oder virtuell).
Bei Microsoft Hyper-V kann zum Beispiel durch starken Clock-Drift im Gastsystem vermehrt die in Punkt 1 genannte Ursache auftreten.

E Mail Verarbeitung

Warum erhalten Empfänger eine Anlage namens „winmail.dat“?

Outlook beziehungsweise Exchange verfügt über drei verschiedene Formate für das Verfassen von E-Mails:

  1. Nur Text
  2. HTML
  3. Rich Text (RTF)

Während „Nur Text“ und „HTML“ in der Regel von allen E-Mail Clients gelesen werden können, handelt es sich bei „RTF“ um ein proprietäres Microsoft Format.
Aus diesem Grund sollte das Verwenden dieses Formats sowohl in Outlook als auch in Exchange unterbunden werden, um diese Problematik zu vermeiden.
Sollte das Problem dennoch weiterhin auftreten, lesen Sie bitte den Artikel kb958012.

Kann die SEPPmail Appliance an Microsoft Office365 angebunden werden?

Ja, eine Schritt für Schritt Anweisung ist im anhängenden PDF-Dokument zu finden.

office365_Anbindung

Weshalb wird der als „Forwarding Server“ beziehungsweise „SMTP Server“ eingegebene FQDN nicht als Hostname sondern als MX aufgelöst?

Soll der FQDN als Hostname aufgelöst werden, so ist dieser in eckige Klammern [ ] zu setzen.

Der Versand von E-Mails funktioniert nicht über meinen Provider Strato, obwohl der Server wie vorgegeben in der Administrationsoberfläche unter „Mail System -> Outgoing Server -> Use the following SMTP server: -> Server name -> [smtp.strato.de]:465“ eingetragen wurde

Verwenden Sie Port 587 anstatt 465, also „[smtp.strato.de]:587“. Nähere Erklärungen sind den FAQs des Providers zu entnehmen.

Eine eingehende signierte E-Mail kann an meinem Mobilen Endgerät nicht geöffnet werden beziehungsweise kann auf eine signierte E-Mail nicht geantwortet werden. Dies, obwohl die E-Mail Signatur bereits an der SEPPmail Appliance geprüft, und die E-Mail gekennzeichnet wurde.

Die SEPPmail Appliance wurde so konfiguriert, dass E-Mail Signaturen nach deren Prüfung nicht abgeschnitten wurden. Im Normalfall steht auf Mobilen Endgeräten aus Sicherheitsgründen kein Schlüsselmaterial zur Verfügung, so dass keine Möglichkeit für das Prüfen von Schlüsselmaterial gegeben ist. Dies ist ursächlich für das genannte Verhalten.

Um die Problematik zu umgehen, empfiehlt sich das Abschneiden der Signaturen an der Appliance (siehe Administrationsoberfläche „Mail Processing -> Ruleset Generator -> Signing -> Incoming e-mails -> remove signature if S/MIME signature check succeeds/fails“)

Weshalb wird eine HTML-E-Mail nach der OpenPGP Verschlüsselung beim Empfänger als Text-Mail angezeigt?

Bei OpenPGP gibt es generell zwei Möglichkeiten eine E-Mail zu verschlüsseln, „pgp/partitioned“ und „pgp/MIME“. Bei „pgp/partitioned“ wird jedes Attachment einzeln verschlüsselt. Bei pgp/MIME wird – ähnlich wie bei S/MIME – die gesamte E-Mail verschlüsselt.

Der „Body“ einer E-Mail ist aus MIME – Sicht nichts anderes als ein Attachment, wenngleich auch ein spezielles, da dieses in einer E-Mail fast immer doppelt mitgeliefert wird, einmal als Text und einmal als HTML. Der E-Mail Client stellt dann jeweils das dar, was er kann.
Da bei pgp/partitioned jedoch ein Body im HTML-Format nicht möglich ist, wird jeweils nur der Text verschlüsselt und das HTML verworfen. Einige OpenPGP – Implementationen hängen auch als Workaround den HTML – Body als Attachment an.

Für das Entschlüsseln beherrscht SEPPmail sowohl pgp/partitioned als auch pgp/mime. Beim Senden wird jedoch generell pgp/partitioned verwendet. Hintergrund hierfür ist der hohe Verbreitungsgrad von Implementationen welche nicht mit pgp/MIME umgehen können. Eine Einstellung pro Empfänger ist aufgrund des sehr hohen Administrationsaufwandes keine Option, jedoch ist eine generelle Einstellung in den SEPPmail Optionen beziehungsweise – wie oben erwähnt – die HTML – Nachricht als Attachment anzuhängen geplant.

Können E-Mails zu einer bestimmten E-Mail Ziel-Domäne über einen bestimmten E-Mail Server geleitet werden?

Ja, durch den Eintrag  der E-Mail Domäne als TLS-Domain.

Hierzu ist zunächst in der Administrationsoberfläche im Menü „Mail System“, in der Sektion „TLS settings“ über die Schaltfläche „Add TLS Domain…“  das Menü für das Hinzufügen neuer TLS Ziel Domänen zu öffnen.
Anschliessend ist in der Sektion „Domain Info“ unter „Domain Name“ der Name der E-Mail Domäne einzutragen, welche  über einen bestimmten E-Mail Server geleitet werden sollen. Besagter E-Mail Server ist unter „Optional Forwarding Server Address“ einzutragen.
Über die Schaltfläche Save ist der Eintrag zu sichern.

Hinweis:
Im Standard wird die TLS Einstellung (siehe Sektion „TLS Settings“) „May“ (opportunistisch, verschlüsseln wenn möglich) verwendet.
Natürlich kann bei dieser Gelegenheit bei Bedarf auch ein individueller Level eingestellt, beziehungsweise die TLS Verschlüsselung unterdrückt werden.

Weshalb erhalte ich teilweise E-Mails als Anhang einer leeren Träger-E-Mail?

Die SEPPmail Appliance ist so konfiguriert, dass sie nach dem Prüfen einer S/MIME Signatur diese nicht abschneidet.

Das beziehungsweise ein nachfolgendes E-Mail System – in der Regel der interne Groupware Server – versucht der E-Mail einen Disclaimer oder Footer anzuhängen, zum Beispiel „Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss!“.
Dabei stellt das E-Mail-System fest, dass die von der SEPPmail zugestellte E-Mail über eine S/MIME Signatur verfügt. Da diese Signatur durch Anhängen des Disclaimers zerstört würde, packt das System die komplette E-Mail als Anhang in eine Träger-E-Mail, welche dann mit dem Disclaimer versehen wird.

Um dieses Verhalten abzustellen sollte das Anhängen des Disclaimers abgeschaltet werden. Alternativ kann auf der SEPPmail die Signatur nach deren Prüfung abgeschnitten werden (Remove signature if S/MIME signature check…).

 

Ich möchte mit einem Domänenzertifikat alle ausgehenden E-Mails signieren. Was ist zu beachten?

Zwar erscheint die Domänensignatur, also das Signieren aller ausgehender E-Mails mit nur einem S/MIME (Domänen-)Schlüssel, zunächst als günstige Alternative zum Signieren mit jeweils personifizierten S/MIME Schlüsseln. Tatsächlich wird dieses Verfahren jedoch über Kurz oder Lang zu Problemen beziehungsweise enormen Verwaltungsaufwänden führen.

Zur Funktionsweise:
Damit der Antragsteller eines Domänenzertifikates mit dem Absender der E-Mail übereinstimmt, und somit die Signaturprüfung beim Empfänger erfolgreich durchgeführt werden kann, muss der Absender der E-Mail bei jeder ausgehenden E-Mail manipuliert werden, so dass er mit dem Antragsteller des Domänenzertifikats übereinstimmt. Somit wird bei jeder E-Mail die eigentliche Absenderadresse (zum Beispiel max.mustermann@meinefirma.tld) in den „reply to“ Header geschrieben und Inhalt des „from“ Header (max.mustermann@meinefirma.tld) durch die Adresse des Antragstellers des Zertifikates (zum Beispiel signatur@meinefirma.tld) ersetzt.
Antwortet der Empfänger einer solchen E-Mail direkt, so wird die Adresse des „reply to“ Headers verwendet und alles funktioniert wie erwartet.
Nimmt der Empfänger jedoch den Absender der E-Mail in sein Adressbuch auf (Max, Mustermann), so wird unter dessen Namen nicht wie erwartet die E-Mail Adresse (max.mustermann@meinefirma.tld) des angezeigten Absenders (Max, Mustermann) in das Adressbuch übernommen, sondern die umgesetzte Adresse aus dem „from“ Header (signatur@meinefirma.tld). Sendet der ursprüngliche Empfänger nun eine E-Mail an den ursprünglichen Absender Max Mustermann, so wird diese an signatur@meinefirma.tld anstatt max.mustermann@meinefirma.tld gesendet. Ebenso werden sogenannte Non Delivery Reports (NDR) immer an den tatsächlichen Absender einer E-Mail gesendet. Das heißt, erreicht die E-Mail eines Absenders aus der Domäne meinefirma.tld den externen Empfänger gar nicht, so wird der NDR statt an den ursprünglichen Absender an signatur@meinefirma.tld gesendet. Somit ist für den Absender nicht ersichtlich, dass seine E-Mail nicht zugestellt wurde.

Fazit:
Je länger mit einer Domänen Signatur gearbeitet wird, desto mehr und desto häufiger werden E-Mails – irrtümlich – an die Antragsteller Adresse aus dem Zertifikat gesendet. Das heißt auch, dieses Postfach muss in regelmäßigen, kurzen Abständen von einer Person überprüft und die falsch zugestellten E-Mails manuell an die richtigen Empfänger (sofern überhaupt möglich/erkennbar) weitergeleitet werden. Unterbleibt dies, können daraus nicht zuletzt rechtliche Nachteile entstehen.

In unserem Handbuch zum entsprechenden Konfigurationspunkt dementsprechend auch folgende Warnung zu finden:
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.

Warum weist meine Appliance nach dem Aktivieren des Virenscanners alle E-Mails ab?

Nach dem Aktivieren der Option(en) Use ClamAV AntiVirus Engine (Note: remember to activate in ruleset) und gegebenenfalls Enable unofficial Signatures for ClamAV aus dem Menü Mail System, Sektion AntiSpam kann es je nach Internetanbindung sehr lange dauern, bis die Signaturen für die AntiVirus Engine zur Verfügung stehen.
Solange die Signaturen noch nicht zur Verfügung stehen, werden bei aktivierter Option alle E-Mails mit dem Fehler „Virus scan: Runtime Error“ abgewiesen „Message Rejected. (421 Rule Engine Error)“.

SEPPmail Plugin

Verschlüsselungsverfahren

Warum öffnet der GINA Dateianhang auf meinem iOS (iPad / iPhone) trotz installierter SEPPmail App nicht?

Damit das iOS Gerät in Verbindung mit der SEPPmail App korrekt arbeiten kann, ist ein gültiges Zertifikat für den GINA Zugang auf der SEPPmail Appliance erforderlich. Wenden Sie sich gegebenenfalls an den Betreiber der SEPPmail Appliance.

In der Administrationsoberfläche der Appliance muss im Menü „SSL“ ein Zertifikat einer vertrauenswürdigen CA, welches den FQDN des GINA Zugangs beinhaltet, hinterlegt werden (siehe auch Handbuch „Referenz der Menüpunkte SSL).

Kann das GINA-Interface mittels „Captcha“ vor Robot Eingaben geschützt werden?

Ein Schutz des GINA Interfaces vor Robots mittels Captcha ist aus folgenden Gründen nicht notwendig:

Die Self-Registration ist durch einen Mail-Ping abgesichert. Das heißt durch die Registrierung am Web-Interface wird noch 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.

Auch bei der Anmeldung eines bestehenden Benutzers wurde aus Usability Gründen auf ein Captcha verzichtet. Bei mehrfacher Falscheingabe eines Passwortes – die Anzahl ist natürlich konfigurierbar –  wird der GINA-Benutzer jedoch gesperrt, so dass ein Missbrauch auch hier ausgeschlossen ist.

Wie richte ich Domänenverschlüsselung zur SEPPmail Appliance eines meiner Kommunikationspartner ein?

Aufgrund des Managed Domain Services wird der Domain Key aller SEPPmail Appliances automatisch ausgetauscht. Somit werden alle Mails von und zu Kommunikationspartnern, welche eine SEPPmail Appliance betreiben verschlüsselt.

Weshalb können über die Windows Mail App (Metro Oberfläche) GINA-Mails nicht geöffnet werden?

Die Windows Mail App kann nicht mit den im Standard eingebetteten Cascading Style Sheets (CSS) umgehen.
Die Verwendung von CSS in den Benachrichtigungs E-Mails kann jedoch jeweils pro GINA Interface (siehe Auswahl in der Administrationsoberfläche im Menü „Mail Processing“ in der  Sektion „GINA domains“) abgeschaltet werden. Hierzu wird über die Schaltfläche „Edit“ in das Konfigurationsmenü der zuvor ausgewählten GINA domain gewechselt und dort weiter über die Schaltfläche „Edit GINA Layout“ (oben rechts) zur Sektion „E-Mail CSS“ navigiert. Durch das Entfernen des Hakens der Option „Use HTML e-mail templates based on tables and separate CSS“ wird das Verwenden von CSS in GINA-Mails unterbunden, wodurch diese auch über die Windows Mail App lesbar werden. Über die Schaltfläche „Save“ muss die Änderung noch gespeichert werden.

Mein Kommunikationspartner setzt ein Verschlüsselungsgateway eines anderen Herstellers ein. Kann ich trotzdem Domänenverschlüsselung verwenden?

 

Ja, sofern das Verschlüsselungs-Gateway des Kommunikationspartners diese Funktion ebenfalls unterstützt. Dabei muss mit dem Kommunikationspartner der Domänen Schlüssel (bevorzugt S/MIME, wobei auch OpenPGP möglich ist) ausgetauscht werden.

Der öffentliche Domänen Schlüssel der SEPPmail Appliance kann vom Kommunikationspartner direkt über das GINA-Portal heruntergeladen werden, sofern diese Funktion freigeschaltet ist.

Andernfalls ist der Schlüssel in der Administrationsoberfläche unter „Mail System“ -> „Managed Domains“ -> „<Auswahl Ihrer Managed Domain>“ durch den Administrator aus der entsprechenden Sektion (OpenPGP beziehungsweise S/MIME Domain Encryption) herunterzuladen und dem Kommunikationspartner zur Verfügung zu stellen.

Der vom Kommunikationspartner zur Verfügung gestellte öffentliche Domänen Schlüssel ist unter „Domain certificates“ an der entsprechenden Stelle einzubinden.

Wie kann ein vorgeschalteter Loadbalancer die Verfügbarkeit der GINA-Interfaces auf den SEPPmail Appliances eines Clusters prüfen?

Im Standard kann die Verfügbarkeit via OpenSSL wie folgt geprüft werden:

Zunächst die Verbindung zur Appliance (FQDN aus den [default] GINA Einstellungen, im Beispiel securemail.meinfirma.ch) herstellen:

openssl s_client -connect securemail.meinfirma.ch:443

Daraufhin wird Zertifikat, Handshake und so weiter angezeigt. Nun

GET / HTTP/1.0

eingeben und zwei mal (!) Enter drücken. Ist das Interface verfügbar, so wird zunächst die Meldung

HTTP/1.1 200 OK

sowie einige weitere Informationen ausgegeben.

Werden auf der Appliance mehrere GINA Interfaces bereitgestellt, so können diese bei Bedarf explizit durch Angabe deren „Hostname“ Eintrages (zum Beispiel „Mandant1“) aus den jeweiligen GINA Einstellungen geprüft werden (Achtung, Gross-/Kleinschreibung ist zu beachten). Die Abfrage würde nach Herstellen der Verbindung zur Appliance wie folgt lauten:

GET /Mandant1/ HTTP/1.0

Mein Sicherheitsscanner zeigt an, dass die SEPPmail Appliance eine alte TLS Version verwendet.

Meist ist die Ursache für solche Meldungen, dass der TLS Tunnel gar nicht an der SEPPmail Appliance, sondern einem vorgelagerten E-Mail Relay / Firewall terminiert wird.

In seltenen Fällen könnte jedoch auch bei Terminierung des Tunnels durch die SEPPmail Appliance eine veraltete TLS Version angezeigt werden.  Hintergrund hierfür ist, dass die verwendete TLS Version vom eingestellten TLS Sicherheitslevel abhängig ist. Im Standard verwendet die Appliance opportunistisches TLS (verwenden wenn möglich/vorhanden). Dieser Sicherheitslevel ist in der aktuellsten Version von TLS nicht mehr zulässig.

Mein Kommunikationspartner hat Probleme bei der Darstellung von GINA-Mails in seinem Browser.

Das GINA Web Interface wird von uns mit jedem Versionswechsel mit den gängigen Browsern getestet. Sollten dennoch Darstellungsprobleme auftauchen, können diese durch leeren des Browser Caches, beziehungsweise wenn dies erfolglos bleibt durch zurücksetzen des Browsers auf Werkseinstellungen beseitigt werden.

Mein Sicherheitsscanner zeigt an, dass die SEPPmail Appliance eine anfällig auf RC4 Attacken ist.

Bei Konfiguration der Appliance wurde ursprünglich auf maximale Kompatibilität geachtet. Durch setzen des Hakens in der Administrationsoberfläche unter „Mail Processing“ – „GINA Settings“ – „Disallow insecure ciphers (breaks windows XP compatibility, but necessary for PCI compliance)“ wird die Anfälligkeit auf RC4 Attacken abgeschaltet.
Dies führt jedoch zur Inkompatibilität mit älteren Systemen.

Wie kann das Datumsformat in der GINA Oberfläche geändert werden?

Grundsätzlich sind alle Texte der GINA Oberfläche jeweils in den Spracheinstellungen vorzunehmen. Dabei ist jede verwendete Sprache separat zu betrachten.

Anbei eine Beschreibung anhand der deutschen Sprachdatei:
Zunächst ist in der Administrationsoberfläche das Menü „Mail Processing“ zu wählen. In der Sektion „GINA domains“ ist die zu Ändernde GINA Oberfläche aus dem DropDown Menü zu wählen. Durch klicken der Schaltfläche „Edit“ öffnet das Folgemenü mit den entsprechenden „GINA settings“.  Dort ist in der Sektion „Language settings“, Abschnitt „German (d)“  die Schaltfläche „Edit translations“ zu klicken. Ein weiteres Folgemenü öffnet, in welchem ganz unten rechts die Schaltfläche „Advanced View“ zu klicken ist. Im Anschluss kann über die Browser Suchfunktion nach „date_format“ gesucht werden. Im darunter befindlichen Message String „msgstr“ kann das Datumsformat dann nach den individuellen Vorlieben geändert werden. Abschliessend ist der Vorgang mit „Save“ zu beenden.

Hinweis zum Datumsformat:
Die Formatierungen sind ANSI-C89 kompatibel. Eine genauere Beschreibung hierzu ist unter
http://man7.org/linux/man-pages/man3/strftime.3.html
zu finden.
Um das korrekte Format zu generieren ist steht zum Beispiel folgendes Tool im Internet zur Verfügung:
http://www.foragoodstrftime.com/