IIS / SMTP - email bị kẹt trong mailroot / Hàng đợi

Tôi đang cố gắng gửi e-mail qua SMTP trong thư mục chọn IIS. Thật không may, các e-mail chỉ đi vào thư mục mailroot / queue và ở đó. Họ không bao giờ thực sự được gửi.

Có ai biết tại sao điều này sẽ xảy ra và một sửa chữa tiềm năng cho vấn đề?

Có một vấn đề tương tự với các tập tin bị mắc kẹt trong hàng đợi. Trong trình quản lý IIS, Máy chủ ảo SMTP> Thuộc tính> Delievery> Kết nối ngoài. Tùy chọn cho Limit number of connections tođã được kiểm tra và giá trị là 0. Vì vậy, nó được cấu hình để không bao giờ thực hiện bất kỳ kết nối ngoài nào, khiến các email không bao giờ rời khỏi máy chủ. Tôi đã bỏ chọn tùy chọn và khởi động lại máy chủ SMTP và tất cả đều ổn.

Tôi đã có vấn đề này ngày hôm nay.

Sau khi khởi động lại dịch vụ 'Giao thức chuyển thư đơn giản (SMTP)', nó bắt đầu hoạt động trở lại.

Chỉ để ghi lại: chúng tôi đã gặp trường hợp máy chủ không thể giải quyết tên nữa do cài đặt DNS không đúng. Hành vi kết quả chính xác là hành vi mà bạn mô tả.

IISRESET đã sửa lỗi này cho tôi. Tôi tin rằng nó tương tự như giải pháp đặt lại dịch vụ SMTP vì dịch vụ này phụ thuộc vào IIS. Sau khi nó khởi động lại, thư bên trong C: \ inetpub \ mailroot \ Queue bắt đầu biến mất!

Tôi gặp vấn đề này gần đây. Trong trường hợp của tôi, hóa ra đó là một vấn đề với định nghĩa máy chủ DNS trong bộ điều hợp mạng (điều này có hai lý do không biết đối với tôi). Máy chủ DNS được chỉ định được đặt thành "127.0.0.1" thay vì "8.8.8.8" thông thường thường được sử dụng trên mạng này. Tôi đã thay đổi giá trị này thành giá trị chính xác, khởi động lại máy chủ SMTP của tôi và các email được xếp hàng ngay lập tức được phân phối.

Làm thế nào tôi tìm ra điều đó để xem xét vấn đề định nghĩa DNS:

• Đã sử dụng nslookup để tìm máy chủ mx để kiểm tra (đã kiểm tra 5 hoặc 6 cái khác nhau)
• Đã thử telnet đến máy chủ (mỗi lần gặp thông báo "không thể kết nối" khiến tôi ban đầu nghĩ về các vấn đề về tường lửa)
• Đã thử ping giá trị cho máy chủ mx đã kiểm tra (mỗi lần gặp thông báo "không thể kết nối với máy chủ")

Hy vọng rằng điều này sẽ giúp người khác, không phải là điều mà tôi đã nghĩ để xem xét ban đầu.

Theo kinh nghiệm của tôi, điều này thường là do IIS SMTP đang cố gửi và gặp lỗi tạm thời (mã phản hồi 4xx). Bạn đã bật đăng nhập dịch vụ IIS SMTP và xem lại nhật ký chưa? Xin lỗi nếu đó là tất cả rõ ràng, nhưng thật khó để biết nguyên nhân hoặc cách khắc phục mà không biết nhật ký cho thấy gì.

Tôi nghĩ vấn đề có thể là có sự nhầm lẫn giữa IPv4 và IPv6 trên hệ thống, vì vậy khi bạn chỉ định localhost, giao thức IPv6 mặc định được chọn. Tôi đã gặp vấn đề tương tự ngày hôm nay và nó đã được sửa sau khi tham chiếu localhost đến địa chỉ IPv6 trong máy chủ được băm ra, mặc dù đó có thể là một sự trùng hợp ngẫu nhiên (tôi cũng đang thiết lập SVN). Vì vậy, đây là thiết lập của tôi chỉ trong trường hợp:

1. Trong IIS7, tôi có tùy chọn "Phân phối đến máy chủ SMTP" được bật với localhost làm máy chủ được chọn.
2. Trong IIS6 tôi có quyền truy cập được đặt thành chỉ 127.0.0.1, không có xác thực cho việc đến hoặc đi.

Tôi loay hoay với các thiết lập cả ngày, vì vậy, thành thật mà nói, không chắc điều gì khác có thể ảnh hưởng đến thực tế là nó đang hoạt động. Hy vọng điều này sẽ giúp ít nhất một chút mặc dù.

Nơi đầu tiên để tìm là các tệp nhật ký máy chủ. Điều này sẽ cho bạn biết nếu máy chủ của bạn gặp sự cố khi gửi đến các máy chủ cụ thể. Phần lớn thời gian điều này xảy ra (theo kinh nghiệm của tôi) thường là DNS (ở đầu của bạn hoặc từ xa) là thủ phạm.

Máy chủ SMTP đang tìm kiếm một máy chủ / cổng SMTP để gửi thư đến.

Nếu bạn đang cố gắng gửi đến localhost, thì IP localhost sẽ là cổng. Nếu bạn đang cố gắng gửi đến một địa chỉ email bên ngoài như gmail hoặc hotmail, bạn sẽ cần thêm cổng thư của ISP làm máy chủ thông minh.

Để thiết lập một máy chủ thông minh:

1. Trong Trình quản lý IIS, bấm chuột phải vào máy chủ ảo SMTP, rồi bấm Thuộc tính.
2. Bấm vào tab Giao hàng và bấm Nâng cao.
3. Trong hộp Máy chủ thông minh, nhập tên của máy chủ lưu trữ thông minh. Bạn có thể nhập một chuỗi để thể hiện tên hoặc nhập địa chỉ IP.
4. Nếu bạn muốn dịch vụ SMTP cố gắng gửi tin nhắn từ xa trực tiếp trước khi chuyển tiếp chúng đến máy chủ lưu trữ thông minh, hãy chọn hộp kiểm Thử gửi trực tiếp trước khi gửi đến hộp kiểm máy chủ thông minh. Mặc định là gửi tất cả các tin nhắn từ xa đến máy chủ thông minh, không cố gửi trực tiếp.

Tôi gặp vấn đề tương tự sau khi chuyển dịch vụ email từ máy chủ này sang máy chủ khác (máy chủ mới là Office 365). Sau rất nhiều thử nghiệm và sai sót, cuối cùng nó đã bắt đầu hoạt động bằng cách làm điều này:

1. Thêm tên miền email của tôi vào IIS 6 dưới dạng tên miền "từ xa". (Đây là tên miền được lưu trữ trong O365 và tất cả tài khoản người dùng sử dụng.)
2. Trong IIS 6, bấm đúp vào tên miền đó; trong "Định tuyến tên miền", chọn "Chuyển tiếp tất cả thư đến máy chủ thông minh" và nhập máy chủ của bạn (trong trường hợp của tôi, "smtp.office365.com"). Đồng thời đánh dấu vào ô "Cho phép thư đến được chuyển tiếp đến miền này."
3. Trong IIS 6, bấm chuột phải vào máy chủ ảo SMTP> Thuộc tính.
   • Tab Chung: Nhấp vào Nâng cao và thêm IP máy chủ cục bộ của bạn và cổng 587
   • Tab truy cập: đảm bảo "Yêu cầu mã hóa TLS" được chọn. Tôi đã phải tạo một chứng chỉ miền trong IIS 7 với tên miền email của tôi.
   • Tab truy cập: Thêm IP máy chủ cục bộ của bạn vào danh sách "Kết nối" và "Chuyển tiếp".
   • Tab phân phối: Bảo mật gửi đi: chọn xác thực cơ bản, nhập thông tin đăng nhập của người dùng được cấp phép hợp lệ; đánh dấu vào ô "mã hóa TLS"
   • Tab phân phối: Kết nối đi: Nhập 587 cho cổng TCP
   • Tab phân phối: Nâng cao: Nhập tên miền email của bạn dưới dạng "Tên miền đủ điều kiện" và máy chủ email của bạn dưới dạng "Máy chủ thông minh" (một lần nữa trong trường hợp của tôi là smtp.office365.com).

Tường lửa: Tôi đã đọc rằng bạn cần mở cổng 587 cho hướng ngoại. (Tôi đã không làm thế bởi vì đây là máy chủ VOIP cần tắt tường lửa.)

Office 365: Thêm "trình kết nối" trong Quản trị viên> Trao đổi để cho phép IP tĩnh cục bộ của bạn. Microsoft cung cấp các hướng dẫn trực tuyến.

Chạy vào vấn đề này gần đây. Ai đó đã cài đặt MalwareBytes lên máy chủ smtp và các thư mục mailroot smtp không được đưa vào danh sách trắng. Phần mềm coi tất cả mọi thứ trong hàng đợi là một chiến dịch spam tiềm năng và để nó hết thời gian đủ để nó chuyển sang badmail. Tất cả các lĩnh vực đã bị ảnh hưởng. Tôi đã bối rối (hoạt động hoàn hảo trong nhiều năm nay ..) cho đến khi tôi nhìn vào các quy trình đang chạy và nhận thấy exe của mbam.

Tôi gặp vấn đề tương tự. Như những người khác tuyên bố nó có liên quan đến DNS. Tôi có một khu vực tra cứu chuyển tiếp trên các máy chủ DNS nội bộ của chúng tôi cho tên miền công cộng của chúng tôi (khác với tên miền nội bộ của chúng tôi). Tôi đã phải thêm các bản ghi MX trên vùng tra cứu chuyển tiếp nội bộ này để khớp với các bản ghi MX trên các bản ghi DNS miền công cộng của chúng tôi. Điều này đã giải quyết vấn đề.