Ausgangssituation:
In einer MS Office365 Umgebung werden E-Mail-Alias_Adressen, Verteilerlisten und/oder E-Mail Weiterleitungen verwendet. E-Mails, welche an diese Adressen gesendet werden, landen verschlüsselt in den Postfächern der Empfänger.
Hintergrund:
Exchange Online ersetzt die ursprünglich adressierten E-Mails Adressen im E-Mail Header bereits beim Empfang aus dem Internet, anstatt nach dem Empfang durch das SEPPmail Secure E-Mail Gateway (siehe gegebenenfalls auch Eingehender E-Mail Fluss).
Dies ist eine Eigenart von Exchange Online und kann - zumindest derzeit - nicht abgestellt werden.
Nachdem das SEPPmail Secure E-Mail Gateway den privaten Schlüssel zum Entschlüsseln der E-Mail anhand der Empfänger-Adresse ermittelt, passt der private Schlüssel nicht zum Zertifikat, welches zum Verschlüsseln verwendet wurde (ursprüngliche Empfängeradresse vor dem Umschreiben).
Frage:
Wie kann das korrekte Entschlüsseln einer E-Mail, trotz eingerichteter Weiterleitung gewährleistet werden?
Lösung:
Microsoft seitig steht derzeit nur eine Beta-Lösung zur Verfügung (siehe auch das Kapitel Aliase und mehrere Domains in Exchange Online).
Andernfalls bleiben folgende Workarounds:
Verteilerlisten
Anstatt von Verteilerlisten sollten Freigegebene Postfächer (Shared Mailbox) verwendet werden.
Alias-Adressen
Diese sollten generell vermieden werden. Diese verursachen abgesehen von der hier dargestellten Problematik auch zusätzliche Kosten, da für das signierte Versenden von E-Mails von Alias Adressen (und damit in der Folge den möglichen Erhalt verschlüsselter E-Mails an diese Adressen) auch jeweils ein Zertifikat erforderlich ist.
Eventueller Workaround auf dem SEPPmail Secure E-Mail Gateway bei Domänen basierten Umschreibungen:
Zunächst sollten folgende Punkte gewährleistet sein:
1.Hinter beiden Adressen, ursprünglicher und weitergeleiteter Empfänger, steht dieselbe Person beziehungsweise derselbe Personenkreis.
2.Für beide Empfängeradressen existiert auf dem SEPPmail Secure E-Mail Gateway ein Benutzerkonto (siehe Users) mit entsprechendem Schlüsselmaterial.
Nun kann durch entsprechende Custom Commands das Entschlüsseln unter Verwendung beider Empfängeradressen erfolgen. Hierzu ist in Custom commands for incoming e-mails BEFORE decryption: in etwa folgender Code einzugeben:
Zeile |
Code |
|---|---|
01 |
# Begin: Custom commands for incoming e-mails BEFORE decryption |
02 |
log(1,'Begin: Custom commands for incoming e-mails BEFORE decryption'); |
|
|
03 |
# Begin: Decrypt forwarded e-mails |
04 |
log(1,'Begin: Decrypt forwarded e-mails'); |
|
|
05 |
if (smime_encrypted()) { |
06 |
if (replace_rcpt('@original\.tld', '@forwarded.tld',1)) { |
07 |
log(1, 'Encrypted mail to @original.tld, check if we can decrypt with @forwarded-tld keys'); |
08 |
if (decrypt_smime()) { |
09 |
@REMOVETAGS@ |
10 |
log(1, 'S/MIME decrypted with user certificate'); |
11 |
@TAGDECRYPTED@ |
12 |
@TAGHEADERDECRYPTED@ |
13 |
@SETDECRYPTED@ |
14 |
} else if (decrypt_domain_smime()) { |
15 |
@REMOVETAGS@ |
16 |
log(1, 'S/MIME decrypted using domain certificate'); |
17 |
@TAGDECRYPTED@ |
18 |
@TAGHEADERDECRYPTED@ |
19 |
@SETDECRYPTED@ |
20 |
} else { |
21 |
log(1, 'Decryption for @forwarded.tld FAILED, going on with decryption for @original.tld'); |
22 |
} |
23 |
replace_rcpt('@forwarded\.tld', '@original.tld', 1); |
24 |
} |
25 |
} |
|
|
26 |
log(1,'End: Decrypt forwarded e-mails'); |
27 |
# End: Decrypt forwarded e-mails |
|
|
28 |
log(1,'End: Custom commands for incoming e-mails BEFORE decryption'); |
29 |
# End: Custom commands for incoming e-mails BEFORE decryption |
