iOS Outlook Activesync 有效，iOS Mail Activesync 無效
我們有一個訪客 wifi 網路，位於防火牆上的類似 DMZ 的區域中。我們的 Exchange 2010 伺服器位於防火牆的“內部”區域，1-1 NAT 到“外部”區域的公共 IP 地址。
自動發現和 Activesync 在“外部”的所有情況下都能正常工作（請注意，這意味著 Microsoft 遠端連接分析器通過了所有測試）。
從訪客 wifi 區域到 Exchange 伺服器所在的內部區域涉及防火牆外部介面上的“髮夾”或“掉頭”，因為訪客 wifi 客戶端使用公共 DNS 進行自動發現和 Activesync（我們不當然，希望客人能夠看到我們的內部 DNS）。防火牆製造商 (Palo Alto) 有一個我遵循的 u-turn 配置的配置指南，除了一個怪癖之外，它可以工作：
訪客 wifi 上的 iOS 設備可以使用適用於 iOS 的 Microsoft Outlook 應用程序連接到 Exchange 進行自動發現和 Activesync，但不能使用內置 iOS 郵件應用程序使用自動發現或 Activesync。
我無法弄清楚為什麼這兩者的行為或工作方式會有所不同。到目前為止，我一直懷疑 Apple 正在嘗試使用不同的埠或其他東西進行同步，即使我的期望只是 HTTPS 443 並且（可能）需要 HTTP 80。目前，我從來賓 wifi 區域向 Exchange 伺服器開放的埠是 80、443 和 143（對於 IMAP 作為暗中的刺）。
在 Activesync 方面，Outlook for iOS 和 iOS Mail 有什麼區別？
編輯 - 更多資訊
我已經做了幾件事來試圖弄清楚這一點。首先，我打開了訪客 wifi 區域和 Exchange 伺服器之間的所有埠，但沒有任何改變。這讓我覺得 u-turn 配置可能無法正常工作，但 Outlook for iOS 應用程序正在解決這個問題。
其次，我過濾了從訪客 wifi 區域到 Exchange 伺服器的連接的防火牆日誌，並且沒有任何記錄，即使 Outlook for iOS 應用程序正在檢索郵件。
所以我目前的理論是，微軟通過允許它使用一種 Activesync 代理服務來幫助它在所有情況下或類似的情況下到達目標伺服器，從而在他們的 Outlook for iOS 應用程序中建立了一些彈性。
Outlook 應用程序不直接連接到 Exchange - 這就是區別。
Outlook 應用程序的所有流量都流向 Microsoft 控制下的伺服器（它們在 Amazon AWS 中，我認為它們現在已被帶到 Azure）。然後，Microsoft 伺服器會連接到您的 Exchange 伺服器。
適用於 iOS 和 Android 的 Microsoft Outlook 應用程序基於另一個名為 Accomli 的應用程序，微軟於 2014 年購買了該應用程序。這是一篇關於它的擔憂的舊部落格文章（唯一改變的是使用的數據中心）：
您需要再次檢查您的防火牆配置 - 以便您的內部伺服器的流量以正確的方式流出。