TLS 身份驗證問題：‘CompanyA@exmple.com ‘via’ SendGrid.me’ 電子郵件被 Exchange 丟棄
尋找有關此 Exchange 2007 命令行管理程序 (Powershell) 命令的作用以及它如何影響接收連接器上的 TLS 的說明：ms-exch-smtp-accept-authoritative-domain-sender
在我擔任系統管理員的公司，大約 3 個月前，我們幾乎每天都會收到“欺騙”電子郵件。這些“欺騙”電子郵件通常會將我們的 CEO 或域管理員作為“發件人”。為了緩解這種情況，我使用 Exchange 命令行管理程序 (Powershell) 命令將我們的預設 Exchange“網際網路”接收連接器設置為 DISallow anonymous (edit) RELAY，並創建了一個單獨的 RC 以允許使用一組列入白名單的 IP 進行匿名身份驗證 (帶掃描到電子郵件、持續聯繫等的異地複印機）。這奏效了，欺騙完全停止了。
但這是問題所在，現在似乎沒有人試圖“代表”或“通過”其他人發送任何東西可以通過電子郵件向我們發送電子郵件（除非他們通過第三方、SendGrid、Constant Contact 等驗證 TLS ）。我的印像是禁用匿名身份驗證僅適用於我們的組織，但它似乎也影響了所有外部各方（編輯：我現在知道這不是真的）。
編輯：經過大量評論；
更改ms-exch-smtp-accept-authoritative-domain-sender的值很有用，因為它也可以阻止您的伺服器充當活動中繼。這僅適用於您自己的組織。（在您的 Exchange 的 GUI 中列為權威的域）
伺服器通過阻止此類請求來按您的意願行事，因為該值使伺服器拒絕任何電子郵件**，因為發件人來自您的權威域**，MSExchange 通過其面向 Internet 的接收連接器進行管理。
現在，如果是未知使用者阻止的郵件，請驗證您的接收隊列以了解拒絕的根本原因。
在 Exchange Powershell 中發出類似的命令；
Get-AgentLog |?{ ($_.p1fromaddress -match “contoso.com” –or $_.p2fromaddresses -match ” contoso.com “) -and $_.action –eq “RejectMessage”}從那裡您將收到如下輸出：
時間戳：XXXX-XX-XX XX:XX:XX SessionId：XXXXXXXXXXXXXXXX IPAddress：XXXX MessageId：P1FromAddress：test@contoso.com P2FromAddresses：{test@contoso.com} 收件人：{test@contoso.com} 代理
：發件人 ID 代理事件：OnEndOfHeaders 操作：RejectMessage SmtpResponse：550 5.7.1 缺少聲稱的負責地址原因：MissingPRA ReasonData：沒有有效的 PRA 診斷：
從那裡檢查它被阻止的原因。如果代表是您管理的域，它當然會被拒絕，但電子郵件可能觸發了其他反垃圾郵件的規則。
現在，如果它來自您的使用者。為什麼他們不在辦公室或通過 vpn 時可能會使用該連接器？請為無法通過 VPN 連接的遠端使用者啟動 Active Sync。代表他人或從他人發送電子郵件是您在 Exchange 中授予的權利，因此，我猜那些使用者正在路上。當您的使用者不在辦公室或通過 VPN 連接時，使用可以通過 Active Sync 或 OWA 連接到您的伺服器的設備是管理這種情況的方法。
注意，下次請使用正確的單詞/拼寫，對我來說“禁用匿名身份驗證”是指將其從接收連接器上的 GUI 中刪除（不是您刪除的實際設置）謝謝！
您的設置包含一些錯誤；
在我擔任系統管理員的公司，大約 3 個月前，我們幾乎每天都會收到“欺騙”電子郵件。這些“欺騙”電子郵件通常會將我們的 CEO 或域管理員作為“發件人”。為了緩解這種情況，我將我們的預設 Exchange“網際網路”接收連接器設置為禁止使用 Exchange 命令行管理程序 (Powershell) 命令進行匿名身份驗證
那個時候你做錯事了。為了防止這種情況，您需要 SPF 記錄。（一個簡單的例子如何做到這一點）
因此，目前我仍然可以欺騙您的 CEO 電子郵件並直接向您的一位客戶發送電子郵件。
SPF 記錄確保對於您的域，發件人 IP 必須是發送它的人，否則他們知道這是一個惡搞。
發件人策略框架 (SPF) 是一個簡單的電子郵件驗證系統，旨在通過提供一種機制來檢測電子郵件欺騙，以允許接收郵件交換器檢查來自域的傳入郵件是否來自該域管理員授權的主機。1域的授權發送主機列表以特殊格式的 TXT 記錄的形式發佈在該域的域名系統 (DNS) 記錄中。垃圾郵件和網路釣魚通常使用偽造的“發件人”地址，因此發布和檢查 SPF 記錄可以被視為反垃圾郵件技術。
因此，要解決您的問題，請刪除您為創建 SPF 記錄所做的操作
之後應該會更好:)
對於您的接收連接器：
RC 允許使用一組列入白名單的 IP 進行匿名身份驗證（帶掃描到電子郵件的異地複印機、持續聯繫等）
我不明白為什麼它是接收連接器，而不是發送連接器？因此，您只是阻止了網際網路上的任何人向您發送合法電子郵件。埠 25 上面向網際網路的接收連接器應該對通過反垃圾郵件過濾的任何人開放。
請保持您的接收連接器打開，但如果需要，請保護您的發送連接器。