本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 使用組織 在 Amazon WorkMail 中，您的組織代表您公司的使用者。在 Amazon WorkMail 主控台中，您會看到可用組織的清單。如果您沒有任何可用的 ，您必須建立組織才能使用 Amazon WorkMail。 **Topics** + [建立組織](add_new_organization.md) + [刪除組織](delete_organization.md) + [尋找電子郵件地址](find-emails.md) + [使用組織設定](org-settings.md) + [標記組織](org-tag.md) + [使用存取控制規則](access-rules.md) + [設定信箱保留政策](mailbox-retention-policy.md) # 建立組織 若要使用 Amazon WorkMail，您必須先建立組織。一個 AWS 帳戶可以有多個 Amazon WorkMail 組織。建立組織時，您也可以為組織選取網域，並設定使用者目錄和加密設定。 您可以建立新的 Amazon WorkMail 目錄以與 WorkMail 組織搭配使用，或將 Amazon WorkMail 與現有目錄整合。您可以搭配下列類型的現有目錄使用 Amazon WorkMail： + 內部部署 Microsoft Active Directory + AWS Managed Active Directory ([由 AWS Directory Service 管理的 Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)) + Simple AD 透過與您的內部部署目錄整合，您可以在 Amazon WorkMail 中使用現有的使用者和群組，使用者可以使用其現有的登入資料登入。如果您使用的是內部部署目錄，您必須先在其中設定 AD Connector AWS Directory Service。AD Connector 會將您的使用者和群組與 Amazon WorkMail 通訊錄同步，並執行使用者身分驗證請求。如需詳細資訊，請參閱《 *Directory Service 管理指南*》中的 [Active Directory Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html)。 您也可以選擇 AWS KMS key Amazon WorkMail 用來加密信箱內容的 。您可以選取 Amazon WorkMail 的預設 AWS 受管主金鑰，或在 AWS Key Management Service () 中使用現有的 KMS 金鑰AWS KMS。如需有關建立新的 KMS 金鑰的資訊，請參閱《 *AWS Key Management Service 開發人員指南*》中的[建立金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)。如果您以 AWS Identity and Access Management (IAM) 使用者身分登入，請讓自己成為 KMS 金鑰的金鑰管理員。如需詳細資訊，請參閱《 *AWS Key Management Service 開發人員指南*》中的[啟用和停用金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html)。 **考量事項** 建立 Amazon WorkMail 組織時，請記住下列事項： + Amazon WorkMail 目前不支援您與多個帳戶共用的受管 Microsoft Active Directory 服務。 + 如果您有具有 Microsoft Exchange 和 AD Connector 的內部部署 Active Directory，建議您為組織設定互通性設定。這可讓您在將信箱遷移至 Amazon WorkMail 時將對使用者的干擾降至最低，或使用 Amazon WorkMail 做為公司信箱的子集。如需詳細資訊，請參閱[Amazon WorkMail 與 Microsoft Exchange 之間的互通性](interoperability.md)。 + 如果選取**免費測試網域**選項，您可以開始將 Amazon WorkMail 組織與提供的測試網域搭配使用。測試網域使用此格式： *example*.awsapps.com。只要您在 Amazon WorkMail 組織中維持已啟用的使用者，您就可以將測試郵件網域與 Amazon WorkMail 和其他支援的 AWS 服務搭配使用。不過，您無法將測試網域用於其他用途。如果您的 Amazon WorkMail 組織未維護至少一個已啟用的使用者，則測試網域可能可供其他客戶註冊和使用。 + Amazon WorkMail 不支援多區域目錄。 + Amazon WorkMail 每四小時同步目錄資料與 AWS Managed Active Directory、Simple AD 和 AD Connector。 ## 使用 AWS Managed Active Directory 的重要變更 Amazon WorkMail 正在為使用 AWS Managed Active Directory （受管 AD) 的組織更新其授權模型。此變更會影響 Amazon WorkMail 與目錄資料互動的方式，並要求您採取特定動作以確保持續功能。 先前，當使用 AWS Managed Active Directory 建立 Amazon WorkMail 組織時，Amazon WorkMail 會使用服務層級許可來與 Managed AD 互動。為了為客戶提供額外的彈性來分隔目錄管理和信箱管理角色，WorkMail APIs 和主控台現在將使用 AWS Directory Service Data (DS-Data) APIs 在 AWS Managed Active Directory 中建立或更新使用者和群組。透過 WorkMail 主控台或 APIs 執行這些操作的 IAM 主體還需要授權，才能針對與其 WorkMail 組織相關聯的 Managed AD 使用同等的 DS-Data 動作，從而提供更精細的控制，並與 IAM 政策更好地整合。 無論您是使用 Managed AD 建立新組織，還是擁有使用 Managed AD 的現有組織，如果您想要繼續透過 WorkMail 主控台或 APIs 建立、更新或刪除使用者和群組，您都必須完成額外的組態步驟，以確保使用更新的授權模型的適當功能。這會在 中說明[設定 AWS Managed Active Directory 整合](#configure-managed-ad-integration)。 **Topics** + [使用 AWS Managed Active Directory 的重要變更](#important-changes) + [建立組織](#create-organization) + [設定 AWS Managed Active Directory 整合](#configure-managed-ad-integration) + [檢視組織的詳細資訊](#view-org-details) + [整合 WorkSpaces 目錄](#compatible) + [組織狀態和說明](#org-states) ## 建立組織 在 Amazon WorkMail 主控台中建立新組織。 **建立組織** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱《》中的[區域和端點](https://docs.aws.amazon.com/general/latest/gr/rande.html)*Amazon Web Services 一般參考*。 1. 在導覽列中，選取**組織**。 組織****頁面隨即出現，如果有的話會顯示您的組織。 1. 選擇**建立組織**。 1. 在**電子郵件網域**下，選取要用於組織中電子郵件地址的網域： + ****現有 Route 53 網域**** – 選取您使用 Amazon Route 53 (Route 53) 託管區域管理的現有網域。 + ****新的 Route 53 網域**** – 註冊要與 Amazon WorkMail 搭配使用的新 Route 53 網域名稱。 + ****外部網域**** – 輸入您使用外部網域名稱系統 (DNS) 供應商管理的現有網域。 + ****免費測試網域**** – 使用 Amazon WorkMail 提供的免費測試網域。您可以使用測試網域探索 Amazon WorkMail，稍後再將網域新增至您的組織。 1. （選用） 如果您的網域是透過 Amazon Route 53 管理，請針對 **Route 53 託管區域**選取您的 Route 53 網域。 1. 針對**別名**，輸入組織的唯一別名。 1. 選擇**進階設定**，然後針對**使用者目錄**，選取下列其中一個選項： + **建立新的 Amazon WorkMail 目錄** – 建立新的目錄以新增和管理使用者。 + **使用現有目錄** – 使用現有目錄來管理您的使用者，例如內部部署 Microsoft Active Directory、 AWS 受管 Active Directory 或 Simple AD。 1. 針對**加密**，選取下列其中一個選項： + **使用 Amazon WorkMail 受管金鑰** – 在帳戶中建立新的加密金鑰。 + **使用現有的 KMS 金鑰** – 使用您已在 中建立的現有 KMS 金鑰 AWS KMS。 1. 選擇**建立組織**。 如果您使用外部網域，請將適當的文字 (TXT) 和郵件交換程式 (MX) 記錄新增至 DNS 服務來驗證它。TXT 記錄可讓您輸入有關 DNS 服務的備註。MX 記錄會指定傳入郵件伺服器。 請務必將網域設定為組織的預設值。如需詳細資訊，請參閱[驗證網域](domain_verification.md)及[選擇預設網域](default_domain.md)。 當您的組織處於**作用中**狀態時，您可以將使用者新增至其中，並設定其電子郵件用戶端。如需詳細資訊，請參閱[新增使用者](add_user.md)和[設定 Amazon WorkMail 的電子郵件用戶端](https://docs.aws.amazon.com/workmail/latest/userguide/clients.html)。 ## 設定 AWS Managed Active Directory 整合 將 AWS Managed Active Directory 與 Amazon WorkMail 組織搭配使用時，其他組態步驟可確保具有更新授權模型的適當功能。 **設定新組織的 Managed AD 整合** 1. 在 Directory Service 主控台中，導覽至 Managed AD (Microsoft AD)，或從 Amazon WorkMail 主控台選取左側導覽面板中的**使用者**或**群組**，然後按一下頁面頂端備註方塊中的目錄連結。 1. 選擇**啟用****使用者和群組管理**。此設定預設為停用，且必須啟用才能對使用者和群組執行寫入操作。 1. 使用下列動作連接政策，確保您的 IAM 主體具有必要的許可： ``` ds:AccessDSData ds:ResetUserPassword ds-data:CreateGroup ds-data:DeleteGroup ds-data:AddGroupMember ds-data:RemoveGroupMember ds-data:CreateUser ds-data:DeleteUser ds-data:UpdateUser ``` **遷移現有的 Managed AD 組織** 1. 監控 Amazon WorkMail 主控台中的使用者或群組頁面，以取得遷移通知。 1. 出現通知時，開啟**啟用更新的目錄操作**以遷移至新的 Directory Service APIs。 1. 最後，請確定您已在 Directory Service 主控台中啟用**使用者和群組管理**，並使用必要的 DS-Data 許可更新您的 IAM 政策，如上一節所述。 使用 AWS Directory Service Data (DS-Data) APIs 來建立、更新和刪除使用者，將針對任何使用 Managed AD 且先前尚未啟用的其餘 Amazon WorkMail 組織啟用。 ## 檢視組織的詳細資訊 每個 Amazon WorkMail 組織都可以顯示組織詳細資訊頁面。此頁面會顯示其組織的相關資訊，包括您可以搭配 IDs AWS Command Line Interface。頁面上的訊息也可以顯示完成設定和組織所需的任何步驟，例如未驗證的網域或缺少使用者。訊息也提供設定指定電子郵件用戶端時所遵循的第一個步驟。 **檢視組織詳細資訊** 1. 在導覽列中，選擇**組織**。 **組織**頁面隨即出現，並顯示您的組織。 1. 選擇您要檢視的組織。 ## 整合 WorkSpaces 目錄 若要將 Amazon WorkMail 與 WorkSpaces 搭配使用，請使用下列步驟建立相容的目錄。 **新增相容的 WorkSpaces 目錄** 1. 使用 WorkSpaces 建立相容的目錄。如需 WorkSpaces 說明，請參閱《[Amazon WorkSpaces 管理指南》中的 Amazon WorkSpaces 快速設定入門](https://docs.aws.amazon.com/workspaces/latest/adminguide/getting-started.html)。 *Amazon WorkSpaces * 1. 在 Amazon WorkMail 主控台中，建立您的 Amazon WorkMail 組織，並選擇使用您現有的目錄。如需詳細資訊，請參閱[建立組織](#create-organization)。 ## 組織狀態和說明 在您建立組織後，它可以有以下其中一個狀態。 **** | **州** | Description | | --- | --- | | **Active (作用中)** | 您的組織正常並已做好使用準備。 | | **正在建立** | 工作流程正在執行以建立您的組織。 | | **失敗** | 您的組織無法被建立。 | | **Impaired (受損)** | 您的組織故障或已偵測到問題。 | | **非作用中** | 您的組織失效。 | | **Requested (已請求)** | 您的組織在佇列中建立請求並等待建立。 | | **Validating** (驗證) | 組織的所有設定都被檢查運作狀態。 | # 刪除組織 如果您不想再將 Amazon WorkMail 用於組織的電子郵件，您可以從 Amazon WorkMail 中刪除組織。 **注意** 此操作無法復原。刪除組織後，您將無法復原信箱資料。 **刪除組織** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/rande.html)。 1. 在**組織**畫面上的組織清單中，選取要刪除的組織，然後選擇**刪除**。 1. 針對**刪除組織**，選擇是否刪除或保留現有的使用者目錄，然後輸入組織的名稱。 1. 選擇**刪除組織**。 **注意** 如果您沒有為 Amazon WorkMail 提供自己的目錄，我們會為您建立一個目錄。如果您在刪除組織時保留此現有目錄，除非 Amazon WorkMail、WorkDocs 或 WorkSpaces 正在使用它，否則您將需要支付費用。如需定價資訊，請參閱[其他目錄類型定價](https://aws.amazon.com/directoryservice/other-directories-pricing/)。 為了刪除目錄，它無法啟用任何其他 AWS 應用程式。如需詳細資訊，請參閱《 *AWS Directory Service 管理指南*》中的[刪除 Simple AD 目錄](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/simple_ad_delete.html)[或刪除 AD Connector 目錄](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_delete.html)。 當您嘗試刪除組織時，您可能會收到無效的 Amazon Simple Email Service (Amazon SES) 規則集錯誤訊息。如果您收到此錯誤，請在 Amazon SES 主控台中編輯 Amazon SES 規則，並移除無效的規則集。您編輯的規則在規則名稱中應該有您的 Amazon WorkMail 組織 ID。如需編輯 Amazon SES 規則的詳細資訊，請參閱《*Amazon Simple Email Service 開發人員指南*》中的[建立接收規則](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-receipt-rules-console-walkthrough.html)。 如果您需要找出哪個規則集無效，請先儲存規則。規則集會出現錯誤訊息。 # 尋找電子郵件地址 您可以查看使用者、資源或群組是否在 Organization 中使用電子郵件地址。 **尋找電子郵件地址** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 在**組織**頁面中，選擇**尋找電子郵件地址**。 1. 選擇 **Search** (搜尋)。 # 使用組織設定 下列各節說明如何使用 Amazon WorkMail 組織可用的設定。您選擇的設定將套用至整個組織。 **Topics** + [啟用信箱遷移](migration-settings.md) + [啟用日誌](journaling.md) + [啟用互通性](enable-interop.md) + [啟用 SMTP 閘道](smtp-gateway.md) + [管理電子郵件流程](email-flows.md) + [對內送電子郵件強制執行 DMARC 政策](inbound-dmarc.md) # 啟用信箱遷移 當您想要將信箱從 Microsoft Exchange 或 G Suite Basic 等來源轉移到 Amazon WorkMail 時，您可以啟用信箱遷移。您可以在更大的遷移程序中啟用遷移。如需詳細資訊，包括操作步驟，請參閱本指南*入門*一節[遷移至 Amazon WorkMail](migration_overview.md)中的 。 # 啟用日誌 您可以啟用日誌記錄以記錄您的電子郵件通訊。使用日誌時，您通常會使用整合式第三方封存和 eDiscovery 工具。日誌有助於確保您符合資料儲存、隱私權保護和資訊保護的合規法規。 如需詳細資訊，包括操作步驟，請參閱本指南*入門*一節[搭配 Amazon WorkMail 使用電子郵件日誌](journaling_overview.md)中的 。 # 啟用互通性 互通性可讓您從 Microsoft Exchange 遷移，並使用 Amazon WorkMail 做為公司信箱的子集。如需詳細資訊，包括操作步驟，請參閱本指南*入門*一節[在 Amazon WorkMail 上設定可用性設定](enable_interop_wm.md)中的 。 # 啟用 SMTP 閘道 您可以啟用 Simple Mail Transfer Protocol (SMTP) 閘道，以與傳出電子郵件流程規則搭配使用。傳出電子郵件流程規則可讓您透過 SMTP 閘道路由從 Amazon WorkMail 組織傳送的電子郵件訊息。如需詳細資訊，請參閱[傳出電子郵件規則動作](email-flows.md#email-flows-rule-outbound)。 **注意** 針對傳出電子郵件流程規則設定的 SMTP 閘道，必須使用主要憑證授權單位的憑證來支援 Transport Layer Security (TLS) 1.2 版。僅支援基本身分驗證。 **設定 SMTP 閘道** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 在導覽窗格中，選擇 **Organization settings (組織設定)**。 **組織設定**頁面隨即出現，並顯示一組索引標籤。 1. 選擇 **SMTP 閘道**索引標籤，然後選擇**建立閘道**。 1. 輸入下列資料： + **閘道名稱** — 輸入唯一的名稱。 + **閘道地址** — 輸入閘道的主機名稱或 IP 地址。 + **連接埠號碼** — 輸入閘道的連接埠號碼。 + **使用者名稱** — 輸入使用者名稱。 + **密碼** — 輸入高強度密碼。 1. 選擇**建立**。 SMTP 閘道可用於傳出電子郵件流程規則。 當您設定 SMTP 閘道與傳出電子郵件流程規則搭配使用時，傳出訊息會嘗試比對規則與 SMTP 閘道。符合規則的訊息會路由至對應的 SMTP 閘道，然後處理電子郵件交付的其餘部分。 如果 Amazon WorkMail 無法連線到 SMTP 閘道，系統會將電子郵件訊息退回給寄件者。如果發生這種情況，請遵循上述步驟來更正閘道設定。 # 管理電子郵件流程 若要協助管理電子郵件，您可以設定*電子郵件流程規則*。電子郵件流程規則可以根據電子郵件訊息的地址或網域，對電子郵件訊息採取一或多個動作。您可以在寄件者和收件人的電子郵件地址或網域上使用電子郵件流程規則。 當您建立電子郵件流程規則時，您可以指定在符合指定規則[*模式*](#email-flows-patterns)時套用至電子郵件的規則[*動作*](#email-flows-rule-actions)。 **Topics** + [傳入電子郵件規則動作](#email-flows-rule-actions) + [傳出電子郵件規則動作](#email-flows-rule-outbound) + [寄件者與收件人模式](#email-flows-patterns) + [建立電子郵件流程規則](create-email-rules.md) + [編輯電子郵件流程規則](edit-rules.md) + [AWS Lambda 為 Amazon WorkMail 設定](lambda.md) + [管理對 Amazon WorkMail 訊息流程 API 的存取](lambda-content-access.md) + [測試電子郵件流程規則](test-email-flow-rule.md) + [移除電子郵件流程規則](remove-email-flow-rule.md) ## 傳入電子郵件規則動作 傳入電子郵件流程規則可防止不適當的電子郵件寄達您的使用者信箱。傳入電子郵件流程規則也稱為規則動作，會自動套用至傳送給 Amazon WorkMail 組織內任何人的所有電子郵件訊息。這與個別信箱的電子郵件規則不同。 **注意** 或者，您可以搭配 AWS Lambda 函數使用規則，在傳入電子郵件傳送到使用者信箱之前進行處理。如需搭配 Amazon WorkMail 使用 Lambda 的詳細資訊，請參閱 [AWS Lambda 為 Amazon WorkMail 設定](lambda.md)。如需有關 Lambda 的詳細資訊，請參閱 [https://docs.aws.amazon.com/lambda/latest/dg/welcome.html](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)。 傳入電子郵件流程規則也稱為規則動作，會自動套用至傳送給 Amazon WorkMail 組織內任何人的所有電子郵件訊息。這與個別信箱的電子郵件規則不同。 下列規則動作定義傳入電子郵件的處理方式。您可為每個規則指定[寄件者與收件人模式](#email-flows-patterns)及下列任一動作。 **** | Action | Description | | --- | --- | | 捨棄電子郵件 | 電子郵件訊息會被忽略。它不會被傳送且寄件者不會收到未傳遞通知。 | | 傳送退信回應 | 電子郵件訊息不會傳送，且寄件者會在退信訊息中收到未傳送的通知。 | | 傳遞到垃圾郵件資料夾 | 電子郵件訊息會傳送到使用者的垃圾郵件資料夾，即使 Amazon WorkMail 垃圾郵件偵測系統最初未將其識別為垃圾郵件。 | | 預設 | 電子郵件訊息會在 Amazon WorkMail 垃圾郵件偵測系統檢查後傳送。垃圾電子郵件會傳送至垃圾郵件資料夾。所有其他電子郵件訊息都會傳送到收件匣。 寄件者模式較不明確的其他電子郵件流程規則會被忽略。若要為網域型電子郵件流程規則新增例外狀況，請採用更明確的寄件者模式來設定預設動作。如需詳細資訊，請參閱[寄件者與收件人模式](#email-flows-patterns)。 | | 永不傳送到垃圾郵件資料夾 | 電子郵件訊息一律會傳送到使用者的收件匣，即使 Amazon WorkMail 垃圾郵件偵測系統將其識別為垃圾郵件。 若不使用預設的垃圾郵件偵測系統，您指定的地址可能導致使用者接觸高風險內容。 | | 執行 AWS Lambda | 將電子郵件訊息傳遞至 Lambda 函數，以便在交付至使用者的收件匣之前或期間進行處理。 | **注意** 傳入電子郵件會先傳送到 Amazon SES，然後傳送到 Amazon WorkMail。如果 Amazon SES 封鎖傳入電子郵件訊息，則規則動作將不適用。例如，Amazon SES 會在偵測到已知病毒或因為明確的 IP 篩選規則而封鎖電子郵件訊息。此時指定規則動作 (如 **Default (預設)**、**Deliver to junk folder (傳送到垃圾郵件資料夾)**或 **Never deliver to junk folder (永遠不傳送到垃圾郵件資料夾)**) 都不會有作用。 ## 傳出電子郵件規則動作 您可以使用傳出電子郵件流程規則，透過 SMTP 閘道指示電子郵件訊息，或封鎖寄件者傳送電子郵件訊息給指定的收件人。如需 SMTP 閘道的詳細資訊，請參閱 [啟用 SMTP 閘道](smtp-gateway.md)。 您也可以使用傳出電子郵件流程規則，在傳送電子郵件後將電子郵件訊息傳遞至 AWS Lambda 函數進行處理。如需有關 Lambda 的詳細資訊，請參閱 [https://docs.aws.amazon.com/lambda/latest/dg/welcome.html](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)。 下列規則動作定義傳出電子郵件的處理方式。您可為每個規則指定[寄件者與收件人模式](#email-flows-patterns)及下列任一動作。 **** | Action | 描述 | | --- | --- | | 預設 | 電子郵件訊息會透過正常流程傳送。 | | 捨棄電子郵件 | 電子郵件訊息已捨棄。該郵件不發送，且寄件者不會收到通知。 | | 傳送退信回應 | 電子郵件訊息不會傳送，且寄件者會收到訊息通知，告知管理員已封鎖電子郵件訊息。 | | 路由至 SMTP 閘道 | 電子郵件訊息會透過設定的 SMTP 閘道傳送。 | | 執行 Lambda | 在傳送電子郵件之前或期間，將電子郵件訊息傳遞給 Lambda 函數進行處理。 | ## 寄件者與收件人模式 電子郵件流程規則可套用到特定電子郵件地址，或是套用到特定的網域或一組網域中的所有電子郵件地址。由您定義模式，以決定要套用規則的電子郵件地址。 寄件者與收件人兩者的模式採用下列任一格式： + *電子郵件地址*符合單一電子郵件地址，例如： ``` mailbox@example.com ``` + *網域名稱*符合該網域下的所有電子郵件地址；例如： ``` example.com ``` + *萬用字元網域*符合該網域及其所有子網域下的所有電子郵件地址。萬用字元只會顯示於網域的前方，例如： ``` *.example.com ``` + *星號*符合任何網域下的任何電子郵件地址。 ``` * ``` **注意** \$1 符號在寄件者或收件者模式內無效。 多個模式可被一個規則指定。如需詳細資訊，請參閱[傳入電子郵件規則動作](#email-flows-rule-actions)及[傳出電子郵件規則動作](#email-flows-rule-outbound)。 如果傳入電子郵件訊息中的 `Sender`或 `From`標頭符合任何模式，就會套用傳入電子郵件流程規則。如果存在，`Sender` 地址會第一個為符合。如果沒有相符的 `Sender` 標頭或 `Sender` 標頭不符合任何規則，`From` 地址為符合。如果電子郵件訊息有多個收件人符合不同的規則，則每個規則適用於相符的收件人。 如果外寄電子郵件訊息中的收件人和 `Sender`或 `From`標頭符合任何模式，就會套用外寄電子郵件流程規則。如果電子郵件訊息有多個收件人符合不同的規則，則每個規則適用於相符的收件人。 若多個規則相符，將套用最明確的規則動作。例如，特定電子郵件地址的規則優先於整個網域的規則。若多個規則的明確程度相同，將套用限制最嚴格的動作。例如，**Drop (捨棄)** 動作的優先順序高於 **Bounce (退信)** 動作。動作的優先順序與 [傳入電子郵件規則動作](#email-flows-rule-actions) 和 [傳出電子郵件規則動作](#email-flows-rule-outbound) 所列的順序相同。 **注意** 以**刪除**或**彈跳**動作建立重疊的寄件者模式規則時請注意。未預期的優先順序排序可能會導致許多傳入電子郵件訊息無法傳遞。 # 建立電子郵件流程規則 電子郵件流程規則會將[規則動作](email-flows.md#email-flows-rule-actions)套用至傳入和傳出電子郵件訊息。當訊息符合指定的[模式](email-flows.md#email-flows-patterns)時，就會套用動作。新的電子郵件流程規則會立即生效。 **建立電子郵件流程規則** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 在導覽窗格中，選擇 **Organization settings (組織設定)**。 **組織設定**頁面隨即出現，並顯示一組索引標籤。從此頁面，您可以建立傳入或傳出規則。下列步驟說明如何建立這兩種類型。 **建立傳入規則** 1. 選擇**傳入規則**索引標籤，然後選擇**建立**。 1. 在**規則名稱**方塊中，輸入唯一的名稱。 1. 在**動作**下，開啟清單並選取動作。清單中的每個項目都包含描述，有些則提供**進一步了解**連結。 **注意** 如果您選擇**執行 Lambda** 動作，則會顯示其他控制項：如需使用這些控制項的相關資訊，請參閱下一節：[AWS Lambda 為 Amazon WorkMail 設定](lambda.md)。 1. 在**寄件者網域或地址**下，輸入您要套用規則的寄件者網域或地址。 1. 在**目的地網域或地址**下，輸入目的地網域和電子郵件地址的任意組合。 1. 選擇**建立**。 **建立傳出規則** 1. 選擇**傳出規則**索引標籤，然後選擇**建立**。 1. 在**規則名稱**方塊中，輸入唯一的名稱。 1. 在**動作**下，開啟清單並選取動作。清單中的每個項目都包含描述，有些則提供**進一步了解**連結。 **注意** 如果您選擇**執行 Lambda** 動作，則會顯示其他控制項。如需使用這些控制項的詳細資訊，請參閱下一節：[AWS Lambda 為 Amazon WorkMail 設定](lambda.md)。 1. 在**寄件者網域或地址**下，輸入有效寄件者網域和電子郵件地址的任意組合。 1. 在**目的地網域或地址**下，輸入有效目的地網域和電子郵件地址的任意組合。 1. 選擇**建立**。 您可以測試新建立的電子郵件流程規則。如需詳細資訊，請參閱[測試電子郵件流程規則](test-email-flow-rule.md)。 # 編輯電子郵件流程規則 當您需要變更電子郵件訊息的一或多個[規則動作](email-flows.md#email-flows-rule-actions)時，您可以編輯電子郵件流程規則。本節中的步驟適用於傳入和傳出電子郵件訊息。 **編輯電子郵件流程規則** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 在導覽窗格中，選擇 **Organization settings (組織設定)**。 **組織設定**頁面隨即出現，並顯示一組索引標籤。 1. 選擇**傳入規則**或**傳出規則**索引標籤。 1. 選擇您要變更之規則旁的選項按鈕，然後選擇**編輯**。 1. 視需要變更規則中的動作，然後選擇**儲存**。 # AWS Lambda 為 Amazon WorkMail 設定 使用傳入和傳出電子郵件流程規則中的**執行 Lambda** 動作，將符合規則的電子郵件訊息傳遞至 AWS Lambda 函數進行處理。 從下列組態中選擇 Amazon WorkMail 中的**執行 Lambda** 動作。 **同步**執行 Lambda** 組態** 符合流程規則的電子郵件訊息會在傳送或交付之前傳遞至 Lambda 函數進行處理。使用此組態來修改電子郵件內容。您也可以控制不同使用案例的傳入或傳出電子郵件流程。例如，傳遞至 Lambda 函數的規則可能會封鎖敏感電子郵件訊息的傳遞、移除附件或新增免責聲明。 **非同步 **Run Lambda** 組態** 符合流程規則的電子郵件訊息會在傳送或交付時傳遞至 Lambda 函數進行處理。此組態不會影響電子郵件傳遞，而且可用於收集傳入或傳出電子郵件訊息的指標等任務。 無論您選擇同步或非同步組態，傳遞至 Lambda 函數的事件物件都會包含傳入或傳出電子郵件事件的中繼資料。您也可以使用中繼資料中的訊息 ID，以存取電子郵件訊息的完整內容。如需詳細資訊，請參閱[使用 擷取訊息內容 AWS Lambda](lambda-content.md)。如需電子郵件事件的詳細資訊，請參閱 [Lambda 事件資料](#lambda-data)。 如需傳入和傳出電子郵件流程規則的詳細資訊，請參閱[管理電子郵件流程](email-flows.md)。如需有關 Lambda 的詳細資訊，請參閱 [https://docs.aws.amazon.com/lambda/latest/dg/welcome.html](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)。 **注意** 目前，Lambda 電子郵件流程規則僅參考相同 AWS 區域中和所設定 AWS 帳戶 Amazon WorkMail 組織的 Lambda 函數。 ## 適用於 Amazon WorkMail AWS Lambda 的 入門 若要開始使用 AWS Lambda 搭配 Amazon WorkMail，建議您將 [ WorkMail Hello World Lambda 函數](https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-1:489970191081:applications/workmail-hello-world-python)從 部署 AWS Serverless Application Repository 至您的帳戶。函數具有所有必要的資源，以及為您設定的許可。如需更多範例，請參閱 GitHub 上的 [amazon-workmail-lambda-templates](https://github.com/aws-samples/amazon-workmail-lambda-templates) 儲存庫。 如果您選擇建立自己的 Lambda 函數，則必須使用 AWS Command Line Interface () 設定許可AWS CLI。在下列範例命令中，執行下列動作： + `MY_FUNCTION_NAME` 將 取代為 Lambda 函數的名稱。 + `REGION` 將 取代為您的 Amazon WorkMail AWS 區域。可用的 Amazon WorkMail 區域包括 `us-east-1`（美國東部 （維吉尼亞北部）)、 `us-west-2` （美國西部 （奧勒岡）) 和 `eu-west-1`（歐洲 （愛爾蘭）)。 + `AWS_ACCOUNT_ID` 將 取代為您的 12 位數 AWS 帳戶 ID。 + `WORKMAIL_ORGANIZATION_ID` 將 取代為您的 Amazon WorkMail 組織 ID。您可以在 **Organizations** 頁面上的組織卡片上找到它。 ``` aws --region REGION lambda add-permission --function-name MY_FUNCTION_NAME --statement-id AllowWorkMail --action "lambda:InvokeFunction" --principal workmail.REGION.amazonaws.com --source-arn arn:aws:workmail:REGION:AWS_ACCOUNT_ID:organization/WORKMAIL_ORGANIZATION_ID ``` 如需使用 的詳細資訊 AWS CLI，請參閱 [https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)。 ## 設定同步**執行 Lambda** 規則 若要設定同步**執行 Lambda** 規則，請使用**執行 Lambda** 動作建立電子郵件流程規則，然後選取**同步執行**核取方塊。如需如何建立郵件流程規則的詳細資訊，請參閱[建立電子郵件流程規則](create-email-rules.md)。 若要完成建立同步規則，請新增 Lambda Amazon Resource Name (ARN) 並設定下列選項。 ****Fallback action (備用動作)**** 如果 Lambda 函數無法執行，Amazon WorkMail 會套用動作。如果未設定 **allRecipients** 旗標，則此動作也適用於從 Lambda 回應省略的任何收件人。**備用動作**不能是另一個 Lambda 動作。 ****Rule timeout (規則逾時)** (以分鐘為單位)** 如果 Amazon WorkMail 無法調用 Lambda 函數，則會重試該函數的期間。系統會在此期間結束時套用 **Fallback action (備用動作)**。 **注意** 同步**執行 Lambda** 規則僅支援**\$1**目的地條件。 ## Lambda 事件資料 使用以下事件資料觸發 Lambda 函數。資料的呈現取決於 Lambda 函數使用的程式設計語言。 ``` { "summaryVersion": "2018-10-10", "envelope": { "mailFrom" : { "address" : "from@example.com" }, "recipients" : [ { "address" : "recipient1@example.com" }, { "address" : "recipient2@example.com" } ] }, "sender" : { "address" : "sender@example.com" }, "subject" : "Hello From Amazon WorkMail!", "messageId": "00000000-0000-0000-0000-000000000000", "invocationId": "00000000000000000000000000000000", "flowDirection": "INBOUND", "truncated": false } ``` 事件 JSON 包括下列資料。 **summaryVersion** 的版本編號`LambdaEventData`。這只會在您於 中進行回溯不相容的變更時更新`LambdaEventData`。 **envelope** 電子郵件訊息的信封，其中包含下列： 欄位。 **mailFrom** **From (寄件人)** 地址通常是傳送電子郵件訊息的使用者電子郵件地址。若使用者以另一位使用者的身分或代表另一位使用者傳送了電子郵件訊息，則 **mailFrom (寄件者地址)** 欄位會傳回授權使用者傳送電子郵件的電子郵件地址，而非實際寄件者的電子郵件地址。 **recipients** 收件人電子郵件地址清單。Amazon WorkMail 不會區分 **To**、**CC** 或 **BCC**。 對於傳入電子郵件流程規則，此清單包含您在其中建立規則的 Amazon WorkMail 組織中所有網域中的收件人。系統會針對來自寄件者的每個 SMTP 對話分別叫用 Lambda 函數，而收件人欄位會列出來自該 SMTP 對話的收件人。使用外部網域的收件人不包含在內。 **寄件者** 代表另一位使用者傳送電子郵件訊息的使用者的電子郵件地址。只有在代表其他使用者傳送電子郵件訊息時，才會設定此欄位。 **subject** 電子郵件主旨行。超過 256 個字元限制時就會遭到截斷。 **messageId** 使用 Amazon WorkMail 訊息流程 SDK 時，用來存取電子郵件訊息完整內容的唯一 ID。 **invocationId** 唯一 Lambda 調用的 ID。當針對相同的 **LambdaEventData** 呼叫 Lambda 函數多次時，此 ID 保持不變。用於偵測重試次數並避免重複。 **flowDirection** 指出電子郵件流程的方向，即 **INBOUND (傳入)** 或 **OUTBOUND (傳出)**。 **truncated** 適用於承載大小，而不是主旨行長度。若此值為 `true`，則負載大小會超過 128 KB 的限制，因此會截斷收件人清單以符合限制。 ## 同步**執行 Lambda** 回應結構描述 當具有同步**執行 Lambda** 動作的電子郵件流程規則符合傳入或傳出電子郵件訊息時，Amazon WorkMail 會呼叫設定的 Lambda 函數，並等待回應，然後再對電子郵件訊息採取動作。Lambda 函數會根據預先定義的結構描述傳回回應，該結構描述會列出動作、動作類型、適用的參數和套用動作的收件人。 下列範例顯示同步**執行 Lambda** 回應。回應會根據用於 Lambda 函數的程式設計語言而有所不同。 ``` { "actions": [ { "action" : { "type": "string", "parameters": { various } }, "recipients": [list of strings], "allRecipients": boolean } ] } ``` 回應 JSON 包含下列資料。 **動作** 要為收件人採取的動作。 **type** 動作類型。非同步 **Run Lambda** 動作不會傳回動作類型。 傳入規則動作類型包含 **BOUNCE (退信)**、**DROP (捨棄)**、**DEFAULT (預設)**、**BYPASS\$1SPAM\$1CHECK** 和 **MOVE\$1TO\$1JUNK**。如需詳細資訊，請參閱[傳入電子郵件規則動作](email-flows.md#email-flows-rule-actions)。 輸出規則動作類型包含 **BOUNCE (退信)**、**DROP (捨棄)** 和 **DEFAULT (預設)**。如需詳細資訊，請參閱[傳出電子郵件規則動作](email-flows.md#email-flows-rule-outbound)。 **parameters** 其他動作參數。支援 **BOUNCE** 動作類型做為具有金鑰 **bounceMessage** 和值**字串**的 JSON 物件。此退信訊息可用來建立退信電子郵件訊息。 **recipients** 應對其採取動作的電子郵件地址清單。即使原始收件人清單中未包含收件人，您仍可將收件人新增至回應中。如果某個動作的 **allRecipients** 為 true，此欄位則非必填。 當對傳入電子郵件呼叫 Lambda 動作時，您只能新增來自您組織的新收件人。新收件人會以 **BCC (密件副本)** 的形式新增至回應中。 **allRecipients** 為 true 時， 會將動作套用至 Lambda 回應中不受其他特定動作限制的所有收件人。 ### 同步**執行 Lambda** 動作限制 當 Amazon WorkMail 針對同步**執行 Lambda 動作調用 Lambda** 函數時，適用下列限制： + Lambda 函數必須在 15 秒內回應，或視為失敗的調用。 **注意** 系統會針對您指定的**規則逾時**間隔重試呼叫。 + 允許最多 256 KB 的 Lambda 函數回應。 + 回應中最多可允許 10 個唯一動作。10 個以上都動作會受到設定的 **Fallback action (備用動作)** 所約束。 + 傳出 Lambda 函數最多允許 500 個收件人。 + **Rule timeout (規則逾時)** 的最大值為 240 分鐘。如果已設定最小值 0，Amazon WorkMail 套用後援動作之前不會重試。 ### 同步**執行 Lambda** 動作失敗 如果 Amazon WorkMail 因為錯誤、無效的回應或 Lambda 逾時而無法叫用 Lambda 函數，Amazon WorkMail 會以指數退避重試調用，以降低處理速率，直到**規則逾時**期間完成為止。接著，**Fallback action (備用動作)** 會套用至電子郵件訊息的所有收件人。如需詳細資訊，請參閱[設定同步**執行 Lambda** 規則](#synchronous-rules)。 ## 同步**執行 Lambda** 回應範例 下列範例示範常見同步 **Run Lambda** 回應的結構。 **Example ：從電子郵件訊息中移除指定的收件人** 下列範例示範從電子郵件訊息中移除收件人的同步 **Run Lambda** 回應結構。 ``` { "actions": [ { "action": { "type": "DEFAULT" }, "allRecipients": true }, { "action": { "type": "DROP" }, "recipients": [ "drop-recipient@example.com" ] } ] } ``` **Example ：自訂電子郵件訊息的退信** 下列範例示範同步 **Run Lambda** 回應的結構，以便使用自訂電子郵件訊息進行彈跳。 ``` { "actions" : [ { "action" : { "type": 'BOUNCE', "parameters": { "bounceMessage" : "Email in breach of company policy." } }, "allRecipients": true } ] } ``` **Example ：將收件人新增至電子郵件訊息** 下列範例示範將收件人新增至電子郵件訊息的同步 **Run Lambda** 回應結構。這不會更新電子郵件訊息的 **To (收件人)** 或 **CC (副本)** 欄位。 ``` { "actions": [ { "action": { "type": "DEFAULT" }, "recipients": [ "new-recipient@example.com" ] }, { "action": { "type": "DEFAULT" }, "allRecipients": true } ] } ``` 如需為**執行 Lambda 動作建立 Lambda** 函數時要使用的更多程式碼範例，請參閱 [Amazon WorkMail Lambda 範本](https://github.com/aws-samples/amazon-workmail-lambda-templates)。 ## 搭配 Amazon WorkMail 使用 Lambda 的詳細資訊 您也可以存取觸發 Lambda 函數之電子郵件訊息的完整內容。如需詳細資訊，請參閱[使用 擷取訊息內容 AWS Lambda](lambda-content.md)。 # 使用 擷取訊息內容 AWS Lambda 設定 AWS Lambda 函數以管理 Amazon WorkMail 的電子郵件流程後，您可以存取使用 Lambda 處理之電子郵件訊息的完整內容。如需 Lambda for Amazon WorkMail 入門的詳細資訊，請參閱 [AWS Lambda 為 Amazon WorkMail 設定](lambda.md)。 若要存取電子郵件訊息的完整內容，請使用 Amazon WorkMail Message Flow API 中的 `GetRawMessageContent`動作。呼叫時傳送到 Lambda 函數的電子郵件訊息 ID 會將請求傳送至 API。接著，API 會以電子郵件訊息的完整 MIME 內容來回應。如需詳細資訊，請參閱[《Amazon WorkMail API 參考》中的 Amazon WorkMail 訊息流程](https://docs.aws.amazon.com/workmail/latest/APIReference/API_Operations_Amazon_WorkMail_Message_Flow.html)。 *Amazon WorkMail * 下列範例顯示使用 Python 執行時間環境的 Lambda 函數如何擷取完整訊息內容。 **提示** 如果您從 將 Amazon WorkMail [ Hello World Lambda 函數](https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-1:489970191081:applications/workmail-hello-world-python)部署 AWS Serverless Application Repository 到您的帳戶開始，系統會使用所有必要的資源和許可在您的帳戶中建立 Lambda 函數。然後，您可以根據您的使用案例，將商業邏輯新增至 lambda 函數。 ``` import boto3 import email import os def email_handler(event, context): workmail = boto3.client('workmailmessageflow', region_name=os.environ["AWS_REGION"]) msg_id = event['messageId'] raw_msg = workmail.get_raw_message_content(messageId=msg_id) parsed_msg = email.message_from_bytes(raw_msg['messageContent'].read()) print(parsed_msg) ``` 如需分析傳輸中訊息內容的更詳細範例，請參閱 GitHub 上的 [amazon-workmail-lambda-templates](https://github.com/aws-samples/amazon-workmail-lambda-templates) 儲存庫。 **注意** 您只能使用 Amazon WorkMail Message Flow API 存取傳輸中的電子郵件訊息。您只能在傳送或接收訊息的 24 小時內存取訊息。若要以程式設計方式存取使用者信箱中的訊息，請使用 Amazon WorkMail 支援的其他通訊協定，例如 IMAP 或 Exchange Web Services (EWS)。 # 使用 AWS Lambda 更新訊息內容 設定同步 AWS Lambda 函數來管理電子郵件流程後，您可以使用 Amazon WorkMail Message Flow API 中的 `PutRawMessageContent`動作來更新傳輸中電子郵件訊息的內容。如需 Amazon WorkMail Lambda 函數入門的詳細資訊，請參閱 [設定同步**執行 Lambda** 規則](lambda.md#synchronous-rules)。如需 API 的詳細資訊，請參閱 [ PutRawMessageContent](https://docs.aws.amazon.com/workmail/latest/APIReference/API_messageflow_PutRawMessageContent.html)。 **注意** PutRawMessageContent API 需要 boto3 1.17.8，或者您可以將 layer 新增至 Lambda 函數。若要下載正確的 boto3 版本，請參閱 [ GitHub 上的 boto 頁面](https://github.com/boto/boto)。如需新增層的詳細資訊，請參閱[設定函數以使用層](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html#configuration-layers-using)。 以下是範例 layer：`"LayerArn":"arn:aws:lambda:${AWS::Region}:489970191081:layer:WorkMailLambdaLayer:2"`。在此範例中，`${AWS::Region}`以適當的 aws 區域取代，例如 us-east-1。 **提示** 如果您從將 Amazon WorkMail [Hello World Lambda 函數](https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-1:489970191081:applications/workmail-hello-world-python)從 AWS Serverless Application Repository 部署到您的帳戶開始，系統會在您的帳戶中建立具有必要資源和許可的 Lambda 函數。然後，您可以根據您的使用案例，將商業邏輯新增至 lambda 函數。 當您離開時，請記住下列事項： + 使用 [ GetRawMessageContent](https://docs.aws.amazon.com/workmail/latest/APIReference/API_messageflow_GetRawMessageContent.html) API 擷取原始訊息內容。如需更多資訊，請參閱[使用 擷取訊息內容 AWS Lambda](lambda-content.md)。 + 收到原始訊息後，請變更 MIME 內容。完成後，將訊息上傳至您帳戶中的 Amazon Simple Storage Service (Amazon S3) 儲存貯體。確保 S3 儲存貯體使用與 Amazon WorkMail 操作 AWS 帳戶 相同的 ，而且它使用與 API 呼叫相同的 AWS 區域。 + 若要讓 Amazon WorkMail 處理請求，您的 S3 儲存貯體必須具有正確的政策，才能存取 S3 物件。如需詳細資訊，請參閱[Example S3 policy](#s3example)。 + 使用 [ PutRawMessageContent](https://docs.aws.amazon.com/workmail/latest/APIReference/API_messageflow_PutRawMessageContent.html) API 將更新的訊息內容傳回 Amazon WorkMail。 **注意** `PutRawMessageContent` API 可確保更新訊息的 MIME 內容符合 RFC 標準，以及 [RawMessageContent](https://docs.aws.amazon.com/workmail/latest/APIReference/API_messageflow_RawMessageContent.html) 資料類型中提及的條件。傳入 Amazon WorkMail 組織的電子郵件不一定符合這些標準，因此 `PutRawMessageContent` API 可能會拒絕它們。在這種情況下，您可以參閱傳回的錯誤訊息，以取得如何修正任何問題的詳細資訊。 **Example 範例 S3 政策** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "workmail.REGION.amazonaws.com" }, "Action": [ "s3:GetObject", "s3:GetObjectVersion" ], "Resource": "arn:aws:s3:::My-Test-S3-Bucket/*", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" }, "Bool": { "aws:SecureTransport": "true" }, "ArnLike": { "aws:SourceArn": "arn:aws:workmailmessageflow:us-east-1:111122223333:message/WORKMAIL_ORGANIZATION_ID/*" } } } ] } ``` 下列範例顯示 Lambda 函數如何使用 Python 執行期來更新傳輸中電子郵件訊息的主旨。 ``` import boto3 import os import uuid import email def email_handler(event, context): workmail = boto3.client('workmailmessageflow', region_name=os.environ["AWS_REGION"]) s3 = boto3.client('s3', region_name=os.environ["AWS_REGION"]) msg_id = event['messageId'] raw_msg = workmail.get_raw_message_content(messageId=msg_id) parsed_msg = email.message_from_bytes(raw_msg['messageContent'].read()) # Updating subject. For more examples, see https://github.com/aws-samples/amazon-workmail-lambda-templates. parsed_msg.replace_header('Subject', "New Subject Updated From Lambda") # Store updated email in S3 key = str(uuid.uuid4()); s3.put_object(Body=parsed_msg.as_bytes(), Bucket="amzn-s3-demo-bucket", Key=key) # Update the email in WorkMail s3_reference = { 'bucket': "amzn-s3-demo-bucket", 'key': key } content = { 's3Reference': s3_reference } workmail.put_raw_message_content(messageId=msg_id, content=content) ``` 如需分析傳輸中訊息內容之方式的更多範例，請參閱 GitHub 上的 [ amazon-workmail-lambda-templates ](https://github.com/aws-samples/amazon-workmail-lambda-templates) 儲存庫。 # 管理對 Amazon WorkMail 訊息流程 API 的存取 使用 AWS Identity and Access Management (IAM) 政策來管理對 Amazon WorkMail 訊息流程 API 的存取。 Amazon WorkMail Message Flow API 適用於單一資源類型，即傳輸中的電子郵件訊息。每個傳輸中的電子郵件都有一個與其關聯的唯一 Amazon Resource Name (ARN)。 以下範例顯示與傳輸中電子郵件訊息關聯的 ARN 語法。 ``` arn:aws:workmailmessageflow:region:account:message/organization/context/messageID ``` 上述範例中的可變更欄位包含下列項目： + **區域** – Amazon WorkMail 組織的 AWS 區域。 + **帳戶** – Amazon WorkMail 組織的 AWS 帳戶 ID。 + **組織** – 您的 Amazon WorkMail 組織 ID。 + **內容** – 指出訊息是`incoming`傳送到您的組織還是`outgoing`來自組織。 + **訊息 ID** – 做為輸入傳遞至 Lambda 函數的唯一電子郵件訊息 ID。 以下範例包含與傳輸中傳入電子郵件訊息相關聯的 ARN 範例 ID。 ``` arn:aws:workmailmessageflow:us-east-1:111122223333:message/m-n1pq2345678r901st2u3vx45x6789yza/incoming/d1234567-8e90-1f23-456g-hjk7lmnop8q9 ``` 您可以使用這些 ARNs 做為 IAM 使用者政策 `Resource`區段中的資源，以管理對傳輸中 Amazon WorkMail 訊息的存取。 ## Amazon WorkMail 訊息流程存取的 IAM 政策範例 下列範例政策會授予 IAM 實體對 中每個 Amazon WorkMail 組織的所有傳入和傳出訊息的完整讀取存取權 AWS 帳戶。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "workmailmessageflow:GetRawMessageContent" ], "Resource": "arn:aws:workmailmessageflow:us-east-1:111122223333:message/*", "Effect": "Allow" } ] } ``` ------ 如果您的 中有多個組織 AWS 帳戶，您也可以限制對一或多個組織的存取。如果某些 Lambda 函數只應該用於特定組織，這會很有用。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "workmailmessageflow:GetRawMessageContent" ], "Resource": "arn:aws:workmailmessageflow:us-east-1:111122223333:message/organization/*", "Effect": "Allow" } ] } ``` ------ 您也可以選擇根據訊息是 `incoming` (傳入) 組織還是從組織 `outgoing` (傳出)，來授予訊息的存取權。若要執行此作業，請在 ARN 中使用限定詞 `incoming` 或 `outgoing`。 以下範例政策僅授予對傳入組織之訊息的存取權。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "workmailmessageflow:GetRawMessageContent" ], "Resource": "arn:aws:workmailmessageflow:us-east-1:111122223333:message/organization/incoming/*", "Effect": "Allow" } ] } ``` ------ 下列範例政策會授予 IAM 實體對 中每個 Amazon WorkMail 組織的所有傳入和傳出訊息的完整讀取和更新存取權 AWS 帳戶。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "workmailmessageflow:GetRawMessageContent", "workmailmessageflow:PutRawMessageContent" ], "Resource": "arn:aws:workmailmessageflow:us-east-1:111122223333:message/*", "Effect": "Allow" } ] } ``` ------ # 測試電子郵件流程規則 若要檢查目前的規則組態，您可以針對特定電子郵件地址測試組態的行為。 **測試電子郵件流程規則** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 在導覽窗格中，選擇 **Organization settings (組織設定)**、**Inbound/Outbound rules (傳入/傳出規則)**。 1. 請在 **Test configuration (測試組態)** 旁輸入欲測試寄件者和收件人兩者的完整電子郵件地址。 1. 選擇**測試**。顯示所提供的電子郵件地址會採取的動作。 # 移除電子郵件流程規則 當您移除電子郵件流程規則時，變更會立即被套用。 **移除電子郵件流程規則** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 在導覽窗格中，選擇 **Organization settings (組織設定)**、**Inbound/Outbound rules (傳入/傳出規則)**。 1. 選取規則然後選擇 **Remove** (移除)。 1. 在確認提示中，選擇 **Remove (移除)**。 # 對內送電子郵件強制執行 DMARC 政策 電子郵件網域使用網域名稱系統 (DNS) 記錄以確保安全。可以保護您的使用者免受常見的攻擊，例如詐騙或網路釣魚。DNS 記錄通常包含網域型訊息驗證、報告和一致性 (DMARC) 記錄，這些記錄是由傳送電子郵件的網域擁有者所設定。DMARC 記錄包含的政策指定當電子郵件未通過 DMARC 檢查時要採取的動作。您可以選擇是否要對傳送至組織的電子郵件強制執行 DMARC 政策。 新的 Amazon WorkMail 組織預設會開啟 DMARC 強制執行。 **若要開啟強制執行 DMARC 功能** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 在導覽窗格中，選擇 **Organization settings (組織設定)**。**組織設定**頁面隨即出現，並顯示一組索引標籤。 1. 選擇 **DMARC** 索引標籤，然後選擇**編輯**。 1. 將 **DMARC 強制執行**滑桿移至開啟位置。 1. 選取**我確認開啟 DMARC 強制執行旁的核取方塊，可能會導致根據寄件者的網域組態捨棄或隔離傳入電子郵件。** 1. 選擇**儲存**。 **若要關閉 DMARC 強制執行功能** + 遵循上一節中的步驟，但將 **DMARC 強制執行**滑桿移至關閉位置。 ## 使用電子郵件事件記錄來追蹤 DMARC 的強制執行 開啟 DMARC 強制執行可能會導致內送電子郵件遭到捨棄或標示為垃圾郵件，視寄件者設定其網域的方式而定。如果寄件者設定錯誤的電子郵件網域，您的使用者可能會停止接收合法電子郵件。若要檢查未交付給使用者的電子郵件，您可以為 Amazon WorkMail 組織啟用電子郵件事件記錄。然後，您可以查詢電子郵件事件日誌，找出根據寄件者的 DMARC 政策篩選掉傳入的電子郵件。 在您使用電子郵件事件記錄來追蹤 DMARC 強制執行之前，請在 Amazon WorkMail 主控台中啟用電子郵件事件記錄。若要充分利用您的日誌資料，請在記錄電子郵件事件的同時等待一些時間。如需詳細資訊和指示，請參閱[啟用電子郵件事件記錄](tracking.md#enable-tracking)。 **若要使用電子郵件事件記錄來追蹤 DMARC 強制執行** 1. 在 CloudWatch Insights 主控台的 **Logs (記錄)** 下，選擇 **Insights (Insights)**。 1. 針對**選取日誌群組 （選取）**，選取您 Amazon WorkMail 組織的日誌群組。例如，/aws/workmail/events/organization-alias。 1. 選取要查詢的時間期間。 1. 執行以下查詢：**stats count() by event.dmarcPolicy \$1 filter event.dmarcVerdict == "FAIL"** 1. 選擇 **Run query** (執行查詢)。 您也可以為這些事件設定自訂指標。如需詳細資訊，請參閱[建立指標篩選器](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringPolicyExample.html)。 # 標記組織 標記 Amazon WorkMail 組織資源可讓您： + 在 AWS 帳單與成本管理 主控台中區分組織。 + 將 Amazon WorkMail 組織資源新增至 AWS Identity and Access Management (IAM) 許可政策陳述式的 `Resource`元素，以控制對 Amazon WorkMail 組織資源的存取。 如需 Amazon WorkMail 資源層級許可的詳細資訊，請參閱 [Resources](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-resources)。如需有關根據標籤控制存取的更多資訊，請參閱[以 Amazon WorkMail 標籤為基礎的授權](security_iam_service-with-iam.md#security_iam_service-with-iam-tags)。 Amazon WorkMail 管理員可以使用 Amazon WorkMail 主控台標記組織。 **將標籤新增至 Amazon WorkMail 組織** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 選擇**標籤**。 1. 對於 **Organization tags (組織標籤)**，選擇 **Add New Tag (新增標籤)**。 1. 針對**金鑰**，輸入識別標籤的名稱。 1. (選用) 在 **Value (值)** 中，輸入標籤的值。 1. (選用) 重複步驟 4-6，將更多標籤新增至您的組織。您最多可以新增 50 個標籤。 1. 選擇**儲存**，以儲存變更。 您可以在 Amazon WorkMail 主控台中檢視您的組織標籤。 開發人員也可以使用 AWS SDK 或 AWS Command Line Interface () 標記組織AWS CLI。如需詳細資訊，請參閱 Amazon WorkMail API `TagResource`參考或 `UntagResource` 命令參考中的 `ListTagsForResource`、 [AWS CLI 和 命令](https://docs.aws.amazon.com/cli/latest/reference/workmail/index.html)。 [Amazon WorkMail ](https://docs.aws.amazon.com/workmail/latest/APIReference/Welcome.html) 您可以隨時使用 Amazon WorkMail 主控台從組織移除標籤。 **從 Amazon WorkMail 組織移除標籤** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 選擇**標籤**。 1. 對於 **Organization tags (組織標籤)**，選擇要移除之標籤旁邊的 **Remove (移除)**。 1. 選擇**提交**來儲存您的變更。 # 使用存取控制規則 Amazon WorkMail 的存取控制規則可讓管理員控制其組織的使用者和模擬角色如何獲得 Amazon WorkMail 的存取權。每個 Amazon WorkMail 組織都有預設存取控制規則，可將信箱存取權授予新增至組織的所有使用者和模擬角色，無論他們使用哪個存取通訊協定或 IP 地址。管理員可以編輯或使用自己的其中一個規則取代預設規則、新增規則或刪除規則。 **警告** 如果管理員刪除組織的所有存取控制規則，Amazon WorkMail 會封鎖組織信箱的所有存取。 管理員可以根據下列準則套用允許或拒絕存取的存取控制規則： + **通訊協定** – 用來存取信箱的通訊協定。範例包括 **Autodiscover**、**EWS**、**IMAP**、**SMTP**、**ActiveSync**、適用於 **Windows 的 Outlook** 和 **Webmail**。 + **IP 地址** – 用來存取信箱的 IPv4 CIDR 範圍。 + **Amazon WorkMail 使用者** – 組織中用來存取信箱的使用者。 + **模擬角色** – 組織中用來存取信箱的模擬角色。如需詳細資訊，請參閱[管理模擬角色](managing-impersonation-roles.md)。 除了使用者的信箱和資料夾權限之外，管理員還會套用存取控制規則。如需詳細資訊，請參閱《*Amazon WorkMail 使用者指南*》中的[使用信箱許可](mail_perms_overview.md)和[共用資料夾和資料夾許可](https://docs.aws.amazon.com/workmail/latest/userguide/share-folders.html)。 **注意** 當您啟用 Outlook for Windows 的存取權時，建議您也啟用 Autodiscover 和 EWS 的存取權。 存取控制規則不適用於 Amazon WorkMail 主控台或 SDK 存取。請改用 AWS Identity and Access Management (IAM) 角色或政策。如需詳細資訊，請參閱[Amazon WorkMail 的身分和存取管理](security-iam.md)。 ## 建立存取控制規則 從 Amazon WorkMail 主控台建立新的存取控制規則。 **建立新的存取控制規則** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 選擇 **Access Control List (存取控制規則)**。 1. 選擇**建立規則**。 1. 對於 **Description (描述)**，請輸入規則的描述。 1. 對於 **Effect (效果)**，請選擇 **Allow (允許)** 或 **Deny (拒絕)**。這會根據您在下列步驟中選取的條件允許或拒絕存取。 1. 對於**此規則適用於 ... 的請求**，請選取要套用至規則的條件，例如是否包含或排除特定通訊協定、IP 地址或使用者，或是模擬角色。 1. （選用） 如果您輸入 IP 地址範圍、使用者或模擬角色，請選擇**新增**以將其新增至規則。 1. 選擇**建立規則**。 ## 編輯存取控制規則 從 Amazon WorkMail 主控台編輯新的和預設存取控制規則。 **編輯存取控制規則** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 選擇 **Access Control List (存取控制規則)**。 1. 選取要編輯的規則。 1. 選擇**編輯規則**。 1. 視需要編輯描述、效果和條件。 1. 選擇**儲存變更**。 **重要** 當您變更存取規則時，受影響的信箱可能需要五分鐘的時間才能遵循更新後的規則。存取受影響信箱的用戶端在此期間可能會顯示不一致的行為。不過，當您測試規則時，會立即看到正確的行為。如需測試規則的詳細資訊，請參閱下一節中的步驟。 ## 測試存取控制規則 若要查看如何套用組織的存取控制規則，請從 Amazon WorkMail 主控台測試規則。 **測試組織的存取控制規則** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 選擇 **Access Control List (存取控制規則)**。 1. 選擇**測試規則**。 1. 在 **Request context (要求內容)** 中，請選取要測試的通訊協定。 1. 在 **Source IP address (來源 IP 地址)** 中，輸入要測試的 IP 地址。 1. 針對 **執行的請求**，選擇要測試**的使用者**或**模擬角色**。 1. 選取要測試**的使用者**或**模擬角色**。 1. 選擇**測試**。 測試結果會出現在 **Effect (效果)** 下。 ## 刪除存取控制規則 從 Amazon WorkMail 主控台刪除不再需要的存取控制規則。 **警告** 如果管理員刪除組織的所有存取控制規則，Amazon WorkMail 會封鎖組織信箱的所有存取。 **刪除存取控制規則** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 選擇 **Access Control List (存取控制規則)**。 1. 選取要刪除的規則。 1. 選擇 **Delete rule (刪除規則)**。 1. 選擇 **刪除**。 # 設定信箱保留政策 您可以為 Amazon WorkMail 組織設定信箱保留政策。保留政策會在您選擇的期間之後，自動從使用者信箱刪除電子郵件訊息。您可以選擇要套用保留政策的信箱資料夾。此外，您可以選擇是否要為不同的資料夾設定不同的保留政策。信箱保留政策會套用至組織中所有使用者信箱中選取的資料夾。使用者無法覆寫保留政策。 **設定信箱保留政策** 1. 開啟位於 https：//[https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/) 的 Amazon WorkMail 主控台。 如有必要請變更 AWS 區域。在主控台視窗頂端的列中，開啟**選取區域**清單，然後選擇區域。如需詳細資訊，請參閱 *Amazon Web Services 一般參考* 中的 [ 區域與端點](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)。 1. 在導覽窗格中，選擇**組織**，然後選擇組織的名稱。 1. 選擇 **Retention policy (保留政策)**。 1. 針對 **Folder actions (資料夾動作)**，選取要包含在政策中的每個信箱資料夾旁邊的 **Delete (刪除)** 或 **Permanently delete (永久刪除)**。 1. 輸入刪除電子郵件訊息之前，將電子郵件訊息保留在每個信箱資料夾中的天數。 1. 選擇**儲存**。 為您的組織套用保留政策需要 48 小時。如果您選擇**刪除**資料夾動作，使用者可以從 Amazon WorkMail Web 應用程式和支援的用戶端復原已刪除的電子郵件訊息。如果您選擇**永久刪除**資料夾動作，電子郵件訊息在刪除後將無法復原。 保留政策保留項目的天數是以建立、修改或移動項目的時間為基礎。例如，如果保留政策在一年後刪除項目，則政策會從您建立或上次對該項目採取動作的日期開始計算保留天數。它不受您實作保留政策的日期影響。