400 tin nhắn 4.4.7 bị trì hoãn


8

Tuần trước Exchange 2010 đã hoạt động và tôi nhận thấy trong trình xem hàng đợi (trong bảng điều khiển trao đổi) rằng nó đang xuất hiện một vài email bị lỗi 400 4.4.7 message delayed.

Phản hồi kickback mà các thành viên của chúng tôi đang nhận được là:

Delivery is delayed to these recipients or groups:

XXX@aol.com (XXX@aol.com)

Subject: test

This message hasn't been delivered yet. Delivery will continue to be attempted.

The server will keep trying to deliver this message for the next 1 days, 19 hours and 54 minutes. You'll be notified if the message can't be delivered by that time.

Đây chỉ là một ví dụ cụ thể và có nhiều cho nhiều tên miền mà các địa chỉ email khác hoạt động (cho cùng một tên miền).

Chúng tôi sắp có thư được lọc qua bộ lọc của họ và sau đó vào máy chủ nhưng ngay bây giờ bản ghi MX trực tiếp vào máy chủ trao đổi của chúng tôi.

Có ai có bất kỳ ý tưởng về cách giải quyết điều này? Hoặc nếu di chuyển đến bộ lọc (do đó thay đổi địa chỉ bản ghi MX của chúng tôi sẽ chuyển sang) sẽ giải quyết vấn đề này?

Câu trả lời:


7

Có nhiều khả năng liên quan đến lỗi này. Lấy từ câu trả lời này của tôi cho một câu hỏi khác (nhưng được sửa đổi một chút):

Trước tiên, hãy thử thiết lập phiên SMTP với các máy chủ thư từ xa bằng telnet để xem bạn có thể nhận thêm thông tin nào không.

Cũng có khả năng một số loại quy tắc tường lửa kỳ quặc đã được đặt ở vị trí làm rơi, thay đổi hoặc điều chỉnh các gói đến hoặc từ một miền hoặc IP được liên kết với máy chủ từ xa. Không thể, nhưng tôi đã thấy những điều lạ. Kiểm tra tường lửa cổng của bạn cũng như tường lửa phần mềm của máy chủ Exchange để biết bất kỳ quy tắc nào có thể có liên quan đến máy chủ SMTP từ xa. Kiểm tra tên miền, IP và bất kỳ phạm vi địa chỉ nào có thể được liên kết với tên miền từ xa.

Một khả năng mỏng khác là miền từ xa có vấn đề về vùng DNS. Có thể hồ sơ MX của họ đã cũ. Có lẽ họ đã thực hiện di chuyển vùng nhưng không bao giờ di chuyển mọi thứ sang máy chủ DNS mới. Một lần nữa, những điều điên rồ hơn đã xảy ra.

Tuy nhiên, một khả năng khác là máy chủ nhận đang thực hiện tra cứu DNS ngược trên IP gửi của bạn và nó không khớp với các bản ghi MX của bạn. Nếu bản ghi MX của bạn trỏ đến 192.0.2.1, nhưng nó nằm sau tường lửa 192.0.2.2 và IP ảo được thiết lập trên tường lửa để chấp nhận 192.0.2.1, thì lưu lượng truy cập bên ngoài sẽ được xem là 192.0.2.1, nhưng RDNS sẽ hiển thị 192.0.2.2 dưới dạng máy chủ thư. Sự khác biệt đó có thể khiến một số máy chủ nhận từ chối thư theo nhiều cách khác nhau (mặc dù tôi hy vọng quản trị viên email người nhận sẽ không chặn các thư bị trả lại thông tin, thay vào đó chọn các thông báo lỗi chung).

(Như một lưu ý phụ, kiểm tra RDNS như trên là dại dột vì nhiều người đã xác thực các rơle cho email gửi đi và, do cần thiết, sẽ không khớp với máy chủ gửi đến. Quản trị viên email, đừng lười biếng!)

Cuối cùng, nhưng chắc chắn không kém, SỬ DỤNG SPF HỒ SƠ! DKIM cũng vậy. Bạn có thể thấy rằng nhiều vấn đề email tạm thời của bạn sẽ biến mất sau khi thiết lập đúng hai điều đó.

Tất nhiên, hãy nghe Shane Madden và kiểm tra hàng đợi thư của bạn .

Cuối cùng, hãy liên hệ với quản trị viên của miền từ xa và tìm hiểu với họ . Bạn có thể phải làm việc với họ để tìm ra vấn đề.


Cảm ơn câu trả lời! Tôi đã thực hiện các thử nghiệm tại testexchangeconnectivity.com và nhớ việc tra cứu DNS ngược khi quay lại chính xác.
Lbaker101

Cho đến khi chúng tôi nhận được bộ lọc email của mình (trong ngày hôm sau), bản ghi MX sẽ trực tiếp đến máy chủ trao đổi của chúng tôi thông qua một IP bên ngoài được chỉ định. ASA5505 thực hiện NAT Forwarding để trỏ địa chỉ này vào đúng địa chỉ nội bộ và các cổng tường lửa chính xác đã được mở để cho phép lưu lượng email đi qua. Tôi sẽ xem xét điều này nhiều hơn. Cảm ơn vì lời khuyên!
Lbaker101

3

Kiểm tra hàng đợi thư của bạn trong phần "Hộp công cụ" của bảng điều khiển quản lý trao đổi.

Bạn sẽ có thể đi sâu vào các lỗi cụ thể đang được tạo ra mỗi khi tin nhắn được gửi đi, điều này sẽ làm sáng tỏ nguyên nhân gốc rễ. Tìm một thông báo vấn đề cụ thể trong hàng đợi tên miền, sau đó nhấp chuột phải vào tin nhắn và mở thuộc tính; phần " Last Error" là những gì quan tâm.

Nguyên nhân có thể là do sự cố kết nối cổng 25 / tcp và độ phân giải DNS, nhưng hãy chỉnh sửa các lỗi bạn gặp phải nếu bạn vẫn gặp sự cố và chúng tôi có thể hỗ trợ xác định nguyên nhân gốc.


Danh tính: XXX-XXX \ 4269 \ 19930 Chủ đề: XXXX ID tin nhắn Internet: <8485BDE284F83A4EB411BC822A8F564EA3F8EC@EFC-XXX.XXX.local> Từ Địa chỉ: XX@XXX.com IP: 255.255.255.255 SCL: -1 Ngày nhận: 8/18/2011 6:53:04 AM Thời gian hết hạn: 8/20/2011 6:53:04 AM Lỗi cuối: 400 4.4.7 Tin nhắn bị chậm ID hàng đợi: XXX -XXX \ 4269 Người nhận: XXXw@XXX.com
Lbaker101

0

Nếu không có thêm thông tin thì điều này có vẻ không lạ. Một số máy chủ của người nhận thực hiện các kiểm soát giới hạn tốc độ ngăn chặn máy chủ của họ. Một số tin nhắn đi qua ngay lập tức những người khác phải chờ (và thử lại sau).

Nếu vấn đề này đúng với hơn 10% số thư của bạn thì bạn gặp vấn đề với độ phân giải DNS, tường lửa nội bộ hoặc các cài đặt mạng lạ khác ngăn luồng thư trên trang web của bạn .

Nhưng điều này hoàn toàn không có gì để làm với các cài đặt MX của bạn.


0

Một lưu ý khác, đặc biệt đối với tên miền aol.com, nếu công ty của bạn sẽ gửi nhiều thư cho họ (tôi không biết ngưỡng nào để họ bắt đầu đưa vào danh sách đen của bạn), bạn cần đăng ký tên miền với người liên hệ với bưu điện trang web này: http://postmaster.aol.com/Postmaster.Whitelist.php


-2

DNS được thiết lập trên máy chủ Exchange của tôi đã ngừng hoạt động. Tôi đã cố gắng ping một vài tên miền bị trì hoãn và không nhận được bất kỳ độ phân giải nào.

Tôi đã đi vào cài đặt mạng của mình trên máy chủ và cập nhật DNS chính và phụ.

Mọi thứ bắt đầu trôi chảy trở lại.

Hi vọng điêu nay co ich

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.