共用方式為

收取目錄和重新顯示目錄

  • 發行項

適用於：Exchange Server 2013

根據預設，Pickup 和 Replay 目錄存在於每個 Microsoft Exchange Server 2013 信箱伺服器或 Edge Transport Server 上。 您複製到 [收取] 或 [重新顯示] 目錄中，格式正確的電子郵件檔案會提交以供傳遞。 收取目錄是由系統管理員用來進行郵件流程測試，或是由必須建立及提交專屬郵件的應用程式所使用。 重新顯示目錄會接收來自外部閘道伺服器的郵件，而且可以用來重新提交系統管理員從 Exchange 伺服器的佇列中匯出的郵件。

電子郵件檔案的分析

標準 SMTP 電子郵件由「郵件信封」(Message Envelope) 和郵件內容組成。 訊息信封包含傳輸和傳遞訊息所需的資訊。 郵件內容包含統稱為 (「郵件標頭」) 的郵件標頭欄位和郵件內容。 RFC 2821 會說明郵件信封，而 RFC 2822 會說明郵件標頭。

當寄件者撰寫電子郵件並提交傳遞時，郵件會包含遵循 SMTP 標準所需的基本資訊，例如寄件者、收件者、郵件撰寫的日期和時間、選用的主旨行，以及選用的郵件內文。 這項資訊包含在訊息本身中，而且根據定義，會包含在訊息標頭中。

寄件者的訊息伺服器會使用在郵件標頭中找到的寄件者和收件者資訊，為郵件產生郵件信封，並將訊息傳輸至網際網路，以傳遞至收件者的訊息伺服器。 收件者永遠不會看到郵件信封，因為它是由訊息傳輸程式所產生，而且實際上不是郵件的一部分。

每部涉及訊息傳輸的伺服器，都可能會插入與伺服器角色相關的訊息標頭欄位，以將訊息或其他應用程式特定的訊息標頭欄位傳遞至訊息標頭。 當收件者使用電子郵件用戶端開啟郵件時，電子郵件用戶端會顯示來自郵件標頭的一些更相關資訊，例如寄件者、收件者和主旨以及訊息本文。

收取及重新顯示目錄如何處理郵件

在 Exchange 2013 中，Pickup 目錄的預設位置是 %ExchangeInstallPath%TransportRoles\Pickup 。 Replay 目錄的預設位置是 %ExchangeInstallPath%TransportRoles\Replay 。 複製到 Pickup 或 Replay 目錄的正確格式 .eml 訊息檔案會在下列步驟中處理以提交：

  1. 每隔五秒會檢查 Pickup 和 Replay 目錄是否有新的訊息檔案。 您無法修改此輪詢間隔。 您可以在Set-TransportService Cmdlet 上使用PickupDirectoryMaxMessagesPerMinute參數來調整訊息檔案處理的速率。 此參數會影響 Pickup 目錄和 Replay 目錄。 預設值為每分鐘 100 則訊息。 無法開啟的檔案會保留在 Pickup 目錄中，並在下次輪詢時重新評估。

  2. 系統會檢查 [取貨] 目錄中郵件檔案的限制，例如標頭大小上限和收件者數目上限。 根據預設，標頭大小上限為 64 KB (KB) ，而收件者的最大數目為 100。 您可以使用 Set-TransportService Cmdlet 來變更這些限制。 這些設定只會影響 Pickup 目錄。

  3. 檔案會從< filename.eml >重新命名為< filename.tmp >。 < 如果 filename.tmp >檔案已經存在，檔案會重新命名為< filename >< datetime.tmp >。 如果檔案重新命名失敗，就會產生事件記錄檔錯誤，而取貨程式會繼續進行到下一個檔案。

  4. 成功將 .tmp 檔案轉換成電子郵件訊息之後，關閉 時的刪除 命令就會發出至 .tmp 檔案。 .tmp 檔案似乎保留在 Pickup 目錄中，但無法開啟檔案。

  5. 成功將訊息排入佇列以進行傳遞之後，會發出 關閉 命令，並從 Pickup 目錄中刪除 .tmp 檔案。 如果刪除失敗，就會產生事件記錄檔錯誤。 如果在 Pickup 目錄中有 .tmp 檔案時重新開機 Microsoft Exchange Transport Service，則所有 .tmp 檔案都會重新命名為 .eml 檔案，並重新處理。 這可能會導致重複的訊息傳輸。

收取目錄郵件檔案需求

複製到收取目錄的郵件檔案必須符合下列需求才能成功傳遞：

  • 訊息檔案必須是符合基本 SMTP 訊息格式的文字檔。 支援 MIME 訊息標頭欄位和內容。

  • 郵件檔案的副檔名必須為 .eml。

  • 郵件標頭的 Sender 或 From 訊息標頭欄位中至少必須有一個電子郵件地址。 如果 和 From 欄位都 Sender 存在單一電子郵件地址，欄位中 From 的電子郵件地址會當做郵件信封中訊息的來源。

  • 欄位中 Sender 只能有一個電子郵件地址。 不允許多個電子郵件地址。 如果欄位中 From 只有一個電子郵件地址，則 Sender 欄位是選擇性的。

  • 欄位中 From 允許多個電子郵件地址，但欄位中 Sender 也必須有單一電子郵件地址。 然後， Sender 欄位中的位址會作為訊息信封中訊息的來源。

  • 、 或 Bcc 欄位中 ToCc 至少必須有一個電子郵件地址。

  • 郵件標頭與郵件內文之間必須有一行空白行。

以下是純文字郵件的範例，該郵件使用收取目錄可接受的格式。

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

This is the body of the message.

Pickup 目錄訊息檔案也支援 MIME 內容。 MIME 定義了廣泛的訊息內容，其中包含無法以 7 位 ASCII 文字、HTML 和其他多媒體內容表示的語言。 MIME 及其需求的完整描述已超出本主題的範圍。 此範例顯示簡單的 MIME 訊息，該訊息會針對 Pickup 目錄使用可接受的格式設定。

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>

收取目錄郵件標頭修改

收取目錄會從郵件標頭移除以下任何的郵件標頭欄位：

  • Received

  • Resent-*

  • Bcc

    注意事項

    在郵件標頭中選擇性 Bcc 郵件標頭欄位中找到的任何電子郵件地址都會正確處理。 將 Bcc 收件者升階為不可見的郵件信封收件者之後，會從郵件標頭中移除這些收件者，以保護其身分識別。 如果郵件只 Bcc 包含收件者，[ 未公開的收件者 ] 的值會新增至 To 訊息標頭中的 欄位。

Pickup 目錄會在訊息提交程式中，將自己的 Received 標頭欄位新增至訊息。 標 Received 頭欄位會以下列格式套用。

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

收取目錄會修改下列郵件標頭欄位 (如果遺失或格式錯誤的話)：

  • Message-Id：如果 Message-Id 欄位遺失或空白，Pickup 目錄會使用GUID > defaultdomain 格式 < 來新增Message-Id欄位。><@

  • 日期：如果 Date 欄位遺失或格式不正確，Pickup 目錄會新增 Pickup 目錄處理訊息的日期和時間。

重新顯示目錄郵件檔案需求

重新顯示目錄是用來重新提交匯出的 Exchange 郵件，以及接收來自外部閘道伺服器的郵件。 這些郵件都已針對重新顯示目錄格式化。 系統管理員或應用程式幾乎不需要使用 Replay 目錄來撰寫和提交新的訊息檔案。 Pickup 目錄應該用來建立和提交新的訊息檔案。

重新執行目錄訊息會大量使用 X 標頭。 X 標頭是使用者定義的非官方訊息標頭欄位，存在於訊息標頭中。 RFC 2822 中並未特別提及 X 標頭，但使用以 「X-」 開頭的未定義訊息標頭欄位，已成為將非官方訊息標頭欄位新增至訊息的可接受方式。 Replay 目錄中訊息檔案中使用的 Exchange 特定 X 標頭，實際上可以設定通常存在於郵件信封中的傳遞資訊。 當您使用 Replay 目錄處理從另一部 Exchange 伺服器匯出的訊息時，需要這項功能才能保留原始訊息資訊。

複製至重新顯示目錄的郵件檔必須符合下列需求，才能順利傳遞：

  • 訊息檔案必須是符合基本 SMTP 訊息格式的文字檔。 支援 MIME 訊息標頭欄位和內容。

  • 郵件檔案的副檔名必須為 .eml。

  • X-Header 必須放在所有標準標頭欄位之前。

  • 標頭欄位與郵件內文之間必須有一行空白行。

重新顯示目錄中的郵件需要下列清單描述的 X-Header：

  • X-Sender：此 X 標頭會 From 取代一般 SMTP 訊息中的訊息標頭欄位需求。 一個 X-Sender 包含一個電子郵件地址的欄位必須存在。 如果郵件標頭欄位存在，則 Replay 目錄會忽略 From 該欄位，不過收件者的電子郵件用戶端會將郵件標頭欄位的 From 值顯示為郵件的寄件者。 欄位中 X-Sender 通常會存在其他參數，如下列範例所示。

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

    注意事項

    這些參數是通常由傳送伺服器產生的訊息信封值。 您可能會在匯出的訊息檔案中看到與此類似的參數。

    RET 指定如果無法傳遞訊息，應該將整個訊息或只有標頭傳回給寄件者。 RET 的值可以是 HDRS 或 FULL 。 ENVID 是訊息信封識別碼。 BODY 指定訊息的文字編碼方式。 auth 指定傳訊伺服器的驗證機制，如 RFC 2554 中所述。

  • X-Receiver：此 X 標頭會 To 取代一般 SMTP 訊息中的訊息標頭欄位需求。 至少必須有一個 X-Receiver 包含一個電子郵件地址的欄位存在。 多個 X-Receiver 收件者可以使用多個欄位。 如果郵件標頭欄位存在，則 Replay 目錄會忽略 To 這些欄位，不過收件者的電子郵件用戶端會將郵件頭欄位的值 To 顯示為郵件的收件者。 欄位中 X-Receiver 可能存在其他選擇性參數，如下列範例所示。

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

    注意事項

    這些參數是通常由傳送伺服器產生的訊息信封值。 您可能會在匯出的訊息檔案中看到與此類似的參數。 這些參數與傳遞狀態通知 (DSN) 訊息相關，如 RFC 1891 中所述。

    NOTIFY 的值可以是 NEVER 、 DELAY 或 FAILURE 。 ORcpt 會保留郵件的原始收件者。

重新顯示目錄中的郵件檔可以選用下列清單描述的 X-Header。

  • X-CreatedBy：用於標頭防火牆功能。 如果此 X 標頭存在，則不得為空白。 X-CreatedBy如果欄位不存在，則會以[未指定] 的值加以新增。 此欄位的值通常是 MSExchange15，但也可能包含在傳送連接器上設定的非 SMTP 位址空間類型，例如 Notes。

  • X-EndOfInjectedXHeaders：所有 X 標頭的位元組大小。 這個 X 標頭可以用來做為標記，以指出在一般訊息標頭欄位開始之前的最後一個 X 標頭。

  • X-ExtendedMessageProps：訊息的擴充訊息屬性。

  • X-HeloDomain：初始 SMTP 通訊協定交談期間呈現的 HELO/EHLO 網域字串。

  • X-Source：由佇列檢視器在 MessageSourceName 資料行下使用。 如果未指定此 X 標頭的值，則會使用 Replay 的值。 此 X 標頭的其他可能值為 Smtp 接收連接器 和 Smtp 傳送連接器。

  • X-SourceIPAddress：傳送伺服器的 IP 位址。 如果未指定任何 IP 位址，則此欄位為 0.0.0.0 。

以下是純文字郵件的範例，該郵件使用重新顯示目錄可接受的格式。

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.

重新執行目錄訊息檔案也支援 MIME 內容。 MIME 定義了廣泛的訊息內容，其中包含無法以 7 位 ASCII 文字、HTML 和其他多媒體內容表示的語言。 MIME 及其需求的完整描述已超出本主題的範圍。 此範例顯示使用 Replay 目錄可接受格式設定的簡單 MIME 訊息。

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>

重新顯示目錄郵件標頭修改

Replay 目錄會 Bcc 從訊息檔案中刪除訊息標頭欄位。

Replay 目錄會將自己的 Received 訊息標頭欄位新增至訊息，作為訊息提交程式的一部分。 [已接收的訊息標頭] 欄位會以下列格式套用。

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

重新顯示目錄會在郵件標頭中修改下列郵件標頭欄位：

  • 訊息標識符：如果此訊息標頭欄位遺失或空白，則 Replay 目錄會使用GUID > defaultdomain 格式 < 來新增 Message-ID 訊息標頭欄位。><@

  • 日期：如果此訊息標頭欄位遺失或格式不正確，Replay 目錄會使用 Replay 目錄處理訊息的日期和時間來新增日期訊息標頭欄位。

收取及重新顯示目錄郵件處理失敗

複製到 Pickup 或 Replay 目錄的訊息檔案可能不會成功排入佇列以進行傳遞。 可能會發生下列類別的訊息提交失敗：

  • 傳遞失敗：格式正確的訊息檔案以及無法成功提交傳遞的有效寄件者，會產生非傳遞報告 (NDR) 。 格式不正確的內容或取貨目錄訊息限制違規也可能導致 NDR。 在訊息處理期間產生 NDR 時，原始訊息檔案會附加至 NDR 訊息，而訊息檔案會從 Pickup 目錄或 Replay 目錄中刪除。

    注意事項

    提交至傳輸管線的正確格式化訊息之後可能會發生傳遞失敗，並傳回給具有 NDR 的寄件者。 這種失敗可能是因為與 Pickup 或 Replay 目錄無關的傳輸問題所造成，例如訊息傳遞路徑上的傳訊伺服器失敗或路由失敗。

  • Badmail：分類為 badmail 的郵件有嚴重的問題，導致 Pickup 或 Replay 目錄無法提交訊息以進行傳遞。 造成錯誤郵件的另一個條件是當郵件格式正確，但收件者無效，而且 NDR 訊息無法傳送至寄件者，因為寄件者無效。

    判斷為 badmail 的郵件檔案會保留在 Pickup 或 Replay 目錄中，並從< filename.eml >重新命名為< filename.bad >。 < 如果 filename.bad >檔案已經存在，檔案會重新命名為< filename >< datetime.bad >。 如果 Badmail 存在於 Pickup 或 Replay 目錄中，則會產生事件記錄檔錯誤，但相同的錯誤訊息不會產生重複的事件記錄檔錯誤。

    注意事項

    在您將訊息檔案複製到 Pickup 目錄以進行傳遞之前，請務必先在不同的位置撰寫並儲存訊息檔案。 Pickup 目錄每隔五秒輪詢一次新的訊息。 因此，如果您嘗試在 Pickup 目錄本身撰寫並儲存訊息檔案，Pickup 目錄可能會在完成撰寫訊息檔案之前嘗試處理這些訊息檔案。

收取及重新顯示目錄的安全性考量

下列清單描述收取目錄及重新顯示目錄常用的安全性考量：

  • 在接收連接器上設定的任何安全性檢查 (例如反垃圾郵件、反惡意程式碼、寄件者篩選，或是收件者篩選動作) 都不會針對透過收取目錄或重新顯示目錄提交的郵件執行。

  • 遭入侵的 Pickup 目錄或重新執行目錄可以作為開啟的轉送。 這可讓訊息重新提交或 轉送 ，方法是使用不同的伺服器來遮罩訊息的實際來源。

下列清單描述適用於重新顯示目錄的安全性考量：

  • Replay 目錄所使用的 X 標頭允許手動建立訊息信封。 和 欄位中 X-SenderX-Receiver 的資訊可以與電子郵件用戶端所顯示的 To 或 From 訊息標頭欄位完全不同。 這類對寄件者和網域的模擬通常稱為 詐騙。 詐騙郵件是一個電子郵件訊息，其傳送位址已修改為顯示，就像是來自訊息實際寄件者以外的寄件者一樣。

  • 如果字 X-CreatedBy 段的值為 MSExchange15，則目的地會被視為值得信任，而且不會套用標頭防火牆。 標頭防火牆 可讓 Exchange 在信任的 Exchange 伺服器之間傳輸的訊息中保留 X 標頭，或從傳輸至 Exchange 組織外部不受信任目的地的訊息中移除可能顯示的 X 標頭。 這些 X 標頭可用來共用 Exchange 資訊，例如垃圾郵件信賴等級 (SCL) 、訊息簽署或授權 Exchange 伺服器之間的加密。 向未經授權的來源揭露這項資訊可能會造成潛在的安全性風險。 如需標頭防火牆的詳細資訊，請參閱 瞭解標頭防火牆。

由於與 Replay 目錄相關聯的其他安全性風險，因此應該將更嚴格的安全性套用至 Replay 目錄。 必須產生和提交訊息的使用者或應用程式可以被授與 Pickup 目錄的存取權，但他們不應該需要重新執行目錄的存取權。

在所有信箱伺服器和 Edge Transport Server 上，預設都會啟用 Pickup 目錄和 Replay 目錄。 如果您的組織中的特定信箱伺服器或 Edge Transport 伺服器不需要 Pickup 目錄或 Replay 目錄，您可以將 Pickup 目錄路徑或重新執行目錄路徑設定為值 $null ，以停用該伺服器上的 Pickup 目錄或 Replay 目錄。 如需詳細資訊， 請參閱設定 Pickup 目錄和重新執行目錄。

收取及重新顯示目錄的權限

收取和重新顯示目錄需要下列權限：

  • 系統管理員：完全控制

  • 系統：完全控制

  • 網路服務：讀取、寫入和刪除子資料夾和檔案

根據預設，Microsoft Exchange Transport Service 會使用網路服務使用者帳戶的安全性認證來管理 Pickup 和 Replay 目錄的位置和許可權。 網路服務帳戶需要 Pickup 目錄的這些許可權，才能開啟 .eml 檔案、重新命名為 .tmp 並刪除，或在郵件分類為 badmail 時重新命名為 .bad。

您可以使用Set-TransportService Cmdlet 上的PickupDirectoryPath和ReplayDirectoryPath參數來移動這些目錄的位置。 成功變更 Pickup 目錄的位置取決於授與新目錄位置之網路服務帳戶的許可權，以及新目錄是否已存在。 如果目錄不存在，且網路服務帳戶具有在新位置建立資料夾和套用許可權所需的許可權，則會建立目錄，並套用正確的許可權。 如果新目錄已經存在，則不會檢查現有的資料夾許可權。 每當您使用 PickupDirectoryPath 或 ReplayDirectoryPath 參數搭配 Set-TransportService Cmdlet 來移動目錄位置時，請一律確認新目錄存在，而且新目錄已套用正確的許可權。