Teams Termineinladung

Statt mit Outlook können Sie auch in Teams ein Meeting planen. Teams legt dabei den Termin nicht nur in ihrem Kalender ab, sondern informiert auch alle eingetragenen Teilnehmer als auch die Teammitglieder per Einladung. Da sie aber nicht per Outlook die Mail versenden, muss Teams das in ihrem Namen tun.

Mail von Teams

Ich plane also einen Termin in Teams, indem ich in einem Kanal zu einer Besprechung einladen.

Ich muss nicht, aber ich kann zusätzliche Empfänger mit einladen:

Wenn ich den Termin dann speichere, dann passiert folgendes:

  • Der Termin wird in meinem Exchange Kalender abgelegt
    Teams greift dazu auf einen Exchange Online Kalender oder auch einen On-Premises-Server zu (Exchange 2016 und höher mit Full Hybrid Bereitstellung erforderlich)
  • Teams sendet eine Mail an die Teammitglieder UND zusätzlich eingeladene Personen
    Daran sollten sie denken, dass der Termin auch immer an alle Teams-Mitglieder gesendet wird. Es gibt keine gesonderten Mitgliedschaften in Kanälen und Teams weist sie auch nicht gesondert darauf hin.

Der Termin kommt dann wie folgt bei mir an:

Die als Teammitglied eingeladenen Empfänger sind als BCC nicht in der Einladung nach extern sichtbar. Absender ist mein Firmenkonten, welches aber quasi im Auftrag des Teamnamens "UCLabor.de" versendet. Die Mail wird aber durch Teams erzeugt, denn Outlook ist in diesem Beispiel gar nicht involviert.

Customizing

Die Möglichkeiten zur Anpassung der Einladung sind etwas beschränkt. Als Administrator können Sie im Teams AdminCenter die Einladung um einige URLs und eine Fußzeile anreichern. Das war es dann aber


https://admin.teams.microsoft.com/meetings/settings

Mehrsprachigkeit

Ein immer wieder nachgefragtes Feature ist die Mehrsprachigkeit. Alles auf Englisch zu senden kommt bei einer rein deutschen Firma schon nicht gut ab. Aber auch bei internationalen Firmen ist es wenig nützlich eine z.B. japanische Einladung zu bekommen. Die Sprachwahl gilt sowohl für den Einladenden als auch den Empfänger der Einladung. Als Sender möchte ich natürlich verstehen, was Outlook oder Teams dort schreiben und als Empfänger möchte ich mehr als nur "zusagen" können. Bis zum Juni 2022 habe ich noch über Transport-Regel etc. nachgedacht oder eigene Skripte zum Erzeugen der Einladungen. Mittlerweile können Sie aber selbst über eine Policy auch mehrsprachige Einladungen erstellen lassen


https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=81521

Ich kann über den Parameter "-MeetingInviteLanguages" am Commandlet "Set-CsTeamsMeetingPolicy" nun mehrere Sprachen angeben:

Set-CsTeamsMeetingPolicy `
   -Identity "HQ Users" `
   -MeetingInviteLanguages "en-US,de-DE"

Laut Beschreibung zu Set-CsTeamsMeetingPolicy sind folgende Sprachen unterstützt:

ar-SA,az-Latn-AZ,bg-BG,ca-ES,cs-CZ,cy-GB,da-DK,de-DE,el-GR,en-GB,
en-US,es-ES,es-MX,et-EE,eu-ES,fi-FI,fil-PH,fr-CA,fr-FR,gl-ES,he-IL,
hi-IN,hr-HR,hu-HU,id-ID,is-IS,it-IT,ja-JP,ka-GE,kk-KZ,ko-KR,lt-LT,
lv-LV,mk-MK,ms-MY,nb-NO,nl-NL,nn-NO,pl-PL,pt-BR,pt-PT,ro-RO,ru-RU,
sk-SK,sl-SL,sq-AL,sr-Latn-RS,sv-SE,th-TH,tr-TR,uk-UA,vi-VN,zh-CN,zh-TW

In einem Unternehmen kann es mehrere Meeting-Policies geben, die Sprache ist per Default "leer" und jeder Benutzer hat genau eine Policy:

PS C:\> Get-CsTeamsMeetingPolicy | ft identity,MeetingInviteLanguages

Identity                           MeetingInviteLanguages
--------                           ----------------------
Global
Tag:Test FC
Tag:AllOn
Tag:RestrictedAnonymousAccess
Tag:AllOff
Tag:RestrictedAnonymousNoRecording
Tag:Default
Tag:Kiosk

PS C:\> get-csonlineuser fcarius| fl teamsmeetingpolicy

TeamsMeetingPolicy : Test FC

Für einen Test können Sie einfach eine neue Policy anlegen und konfigurieren und Pilot/Test-Benutzern zuweisen, ehe die dann die reguläre Policy anpassen.

Set-CsTeamsMeetingPolicy "test FC" -MeetingInviteLanguages "de-DE,en-US"

Die Änderungen müssen natürlich erst im Teams Backend repliziert und dann von Teams Client und dem Outlook Addon bezogen werden. Das kann schon mal ein paar Stunden dauern 

Alle Termineinladungen laufen natürlich durch Exchange Online und könnten durch Transport-Regeln erkannt und verarbeitet werde. Denkbar wäre hier auch eine komplette Umformatierung der Mails über eine 3rd Party Software, wenn ihnen das Layout nicht gefällt.

SMTP-Header

Also habe ich mit die Mal an ein externes Konto gesendet und den Header angeschaut. Der Header ist natürlich "verkürzt" und zeigt zudem auch eine Konfiguration bei der Exchange Online die Mail über einen vorgelagerten NoSpamProxy in der Cloud gesendet wird, der zudem alle internen Header versteckt. Aber auch so gibt es einiges zu entdecken.

  • Received.
    Hier finden wir nur einen Eintrag, da NoSpamProxy die ganzen internen Einträge als Schutz entfernt hat.
Received: from cloudmx.netatwork.de ([193.37.132.101]) by mx.kundenserver.de
 (mxeue011 [212.227.15.41]) with ESMTPS (Nemesis) id 1McYbV-1krSJT0X8P-00cnHg
 for <user@carius.de>; Thu, 24 Sep 2020 13:19:14 +0200
  • ARC/DKIM
    Diese Einträge zeigen, dass die Mail mit dem Key "selector1-netatwork-onmicrosoft-com" per DKIM signiert war und ARC-Authentication-Results liefert auch "PASS". Auch wenn NoSpamProxy die ganzen Header entfernt kann diese DKIM-Signatur nur von Microsoft aufgebracht worden sein
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=xxxxxxx==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xxxxxxx=;
 b=xxxxxxxx==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=netatwork.de; dmarc=pass action=none
 header.from=netatwork.onmicrosoft.com; dkim=pass
 header.d=netatwork.onmicrosoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=netatwork.onmicrosoft.com; s=selector1-netatwork-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xxx=;xxxxxx=
  • Header-From (Siehe auch SMTP P1/P2-Felder)
    Die Envelope-"MAIL FROM" oder "RCPT TO" sehen wir im Header natülich nicht. Bei der Teams-Termineinladung wird die Mailadresse der Office365-Group als Absender genutzt, in deren Kanal das Meeting geplant ist. Das unterscheidet sich von einer Einladung, die Sie z.B. in Outlook planen.
From: Teamname <Teamname@netatwork.onmicrosoft.com>
  • Header-To / CC (Siehe auch SMTP P1/P2-Felder)
    In der Liste der sichtbaren Empfänger taucht nur der Organisator selbst und das Team auf. Weder die anderen Team-Mitglieder noch der externe Empfänger ist hier gelistet. Das ist für SpamFilter wichtig, da einige Filter so eine Konstellation zumindest als "verdächtig" ansehen, wenn keine lokalen Empfänger in der To/CC-Zeile sind. Wobei eine Termineinladung keine "Kopie-Empfänger" hat und "CC" gar nicht auftaucht.
To: "Organisator" <User@Netatwork.de>, frank <user@carius.de>, Teamname <Teamname@netatwork.onmicrosoft.com>
Sender: "Organisator" <User@Netatwork.de>
  • Return-Path
    Diese Feld wird nicht vom Versender addiert sondern in der Regel vom empfangenden Mailserver, der damit den "Envelope FROM", also das "Mail From"-Feld ablegt. Normalerweise haben Sie als Anwender keinen Zugriff auf diese Information, aber so kann ich erkennen, dass sich die Adressen unterscheiden. Das ist wichtig hinsichtlich Spamfilterungen. SPF nutzt normalerweise den "MAIL FROM", also diesen Wert, um ein Prüfung gegen die Quell-IP zu machen. Das gilt aber nicht, wenn per DMARC z.B. der Header-From vorgegeben wird.
Return-Path: <User@Netatwork.de>
  • Interessant finde ich in der Mail das Feld "Envelope-To:". Nicht jeder Mailserver addiert dieses Feld und sollte hier auch vorsichtig sein, damit die BCC-Funktion nicht aufgedeckt wird.
Envelope-To: <user@carius.de>
  • x-ms-exchange-senderadcheck
    Über das Feld habe ich auf X-MS-Exchange-SenderADCheck und DKIM schon die Hintergründe beschrieben. Office 365 zeigt damit an, dass der Absender "verifiziert" wurde. Die Teams Mailengine ist demnach so vertrauenswürdig, dass Exchange mich als Absender ansieht.
x-ms-exchange-senderadcheck: 1
  • Subject und Thread-Topic, Date usw.
    Die weiteren Felder sind erst einmal nicht weiter besonders zu betrachten. Sie sind durch das "X-" als individuelle Felder klassifiziert und verraten das ein oder andere über die Nachricht, wenn der Empfänger damit etwas anfangen kann. Aber wie bei SMTP üblich sollten Sie sich nicht darauf verlassen, da sie einfach geändert werden können. Es sei denn, sie wären per DKIM signiert.
Subject: Testtermin
Thread-Topic: Testtermin
Date: Thu, 24 Sep 2020 11:19:09 +0000
Message-ID:<AM0PR04MB5380...@AM0PR04MB5380.eurprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-exchange-messagesentrepresentingtype: 2
x-ms-exchange-calendar-series-instance-id:<base64>
x-ms-office365-filtering-correlation-id: <guid>
x-ms-traffictypediagnostic: AM0PR04MB4868:MeetingMessage
x-ld-processed: de21c301-a4ae-4292-aa09-6db710a590a6,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam: BCL:0;
MIME-Version: 1.0
X-OriginatorOrg: netatwork.de
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB5380.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2020 11:19:09.7727
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: <tenantGUID>
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB4868
X-Spam-Flag: NO
  • Feld: x-netatwork-exorules
    Diese Feld lasse ich auf dem Exchange Online Server per Transportregel addieren. Damit ist quasi auch bewiesen, dass Teams die Mail erst an die Exchange Instanz im eigenen Tenant eingeliefert wird, um damit dann übertragen zu werden.
x-netatwork-exorules: 1

Message Tracking

Wenn die Mails durch die Exchange Instanz läuft, muss sie hier ja auch im Messagetrace zu finden sein. Über die MessageID ist die Mail schnell zu finden

PS C:\> Get-MessageTrace -MessageId "<xxxx@AM0PR04MB5380.eurprd04.prod.outlook.com>"

Received            Sender Address    Recipient Address                  Subject    Status
--------            --------------    -----------------                  -------    ------
24.09.2020 11:19:09 User@Netatwork.de user@carius.de                     Testtermin Delivered
24.09.2020 11:19:09 User@Netatwork.de teamname@netatwork.onmicrosoft.com Testtermin Expanded
24.09.2020 11:19:09 User@Netatwork.de user@netatwork.de                  Testtermin Delivered

Die Details des erste Eintrag sind:

Message Trace ID  : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Message ID        : <xxxx@AM0PR04MB5380.eurprd04.prod.outlook.com>
Received          : 24.09.2020 11:19:09
Sender Address    : user@Netatwork.de
Recipient Address : user@carius.de
From IP           : 52.114.88.173
To IP             : 193.37.132.101
Subject           : Testtermin
Status            : Delivered
Size              : 27034

Interessant ist, dass die einliefernde IP-Adresse zu Microsoft gehört aber nicht per Reverse-DNS auflösbar ist.


https://ipinfo.io/AS8075/52.112.0.0/14-52.114.88.0/22

Die Mail ist in diesem Fall nach Extern gegangen und daher von Exchange Online direkt zum vorgelagerten Spamfilter, hier eine Cloud-Instanz von NoSpamProxy (193.37.132.101), versendet worden.

Centralized Mail Transport

Wenn ihre Firma die Mails aus Exchange Online nicht direkt in die Cloud sendet, sondern über Hybrid Centralized Mail Transport erst zu einem lokalen Exchange Server sendet, dann können Sie auch dort im Messagetracking sehen, wie die Mail aus der Cloud ankommt, verarbeitet und letztlich versendet wird.

Get-TransportService `
| Get-MessageTrackingLog `
     -Recipients user@carius.de `
     -Start (get-date).addminutes(-30) `
| ft *subject,eventid,source,originalclientip -AutoSize

MessageSubject   EventId   Source OriginalClientIp
--------------   -------   ------ ----------------
Testtermin      RECEIVE    SMTP   104.47.12.54
Testtermin      HARECEIVE  SMTP
Testtermin      HADISCARD  SMTP
Testtermin      HAREDIRECT SMTP
Testtermin      AGENTINFO  AGENT  104.47.12.54
Testtermin      SEND       SMTP

Hier kommt die Mail von Exchange Online (104.47.12.54) als OriginalClientIP an, um dann am Ende nach extern versendet zu werden.

Einladungen und Spamfilter

Solange sie Termine "intern" einladen, bleiben die Mails in ihrer eigenen Umgebung. Sobald sie aber externe Teilnehmer aus anderen Firmen einladen, dann werden diese Mails natürlich von Exchange Online oder ihrem eigenen Mailserver versendet. Damit müssen wir uns um SPF, DKIM und DMARC Gedanken machen. Ansonsten kommen die Mails vielleicht nicht an. Schauen wir uns die relevanten Felder der Termineinladung einmal an: (Siehe dazu auch SMTP P1/P2-Felder)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=netatwork.onmicrosoft.com; s=selector1-netatwork-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xxx=;xxxxxx=

From: Teamname <Teamname@netatwork.onmicrosoft.com>
Return-Path: <User@Netatwork.de>

Wir sehen hier eine von Office 365 angefügte DKIM-Signatur, die solange gültig bleibt, wie sie die damit abgesicherten Felder nicht ändern. Sofern die Einladung nicht an eine "Gruppe geht" die das Feld X-MS-Exchange-SenderADCheck verändert, bleibt die Signatur gültig.

Aus dem Header sehen Sie aber, dass der "Envelope MAIL FROM" die Adresse des Absenders ist während die Header-From die Office Group ist. Damit gibt es je nach DMARC/SPF-Eintrag und Routing verschiedene

netatwork.onmicrosoft.com  
SPF   =  v=spf1 include:spf.protection.outlook.com -all
DMARC =  nicht vorhanden 

netatwork.de
SPF   =  v=spf1 redirect=_spf.netatwork.de 
DMARC =  v=DMARC1; p=reject; ; fo=1; adkim=s; aspf=s; rf=afrf; sp=none

Ehe Sie die Tabelle anschauen, sollten Sie sich folgende Punkte verinnerlichen:

  • Auf die Einstellungen der "tenantname.onmicrosoft.com" haben sie keinen Einfluss
    Sie können hier insbesondere keine eigenen Adressen im SPF-Record eintragen
  • Der "Envelope-From" ist im Bespiel ihre eigene Domain
    Es gibt noch Fälle, wo dies auch anders ist. aber den dazugehörigen SPF-Eintrag können Sie steuern.
  • DMARC wird anhand der Domain aus "Header From" bezogen.
    Die Header-From-Domain muss dann mit dem "d="-Feld in der DKIM Signatur übereinstimmen
  • Ich verzichte auf die Sonderfälle, die ein "DMARC p=Quarantine", "DMARC p=None" oder "spf:~all" enthalten.
    Wenn ich meine Domain schützen will, dann sind solche "weichen" Anweisungen nicht zielführend.
  • Empfänger prüft SPF/DKIM/DMARC
    Sonst würde die Tabelle noch umfangreicher.
DMARC SPF SenderIP Ergebnis Beschreibung

nicht definiert

nicht definiert

Egal

Vielleicht

Der Empfänger kann SPF nicht prüfen. Vielleicht prüft er noch DKIM und erkennt die Signatur als gültig an. Das kann aber auch eine Spammer aber ohne DMARC-Vorgabe wird er Fälschungen nicht ablehnen, sondern die Mail durch die bislang bekannten Antispam-Filter leiten und das Ergebnis anwenden. Als Absender haben Sie die Change vertan, dem Empfänger bei der Klassifizierung zu helfen.

nicht definiert

Empfänger nutzt Envelope-From

-all

Siehe Text

OK

Ohne DMARC-Vorgaben sollte ein Empfänger die Envelope-FROM-Domain gegen einen SPF-Record prüfen. Den sollte Sie natürlich so einstellen, dass die "ausgehenden" Server auch enthalten sind. Senden sie von Exchange Online direkt die Mails raus, dann sollten Sie folgende Zeilen in einen vorhandenen SPF Eintrag addieren:

include:spf.protection.outlook.com
 
p=reject

Empfänger nutzt Header-From

nicht definiert

Egal

OK

Wenn sie auf dem Weg nach draußen nichts ändern, dann sollte die DKIM-Signatur für die "From-Adresse "Teamname <Teamname@netatwork.onmicrosoft.com>" gültig sein und die Mail ankommen lassen. Der Fall ist aber selten, dass eine Firma dann noch auch noch den SPF setzt.

 
p=reject

Empfänger nutzt Header-From

-all

EXO

OK

Durch den DMARC-Eintrag wird nun der "Header-FROM" statt Envelope-MAIL FROM überprüft. Mit dem Alignment wird nun aber neben der Envelope-From auch die Header-From  und damit die Adresse "<Teamname@netatwork.onmicrosoft.com>" geprüft und das stimmt nur, wenn Exchange Online die Mail versendet.

 
p=reject

Empfänger nutzt Header-From

-all

Eigen

Nur mit DKIM

Durch den DMARC-Eintrag wird nun der "Header-FROM" statt Envelope-MAIL FROM überprüft. Hier kommt nun die Adresse "<Teamname@netatwork.onmicrosoft.com>" zur Prüfung und damit haben wir ein SPF-Fail. Ein Empfänger, der nun kein DKIM-Prüfung macht, wird die Mail ablehnen!

Die letzte Zeile ist eigentlich das Problem, denn wenn Sie die Mail z.B. über Hybrid Centralized Mail Transport oder einen eigenen Spam-Service versenden UND die Gegenseite nur eine SPF aber keine keine DKIM-Prüfung vornimmt, dann kommt die Mail aufgrund des SPF=FAIL nicht an.

Sie müssen daher sicherstellen, dass Mails mit einer Absenderdomain <tenantname>.onmicrosoft.com auf jeden Fall von Office 365 versendet werden UND sie die Office 365 IP-Adressen in ihrer Domain als gültige SPF-Einträge eingebunden haben.

Weitere Links