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 (Administrationsoberfläche, Menü „Administration, Sektion „Update“, Schaltfläche „Fetch update“ / „Prefetch (reboot manually)“).

Ein manueller Abgleich ist über die Schaltfläche „Check for Update“ möglich.

Was passiert, wenn die Lizenz abgelaufen ist?

Die Appliance läuft ohne Einschränkung des laufenden Betriebes weiter. Allerdings können 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. Somit wird weder ver- noch entschlüsselt, noch signiert.

Konfiguration

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)“.

Ob und in welchem Stand Antiviren-Signaturen bereitstehen ist der Sektion AntiVirus des Menüs Home zu entnehmen.

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.

SwissSign hat mich zum Erneuern des Operatorenzertifikats wegen Umstellung von SHA1 auf SHA2 aufgefordert. Was ist zu tun?

Meist wird im Zusammenhang mit der Umstellung des Operatorenzertifikats auch eine Umstellung des MPKI connectors von „SwissSign legacy“ auf „SwissSign CMC“ empfohlen.

Hierfür sollten Sie von SwissSign ein neues Operatorenzertifikat samt Passwort, beziehungsweise eine Anleitung für den sicheren Download desselbigen erhalten haben. Weiterhin sollten Sie eine Willkommens-E-Mail (welche in etwa so aussieht SwissSign_Welcome_Mail_MPKI_SEPPmail) erhalten haben. Diese enthält die neuen Zugangsdaten für den CMC connector.
Sofern Ihnen diese Informationen noch nicht vorliegen, fordern Sie diese vor jeder weiteren Aktion beim SwissSign an.

Stellen Sie zunächst den Connector um. Hierfür ist in der Administrationsoberfläche, Menü „CA“, Sektion „External CA“ im Abschnitt „Select MPKI“ die Auswahl „SwissSign CMC“ zu treffen und mit „Save“ zu speichern. Anschließend ist erneut in die Sektion „External CA“ zu wechseln und im Abschnitt „Configure MPKI“ die Schaltfläche „SwissSign CMC connector…“ zu klicken.
Im Folgemenü übertragen Sie die Daten aus der Willkommens-E-Mail in die Sektion „Defalt parameter“, ebenso wie gegebenenfalls in die Sektion „Domain specific parameters“.
In der Sektion „Certificate“ wählen Sie über die Schaltfläche des Abschnitts „PKCS12 identity file“ das neue, von SwissSign zur Verfügung gestellte Operatorenzertifikat aus. Das zugehörige Passwort ist im Abschnitt „PKCS12 Password“ eingetragen.
In der Sektion „Settings“ setzen Sie den Haken der Option „Automatically renew expiring certificates if validity days left less than“ und setzen den Wert auf 365. Hierdurch wird bis zum nächsten Tag für jeden Benutzer das SHA1 gegen ein SHA2 Zertifikat ausgetauscht.
Nun speichern Sie über die Schaltfläche „Save“ (ganz unten links).
Rufen Sie dieses Menü nun erneut über die Schaltfläche „SwissSign CMC connector…“ auf. In der Sektion „Certificate“ sollten nun Informationen zum neuen Operatorenzertifikat in grün angezeigt werden.
Klicken Sie abschließend in der Sektion „Settings auf die Schaltfläche „Add or update“ um auch gegebenenfalls veraltete Zwischen-(Intermediate)Zertifikate zu erneuern.

Wichtig:
Am Tag nach der Umstellung muss die Option „Automatically renew expiring certificates if validity days left less than“ unbedingt zurückgesetzt werden. Empfehlung ist ein Wert zwischen 60 und 90 Tagen.

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.

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. Diese E-Mail sieht in etwa wie folgt aus: SwissSign_Welcome_Mail_MPKI_SEPPmail

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:
SwissSign Bestandskunden, welche noch den „SwissSign legacy“ connector einsetzen, werden vor allem im Zuge der notwendigen Umstellung des Operatorenzertifikates von SHA1 auf SHA2 aufgefordert, auf den neueren  „SwissSign CMC“ connector umzustellen.
Eine weitere FAQ hierzu ist unter
SwissSign hat mich aufgefordert das Operatorenzertifikat wegen Umstellung von SHA1 auf SHA2 zu wechseln. Was ist zu tun?
zu finden.

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 sendet SwissSign trotz automatischer Zertifikatserneuerung Benachrichtigungen über abgelaufene Zertifikate?

In der SEPPmail 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.

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

Ausgangssituation:
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…).

 

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 \(vertraulich\)?

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?

Ausgangssituation:
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“ (oder auch pgp/inline) 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 ein spezielles. Dieses wird in einer E-Mail fast immer doppelt mitgeliefert, einmal im Text- und einmal im HTML-Format. 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-Anhang verschlüsselt und der HTML-Anhang verworfen.
Einige OpenPGP – Implementationen hängen 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

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 der Tabelle anzuklicken. Ein Folgemenü mit den entsprechenden „GINA settings“ öffnet.  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/

 

Wie aktiviere ich die neue GINA Oberfläche, welche seit der Version 8.0 zur Verfügung steht?

Um die neue Oberfläche zu Aktivieren, ist in der Administrationsoberfläche wie folgt vorzugehen:

  • Wechsel in das Menü „Mail Processing“
  • Klick auf den zu bearbeitenden „GINA name“ aus der Tabelle der Sektion „GINA domains“
  • Im erscheinenden Sub-Menü Klick auf die Schaltfläche „Edit GINA layout…“ rechts oben
  • Ein weiteres Folgemenü erscheint, in welchem in der Sektion „GINA CSS“ die Option „Use mobile-friendly web templates“ zu aktivieren ist.
  • Speichern der Änderung durch Klick auf die Schaltfläche „Save“ der Sekrion „GINA CSS“

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 im Menü „Mail Processing“, Sektion „GINA Settings“, Option „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 (Part VII Referenz der Menüpunkte, 8 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 in der Tabelle auf die zu bearbeitende GINA domain geklickt. Im Folgemenü wird ü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.

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 E-Mails von und zu Kommunikationspartnern, welche eine SEPPmail Appliance betreiben automatisch 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 ist 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

Large File Transfer LFT

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 (Part III Die SEPPmail Appliance, 3 Aufbau und Architektur, Sizing) entnommen werden.

Warum wird eine E-Mail nicht als LFT ausgeliefert, obwohl die Kriterien dafür erfüllt sind?

Ausgangssituation:

Obwohl eine E-Mail den für LFT eingestellten Schwellwert überschreitet, beziehungsweise LFT durch eines der Schlüsselworte [lfm] oder [lfm:nocrypt] erzwungen wurde, wird diese als „normale“ E-Mail ausgeliefert.

Ursachen:

  1. Das Lizenzkontingent für LFT wurde überschritten
    (siehe Administrationsoberfläche, Menü „Home“, Sektion „License“, Abschnitt „Large File Transfer (LFT) licenses“)
  2. Nach dem Einrichten von LFT wurde das Ruleset nicht neu generiert
    (siehe Administrationsoberfläche, Menü „Mail Processing“, Sektion „Ruleset generator“, Schaltfläche „Save and create ruleset“ (ganz unten))

Zertifikate

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

In der SEPPmail 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.

SwissSign hat mich zum Erneuern des Operatorenzertifikats wegen Umstellung von SHA1 auf SHA2 aufgefordert. Was ist zu tun?

Meist wird im Zusammenhang mit der Umstellung des Operatorenzertifikats auch eine Umstellung des MPKI connectors von „SwissSign legacy“ auf „SwissSign CMC“ empfohlen.

Hierfür sollten Sie von SwissSign ein neues Operatorenzertifikat samt Passwort, beziehungsweise eine Anleitung für den sicheren Download desselbigen erhalten haben. Weiterhin sollten Sie eine Willkommens-E-Mail (welche in etwa so aussieht SwissSign_Welcome_Mail_MPKI_SEPPmail) erhalten haben. Diese enthält die neuen Zugangsdaten für den CMC connector.
Sofern Ihnen diese Informationen noch nicht vorliegen, fordern Sie diese vor jeder weiteren Aktion beim SwissSign an.

Stellen Sie zunächst den Connector um. Hierfür ist in der Administrationsoberfläche, Menü „CA“, Sektion „External CA“ im Abschnitt „Select MPKI“ die Auswahl „SwissSign CMC“ zu treffen und mit „Save“ zu speichern. Anschließend ist erneut in die Sektion „External CA“ zu wechseln und im Abschnitt „Configure MPKI“ die Schaltfläche „SwissSign CMC connector…“ zu klicken.
Im Folgemenü übertragen Sie die Daten aus der Willkommens-E-Mail in die Sektion „Defalt parameter“, ebenso wie gegebenenfalls in die Sektion „Domain specific parameters“.
In der Sektion „Certificate“ wählen Sie über die Schaltfläche des Abschnitts „PKCS12 identity file“ das neue, von SwissSign zur Verfügung gestellte Operatorenzertifikat aus. Das zugehörige Passwort ist im Abschnitt „PKCS12 Password“ eingetragen.
In der Sektion „Settings“ setzen Sie den Haken der Option „Automatically renew expiring certificates if validity days left less than“ und setzen den Wert auf 365. Hierdurch wird bis zum nächsten Tag für jeden Benutzer das SHA1 gegen ein SHA2 Zertifikat ausgetauscht.
Nun speichern Sie über die Schaltfläche „Save“ (ganz unten links).
Rufen Sie dieses Menü nun erneut über die Schaltfläche „SwissSign CMC connector…“ auf. In der Sektion „Certificate“ sollten nun Informationen zum neuen Operatorenzertifikat in grün angezeigt werden.
Klicken Sie abschließend in der Sektion „Settings auf die Schaltfläche „Add or update“ um auch gegebenenfalls veraltete Zwischen-(Intermediate)Zertifikate zu erneuern.

Wichtig:
Am Tag nach der Umstellung muss die Option „Automatically renew expiring certificates if validity days left less than“ unbedingt zurückgesetzt werden. Empfehlung ist ein Wert zwischen 60 und 90 Tagen.

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 „persönlicher öffentlicher Schlüssel des Signierenden -> ggf. SubCA(s) -> CA -> “ 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, zum Beispiel
    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 Session-Key – 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.

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.

Unterstützt SEPPmail MultiDomain (SAN) SSL Zertifikate?

Ja.

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. Diese E-Mail sieht in etwa wie folgt aus: SwissSign_Welcome_Mail_MPKI_SEPPmail

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:
SwissSign Bestandskunden, welche noch den „SwissSign legacy“ connector einsetzen, werden vor allem im Zuge der notwendigen Umstellung des Operatorenzertifikates von SHA1 auf SHA2 aufgefordert, auf den neueren  „SwissSign CMC“ connector umzustellen.
Eine weitere FAQ hierzu ist unter
SwissSign hat mich aufgefordert das Operatorenzertifikat wegen Umstellung von SHA1 auf SHA2 zu wechseln. Was ist zu tun?
zu finden.

Sicherheit

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)“.

Ob und in welchem Stand Antiviren-Signaturen bereitstehen ist der Sektion AntiVirus des Menüs Home zu entnehmen.

SwissSign hat mich zum Erneuern des Operatorenzertifikats wegen Umstellung von SHA1 auf SHA2 aufgefordert. Was ist zu tun?

Meist wird im Zusammenhang mit der Umstellung des Operatorenzertifikats auch eine Umstellung des MPKI connectors von „SwissSign legacy“ auf „SwissSign CMC“ empfohlen.

Hierfür sollten Sie von SwissSign ein neues Operatorenzertifikat samt Passwort, beziehungsweise eine Anleitung für den sicheren Download desselbigen erhalten haben. Weiterhin sollten Sie eine Willkommens-E-Mail (welche in etwa so aussieht SwissSign_Welcome_Mail_MPKI_SEPPmail) erhalten haben. Diese enthält die neuen Zugangsdaten für den CMC connector.
Sofern Ihnen diese Informationen noch nicht vorliegen, fordern Sie diese vor jeder weiteren Aktion beim SwissSign an.

Stellen Sie zunächst den Connector um. Hierfür ist in der Administrationsoberfläche, Menü „CA“, Sektion „External CA“ im Abschnitt „Select MPKI“ die Auswahl „SwissSign CMC“ zu treffen und mit „Save“ zu speichern. Anschließend ist erneut in die Sektion „External CA“ zu wechseln und im Abschnitt „Configure MPKI“ die Schaltfläche „SwissSign CMC connector…“ zu klicken.
Im Folgemenü übertragen Sie die Daten aus der Willkommens-E-Mail in die Sektion „Defalt parameter“, ebenso wie gegebenenfalls in die Sektion „Domain specific parameters“.
In der Sektion „Certificate“ wählen Sie über die Schaltfläche des Abschnitts „PKCS12 identity file“ das neue, von SwissSign zur Verfügung gestellte Operatorenzertifikat aus. Das zugehörige Passwort ist im Abschnitt „PKCS12 Password“ eingetragen.
In der Sektion „Settings“ setzen Sie den Haken der Option „Automatically renew expiring certificates if validity days left less than“ und setzen den Wert auf 365. Hierdurch wird bis zum nächsten Tag für jeden Benutzer das SHA1 gegen ein SHA2 Zertifikat ausgetauscht.
Nun speichern Sie über die Schaltfläche „Save“ (ganz unten links).
Rufen Sie dieses Menü nun erneut über die Schaltfläche „SwissSign CMC connector…“ auf. In der Sektion „Certificate“ sollten nun Informationen zum neuen Operatorenzertifikat in grün angezeigt werden.
Klicken Sie abschließend in der Sektion „Settings auf die Schaltfläche „Add or update“ um auch gegebenenfalls veraltete Zwischen-(Intermediate)Zertifikate zu erneuern.

Wichtig:
Am Tag nach der Umstellung muss die Option „Automatically renew expiring certificates if validity days left less than“ unbedingt zurückgesetzt werden. Empfehlung ist ein Wert zwischen 60 und 90 Tagen.

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 im Menü „Mail Processing“, Sektion „GINA Settings“, Option „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.

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. Diese E-Mail sieht in etwa wie folgt aus: SwissSign_Welcome_Mail_MPKI_SEPPmail

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:
SwissSign Bestandskunden, welche noch den „SwissSign legacy“ connector einsetzen, werden vor allem im Zuge der notwendigen Umstellung des Operatorenzertifikates von SHA1 auf SHA2 aufgefordert, auf den neueren  „SwissSign CMC“ connector umzustellen.
Eine weitere FAQ hierzu ist unter
SwissSign hat mich aufgefordert das Operatorenzertifikat wegen Umstellung von SHA1 auf SHA2 zu wechseln. Was ist zu tun?
zu finden.

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.

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

In der SEPPmail 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.

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)“.

Ob und in welchem Stand Antiviren-Signaturen bereitstehen ist der Sektion AntiVirus des Menüs Home zu entnehmen.

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 (Part III Die SEPPmail Appliance, 3 Aufbau und Architektur, Sizing) entnommen werden.

Warum wird eine E-Mail nicht als LFT ausgeliefert, obwohl die Kriterien dafür erfüllt sind?

Ausgangssituation:

Obwohl eine E-Mail den für LFT eingestellten Schwellwert überschreitet, beziehungsweise LFT durch eines der Schlüsselworte [lfm] oder [lfm:nocrypt] erzwungen wurde, wird diese als „normale“ E-Mail ausgeliefert.

Ursachen:

  1. Das Lizenzkontingent für LFT wurde überschritten
    (siehe Administrationsoberfläche, Menü „Home“, Sektion „License“, Abschnitt „Large File Transfer (LFT) licenses“)
  2. Nach dem Einrichten von LFT wurde das Ruleset nicht neu generiert
    (siehe Administrationsoberfläche, Menü „Mail Processing“, Sektion „Ruleset generator“, Schaltfläche „Save and create ruleset“ (ganz unten))

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 im  Handbuch in „Part IX HowTo, 4 Mehrere SMTP-Authentifizierungen verwalten“ vor.

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 berücksichtigen um selbst während des Updates einen ungestörten E-Mail-Fluss zu gewährleisten.

Eine Ausnahme sind Frontend-Backend Cluster, da in dieser Konfiguration die Frontend-Maschinen über keine Datenbank verfügen.
Hier ist/sind immer zuerst 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 Updates müssen immer als Zwischenschritt installiert werden, damit die nächste Version auf einen entsprechenden Datenbank Stand aufsetzen kann. Das heisst, sofern das System nicht stets auf den aktuellen Stand gehalten wurde, wird unter Umständen nicht die aktuellste, sondern zunächst die notwendige Zwischenversionen zum Update angeboten.
In diesem Fall sind immer alle Appliances des Clusters 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“, 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.

Tritt zum Beispiel bei einer virtuellen Maschine aufgrund eines nicht mehr, oder nicht mehr zuverlässig verfügbaren Datenspeichers „kernel panic“ auf, so kann die Appliance unter Umständen funktional Ihren Dienst einstellen, jedoch IP-technisch noch erreichbar sein.
Somit würde die Partner-Maschine nicht erkennen, dass sie die Funktion übernehmen muss.

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 (Part VII Referenz der Menüpunkte, 10 Administration, 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. Hierfür muss die entsprechende Funktion durch den Administrator freigeschaltet sein. Dies geschieht über das Aktivieren der Option „Reprocess mails sent to reprocess@decrypt.reprocess“, welche in der Administrationsoberfläche im Menü „Mail Processing“, Sektion „Ruleset Generator“, Abschnitt „General Settings“ zu finden ist.

Funktion:
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 ebenfalls 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

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 ist 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)“.

Ob und in welchem Stand Antiviren-Signaturen bereitstehen ist der Sektion AntiVirus des Menüs Home zu entnehmen.

Kalenderanfragen werden nicht entschlüsselt.

Beim Empfang von Kalenderanfragen wird im Outlook anstatt des erwarteten vcs Formats ein html Anhang mit „PGP“ im Namen angezeigt.

Die Gegenseite scheint die Kalenderanfrage mit PGP/Inline verschlüsselt zu haben. Nach der Entschlüsselung kann Outlook nichts mehr mit der Anfrage anfangen. Mögliche Workarounds:

  • das Gegenüber kann S/MIME statt PGP verwenden
  • das Gegenüber kann PGP/MIME statt PGP/Inline verwenden
  • die Einladungen können unverschlüsselt geschickt werden

Im Outlook erscheint die Fehlermeldung „Dieses Element kann nicht geöffnet werden. Der Name Ihrer digitalen ID kann im zugrunde liegenden Sicherheitssystem nicht gefunden werden.“ beim Versuch eine ursprünglich verschlüsselte/signierte E-Mail zu öffnen.

Dieses Phänomen wurde beim Einsatz von Scanmail von Trend Micro beobachtet. Die ausgelieferten E-Mails sind dann sehr klein (ein paar kb) anstelle der eigentlichen Grösse.

Trend Micro hat(te) seit längerer Zeit einen Bug der dazu führt dass signierte E-Mails zerstört werden (genauer: Der Inhalt wird gelöscht). Outlook reagiert dann mit oben genannter Fehlermeldung, welche eigentlich falsch ist, da die Nachricht gar nicht mehr vorhanden ist.

Bitte prüfen Sie gegebenenfalls, ob entsprechende Updates für Scanmail zur Verfügung stehen.

Warum wird eine E-Mail nicht als LFT ausgeliefert, obwohl die Kriterien dafür erfüllt sind?

Ausgangssituation:

Obwohl eine E-Mail den für LFT eingestellten Schwellwert überschreitet, beziehungsweise LFT durch eines der Schlüsselworte [lfm] oder [lfm:nocrypt] erzwungen wurde, wird diese als „normale“ E-Mail ausgeliefert.

Ursachen:

  1. Das Lizenzkontingent für LFT wurde überschritten
    (siehe Administrationsoberfläche, Menü „Home“, Sektion „License“, Abschnitt „Large File Transfer (LFT) licenses“)
  2. Nach dem Einrichten von LFT wurde das Ruleset nicht neu generiert
    (siehe Administrationsoberfläche, Menü „Mail Processing“, Sektion „Ruleset generator“, Schaltfläche „Save and create ruleset“ (ganz unten))

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 Kapitel „HowTo“ des Handbuchs unter der Überschrift „Microsoft Office365: Anbinden der SEPPmail Appliance“ zu finden.

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.

Weshalb kann ich eine signierte E-Mail an meinem Mobilen Endgerät nicht öffnen beziehungsweise nicht darauf antworten?

Ausgangssituation:
Die SEPPmail Appliance wurde so konfiguriert, dass E-Mail Signaturen nach deren Prüfen nicht abgeschnitten werden. 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, Menü „Mail Processing“, Sektion „Ruleset generator“, Abschnitt „Signing“, Teilabschnitt „Incoming e-mails“, Optionen „remove signature if S/MIME signature check succeeds/fails“)

SEPPmail Plugin

Verschlüsselungsverfahren

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).

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 ist 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.

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.

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

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“ (oder auch pgp/inline) 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 ein spezielles. Dieses wird in einer E-Mail fast immer doppelt mitgeliefert, einmal im Text- und einmal im HTML-Format. 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-Anhang verschlüsselt und der HTML-Anhang verworfen.
Einige OpenPGP – Implementationen hängen 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.

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.

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.

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.

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.