Teilen über


PICKUP-Verzeichnis und Wiedergabeverzeichnis

Gilt für: Exchange Server 2013

Das PICKUP-Verzeichnis und das Wiedergabeverzeichnis sind standardmäßig auf jedem Microsoft Exchange Server 2013-Postfachserver oder Edge-Transport-Server vorhanden. Ordnungsgemäß formatierte E-Mails, die in das PICKUP- oder Wiedergabeverzeichnis kopiert werden, werden zur Zustellung übermittelt. Das PICKUP-Verzeichnis wird von Administratoren zum Testen der Nachrichtenübermittlung oder von Anwendungen verwendet, die ihre eigenen Nachrichten erstellen und senden müssen. Das Wiedergabeverzeichnis empfängt Nachrichten von fremden Gatewayservern und kann dazu verwendet, Nachrichten erneut zu übermitteln, die von Administratoren aus den Warteschlangen von Exchange-Servern exportiert werden.

Aufbau einer E-Mail-Datei

Eine standardmäßige SMTP-E-Mail besteht aus einem Nachrichten-Envelope und dem Nachrichteninhalt. Der Nachrichten-Envelope enthält Informationen, die für die Übermittlung und Zustellung der Nachricht erforderlich sind. Der Nachrichteninhalt enthält Nachrichtenkopffelder (zusammenfassend als Nachrichtenkopf bezeichnet) sowie den Nachrichtentext. Der Nachrichten-Envelope wird in RFC 2821 und der Nachrichtenkopf in RFC 2822 beschrieben.

Wenn ein Absender eine E-Mail-Nachricht verfasst und zur Zustellung übermittelt, enthält die Nachricht die grundlegenden Informationen, die zur Einhaltung der SMTP-Standards erforderlich sind, z. B. einen Absender, einen Empfänger, das Datum und die Uhrzeit der Erstellung der Nachricht, eine optionale Betreffzeile und einen optionalen Nachrichtentext. Diese Informationen sind in der Nachricht selbst enthalten und sind definitionsgemäß im Nachrichtenheader enthalten.

Der Messagingserver des Absenders generiert aus den Absender- und Empfängerinformationen des Nachrichtenkopfes einen Nachrichten-Envelope für die Nachricht und übermittelt diese dann an das Internet zur Zustellung an den Messagingserver des Empfängers. Empfänger bekommen den Nachrichten-Envelope nicht angezeigt, da er vom Nachrichtenübermittlungsprozess generiert wird und nicht tatsächlicher Bestandteil der Nachricht ist.

Jeder Server, der an der Übermittlung der Nachricht beteiligt ist, kann Nachrichtenkopffelder in die Nachricht einfügen, die mit der Funktion des Servers bei der Zustellung der Nachricht oder anderer anwendungsspezifischer Nachrichtenkopffelder in die Nachricht in Zusammenhang stehen. Wenn der Empfänger die Nachricht mit einem E-Mail-Client öffnet, zeigt dieser einige der relevanteren Informationen aus dem Nachrichtenkopf an, beispielsweise den Absender, die Empfänger und den Betreff zusammen mit dem Nachrichtentext.

Verarbeitung von Nachrichten im PICKUP- und im Wiedergabeverzeichnis

In Exchange 2013 ist %ExchangeInstallPath%TransportRoles\Pickupder Standardspeicherort des Pickup-Verzeichnisses . Der Standardspeicherort des Replay-Verzeichnisses ist %ExchangeInstallPath%TransportRoles\Replay. Eine ordnungsgemäß formatierte EML-Nachrichtendatei, die in das PICKUP- oder Wiedergabeverzeichnis kopiert wurde, wird anhand der folgenden Schritte für die Übermittlung verarbeitet:

  1. Das PICKUP- und das Wiedergabeverzeichnis werden alle fünf Sekunden auf neue Nachrichtendateien überprüft. Dieses Abfrageintervall kann nicht geändert werden. Sie können die Verarbeitungsrate der Nachrichtendatei mithilfe des Parameters PickupDirectoryMaxMessagesPerMinute im Cmdlet Set-TransportService anpassen. Dieser Parameter wirkt sich auf das PICKUP-Verzeichnis und das Wiedergabeverzeichnis aus. Der Standardwert beträgt 100 Nachrichten pro Minute. Dateien, die nicht geöffnet werden können, verbleiben im PICKUP-Verzeichnis und werden beim nächsten Abfrageintervall erneut ausgewertet.

  2. Es wird auf Beschränkungen geprüft, die für Nachrichtendateien im PICKUP-Verzeichnis gelten, z. B. die maximale Kopfzeilengröße und die maximale Anzahl von Empfängern. Standardmäßig beträgt die maximale Kopfzeilengröße 64 KB, und die maximale Empfängeranzahl ist auf 100 festgelegt. Sie können diese Grenzwerte mithilfe des Cmdlets Set-TransportService ändern. Diese Einstellungen betreffen nur das PICKUP-Verzeichnis.

  3. Die Datei wird von <filename.eml> in <filename.tmp> umbenannt. Wenn die <Datei "filename.tmp>" bereits vorhanden ist, wird die Datei in <"filename><datetime.tmp>" umbenannt. Schlägt das Umbenennen der Datei fehl, wird ein Fehler im Ereignisprotokoll generiert, und der PICKUP-Prozess geht zur nächsten Datei über.

  4. Nachdem die TMP-Datei erfolgreich in eine E-Mail konvertiert wurde, wird ein delete on close -Befehl an die TMP-Datei ausgegeben. Die TMP-Datei scheint im PICKUP-Verzeichnis zu verbleiben, kann aber nicht geöffnet werden.

  5. Nachdem die Nachricht erfolgreich zur Zustellung in die Warteschlange eingereiht wurde, wird ein close -Befehl ausgegeben, und die TMP-Datei wird aus dem PICKUP-Verzeichnis gelöscht. Schlägt der Löschvorgang fehl, wird ein Fehler im Ereignisprotokoll generiert. Wird der Microsoft Exchange-Transportdienst neu gestartet, während sich noch TMP-Dateien im PICKUP-Verzeichnis befinden, werden alle TMP-Dateien in EML-Dateien umbenannt und erneut verarbeitet. Dadurch kann es zu doppelten Nachrichtenübertragungen kommen.

Voraussetzungen für eine Nachrichtendatei im PICKUP-Verzeichnis

Eine Nachrichtendatei, die in das PICKUP-Verzeichnis kopiert wird, muss die folgenden Voraussetzungen erfüllen, damit eine erfolgreiche Zustellung gewährleistet ist:

  • Die Nachrichtendatei muss eine Textdatei sein, die dem grundlegenden SMTP-Nachrichtenformat entspricht. Felder und Inhalt von MIME-Nachrichtenköpfen werden nicht unterstützt.

  • Die Nachrichtendatei muss die Dateinamenerweiterung .eml aufweisen.

  • Mindestens eine E-Mail-Adresse muss in den Sender Nachrichtenkopffeldern oder From im Nachrichtenkopf vorhanden sein. Wenn eine einzelne E-Mail-Adresse in den Sender Feldern und From vorhanden ist, wird die E-Mail-Adresse im From Feld als Absender der Nachricht im Nachrichtenumschlag verwendet.

  • Im Feld kann nur eine E-Mail-Adresse vorhanden sein Sender . Mehrere E-Mail-Adressen sind nicht zulässig. Das Sender Feld ist optional, wenn nur eine E-Mail-Adresse im From Feld vorhanden ist.

  • Mehrere E-Mail-Adressen sind im From Feld zulässig, aber auch eine einzelne E-Mail-Adresse muss im Sender Feld vorhanden sein. Die Adresse im Sender Feld wird dann als Absender der Nachricht im Nachrichtenumschlag verwendet.

  • In den ToFeldern , Ccoder Bcc muss mindestens eine E-Mail-Adresse vorhanden sein.

  • Nachrichtenkopf und Nachrichtentext müssen durch eine Leerzeile getrennt sein.

Dieses Beispiel zeigt eine Nur-Text-Nachricht, die eine akzeptable Formatierung für das PICKUP-Verzeichnis verwendet.

To: mary@contoso.com
From: bob@fabrikam.com
Subject: Message subject

This is the body of the message.

In Nachrichtendateien des PICKUP-Verzeichnisses werden auch MIME-Inhalte unterstützt. MIME definiert eine breite Palette von Nachrichteninhalten, wozu auch Sprachen gehören, die nicht als 7-Bit-ASCII-Text darstellbar sind, sowie HTML und andere Multimediainhalte. Eine vollständige Beschreibung von MIME und den für diesen Standard geltenden Voraussetzungen würde den Rahmen dieses Themas jedoch sprengen. Dieses Beispiel zeigt eine einfache MIME-Nachricht, die eine akzeptable Formatierung für das PICKUP-Verzeichnis verwendet.

To: mary@contoso.com
From: bob@fabrikam.com
Subject: Message subject
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<HTML><BODY>
<TABLE>
<TR><TD>cell 1</TD><TD>cell 2</TD></TR>
<TR><TD>cell 3</TD><TD>cell 4</TD></TR>
</TABLE>

</BODY></HTML>

Nachrichtenkopfänderungen im PICKUP-Verzeichnis

Das PICKUP-Verzeichnis entfernt die folgenden Felder aus dem Nachrichtenkopf:

  • Received

  • Resent-*

  • Bcc

    Hinweis

    Alle E-Mail-Adressen, die in den optionalen Bcc Nachrichtenkopffeldern im Nachrichtenkopf gefunden werden, werden ordnungsgemäß verarbeitet. Nachdem die Bcc Empfänger zu unsichtbaren Nachrichtenumschlagempfängern heraufgestuft wurden, werden sie aus dem Nachrichtenheader entfernt, um ihre Identität zu schützen. Wenn eine Nachricht nur Bcc Empfänger enthält, wird dem Feld im Nachrichtenkopf der To Wert von Nicht offengelegte Empfänger hinzugefügt.

Das Pickup-Verzeichnis fügt einer Nachricht im Rahmen des Nachrichtenübermittlungsprozesses ein eigenes Received Kopfzeilenfeld hinzu. Das Received Headerfeld wird im folgenden Format angewendet.

Received: from localhost by Pickup with Microsoft SMTP Server id <ExchangeServerVersion><datetime>

Das PICKUP-Verzeichnis ändert die folgenden Nachrichtenkopffelder, falls diese fehlen oder fehlerhaft sind:

  • Meldungs-ID: Wenn das Message-Id Feld fehlt oder leer ist, fügt das Pickup-Verzeichnis ein Message-Id Feld im Format <GUID>@<defaultdomain> hinzu.

  • Datum: Wenn das Date Feld fehlt oder falsch formatiert ist, fügt das Pickup-Verzeichnis das Datum und die Uhrzeit der Nachrichtenverarbeitung durch das Pickup-Verzeichnis hinzu.

Voraussetzungen für eine Nachrichtendatei im Wiedergabeverzeichnis

Das Replay-Verzeichnis wird verwendet, um exportierte Exchange-Nachrichten erneut zu übermitteln und Nachrichten von fremden Gateway-Servern zu empfangen. Diese Nachrichten sind bereits für das Replay-Verzeichnis formatiert. Administratoren oder Anwendungen müssen nur wenig oder gar keine neuen Nachrichtendateien über das Replay-Verzeichnis erstellen und übermitteln. Das Pickup-Verzeichnis sollte zum Erstellen und Übermitteln neuer Nachrichtendateien verwendet werden.

Bei den Nachrichten im Wiedergabeverzeichnis werden in hohem Maße X-Header verwendet. X-Header sind benutzerdefinierte, inoffizielle Nachrichtenkopffelder, die im Nachrichtenkopf vorhanden sind. X-Header werden in RFC 2822 nicht speziell erwähnt, die Verwendung eines nicht definierten Nachrichtenkopffelds, das mit "X-" beginnt, ist jedoch mittlerweile ein anerkannter Weg, um einer Nachricht inoffizielle Nachrichtenkopffelder hinzuzufügen. Die Exchange-spezifischen X-Header, die in Nachrichtendateien im Wiedergabeverzeichnis verwendet werden, können Zustellinformationen festlegen, die normalerweise im Nachrichten-Envelope vorhanden sind. Dieses Feature ist erforderlich, um ursprüngliche Nachrichteninformationen zu erhalten, wenn Sie das Wiedergabeverzeichnis zum Verarbeiten von Nachrichten verwenden, die von einem anderen Exchange-Server exportiert wurden.

Eine Nachrichtendatei, die in das Wiedergabeverzeichnis kopiert wird, muss die folgenden Voraussetzungen erfüllen, damit eine erfolgreiche Zustellung gewährleistet ist:

  • Die Nachrichtendatei muss eine Textdatei sein, die dem grundlegenden SMTP-Nachrichtenformat entspricht. Felder und Inhalt von MIME-Nachrichtenköpfen werden nicht unterstützt.

  • Die Nachrichtendatei muss die Dateinamenerweiterung .eml aufweisen.

  • X-Kopfzeilen müssen vor allen anderen regulären Kopfzeilenfeldern stehen.

  • Der Nachrichtentext muss durch eine Leerzeile von den Kopfzeilenfeldern getrennt sein.

Die in der folgenden Liste beschriebenen X-Header sind für Nachrichten im Wiedergabeverzeichnis erforderlich:

  • X-Sender: Dieser X-Header ersetzt die Anforderung des From Nachrichtenkopffelds in einer typischen SMTP-Nachricht. Ein X-Sender Feld, das eine E-Mail-Adresse enthält, muss vorhanden sein. Das Replay-Verzeichnis ignoriert das From Nachrichtenkopffeld, wenn es vorhanden ist, obwohl der E-Mail-Client des Empfängers den Wert des From Nachrichtenkopffelds als Absender der Nachricht anzeigt. In der X-Sender Regel sind im Feld andere Parameter vorhanden, wie im folgenden Beispiel gezeigt.

    X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>
    

    Hinweis

    Diese Parameter sind Nachrichten-Envelopewerte, die normalerweise vom sendenden Server generiert werden. Möglicherweise finden Sie in exportierten Nachrichtendateien Parameter vor, die diesen ähnlich sind.

    RET gibt an, ob die gesamte Nachricht oder nur die Kopfzeilen an den Absender zurückgegeben werden sollen, wenn die Nachricht nicht zugestellt werden kann. RET kann den Wert HDRS oder FULLhaben. ENVID ist ein Nachrichten-Envelopebezeichner. BODY gibt die Textcodierung der Nachricht an. auth gibt dem Messagingserver einen Authentifizierungsmechanismus an, wie in RFC 2554 beschrieben.

  • X-Receiver: Dieser X-Header ersetzt die Anforderung des To Nachrichtenheadersfelds in einer typischen SMTP-Nachricht. Es muss mindestens ein X-Receiver Feld vorhanden sein, das eine E-Mail-Adresse enthält. Mehrere X-Receiver Felder sind für mehrere Empfänger zulässig. Das Replay-Verzeichnis ignoriert die To Nachrichtenkopfzeilenfelder, wenn sie vorhanden sind, obwohl der E-Mail-Client des Empfängers die Werte der To Nachrichtenkopffelder als Empfänger der Nachricht anzeigt. In den X-Receiver Feldern können weitere optionale Parameter vorhanden sein, wie im folgenden Beispiel gezeigt.

    X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
    

    Hinweis

    Diese Parameter sind Nachrichten-Envelopewerte, die normalerweise vom sendenden Server generiert werden. Möglicherweise finden Sie in exportierten Nachrichtendateien Parameter vor, die diesen ähnlich sind. Diese Parameter stehen in Zusammenhang mit DSN-Nachrichten (Delivery Status Notification, Benachrichtigung über den Übermittlungsstatus), wie in RFC 1891 beschrieben.

    NOTIFY kann den Wert NEVER, DELAYoder FAILUREhaben. ORcpt behält den ursprünglichen Empfänger der Nachricht bei.

Die in der folgenden Liste beschriebenen X-Header sind für Nachrichtendateien im Wiedergabeverzeichnis optional:

  • X-CreatedBy: Wird für Headerfirewallfunktionen verwendet. Wenn diese X-Kopfzeile vorhanden ist, darf sie nicht leer sein. Wenn das X-CreatedBy Feld nicht vorhanden ist, wird es mit dem Wert Nicht angegeben hinzugefügt. Normalerweise hat dieses Feld den Wert MSExchange15, es kann jedoch auch den für einen Sendeconnector festgelegten Nicht-SMTP-Adressraumtyp enthalten, beispielsweise Notes.

  • X-EndOfInjectedXHeaders: Größe aller vorhandenen X-Header in Bytes. Diese X-Kopfzeile kann zum Markieren der letzten X-Kopfzeile vor Beginn der regulären Nachrichtenkopffelder verwendet werden.

  • X-ExtendedMessageProps: Erweiterte Nachrichteneigenschaften für die Nachricht.

  • X-HeloDomain: HELO/EHLO-Domänenzeichenfolge, die während der ersten SMTP-Protokollkonversation angezeigt wird.

  • X-Source: Wird von Queue Viewer unter der Spalte MessageSourceName verwendet. Wenn der Wert dieser X-Kopfzeile nicht angegeben ist, wird der Wert Replay verwendet. Andere mögliche Werte für diese X-Kopfzeile sind Smtp Receive Connector und Smtp Send Connector.

  • X-SourceIPAddress: IP-Adresse des sendenden Servers. Dieses Feld ist 0.0.0.0 , wenn keine IP-Adresse angegeben ist.

Dieses Beispiel zeigt eine Nur-Text-Nachricht, die eine akzeptable Formatierung für das Wiedergabeverzeichnis verwendet.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@fabrikam.com> BODY=7bit ENVID=12345AB auth=<someAuth>
Subject: Optional message subject

This is the body of the message.

In Nachrichtendateien des Wiedergabeverzeichnisses werden auch MIME-Inhalte unterstützt. MIME definiert eine breite Palette von Nachrichteninhalten, wozu auch Sprachen gehören, die nicht als 7-Bit-ASCII-Text darstellbar sind, sowie HTML und andere Multimediainhalte. Eine vollständige Beschreibung von MIME und den für diesen Standard geltenden Voraussetzungen würde den Rahmen dieses Themas jedoch sprengen. Dieses Beispiel zeigt eine einfache MIME-Nachricht, die eine akzeptable Formatierung für das Wiedergabeverzeichnis verwendet.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@fabrikam.com> BODY=7bit ENVID=12345ABCD auth=<someAuth>
To: mary@contoso.com
From: bob@fabrikam.com
Subject: Optional message subject
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<HTML><BODY>
<TABLE>
<TR><TD>cell 1</TD><TD>cell 2</TD></TR>
<TR><TD>cell 3</TD><TD>cell 4</TD></TR>
</TABLE>

</BODY></HTML>

Nachrichtenkopfänderungen im Wiedergabeverzeichnis

Das Wiedergabeverzeichnis löscht das Bcc Nachrichtenkopfzeilenfeld aus der Nachrichtendatei.

Das Wiedergabeverzeichnis fügt einer Nachricht im Rahmen des Nachrichtenübermittlungsprozesses ein eigenes Received Nachrichtenkopffeld hinzu. Das Received-Nachrichtenkopffeld wird im folgenden Format angewendet.

Received: from <ReceivingServerName> by Replay with <ExchangeServerVersion><DateTime>

Im Wiedergabeverzeichnis werden die folgenden Nachrichtenkopffelder im Nachrichtenkopf geändert:

  • Meldungs-ID: Wenn dieses Feld für den Nachrichtenkopf fehlt oder leer ist, fügt das Replay-Verzeichnis ein Nachrichtenkopfzeilenfeld message-ID im Format <GUID>@<defaultdomain> hinzu.

  • Datum: Wenn dieses Nachrichtenkopffeld fehlt oder falsch formatiert ist, fügt das Wiedergabeverzeichnis das Feld Datumsnachrichtenkopf unter Verwendung des Datums und der Uhrzeit der Nachrichtenverarbeitung durch das Wiedergabeverzeichnis hinzu.

Fehler beim Verarbeiten von Nachrichten im PICKUP- und Wiedergabeverzeichnis

Eine in das PICKUP- oder Wiedergabeverzeichnis kopierte Nachrichtendatei wird möglicherweise nicht erfolgreich für die Zustellung in die Warteschlange eingereiht. Die folgenden Kategorien für Nachrichtenübermittlungsfehler können auftreten:

  • Übermittlungsfehler: Eine ordnungsgemäß formatierte Nachrichtendatei zusammen mit einem gültigen Absender, der nicht erfolgreich zur Übermittlung übermittelt werden kann, generiert einen Nichtzustellbarkeitsbericht (Non-Delivery Report, NDR). Fehlerhafte Inhalte oder eine Verletzung der Nachrichteneinschränkungen für das PICKUP-Verzeichnis können ebenfalls dazu führen, dass ein Unzustellbarkeitsbericht generiert wird. Wenn während der Verarbeitung der Nachricht ein Unzustellbarkeitsbericht generiert wird, wird die ursprüngliche Nachrichtendatei an die Nachricht des Unzustellbarkeitsberichts angefügt und die Nachrichtendatei aus dem PICKUP-Verzeichnis oder Wiedergabeverzeichnis gelöscht.

    Hinweis

    Eine ordnungsgemäß formatierte Nachricht, die in die Transportpipeline übermittelt wurde, kann später einen Zustellungsfehler aufweisen und mit einem Unzustellbarkeitsbericht an den Absender zurückgesendet werden. Diese Art von Fehler kann durch Übertragungsprobleme hervorgerufen werden, die nichts mit dem PICKUP- oder Wiedergabeverzeichnis zu tun haben, etwa Messagingserverfehler oder Routingfehler im Zustellungspfad der Nachricht.

  • Badmail: Eine als badmail klassifizierte Nachricht weist schwerwiegende Probleme auf, die verhindern, dass das Pickup- oder Replay-Verzeichnis die Nachricht zur Zustellung übermittelt. Die zweite Bedingung, die zu einer Badmail führt, liegt vor, wenn die Nachricht richtig formatiert ist, jedoch ein ungültiger Empfänger vorliegt und kein Unzustellbarkeitsbericht an den Absender gesendet werden kann, da der Absender ungültig ist.

    Nachrichtendateien, die als badmail ermittelt wurden, verbleiben in den Verzeichnissen Pickup oder Replay und werden von <filename.eml> in <filename.bad> umbenannt. Wenn die <Datei filename.bad> bereits vorhanden ist, wird die Datei in <den Dateinamen><datetime.bad> umbenannt. Sind im PICKUP- oder Wiedergabeverzeichnis BadMailnachrichten vorhanden, wird ein Fehler im Ereignisprotokoll generiert, aber dieselben BadMailnachrichten generieren keine wiederholten Fehler im Ereignisprotokoll.

    Hinweis

    Erstellen und Speichern Sie Nachrichtendateien immer an einem anderen Ort, bevor Sie diese zur Zustellung in das PICKUP-Verzeichnis kopieren. Das PICKUP-Verzeichnis wird alle fünf Sekunden auf neue Nachrichten überprüft. Wenn Sie daher versuchen, die Nachrichtendateien im PICKUP-Verzeichnis selbst zu erstellen und zu speichern, versucht das PICKUP-Verzeichnis vielleicht, die Nachrichtendateien zu verarbeiten, bevor Sie mit dem Verfassen fertig sind.

Sicherheitsüberlegungen für das PICKUP- und das Wiedergabeverzeichnis

In der folgenden Liste werden Sicherheitsrisiken für das PICKUP- und Wiedergabeverzeichnis beschrieben:

  • Alle Sicherheitsüberprüfungen, die für einen Empfangsconnector konfiguriert sind, beispielsweise Antispam-, Antischadsoftware-, Absenderfilterungs- oder Empfängerfilterungsaktionen, werden nicht für Nachrichten ausgeführt, die über das PICKUP- oder das Wiedergabeverzeichnis übermittelt werden.

  • Ein kompromittiertes Pickup-Verzeichnis oder Replay-Verzeichnis kann als offenes Relay fungieren. Dadurch können Nachrichten erneut übermittelt oder weitergeleitet werden, indem ein anderer Server verwendet wird, um die wahre Quelle der Nachrichten zu maskieren.

In der folgenden Liste werden zusätzliche Sicherheitsrisiken für das Wiedergabeverzeichnis beschrieben:

  • Die vom Wiedergabeverzeichnis verwendeten X-Header lassen die manuelle Erstellung des Nachrichten-Envelopes zu. Die Informationen in den X-Sender Feldern und X-Receiver können sich vollständig von den Nachrichtenkopffeldern oder From unterscheiden, die To von E-Mail-Clients angezeigt werden. Ein solcher Identitätswechsel eines Absenders und einer Domäne wird häufig als Spoofing bezeichnet. Eine Spoof-E-Mail ist eine E-Mail, die eine Absenderadresse hat, die so geändert wurde, dass sie von einem anderen Absender als dem tatsächlichen Absender der Nachricht zu stammen scheint.

  • Wenn das X-CreatedBy Feld den Wert MSExchange15 aufweist, gilt das Ziel als vertrauenswürdig, und die Headerfirewall wird nicht angewendet. Die Kopfzeilenfirewall ist ein Verfahren für Exchange, die X-Header in Nachrichten zu erhalten, die zwischen vertrauenswürdigen Exchange-Servern übermittelt werden, oder potenziell verräterische X-Header aus Nachrichten zu entfernen, die an nicht vertrauenswürdige Ziele außerhalb der Exchange-Organisation übermittelt werden. Mithilfe dieser X-Header können Exchange-Informationen wie SCL-Bewertung (Spam Confidence Level), Nachrichtensignierung oder Verschlüsselung zwischen autorisierten Exchange-Servern freigegeben werden. Die Offenlegung solcher Informationen gegenüber nicht autorisierten Quellen kann ein potenzielles Sicherheitsrisiko darstellen. Weitere Informationen zur Kopfzeilenfirewall finden Sie unter Grundlegendes zur Kopfzeilenfirewall.

Auf das Wiedergabeverzeichnis sollten wegen der damit einhergehenden zusätzlichen Sicherheitsrisiken stärkere Sicherheitsmaßnahmen angewendet werden. Benutzern oder Anwendungen, die Nachrichten generieren und übermitteln müssen, kann der Zugriff auf das PICKUP-Verzeichnis gewährt werden, aber es sollte kein Zugriff auf das Wiedergabeverzeichnis erteilt werden.

Sowohl das PICKUP-Verzeichnis als auch das Wiedergabeverzeichnis sind auf allen Postfachservern und Edge-Transport-Servern standardmäßig aktiviert. Wenn das Pickup-Verzeichnis oder das Replay-Verzeichnis auf einem bestimmten Postfachserver oder Edge-Transport-Server in Ihrer Organisation nicht erforderlich ist, können Sie das Pickup-Verzeichnis oder das Wiedergabeverzeichnis auf diesem Server deaktivieren, indem Sie den Pickup-Verzeichnispfad oder den Pfad des Wiedergabeverzeichnisses auf den Wert $nullfestlegen. Weitere Informationen finden Sie unter Konfigurieren des PICKUP-Verzeichnisses und des Wiedergabeverzeichnisses.

Berechtigungen für das PICKUP- und das Wiedergabeverzeichnis

Die folgenden Berechtigungen sind für das PICKUP- und Wiedergabeverzeichnis erforderlich:

  • Administrator: Vollzugriff

  • System: Vollzugriff

  • Netzwerkdienst: Lesen, Schreiben und Löschen von Unterordnern und Dateien

Standardmäßig verwendet der Microsoft Exchange-Transportdienst die Sicherheitsanmeldeinformationen des Benutzerkontos des Netzwerkdiensts, um den Speicherort und die Berechtigungen der Verzeichnisse Pickup und Replay zu verwalten. Das Netzwerkdienstkonto erfordert diese Berechtigungen für das Pickup-Verzeichnis, damit EML-Dateien geöffnet, in TMP umbenannt und gelöscht oder in BAD umbenannt werden können, wenn die Nachricht als badmail klassifiziert ist.

Sie können den Speicherort dieser Verzeichnisse mithilfe der Parameter PickupDirectoryPath und ReplayDirectoryPath im Cmdlet Set-TransportService verschieben. Das erfolgreiche Ändern des Speicherorts für das PICKUP-Verzeichnis hängt von den Rechten ab, die dem Netzwerkdienstkonto an den neuen Verzeichnispositionen gewährt werden, und davon, ob die neuen Verzeichnisse bereits vorhanden sind. Wenn das Verzeichnis noch nicht vorhanden ist und das Netzwerkdienstkonto über die notwendigen Rechte zum Erstellen von Ordnern und Anwenden von Berechtigungen am neuen Speicherort verfügt, wird das neue Verzeichnis erstellt und die korrekten Berechtigungen darauf angewendet. Wenn das neue Verzeichnis bereits vorhanden ist, werden die vorhandenen Ordnerberechtigungen nicht überprüft. Wenn Sie die Verzeichnisspeicherorte mithilfe des Parameters PickupDirectoryPath oder ReplayDirectoryPath mit dem Cmdlet Set-TransportService verschieben, überprüfen Sie immer, ob das neue Verzeichnis vorhanden ist und dass das neue Verzeichnis über die richtigen Berechtigungen verfügt.