SimpleDisplayName

Wenn ein Exchange Benutzer eine Mail an eine externe Adresse sendet, dann wird das "From"-Feld im Header mit dem Absender gefüllt. Normalerweise kommt dazu der "Displayname" zum Einsatz, der aber bei einigen Firmen zusätzliche Informationen enthält. Daher gibt es auch einen "SimpleDisplayName", der gesetzt und über "RemoteDomains" erzwungen werden kann. Diese Seite beschreibt die Funktionsweise.

Auslöser

Wie so oft ist auch diese Seite aufgrund eines "Problems" bei einem Kunden entstanden. Primär war die Problemlösung das Ziel aber bei der Analyse haben sich viele weitere Erkenntnisse ergeben, die ich hier zusätzlich protokoliert habe. Das Ziel des Kunden war, dass die internen Zusatzbezeichnungen am Displayname nicht extern bekannt werden. In dem Fall sollte das Ziel einfach nur die Mailadresse sehen. Dafür ist das Feld "FROM" im E-Mail Header zuständig, welches verschiedene Schreibweisen versteht. Die sind in einer RFC klar definiert:

from            =       "From:" mailbox-list CRLF
mailbox-list    =       (mailbox *("," mailbox)) / obs-mbox-list
mailbox         =       name-addr / addr-spec
name-addr       =       [display-name] angle-addr
display-name    =       phrase
phrase          =       1*word / obs-phrase
angle-addr      =       [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
addr-spec       =       local-part "@" domain
local-part      =       dot-atom / quoted-string / obs-local-part
domain          =       dot-atom / domain-literal / obs-domain
CFWS            =       *([FWS] comment) (([FWS] comment) / FWS)
FWS             =       ([*WSP CRLF] 1*WSP) /   ; Folding white space
                        obs-FWS

Wenn wir eine "mailbox-list" mal auf eine Adresse reduzieren, dann kann es eine reine SMTP-Adresse (angle-Addr) oder eine "Name-addr" sein.

Also habe ich einfach eine RFC822-Datei (.eml) mit folgenden minimalen Inhalten angelegt und in Outlook angezeigt.

Hinweis: Outlook unterscheidet, ob der Absender "authentifiziert" wurde, d.h. im internen System sehen Sie die "<>"Adresse normalerweise nicht, sondern nur im externen Umfeld.

Der Schwerpunkt liegt hier auf den verschiedenen Schreibwesen des "From"-Feld.

FROM-Feld Anzeige in Outlook RFC2822 compliant  Beschreibung 
From: "User1 Test" <user1@msxfaq.de>
To: User2 Test <user2@uclabor.de>
Subject: SimpleDisplayNameTest

Ja

Das ist die "normale" Schreibweise, wie ich sie normalerweise erwarte. Der Empfänger kann dann die Zieladresse anzeigen.

 
From: User1 Test <user1@msxfaq.de>
To: User2 Test <user2@uclabor.de>
Subject: SimpleDisplayNameTest

Ja

Der ausgeschriebene Name muss nicht in Anführungszeichen stehen. Allerdings darf er dann kein "<" oder ">" enthalten.

 
From: <user1@msxfaq.de>
To: User2 Test <user2@uclabor.de>
Subject: SimpleDisplayNameTest

Ja

Sie müssen keinen Anzeigename mitliefern. Dann zeigt z.B. Outlook nur die SMTP-Adresse an.

 
From: user1@msxfaq.de
To: User2 Test <user2@uclabor.de>
Subject: SimpleDisplayNameTest

Ja

Sie müssen keine "<" ">"-Klammern bei einer Absenderadresse verwenden. Die sind nur erforderlich, wenn es auch einen Anzeigename gibt.

 
From: "'User1 Test'" <user1@msxfaq.de>
To: User2 Test <user2@uclabor.de>
Subject: SimpleDisplayNameTest

Ja

Wobei die doppelten unterschiedlichen Anführungszeichen zum Teil angezeigt werden.

 
From: "user1@msxfaq.de" <user1@msxfaq.de>
To: User2 Test <user2@uclabor.de>
Subject: SimpleDisplayNameTest

Ja

Dieser Sonderfall ist interessant, wenn der Anzeigename mit der Mailadresse identisch ist. Outlook zeigt in dem Fall nur einmal die Mailadresse an und nicht mit den "<>"-Klammern.

Leider zeigt Outlook keine "<>" an. Ein weniger versierter Anwender könnte daher glauben, die Mail käme von intern.

 
From: <Sonderfall> user1@msxfaq.de
To: User2 Test <user2@uclabor.de>
Subject: SimpleDisplayNameTest

Nein

Nach meinem Verständnis ist dies nicht erlaubt. Outlook "versucht" aber wohl diesen Fehler zu heilen.

 
From: <Sonderfall> <user1@msxfaq.de>
To: User2 Test <user2@uclabor.de>
Subject: SimpleDisplayNameTest

Nein

Zwei Absender sind möglich, wenn diese durch ein Komma getrennt werden UND zusätzlich dann der Sender eindeutig gesetzt ist. Auch hier versucht Outlook das beste draus zu machen.

 
From: 
To: User2 Test <user2@uclabor.de>
Subject: SimpleDisplayNameTest

Nein

Ein leeres "From"-Feld ist nicht erlaubt. Outlook zeigt dennoch was an aber erwarten Sie nicht, dass ein Spamfilter so etwas durchlässt. SPF und insbesondere DKIM/DMARC-Tests schlagen hier fehl.

 
From: <>
To: User2 Test <user2@uclabor.de>
Subject: SimpleDisplayNameTest

Nein

Verwechseln Sie nicht die "FROM" und "MAIL FROM"-Fehler. Eine Systemmeldung, auf die keine Antwort erfolgen darf, hat im Envelope ein "MAIL FROM: <>" aber im Header den Namen des MTAs

Ein "From:<>" ist nicht erlaubt, denn "angle-addr" fordert ein "addr-spec" zwischen den Klammern und addr-spec hat mindestens ein "@"

angle-addr = [CFWS] "<" addr-spec ">" [CFWS]
addr-spec  = local-part "@" domain

Je nach Schreibweise des "From"-Feldes verhält sich Outlook in der Anzeige demnach anders.

Nur weil Outlook gewisse Schreibweisen zulässt, bedeutet dies nicht, dass Exchange oder ein vorgeschalteter Spamfilter solche Mails akzeptiert.

Exchange From-Erzeugung

Nun kommt die Frage, wie Exchange die "From-Adresse" für eine ausgehende Mail erzeugt. Leider habe ich keinen Zugriff auf den Sourcecode, das dass nur eine kleine Testserie die verschiedenen Fälle anzeigt, bei der folgende Parameter variiert werden:

  • Exchange Umgebung
    Ich werde nicht alle Exchange Versionen und Patchstände durchgehen, sondern beschränke mich auf Exchange 2016 On-Premises und Exchange Online
  • Displayname
    Das AD-Feld "Displayname" muss laut Exchange Vorgaben immer gefüllt sein. Natürlich "könnten" sie das AD-Feld auch nachträglich leeren aber die Ergebnisse sind nicht zugesichert. Das Feld können Sie per Browser im Exchange Control Panel und Exchange Online Admin Portal ändern
  • SimpleDisplayName
    Dieses Feld ist meist leer, aber kann auch gefüllt werden. Allerdings muss es ein IA5-String sein, d.h. kann keine Sonderzeichen enthalten. Das Feld können Sie nicht per Browser im Exchange Control Panel und Exchange Online Admin Portal ändern. Per Exchange PowerShell ist "-SimpleDisplayname" ein Parameter des Commandlets "Set-User"
  • RemoteDomain -UseSimpleDisplayName
    Über die Einstellungen der "RemoteDomain" kann ich pro Domäne steuern, welches der beiden Felder "Displayname" oder "SimpleDisplayName" herangezogen wird. Zum Test habe ich meine eigene Ziel-Domain entsprechend umgestellt.
Set-RemoteDomain `
   -Identity carius.de `
   -UseSimpleDisplayName $true

Diese Einstellung können Sie in Exchange Online nicht per Browser vornehmen.

Es mag trivial klingen aber bei dem Support Case konnte ein Mitarbeiter keine Mails versenden, weil er einen "leeren" SimpleDisplayname hatte und die Gegenseite die Mail abgelehnt hat.

Also habe ich folgende Testfälle durchgespielt und die Mail an den Empfänger direkt von Exchange zum Zielserver geroutet.

Displayname SimpleDisplayName RemoteDomain
-UseSimpleDisplayName:		 RemoteDomain -DisplaySenderName Ergebnis
UserDisplay
UserDisplay<Test>

$null

 $null oder $false

$true

 
UserDisplay <user@uclabor.de>
"UserDisplay<Test>" <user@uclabor.de>

Exchange umgibt den Displayname nicht mit Anführungszeichen, wenn kein Sonderzeichen enthalten ist. Wenn ich aber ein "<" addieren, dann werden '"'-Zeichen addiert.

UserDisplay<Test>

UserSimple

$null oder $false

$true

 
UserDisplay <user@uclabor.de>
“UserDisplay<Test>" <user@uclabor.de>

Die Änderung des SimpleDisplayName hat keine Auswirkung auf die Anzeige

$null

<egal>

$null oder $false

$true

Der Displayname kann nicht leer sein. Der Versuch, dies per Exchange PowerShell zu setzen liefert ein.

Cannot bind parameter 'DisplayName' to the target. 
Exception setting "DisplayName": "DisplayName: The property
DisplayName can't be empty."

Das bedeutet nicht, dass Sie das Feld nicht per ADSIEDIT leeren könnten. Aber es ist nicht supported und die Ergebnisse sind damit nicht zwingend stabil.

UserDisplay

UserSimple

$true

$true

 
UserSimple <user@uclabor.de>

Der Anzeigename wird diesmal aus dem SimpleDisplayName generiert. Denken Sie dran, dass der SimpleDisplayName ein IA5-String ist und daher keine Sonderzeichen enthalten kann. Ein Versuch den Namen zu setzen, schlägt fehl:

Cannot bind parameter 'SimpleDisplayName' to the target. 
Exception setting "SimpleDisplayName": "SimpleDisplayName:
The property value 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 
'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't',
'u', 'v', 'w', 'x', 'y', 'z', 'A', 'B', 'C', 'D', 'E', 'F', 
'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q','R',
 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '0', '1', '2', '3', 
'4', '5', '6', '7', '8', '9', '"', ''', '(', ')','+', ',', 
'-', '.', '/', ':', '?', ' '.

UserDisplay

$null
""
"   "

$true

$true

 
“user@uclabor.de" <user@uclabor.de>

Aufgrund des fehlenden SimpleDisplayName nutzt Exchange einfach die primäre SMTP-Adresse und umgibt sie mit Anführungszeichen. Exchange scheint dabei einen Art "TRIM()" auf den String zu machen, da reine "Leerzeichen" auch als Leerstring getrachtet werden.

UserDisplay

UserSimple

 $true
$false

$False

 
From: <user@uclabor.de>

Dieser Schalter verhindert, dass generell ein "Anzeigename" angefügt wird. Die "From:"-Adresse ist dann nur die Mailadresse.

Die Logik ist damit recht einfach nachzuvollziehen:

Das können wir auch als Tabelle mit den acht Fällen schreiben:

Fall DisplaySenderName UseSimpleDisplayname Feld SimpleDisplayname Ergebnis Header FROM-Zeile

1

$true

$true

Gefüllt

 
From: "SimpleDisplayName" <SMTP-Adresse>

2

$true

$true

Nicht gefüllt

 
From: "SMTP-Adresse" <SMTP-Adresse>

3

$true

$false

Gefüllt

 
From: "Displayname" <SMTP-Adresse>

4

$true

$false

Nicht gefüllt

 
From: "Displayname" <SMTP-Adresse>

5

$false

$true

Gefüllt

 
From: "SMTP-Adresse" <SMTP-Adresse>

6

$false

$true

Nicht gefüllt

 
From: "SMTP-Adresse" <SMTP-Adresse>

7

$false

$false

Gefüllt

 
From: "SMTP-Adresse" <SMTP-Adresse>

8

$false

$false

Nicht gefüllt

 
From: "SMTP-Adresse" <SMTP-Adresse>

Nur im ersten Fall, wenn DisplaySenderName=$true und UserSimpleDisplayName=$true gesetzt sind und der SimplyDisplayname gefüllt ist, dann wird der SimpleDisplayName beim Versand einer Mail per SMTP gesetzt.

Das bedeutet aber auch, dass Absender ohne "SimpleDisplayName" bei einer Mail an die Domains, für die ein "-UseSimpleDisplayName: $true" gesetzt ist, mit der SMTP-Adresse ankommen und kein Fallback auf den Displayname erfolgt.

Sie könnten natürlich nun ein Skript schreiben, welches den SimpleDisplayname für die Benutzer auf den Displayname setzt, die keinen SimpleDisplayname haben. Das ist dann eine Aufgabe für ihr Provisioning.

Suche nach Objekten

Bei vielen Anwendern oder automatischen Prüfungen eigenen sich Skripte besser zur Suche. Sie können per Exchange oder LDAP suchen, wobei Sie den Namen entsprechend anpassen müssen.

der OPATH-Filter "-Filter auf den Simple Displayname ist nur für folgende Commandlets gültig

Get-Contact
Get-DistributionGroup
Get-DynamicDistributionGroup
Get-Group
Get-LinkedUser
Get-Mailbox
Get-MailContact
Get-MailPublicFolder
Get-MailUser
Get-RemoteMailbox
Get-User

Leider ist gerade "Ger-Recipient" nicht dabei, d.h. sie müssen schon jeden Absendertyp einzeln erfassen

Alternativ können Sie natürlich per LDAP suchen, z.B.: über die MMC:

Die gleiche Funktion geht auch per PowerShell über das LDAP-Feld "DisplayNamePrintable":

Get-ADObject -LDAPFilter "(DisplayNamePrintable=*)"

Sonderfall DisplaySenderName

Wenn Sie die Beschreibung zu "Set-RemoteDomain" genau lesen, fällt ihnen in dem Zusammenhang auch der Parameter "DisplaySenderName" auf.


RemoteDomain -DisplaySenderName
https://docs.microsoft.com/de-de/powershell/module/exchange/set-remotedomain

Warum vor dem Einsatz dieses Parameters gewarnt wird, kann ich nicht genau sagen. Das Ergebnis ist auf jeden Fall, dass die Absenderadresse einer nach extern gesendeten Mail keinen "Anzeigename" mehr enthält. Es ist nur die Mailadresse in spitzen Klammern vorhanden, was laut RFC2822 auch erlaubt ist.

"From: <mailadresse>"

Der Default ist "True".

DisplaynamePrintable und ADSync

Wenn Sie Exchange Hybrid verwenden, dann müssen Sie viele Einstellungen im lokalen Active Directory vornehmen, da ADSync diese Daten in die Cloud repliziert. Allerdings ist der "SimpleDisplayname" hier eine Ausnahme. Obwohl mein eigenes ExchangeOnline-Postfach durch ADSync abgeglichen wird, konnte ich durch "Set-User" in der ExchangeOnline-PowerShell meinen SimpleDisplaynamen setzen.

PS C:\> set-user user@msxfaq.de  -SimpleDisplayName "User (Simple)"
PS C:\> get-user user@msxfaq.de | fl SimpleDisplayName

SimpleDisplayName   : User (Simple)

PS C:\> set-user user@msxfaq.de  -SimpleDisplayName $null

Beim lokalen Exchange Server in einer Hybrid-Umgebung kann ich den SimpleDisplayName bei den meisten Objekten per Exchange PowerShell setzen. Den SimpleDisplayname gibt es auch nicht bei allen Befehlen:

Set-Mailbox             Ja
Set-MailContact         Ja
Set-MailUser            Ja
Set-Distributiongroup   Ja
Set-User                Ja
Set-RemoteMailbox       Nein

Interessanterweise ist genau beim Set-RemoteMailbox der Parameter nicht vorhanden. Aber mittel Set-User kann der Wert auch hier gesetzt werden. Bei den Exchange Commandlets stellt Exchange sicher, dass die Werte den Beschränkungen des IA5-Formats entsprechen.

Das ist aber nicht durch das AD abgesichert. Im lokalen Active Directory kann ich das korrespondierende Feld "displayNamePrintable" per LDAP direkt schreiben. Hier wird auch nicht verhindert, dass Sonderzeichen darin erscheinen und auch das Schema unterbindet dies nicht.

Zwar ist das Feld als "Print Case String" statt "Unicode-String" geführt aber Umlaute sind hier schon per LDAP möglich. Wobei bei der Neuanlage eines eigenen Attributes sehr wohl IA5String als Syntax möglich gewesen wäre.

Ich vermute aber, dass dieses Feld schon seit Windows 2000 vorhanden ist und damals darauf noch keinen Wert gelegt wurde. Eine nachträgliche Änderung ist nicht möglich. Es bleibt also die Aufgabe des Administrators oder eines Provisioning-Frameworks hier für Exchange legitime Werte zu schreiben.

Vielleicht hat es auch was Gutes, wenn Administratoren nicht per LDAP direkt das AzureAD verändern können, sondern die vorgegeben APIs nutzen müssen. Entsprechend neugierig war ich natürlich, was nun ADSync hier macht. Ich habe zuerst in den Regeln und im Metaverse gesucht aber bin nicht fündig geworden. Dann habe ich bei einem On-Premises-Empfänger den SimpleDisplayName mit der Exchange PowerShell gesetzt und einen Delta-Import in ADSync gestartet. ADSync hat aber keine Änderungen erkannt.

ADSync ignoriert das Feld!

Damit ist dann natürlich auch verständlich, warum ich das Feld trotz ADSync auch in der Cloud setzen kann.

SimpleDisplayName ist nicht synchronisiert
Wenn Sie Mailboxen in die Cloud verschieben und eine der obigen Einstellungen nutzen, um den SimpleDisplayName statt des Displayname nach extern zu verwenden, dann bricht die Funktion. Sie müssen sich etwas überlegen, um einen lokal gepflegten "SimpleDisplayName" auch in der Cloud analog zu setzen.

Entweder sie machen die manuell per PowerShell oder im Rahmen ihres regulären Provisioning. Mit ADSync konnte ich zwar das MetaVerse um ein neues Feld erweitern und das Feld auf dem lokalen AD auch auslesen aber der Export zu Exchange Online erlaubt kein Schreiben des SimpleDisplayname/UserNamePrintable.

Bifurcation

Wenn Sie eine Mail an mehrere Personen in unterschiedlichen Domänen senden, dann könnte es ja sein, das ein Empfänger zu einer RemoteDomain mit "$true" und dir andere Empfängerdomain mit einem "$false" versehen ist. Exchange trennt die Mail dann entsprechend auf und setzt die Einstellung entsprechend um. Das passiert sehr früh, vermutlich schon beim ersten Server, denn selbst in einer Umgebung mit Hybrid Centralized Mail Transport mit einem Absender in Exchange Online kam die Einstellung bezüglich "RemoteDomain" in der Cloud zum Einsatz.

RemoteDomain

Der "SimpleDisplayName" wird nur für Mails verwendet, die nach Extern geht, d.h. außerhalb der eigenen Exchange Organisation sind. Über die "Remote Domain" in Exchange können Sie dabei steuern, für welche Zieldomäne der SimpleDisplayName verwendet werden soll. Folgender Befehl aktiviert für die Domain "msxfaq.de" die Übermittlung des "SimpleDisplayName" statt des normalen Displayname

Set-RemoteDomain `
   -Identity "msxfaq.de" `
   -UseSimpleDisplayName:$true

Sie können sich nun also überlegen, ob sie den globalen Standard für die Default Domain "*" so einstellen, der SimpleDisplayName gesendet wird und nur ausgewählte "vertrauenswürdige Partnerdomains" dann den internen "Displaynamen" bekommen. Aber genauso ist auch der umgekehrte Fall denkbar, d.h. sie lassen den Default und senden nur aus besondere Domains den SimpleDisplayName, die mit dem regulären Namen nicht zurecht kommen.

Zusammenfassung

Viele Firmen nutzen den Displaynamen ihrer Anwender, um einfach und schnell sichtbar Zusatzinformationen anzuzeigen, z.B. ob es ein Azubi oder eine externe Kraft ist. Einige Firmen schreiben hier auch Abteilungskürzel oder Projektbezeichnungen hinein. Im Innenverkehr ist das nett aber sobald Personen auch Mails ins Internet senden, möchten Sie diese Informationen vielleicht nicht veröffentlicht haben. Über die "RemoteDomain"-Funktion von Exchange kann der Inhalt des "SimpleDisplayname" als Anzeigename für ausgewählte oder alle Domains (Default) genutzt werden.

Wenn sie dann den "SimpleDisplayName" gar nicht anfassen, dann sehen die externen Empfänger einfach nur die Mailadresse. Wer hier etwas mehr Komfort haben möchte, kann dann z.B. per Skript den SimpleDisplayName pflegen. Allerdings sind sie da dann wieder auf "A-Za-z0-9" und einige Sonderzeichen beschränkt.

Wer nach extern abweichende "Anzeigenamen" mit Umlauten nutzen möchte, muss auf 3rd Party Tols ausweichen, denn der SimpleDisplayName erlaubt keine Sonderzeichen.

Wer Exchange Hybrid nutzt, sollte daran denken, dass standardmäßig der "SimpleDisplayName" nicht durch ADSync repliziert wird.

Weitere Links