Nói tóm lại: các email hợp pháp đang hạ cánh trong các thư mục Rác vì EOP (Exchange Online Protection) đóng dấu thư email là rác (SCL5) và SPF-không thành công. Điều này xảy ra với tất cả các tên miền bên ngoài (ví dụ: gmail.com/hp.com/microsoft.com) cho miền của khách hàng (contoso.com).
Thông tin cơ bản:
Chúng tôi đang ở giai đoạn bắt đầu di chuyển hộp thư sang Office 365 (Exchange Online). Đây là cấu hình Hybrid Deployment / Rich-Coexistence, trong đó:
- Tại chỗ = Exchange 2003 (Di sản) & 2010 (Được cài đặt để triển khai kết hợp)
- Ngoài cơ sở = Office 365 (Trao đổi trực tuyến)
- EOP được cấu hình để kiểm tra SPF.
- Các bản ghi MX đang chỉ vào cơ sở vì chúng tôi chưa hoàn thành việc di chuyển tất cả các hộp thư từ tại chỗ sang Exchange Online.
Vấn đề là khi người dùng bên ngoài gửi email đến hộp thư Office 365 trong tổ chức (luồng thư: Bên ngoài -> Cổng thư -> máy chủ thư tại chỗ -> EOP -> Office 365), EOP thực hiện tra cứu SPF và cứng / mềm không gửi được thư có địa chỉ IP đối diện bên ngoài của Cổng thư mà từ đó nhận được thư.
(Hộp thư tại chỗ không hiển thị vấn đề này; chỉ có hộp thư được di chuyển sang Office 365 mới làm.)
Sự minh họa:
Ví dụ 1: từ Microsoft đến O365
Authentication-Results: spf=fail (sender IP is 23.1.4.9)
smtp.mailfrom=microsoft.com; contoso.mail.onmicrosoft.com;
dkim=none (message not signed) header.d=none;
Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate
23.1.4.9 as permitted sender) receiver=protection.outlook.com; client-ip=23.1.4.9;
helo=exchange2010.contoso.com; X-MS-Exchange-Organization-SCL: 5
Ví dụ 2: từ HP đến O365
Authentication-Results: spf=none (sender IP is 23.1.4.9)
smtp.mailfrom=hp.com; contoso.mail.onmicrosoft.com; dkim=none
(message not signed) header.d=none; Received-SPF: None
(protection.outlook.com: hp.com does not designate permitted sender hosts)
X-MS-Exchange-Organization-SCL: 5
Ví dụ 3: từ Gmail đến O365
Authentication-Results: spf=softfail (sender IP is 23.1.4.9)
smtp.mailfrom=gmail.com; contoso.mail.onmicrosoft.com;
dkim=fail (signature did not verify) header.d=gmail.com;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
gmail.com discourages use of 23.1.4.9 as permitted sender)
X-MS-Exchange-Organization-SCL: 5
Để biết các tiêu đề thư có X-Forefront-Antispam-Báo cáo, hãy tham khảo http://pastebin.com/sgjQETzM
Lưu ý: 23.1.4.9 là địa chỉ IP công cộng của trình kết nối máy chủ Exchange 2010 tại chỗ với Exchange Online.
Làm cách nào để chúng tôi ngăn chặn các email bên ngoài bị đánh dấu là rác bởi EOP trong giai đoạn cùng tồn tại của Triển khai kết hợp?
[Cập nhật 2015-12-12]
Sự cố này đã được khắc phục bởi hỗ trợ Office 365 (nhóm leo thang / phụ trợ) vì nó không liên quan gì đến cài đặt của chúng tôi.
Chúng tôi đã đề nghị như sau:
- Danh sách trắng công khai IP trong Danh sách cho phép EOP (Đã thử. Nó không giúp ích gì.)
- Thêm bản ghi SPF cho tên miền của chúng tôi: "v = spf1 ip4: XXX.XXX.XXX.XXX ip4: YYY.YYY.YYY.YYY bao gồm: spf.protection.outlook.com -all" (Đừng nghĩ đề xuất này là hợp lệ vì EOP không nên kiểm tra gmail.com đối với địa chỉ IP SMTP của chúng tôi vì nó không được chỉ định trong các bản ghi SPF của gmail.com. Điều đó dường như không giống như cách hoạt động của SPF.)
- Đảm bảo TLS được bật (Xem bên dưới)
Phần quan trọng là điểm thứ ba. "Nếu TLS không được bật, email đến từ Exchange cục bộ sẽ không được đánh dấu là email nội bộ / tin cậy và EOP sẽ kiểm tra tất cả các hồ sơ", bộ phận hỗ trợ cho biết.
Bộ phận hỗ trợ đã xác định sự cố TLS từ các tiêu đề thư của chúng tôi theo dòng dưới đây:
- X-MS-Exchange-OrganisAs: Ẩn danh
Điều này cho thấy TLS không được kích hoạt khi EOP nhận được email. EOP không coi email đến là email tin cậy. Câu trả lời đúng phải như sau:
- X-MS-Exchange-Organis-AuthAs: Internal
Tuy nhiên, điều này không phải do cài đặt của chúng tôi; người hỗ trợ đã giúp chúng tôi đảm bảo các cài đặt của chúng tôi là chính xác bằng cách xác minh nhật ký SMTP dài dòng từ máy chủ Exchange 2010 Hybrid của chúng tôi.
Đồng thời, nhóm phụ trợ của họ đã khắc phục sự cố mà không cho chúng tôi biết chính xác nguyên nhân gây ra sự cố (không may).
Sau khi họ sửa nó, chúng tôi thấy rằng các tiêu đề thư có một số thay đổi đáng kể như dưới đây.
Đối với thư có nguồn gốc nội bộ từ Exchange 2003 đến Office 365:
X-MS-Exchange-Organis-AuthAs: Internal (Đó là "Ẩn danh")
SCL = -1 (Đó là SCL = 5)
- Đã nhận-SPF: SoftFail (Tương tự)
Và đối với các thư bên ngoài (ví dụ: gmail.com) tới Office 365:
X-MS-Exchange-Organis-AuthAs: Chưa xác định (Nó giống nhau)
SCL = 1 (Đó là SCL = 5)
Đã nhận-SPF: SoftFail (Tương tự)
Mặc dù kiểm tra SPF vẫn không thành công đối với gmail.com (bên ngoài) đối với Office 365, nhưng người hỗ trợ cho biết điều đó vẫn ổn và tất cả các thư sẽ chuyển đến Hộp thư đến thay vì thư mục Rác.
Một lưu ý phụ, trong quá trình khắc phục sự cố, nhóm phụ trợ đã phát hiện một sự cố cấu hình có vẻ nhỏ - chúng tôi đã có IP từ Trình kết nối gửi đến (tức là IP công khai của máy chủ kết hợp Exchange 2010) được xác định trong Danh sách cho phép IP của chúng tôi (được đề xuất bởi hỗ trợ Office 365 khác người như một bước xử lý sự cố). Họ cho chúng tôi biết rằng chúng tôi không cần phải làm điều này và trên thực tế làm như vậy có thể gây ra sự cố định tuyến. Họ nhận xét rằng trên đường chuyền ban đầu, email không bị đánh dấu là thư rác nên cũng có một vấn đề có thể xảy ra ở đây. Sau đó chúng tôi đã xóa IP khỏi Danh sách cho phép IP. (Tuy nhiên, sự cố thư rác đã tồn tại trước khi cài đặt Danh sách cho phép IP được tạo. Chúng tôi không nghĩ Danh sách cho phép là nguyên nhân.)
Để kết luận, "nó nên là cơ chế EOP," người hỗ trợ nói. Do đó, toàn bộ điều nên được gây ra bởi cơ chế của họ.
Đối với bất kỳ ai quan tâm, có thể xem chủ đề khắc phục sự cố với một trong những người hỗ trợ của họ tại đây: https://community.office365.com/en-us/f/156/t/403396