Message Tracking Exchange 2016

Tracking von verschiedenen Quellen
Der Weg zum Postfach auf einem einzelnen Server
Der Weg durch mehrere Server
Benutzer und Gruppen, Sender und Empfänger
Der erste Aufschlag: Feld: OriginalClientIP
Feld Messageinfo
Feld Directionality
Feld: MessageID u.a.
Anonyme Einlieferer erkennen
Weitere Links

Diese Seite ist eigentlich entstanden, weil ich ermitteln musste, welche Clients per SMTP anonym Mails einliefern. Heraus gekommen ist dann aber doch eine etwas umfangreichere Analyse des Exchange 2016 Tracking Logs.

Tracking von verschiedenen Quellen

Ich habe daher erst mal einen Test gemacht, wie die Mails eingeliefert werden und folgende fünf Fälle betrachtet:

Authentifizierter Versand per Outlook über MAPI/HTTP
Authentifizierter Versand per Outlook Web App
Authentifizierter Versand per ActiveSync
Authentifizierter Versand per SMTP
Anonymer Versand per SMTP

Das entsprechende Messagetracking ergibt:

[PS] C:\>Get-MessageTrackingLog | sort timestamp| ft messagesubject,source,eventid,originalclientip,clientip,kmessageinfo

MessageSubject Source      EventId      OriginalClientIp ClientIp                     MessageInfo
-------------- ------      -------      ---------------- --------                     -----------
EAS            STOREDRIVER RECEIVE                       fe80::c576:b2c3:f631:f737    04I:
EAS            SMTP        RECEIVE      192.168.100.33   192.168.100.33               0cI:
EAS            STOREDRIVER SUBMIT                        fe80::c576:b2c3:f631:f737%12 2018-02-05T12:56:41.168Z;LSRV=EX01.neta...
EAS            AGENT       AGENTINFO    192.168.100.33
EAS            ROUTING     TRANSFER
EAS            SMTP        SENDEXTERNAL                  192.168.100.33               2018-02-05T12:56:41.168Z;SRV=EX01.netat...
OWA            STOREDRIVER RECEIVE      192.168.100.5    fe80::c576:b2c3:f631:f737    04I:
OWA            SMTP        RECEIVE      192.168.100.5    192.168.100.33               0cI:
OWA            STOREDRIVER SUBMIT       192.168.100.5    fe80::c576:b2c3:f631:f737%12 2018-02-05T12:58:12.622Z;LSRV=EX01.neta...
OWA            AGENT       AGENTINFO    192.168.100.5
OWA            ROUTING     TRANSFER
OWA            SMTP        SENDEXTERNAL                  192.168.100.33               2018-02-05T12:58:12.622Z;SRV=EX01.netat...
Outlook        STOREDRIVER RECEIVE      192.168.103.56   fe80::c576:b2c3:f631:f737    04I:
Outlook        SMTP        RECEIVE      192.168.103.56   192.168.100.33               0cI:
Outlook        STOREDRIVER SUBMIT       192.168.103.56   fe80::c576:b2c3:f631:f737%12 2018-02-05T12:59:27.467Z;LSRV=EX01.neta...
Outlook        AGENT       AGENTINFO    192.168.103.56
Outlook        ROUTING     TRANSFER
Outlook        SMTP        SENDEXTERNAL                  192.168.100.33               2018-02-05T12:59:27.467Z;SRV=EX01.netat...
SMTP Auth      SMTP        RECEIVE      192.168.103.56   192.168.100.33               07I:
SMTP Auth      AGENT       AGENTINFO    192.168.103.56
SMTP Auth      SMTP        SENDEXTERNAL                  192.168.100.33               2018-02-05T13:07:41.772Z;SRV=EX01.netat...
smtpanon       SMTP        RECEIVE      192.168.103.56   192.168.100.33               0cA:
smtpanon       AGENT       AGENTINFO    192.168.103.56
smtpanon       SMTP        SEND                          192.168.100.33               2018-02-05T13:09:07.107Z;LSRV=EX01.neta...
smtpanon       STOREDRIVER DELIVER      192.168.103.56                                2018-02-05T13:09:07.107Z;SRV=EX01.netat...
EWSTest        STOREDRIVER RECEIVE      192.168.103.56   fe80::c576:b2c3:f631:f737    04I:
EWSTest        SMTP        RECEIVE      192.168.103.56   192.168.100.33               0cI:
EWSTest        STOREDRIVER SUBMIT       192.168.103.56   fe80::c576:b2c3:f631:f737%12 2018-02-05T13:27:12.152Z;LSRV=EX01.neta...
EWSTest        AGENT       AGENTINFO    192.168.103.56
EWSTest        ROUTING     TRANSFER
EWSTest        SMTP        SENDEXTERNAL                  192.168.100.33               2018-02-05T13:27:12.152Z;SRV=EX01.netat...

Genau genommen fehlt hier natürlich noch die RESTAPI. Der Fall "SMTP-Anon" ist ein Sonderfall, da ich hier die Mail lokal zustellen musste (Mein Exchange ist kein Anonymes offenes Relay)

Der Weg zum Postfach auf einem einzelnen Server

Ich habe mir die sechs Wege durch den Exchange Server erst einmal skizziert. Das ist gar nicht so einfach, wenn auf einem Server alle Funktionen sehr schnell ablaufen und die Protokollierung im Messagetracking nicht in der zeitlich korrekten Abfolge geschrieben wird.

Es ist gut zu sehen, dass "SMTP/RECEIVE" also auch "AGENT/AGENTINFO" von allen Mails durchlaufen wird. Sie sehen hier auch gut den "Sonderfall SMTP Anonym" und die letzten beiden Stationen sind natürlich auch für eine Einlieferung über die anderen Fälle gültig. Der "STORE/SUBMIT" zeigt auch, wann die Mail in "Gesendete Objekte erscheint".

Der Weg durch mehrere Server

Interessant wird es, wenn Sie nun zwei oder mehr Server haben. Hier werden die Mails ggfls. über unterschiedliche Transport-Systeme übertragen und auch der ShadowCache sorgt für zusätzliche Events. Zudem scheint es Events zu geben, die auf einem Single-Server nicht erscheinen, z.B. MAPI/NOTIFY. Hier einfach mal eine Mail von zwei internen Postfächern. Die Events sind von zwei Servern und aufgrund der engen Zeitstempel bin ich nicht sicher, ob die Reihenfolge so passt.

Timestamp           Source      EventId    MessageInfo
---------           ------      -------    -----------
13.04.2017 17:15:29 STOREDRIVER RECEIVE    04I:
13.04.2017 17:15:29 SMTP        RECEIVE    0cI:
13.04.2017 17:15:29 SMTP        HAREDIRECT
13.04.2017 17:15:29 SMTP        HARECEIVE
13.04.2017 17:15:29 STOREDRIVER SUBMIT     2018-02-01T16
13.04.2017 17:15:29 AGENT       AGENTINFO
13.04.2017 17:15:29 STOREDRIVER DELIVER    2018-02-01T16
13.04.2017 17:15:30 SMTP        SEND       2018-02-01T16
13.04.2017 17:15:31 SMTP        HADISCARD

Der Weg durch die Server ist erst mal identisch aber hinzu kommen hier die Kopien auf eigenem anderen Server für die Hochverfügbarkeit:

Wenn ich in dem Fall ein "Anonymes Relay nacherfolge, dann sehe ich:

Timestamp           Source EventId    MessageInfo
---------           ------ -------    -----------
13.04.2017 16:52:02 SMTP   RECEIVE    0cA:
13.04.2017 16:52:02 SMTP   HAREDIRECT
13.04.2017 16:52:02 AGENT  AGENTINFO
13.04.2017 16:52:02 SMTP   SEND       2018-02-01T1
13.04.2017 16:52:02 SMTP   HARECEIVE
13.04.2017 16:52:56 SMTP   HADISCARD
13.04.2017 16:53:15 SMTP   HADISCARD
13.04.2017 16:53:36 SMTP   HARECEIVE
13.04.2017 16:53:36 SMTP   HAREDIRECT
13.04.2017 16:53:36 SMTP   RECEIVE    0cA:
13.04.2017 16:53:36 AGENT  AGENTINFO
13.04.2017 16:53:37 SMTP   SEND       2018-02-01T1
13.04.2017 16:54:04 SMTP   HADISCARD
13.04.2017 16:54:51 SMTP   HADISCARD

So genau habe ich aber diesen Durchlauf nun auch nicht mehr verstanden. Der Hauptweg der Mail ist verständlich und sie sehen auch, dass hier anscheinend die Agenten zweimal aktiv werden und ganz viele Einträge der Hochverfügbarkeit des Transport geschuldet sind.

Benutzer und Gruppen, Sender und Empfänger

Zusätzlich habe ich noch mal drei Trackings erstellt, die den Mailfluss beschreiben. Diese Referenz nutze ich, wenn ich z.B. Auswertungen nach Empfängern und Absendern erzeugen möchte

Mail von intern nach Extern

Sie sehen gut, dass die Mail beim StoreDriver startet und es sowohl einen SMTP RECEIVE als auch SMTP SEND Event gibt.

EventId    Source      Sender            Recipients            MessageSubject
-------    ------      ------            ----------            --------------
NOTIFYMAPI STOREDRIVER user1@uclabor.de  {}
RECEIVE    STOREDRIVER user1@uclabor.de  {sender@msxfaq.de}     Testmail nach extern
HAREDIRECT SMTP        user1@uclabor.de  {sender@msxfaq.de}     Testmail nach extern
RECEIVE    SMTP        user1@uclabor.de  {sender@msxfaq.de}     Testmail nach extern
HARECEIVE  SMTP        user1@uclabor.de  {sender@msxfaq.de}     Testmail nach extern
SUBMIT     STOREDRIVER user1@uclabor.de  {sender@msxfaq.de}     Testmail nach extern
TRANSFER   ROUTING     user1@uclabor.de  {sender@msxfaq.de}     Testmail nach extern
AGENTINFO  AGENT       user1@uclabor.de  {sender@msxfaq.de}     Testmail nach extern
SEND       SMTP        user1@uclabor.de  {sender@msxfaq.de}     Testmail nach extern
HADISCARD  SMTP        user1@uclabor.de  {sender@msxfaq.de}     Testmail nach extern
HADISCARD  SMTP        user1@uclabor.de  {sender@msxfaq.de}     Testmail nach extern

Interne Mail

Auch wenn eine Mail allein von intern nach Intern gesendet wird, sehen Sie SMTP SEND und SMTP RECEIVE Messages

EventId    Source      Sender            Recipients            MessageSubject
-------    ------      ------            ----------            --------------
NOTIFYMAPI STOREDRIVER user1@uclabor.de  {}
RECEIVE    STOREDRIVER user1@uclabor.de  {user2@uclabor.de     Testmail Intern
SUBMIT     STOREDRIVER user1@uclabor.de  {user2@uclabor.de     Testmail Intern
RECEIVE    SMTP        user1@uclabor.de  {user2@uclabor.de     Testmail Intern
HAREDIRECT SMTP        user1@uclabor.de  {user2@uclabor.de     Testmail Intern
HARECEIVE  SMTP        user1@uclabor.de  {user2@uclabor.de     Testmail Intern
AGENTINFO  AGENT       user1@uclabor.de  {user2@uclabor.de     Testmail Intern
DELIVER    STOREDRIVER user1@uclabor.de  {user2@uclabor.de     Testmail Intern
SEND       SMTP        user1@uclabor.de  {user2@uclabor.de     Testmail Intern
HADISCARD  SMTP        user1@uclabor.de  {user2@uclabor.de     Testmail Intern

Eingehende Mail aus dem Internet

Das bekannte Bild, nur dass der Anfang diesmal ein SMTP Receive ist.

EventId    Source      Sender            Recipients           MessageSubject
-------    ------      ------            ----------           --------------
HARECEIVE  SMTP        sender@msxfaq.de  {user1@uclabor.de    Extern nach Intern
HAREDIRECT SMTP        sender@msxfaq.de  {user1@uclabor.de    Extern nach Intern
RECEIVE    SMTP        sender@msxfaq.de  {user1@uclabor.de    Extern nach Intern
AGENTINFO  AGENT       sender@msxfaq.de  {user1@uclabor.de    Extern nach Intern
DELIVER    STOREDRIVER sender@msxfaq.de  {user1@uclabor.de    Extern nach Intern
SEND       SMTP        sender@msxfaq.de  {user1@uclabor.de    Extern nach Intern
HADISCARD  SMTP        sender@msxfaq.de  {user1@uclabor.de    Extern nach Intern

Mail an Verteiler

Hier interessiert mich, ab wann der Empfänger sich verändert. Die Mail ging an die "DistributionGroup DL@uclabor.de" und enthält zwei Empfänger. Der SMTP RECEIVE hat noch den Verteiler als Empfänger und wird direkt vom "EXPAND ROUTING" gefolgt. Hier sehen Sie dann die Auflösung der Mitgliedschaften. Danach sehen sie noch ein paar "Nacharbeiten" für die Mail an die Verteilergruppe während die Zustellung an die Benutzer weiter geführt wird. Die SMTP SEND Einträge gibt es dann je Empfänger einzelne.

EventId    Source      Sender            Recipients
-------    ------      ------            ----------
NOTIFYMAPI STOREDRIVER sender@uclabor.de {}
RECEIVE    STOREDRIVER sender@uclabor.de {dl@uclabor.de}
RECEIVE    SMTP        sender@uclabor.de {dl@uclabor.de}
HAREDIRECT SMTP        sender@uclabor.de {dl@uclabor.de}
EXPAND     ROUTING     sender@uclabor.de {user1@uclabor.de,user2@uclabor.de}
SUBMIT     STOREDRIVER sender@uclabor.de {dl@uclabor.de}
TRANSFER   ROUTING     sender@uclabor.de {user1@uclabor.de,user2@uclabor.de}
AGENTINFO  AGENT       sender@uclabor.de {dl@uclabor.de,user1@uclabor.de,user2@uclabor.de}
DROP       ROUTING     sender@uclabor.de {dl@uclabor.de}
HARECEIVE  SMTP        sender@uclabor.de {dl@uclabor.de}
SEND       SMTP        sender@uclabor.de {user2@uclabor.de}
SEND       SMTP        sender@uclabor.de {user1@uclabor.de}
DELIVER    STOREDRIVER sender@uclabor.de {user2@uclabor.de}
DELIVER    STOREDRIVER sender@uclabor.de {user1@uclabor.de}
HADISCARD  SMTP        sender@uclabor.de {dl@uclabor.de}

Wer also Statistiken aus dem Messagetracking nach Empfängern generieren will, muss schon überlegen, wie er Mails behandelt, die erst an einen Verteiler gehen und dann aufgefächert werden. Eine Suche nach SMTP RECEIVE liefert die Mail vor der Aufschlüsseung. Eine Suche nach SMTP SEND zeigt die Mail nach der Verteilung. Allerdings kann auch der Eintrag "AGENTINFO AGENT" die bessere Wahl sein, weil hier alle Empfänger enthalten sind.

Der erste Aufschlag: Feld: OriginalClientIP

Mein Ziel war es zu erkunden, wie die ersten Einträge im Tracking bezüglich EventID, OriginalClientIP und ClientIP aussieht. Schaut man sich das Tracking nun genauer an, dann findet man pro Weg unterschiedliche erste "Treffer". Zusätzlich habe ich mir die erste "ReceivedBy"-Zeile in der empfangenen Mail angeschaut, auch wenn diese im Messagetracking nicht aber auf dem Client meist sichtbar ist.

Protokoll	Source und Event	MessageInfo	OriginalClientIP	ClientIP	ReceivedBy: with...
EAS	STORE RECEIVE STORE RECEIVE	04I: 0cI:	Leer Exchange FE IPv4	Exchange FE IPv6 Exchange FE IPv4	mapi
OWA	STORE RECEIVE STORE RECEIVE	04I: 0cI:	Client oder Proxy Client oder Proxy	Exchange FE IPv6 Exchange FE IPv4	mapi
Outlook	STORE RECEIVE STORE RECEIVE	04I: 0cI:	Client oder Proxy Client oder Proxy	Exchange FE IPv6 Exchange FE IPv4	mapi
SMTP Auth	SMTP RECEIVE	07I:	Client IP	Exchange FE IPv4	Microsoft SMTP Server
SMTP Anonym	SMTP RECEIVE	0cA:	Client IP	Exchange FE IPv4	Microsoft SMTP Server
EWS	STORE RECEIVE STORE RECEIVE	04I: 0cI:	Client IP Client IP	Exchange FE IPv6 Exchange FE IPv4	mapi

Sie sehen hier schon gut, dass das Feld "OriginalClientIP" bis auf den Sonderfall ActiveSync immer die IP-Adresse des einliefernden Clients enthält, Diese Feld wird sogar in der Folge weiter mitgeführt, d.h. selbst beim finalen Zustellen in eine Mailbox mit "STOREDRIVER:DELIVER" oder dem Versand nach extern mittels "SMTP:SEND" die der Inhalt von "OriginalClientIP" vorhanden und erlaubt eine schnelle Analyse von wo nach wo die Mail geroutet wurde.

Hier interessieren mich einige Fehler für die spätere Auswertung:

ClientIP
Es ist gut zu sehen, dass mit Ausnahme von SMTP-Einlieferungen die "ClientIP" immer die Exchange interne IPv6-Adresse ist. Dieses Feld ist für eine Auswertung nach der Quelle nicht geeignet
OriginalClientIP
Daher wird Microsoft auch dieses Feld eingeführt haben, damit man zumindest halbwegs erkennen kann, welcher Client hier verbunden war. Interessanterweise liefert ActiveSync hier keine Information mit.
Source und Event
Nur SMTP umgeht den Store. Alle anderen Protokolle legen ihre Mails quasi im Postausgang des Anwenders ab und werden dort abgeholt.
MessageInfo
Dieses Feld habe ich lange nicht weiter betrachtet. Aber es ist wichtig um mehr Details zur Einlieferung zu erhalten

Bei der Betrachtung der ersten Einträge je nach Protokoll fällt auf, dass jede Mail eine "SMTP-RECEIVE"-Zeile hat. Das ist ja auch verständlich, da jede Mail durch den SMTP-Tramsport durch geroutet wird. Wer allerdinge mehrere Server hat und eine Mail mehrere Stationen durchläuft, wird entsprechend mehrere Einträge finden. Auch wenn mehrere Empfänger zu adressieren sind und die Mail vielleicht noch aufgesplittet wird (Bifurcation), wird mehrere dieser Einträge finden. für eine "Zählung" müssen Sie also noch etwas genauer hinschauen. Aber auch der Eintrag "AGENT/AGENTINFO" kann für eine Mail mehrfach auftreten. Ich habe aber zwei solcher Einträge verglichen und sie sind identisch. Für eine Zählung der Mails alleine aber auch kein 100% zuverlässiger Event. Dubletten und damit Falschzählungen sind möglich.

Feld Messageinfo

Auf der Suche nach einer verlässlichen Quelle zur Erkennung von "anonymen Mails" habe ich die beiden Logs zu "SMTP Auth" und "SMTP Anonym" verglichen und abgesehen von dem Timestamp und dem Betreff hat sich nur noch das Feld "MessageInfo" unterschieden: . Also habe ich mir mal genauer angeschaut, welche Events es bei mir gibt. Das Feld hat manchmal eine dreistellige Kombination aber später enthält es viel mehr Daten. Hier mal ein Auszug einer Mail:

MessageSubject Source      EventId      MessageInfo
-------------- ------      -------      -----------
Outlook        STOREDRIVER RECEIVE      04I:
Outlook        SMTP        RECEIVE      0cI:
Outlook        STOREDRIVER SUBMIT       2018-02-05T12:59:27.467Z;LSRV=EX16.msxfaq.de:TOTAL-SUB=0.328|SA=0.078|MTSS=0.253(M...
Outlook        AGENT       AGENTINFO
Outlook        ROUTING     TRANSFER
Outlook        SMTP        SENDEXTERNAL 2018-02-05T12:59:27.467Z;SRV=EX16.msxfaq.de:TOTAL-SUB=0.203|SA=0.078|MTSS-PEN=0.12...

Einige Events sind leer und einige andere Events enthalten umfangreiche Verarbeitungsinformationen. Das Feld gibt es wohl seit Exchange 2007 und die Bedeutung is wie folgt umschrieben

The message origination date-time in UTC for DELIVER and SEND events. The origination date-time is the time when the message first entered the Exchange organization. The UTC date-time is represented in the ISO 8601 date-time format: yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, T indicates the beginning of the time component, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC.
Authentication errors. For example, you may see the value 11a and the type of authentication that was used when the authentication error occurred.
Message tracking
https://technet.microsoft.com/en-us/library/bb124375(v=exchg.160).aspx

Leider gibt es keine Auflistung für die "Authentication Errors". Also habe ich die obige Liste genommen und versucht zu ermitteln, welche Events damit verbunden sind. Ich war natürlich neugierig, welche Events dahinter verborgen waren. Ich habe ein paar Versuche gebraucht um zu erkennen, dass bei den kurzen Einträgen ein "Leerzeichen" hinter dem Doppelpunkt steht. So sah dann die Verteilung bei mir aus:

Get-MessageTrackingLog `
   -Start (get-date).adddays(-10) `
   -ResultSize unlimited `
| ?{$_.messageinfo -like "*: "} `
| group messageinfo `
   -NoElement

Folgende Einträge habe ich mit der angegebenen Häufigkeit und den verbundenen Events gefunden und aus verschiedenen anderen Quellen zusammengesucht:

Code	Häufigkeit	Events	Connector	Beschreibung
0cI:	7044	SMTP/RECEIVE	Default Receive Connector	Interne Absender, vermutlich authentifiziert
07I:	7486	SMTP/RECEIVE	Client Receive Connector	Über den Port 465 angenommene
0cA:	13678	SMTP/RECEIVE	Default Receive Connector	Die Absenderadresse ist extern.
0cI:		SMTP/RECEIVE	Default Receive Connector	Die Absenderadresse ist intern
05I:	1	AGENT/RECEIVE		Bei mir war das eine Mail des Malware Agent
03I:	465	MAILBOXRULE/RECEIVE STOREDRIVER//RECEIVE	$null	Automatische Antworten, Weiterleitungen Angeblich auch ein Hinweis auf MAPI ohne RPC-Encryption
04I:	5762	STOREDRIVER/RECEIVE	$null	Von Anwendern zum Versand übergebene Nachrichten. Darunter fallen auch HealthMailboxen. Andere Quellen MAPI beschreiben diese als Zugriffe per RPC Verschlüsselung
00a:	0	?	?	Angeblich Keine Verschlüsselung, Anonym per SMTP empfangen
0aI:	0	?	?	Authentifiziertes SMTP empfangen

Wenn Sie weitere Events finden und zuordnen können, dann bin ich für Hinweise dankbar.

RE: Meaning of this Codes (03I: , 04I:, 00A:) on Exchange 2007
http://www.mail-archive.com/exchangelist@lyris.sunbelt-software.com/msg45705.html
03I: 04I: 00A: In the message-info field of message tracking logs. what do they mean?
https://social.technet.microsoft.com/Forums/lync/en-US/32c7029d-fb09-4d2d-9acd-95281f8ee8d8/03i-04i-00a-in-the-messageinfo-field-of-message-tracking-logs-what-do-they-mean?forum=exchangesvrgenerallegacy
Message Tracking Log – znaczenie: MessageInfo (Polnisch)
https://heloexchange.wordpress.com/2011/11/04/message-tracking-log-znaczenie-messageinfo

Feld Directionality

Im Messagetracking habe ich noch ein Feld "Directionality" entdeckt. Auch hier habe erst etwas Hoffnung gehabt aber eine schnelle Auswertung hat gezeigt, dass diese Angabe der Richtung wenig beitragen kann

Get-TransportService | Get-MessageTrackingLog -ResultSize 1000 | group Directionality 

Count Name
----- ----
11165 Originating
9569 Incoming
1124

Bei der Analyse, welche Event mit welchen Einträgen vorkommen, können Sie schon selbst erkennen, dass man hier wohl nicht weiter kommt.

directionality	Source/Event
Incoming	STOREDRIVER/DELIVER STOREDRIVER/DUPLICATEDELIVER
Originating	STOREDRIVER: DELIVER STOREDRIVER: RECEIVE STOREDRIVER: DUPLICATEDELIVER STOREDRIVER: SUBMIT STOREDRIVER: THROTTLE MAILBOXRULE: RECEIVE

Irgendwie logisch, dass ein "Deliver" bei "Incoming auftaucht". Aber ich habe keinen einzigen Event von SMTP oder AGENT gefunden, der das Feld "Directioality" gesetzt hätte. Als Kriterium für die "Richtung" ist das Feld damit wohl schon ziemlich überflüssig.

Feld: MessageID u.a.

Wenn Sie sich bei SMTP/RECEIVE mal so einen Header anschauen, dann fallen ihnen gleich mehrere Felder auf, die etwas mit einer MessageID zu tun haben. Die werden gerne als primärer Schlüssel für die Suche von zusammen gehörenden Mails genutzt. Das ist aber nicht immer so einfach:

RunspaceId              : 0f13ec85-1234-1234-1234-67d8cc282755
Timestamp               : 2/09/2018 11:28:01 AM
ClientIp                : 192.168.1.26
ClientHostname          : EX2016B.msxfaq.net
ServerIp                : 192.168.1.16
ServerHostname          : EX2016A
SourceContext           : 08D572C8F08A428A;2018-02-09T10:27:48.749Z;9
ConnectorId             : EX201A\Default EX201A
Source                  : SMTP
EventId                 : RECEIVE
InternalMessageId       : 468967479081
MessageId               : <2127232375.466@ex2016A.msxfaq.net>
NetworkMessageId        : 5e630e82-bf20-5678-5678-08d572cc7562
Recipients              : {User2@msxfaq.com}
RecipientStatus         : {}
TotalBytes              : 3636
RecipientCount          : 1
RelatedRecipientAddress :
Reference               :
MessageSubject          : TestMessage
Sender                  : User1@msxfaq.de
ReturnPath              : User1@msxfaq.de
Directionality          : Incoming
TenantId                :
OriginalClientIp        : 80.66.20.20
MessageInfo             : 0cA:
MessageLatency          :
MessageLatencyType      : None
EventData               : {[ProxyHop1, EX2016A.com.msxfaq.net(192.168.1.26)], [MessageValue, MediumHigh], [Replication, EX2016B], [FirstForestHop,
                          EX2016C.com.msxfaq.net], [FromEntity, Internet], [ProxiedClientIPAddress, 80.66.20.20], [ProxiedClientHostname,
                          EX2016EDGE.dmz.msxfaq.net], [DeliveryPriority, Normal], [OriginalFromAddress, User1@msxfaq.net],
                          [AccountForest, msxfaq.net]}
TransportTrafficType    : Email
SchemaVersion           : 15.01.1261.035

Interessant sind natürlich Felder, die über mehrere Stationen unverändert bleiben und einmalig sind. Es ist sonst gar nicht so einfach zu ermitteln, ob mehrere Events nun die gleiche Mail auf mehreren Zwischenstationen darstellen oder ob eine Mail an mehrere Empfänger entsprechende Events erzeugt. Meine Erkenntnisse sind soweit:

MessageID
Durch den Absender vorgegeben aber wird von Exchange addiert, wenn sie fehlt. Wird die gleiche Mail zugleich an mehrere Empfänger gesendet, (CC, BCC), dann gibt es mehrere Mails mit der gleichen MessageID. Ich habe schon komplett unterschiedliche Mails an verschiedene Empfänger gesehen, die die gleiche MessagID haben. Sie ist also nicht eindeutig
InternalMessageId
Diese ID scheint Exchange selbst zu generieren. Allerdings habe ich schon zwei komplett unterschiedliche Mails mit der gleichen "InternalMessageId" gefunden. Richtig brauchbar ist das Feld daher nicht
NetworkMessageId
Dieses Feld wird auch von Exchange vergeben und ist wohl innerhalb der Organisation einmalig und beständig. Es eignet sich vortrefflich, um z.B. mehrfache Events zusammen zu fassen.

Sprechend ist von den drei Feldern natürlich die MessageID. Aus Datenschutzgründen könnte es aber nicht gewünscht sein, den Inhalt dieses Felds zu verwenden. Dann ist NetworkMessageID ein gleichwertiges Feld. Nur dem Inhalt von InternalMessageID vertraue ich nicht.

Es gibt kein 100% zuverlässiges Feld, welches eine Mail eindeutig erkennbar macht. Sie können versuchen z.B. aus der Absendezeit, dem Sender und Empfänger und der hoffentlich unterschiedlichen MessageID einen Primärschlüssel herzuleiten. Sicher ist das aber auch nicht.

Anonyme Einlieferer erkennen

Wenn ich die ganze Beschreibung nun Revue passieren lasse, dann gibt es mit Exchange 2016 aktuell nur einen Weg, die anonyme Zustellung an Exchange zu erfassen. Man sammelt alle SMTP/RECEIVE-Events, bei denen die MessageInfo den Wert "0cA: " hat. Zumindest ist die aktuell aus meiner Sicht für Exchange 2016 CU7 zutreffend.

Einfacher haben es natürlich die Administratoren, die eine anonyme Zustellung per Default gar nicht erlauben, wie es bei Exchange 2007/2010 noch Default war, und daher einen eigenen SMTP-Receive Connector für die Annahme ohne Authentifizierung angelegt haben. Idealerweise legt man gleich zwei Connector an, um interne Einlieferer von den extern empfangenden Mails zu trennen. Dann können Sie auf dem internen Receive-Connector u.a. die IP-Adressliste getrennt verwalten und über das Messagetracking genau die Quellen anhand des Feldes "ConnectorID" filtern.

Hier der erste "Check", ob es denn solche Mails gibt.

Get-transportservice `
| get-messagetrackinglog `
   -source SMTP `
   -eventid receive `
   -start (get-date).adddays(-1) `
   -resultsize 1000 `
| ?($_.MessageInfo -eq "0cA: ")

Eine erste Sichtprobe hat mir gezeigt, dass diese Annahme wohl gültig sein könnte. Also habe ich das Skript etwas aufgebohrt, um mehrere Server abzufragen und dann die Daten gleich zu verarbeiten. Wenn Sie zu viele PowerShell-Pipelines verbinden, dann zickt Exchange und PowerShell manchmal etwas. Daher lege ich eine For-Schleife drum herum. Sie können beim "Get-TransportService" natürlich noch eine Beschränkung auf die aktiven Transportdienste einbauen oder Edge-Server ausschließen. Um die Datenmenge klein zu halten, kann ich auch die Clients und Subnetze filtern, die mich nicht interessieren um die Datenmenge zu reduzieren. Das sieht dann in etwa so aus:

$serverlist = Get-transportservice
foreach ($Server in $serverlist) {
   write-host "Processing Server $server";
   get-messagetrackinglog `
      -server $server `
      -source SMTP `
      -eventid receive `
      -start (get-date).adddays(-1) `
      -resultsize unlimited `
   | ?{ (  ($_.MessageInfo -eq "0cA: ") `
      -and ($_.OriginalClientIp -ne "192.168.100.4") `
      -and ($_.OriginalClientIp -notlike "192.168.105.*") `
      ) `
   } `
   | select Timestamp,OriginalClientIp,Sender,Messagesubject,{[string]$_.Recipients} `
   | export-csv `
      -path anonsmtpsender.csv `
      -encoding unicode `
      -NoTypeInformation `
      -append
}

Die resultierende Datenmenge ist natürlich je nach Größe ihrer Umgebung nicht zu unterschätzen. Ich habe hier auch schon mal mehrere hundert Megabyte CSV-Dateien generiert. In dem Fall musste ich dann aber noch den Faktor Zeit mit einbauen und habe pro Tag eine eigene CSV-Datei erstellt. Das ist in dem Codebeispiel nicht enthalten. Aber PowerShell hat trotz Pipeline sonst das Problem, dass der Hauptspeicher stark belastet wird.

Das gilt natürlich auch, wenn man hinterher versucht die CSV-Dateien mit Powershell zu lesen und z.B. mit "Group-Objekt" zusammenfassen will. Selbst mit der Angabe von "-NoElement" ist mir regelmäßig der Speicher ausgegangen.

Hier bin ich dann auf Power BI umgestiegen, mit dem ich auf dem Desktop auch viele CSV-Dateien einlesen und auswerten kann.

Leider ist so eine Auswertung mit "Testdaten" nicht wirklich beeindruckend. Wenn Sie aber bei Kunden mehrere hundert Megabyte CSV-Daten mal eben schnell in Power BI grafisch und vor allem interaktiv auswerten, dann bekommen die meisten Kunden schon Appetit auf mehr und denken sogar daran die Daten in eine Datenbank on Office 365 zu laden und mit Power BI online auszuwerten.