Trong trường hợp nào (nếu có), một bản ghi MX sẽ trỏ đến localhost?

Tôi nghĩ rằng hoàn toàn không có lý do hay biện minh nào cho việc này, nhưng trước khi tôi mở miệng và nhận được một số quản trị viên trong kim chi sâu, tôi nghĩ tôi nên hỏi.

Có bất kỳ trường hợp nào bản ghi MX nên trỏ đến địa chỉ loopback không? Đối với tôi, điều này nói rằng bất kỳ máy chủ thư nào cố gắng gửi đến miền này thay vào đó sẽ tự gửi và thất bại, nhưng tôi không phải là một chuyên gia về thư, vì vậy có lẽ tôi đang thiếu một cái gì đó.

Tôi đã xem qua phần bên dưới khi xử lý sự cố tại sao chúng ta không nhận được email ?? vấn đề cho một khách hàng, và tôi gặp khó khăn trong việc xoay quanh nó. Có lẽ tôi đang suy nghĩ quá nhiều.

Câu trả lời ngắn gọn: Không nên.

Câu trả lời dài: Nếu tên miền được đề cập (DIQ) không nên nhận email, thì việc đặt địa chỉ loopback cho bản ghi MX sẽ khiến máy chủ gửi cố gắng kết nối với chính nó. Điều này tiết kiệm cho DIQ một vài byte sởi và có thể xóa sạch các bản ghi tường lửa (nếu bất kỳ ai thậm chí đang xem) khi các máy chủ thư khác cố gắng kết nối. Tuy nhiên, theo tôi, việc tiết kiệm băng thông là không đủ để biện minh cho việc vi phạm RFC 3330.

Chắc chắn là KHÔNG, không phải với IP 127.0.0.0. Toàn bộ phạm vi 127.0.0.0 trên IPv4 hoạt động như địa chỉ loopback, do đó, khi bất kỳ máy nào kết nối với IP trong phạm vi đó, nó sẽ cố gắng kết nối với chính nó.

Địa chỉ IP bản ghi MX của bạn phải có thể truy cập được từ thế giới bên ngoài và kết quả đó đang nói với bất kỳ máy chủ nào thực hiện truy vấn MX, để thử kết nối với chính nó.

Nếu máy chủ của tôi đang cố gửi email cho bạn, nó sẽ tra cứu bản ghi MX và sau đó kết nối địa chỉ IP của chính nó, gửi email và không thành công.

Các RFC có liên quan nói:

• Bản ghi tài nguyên MX PHẢI trỏ đến một tên miền đủ điều kiện (không phải địa chỉ IP) của máy chủ trên Internet công cộng chấp nhận thư cho tên miền. Lưu ý rằng máy chủ này không nhất thiết phải ở cùng miền với bản ghi MX. RFC 1035 phần 3.3.9

• Địa chỉ trong phạm vi 127.0.0.0/8 KHÔNG PHẢI xuất hiện trên Internet công cộng. RFC 5735 phần 3

Lưu ý rằng một số máy chủ thư sẽ từ chối email từ người gửi không tuân thủ RFC có liên quan .

Khi một máy chủ lưu trữ phải có thể gửi thư đến chính nó trên các tên miền được lưu trữ khác nhau nhưng không chấp nhận thư bên ngoài, "MX 0 localhost." là chấp nhận được. Để chỉ ra rằng máy chủ không có máy chủ thư nào, hãy sử dụng "MX 0".

"MX 0." được trình bày chi tiết trong RFC7505 .

Chà, tôi có một tình huống đặt MX của miền thành localhost là cần thiết.

Vào tháng 3 năm 2012 tôi đã đăng ký một tên miền dễ thương mà tôi đã ngạc nhiên khi thấy có sẵn. Đó là cho một trang web hợp tác nghệ thuật mà con gái tôi muốn thiết lập. Tôi đặt MX thành một trong những máy chủ smtp khác của tôi. Điều này hoạt động tốt, nhưng sau đó tôi bắt đầu nhận được rất nhiều thư "người dùng không xác định" bị trả về xxx@cute-domain.com (không phải tên miền thực). Vì vậy, tôi đã sử dụng MailScanner để chặn tất cả các thư đến miền đó ngoại trừ một địa chỉ hợp pháp. Có vẻ như tên miền là một dịch vụ email miễn phí bắt đầu từ năm 2001 nhưng rõ ràng đã tối và từ bỏ tên miền dễ thương của họ.

Điều này hoạt động tốt cho đến một vài ngày trước (20/11/12) khi máy chủ smtp bắt đầu từ chối các tin nhắn đến do kết nối mở quá mức. Đây là những quá trình smtp đang chờ phản hồi "nhận được", tôi nghĩ vậy. Tôi đã xem xét lưu lượng truy cập và tôi đã bị bắn phá bởi hàng ngàn tin nhắn đến cho xxx@cute-domain.com từ nhiều rơle smtp trên toàn thế giới. (17.000 tin nhắn trong một khoảng thời gian 24 giờ)

Vì vậy, tôi đã thay đổi MX để trỏ đến một máy chủ khác không chạy smtp với cổng 25 bị chặn. Chắc chắn, hàng ngàn phiên thả đã bắt đầu hiển thị. Vì hành vi này trông giống như một loại torrent spam, có thể từ botnet, tôi đã hình dung rằng việc đặt MX thành localhost có thể được yêu cầu.

Tôi sẽ để nó như thế này trong một thời gian. Chúng tôi hoàn toàn không cần email cho cute.domain.com, vì vậy không có gì bị mất ngoại trừ chu kỳ cho botnet.

Tại sao không sử dụng mục tiêu MX mà không giải quyết bất cứ điều gì? Ví dụ:

ví dụ.com. Ở MX 10 gì đó.invalid.

Kẻ gửi thư rác sẽ thấy lỗi độ phân giải và không bận tâm với bản ghi MX tiếp theo, nghĩ rằng mục tiêu bị định cấu hình sai. Máy chủ thực sự sẽ thử bản ghi tiếp theo. Điều này sẽ không làm phiền cổng TCP đóng 25 của bất kỳ ai - tức là không có lưu lượng smtp, chỉ DNS.